Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 06 February 2020 21:05 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A8412022A; Thu, 6 Feb 2020 13:05:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob5TLrlhCEet; Thu, 6 Feb 2020 13:05:24 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C54120805; Thu, 6 Feb 2020 13:05:23 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 016L5G4k009379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 6 Feb 2020 16:05:18 -0500
Date: Thu, 6 Feb 2020 13:05:15 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: "draft-ietf-6lo-ap-nd@ietf.org" <draft-ietf-6lo-ap-nd@ietf.org>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, The IESG <iesg@ietf.org>, "Shwetha Bhandari (shwethab)" <shwethab@cisco.com>, "6lo@ietf.org" <6lo@ietf.org>
Message-ID: <20200206210515.GC14382@kduck.mit.edu>
References: <MN2PR11MB3565552065F2F21DD481EEC3D8000@MN2PR11MB3565.namprd11.prod.outlook.com> <20200204030143.GB53329@kduck.mit.edu> <MN2PR11MB35658E5BA1A1DF2BBA232F2DD8030@MN2PR11MB3565.namprd11.prod.outlook.com> <MN2PR11MB3565284DDAB5F7D94CB2F039D8030@MN2PR11MB3565.namprd11.prod.outlook.com> <20200205212015.GC84913@kduck.mit.edu> <MN2PR11MB3565D8C850C5238B162C4C6FD81D0@MN2PR11MB3565.namprd11.prod.outlook.com> <MN2PR11MB35653A3E6D9D20432F2A5D78D81D0@MN2PR11MB3565.namprd11.prod.outlook.com> <20200206173042.GB14382@kduck.mit.edu> <MN2PR11MB356593FE046B0BFAFC8CDC82D81D0@MN2PR11MB3565.namprd11.prod.outlook.com> <850EE9B8-C5A8-4F65-AE30-BC480651B2AA@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <850EE9B8-C5A8-4F65-AE30-BC480651B2AA@cisco.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/RRb-DHcMgy3KH7qONzxkct28aYc>
Subject: Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2020 21:05:26 -0000

Yes, just for the JWK encoding (so, the Wei25519 curve, IIUC).

Moving that IANA registration from the LWIG doc to here would keep us from
blocking on that document, yes -- I forgot that it was only in "AD
Evaluation" state and thought it was further along.

-Ben

On Thu, Feb 06, 2020 at 06:32:04PM +0000, Pascal Thubert (pthubert) wrote:
> Oh it’s the JWK encoding, right?
> 
> Would we speed things up if we just imported the IANA section from the LWIG draft?
> 
> 
> Regards,
> 
> Pascal
> 
> > Le 6 févr. 2020 à 19:09, Pascal Thubert (pthubert) <pthubert@cisco.com> a écrit :
> > 
> > Hello Benjamin
> > 
> > 
> >> "backward compatibility with" is easy to misparse, so maybe add a comma, or
> >> go with "backward compatibility but adds the capability"?
> > 
> >>> We're getting there.  I snipped the places were we appear to have converged.
> >>> 
> >>> Please let me know if the DISCUSS is now solved (we removed all ambiguity
> >> on the crypto-ID and forced that a key is employed uniquely for the purpose of
> >> this draft and for one crypto-ID).
> >> 
> >> I think the technical aspects are all resolved and there just remains the tiniest
> >> of process nits.  Specifically, in order to use some of the algorithms we define
> >> in the protocol we define, we rely on the IANA codepoints currently requested
> >> to be registered by [CURVE-REPRESENTATIONS].
> >> So we have a normative dependency on those registrations being made, but
> >> right now [CURVE-REPRESENTATIONS] is listed as only an informative
> >> reference, so there's not anything that will enforce the sequencing of
> >> publication.  It's probably easiest to promote that reference to being normative
> >> and make a note (either near Table 2 or in the IANA
> >> considerations) that we rely on the codepoints being registered by [CURVE-
> >> REPRESENTATIONS].
> >> 
> >> Sorry to be so picky!
> >> 
> > 
> > 
> > I'm happy to do the changes though it will delay a spec that 802.11 is waiting for.
> > But I fail to understand why we depend on a COSE or a JOSE registry to compute our signature.
> > 
> > What do I miss?
> > 
> > 
> >>> But I guess it does not hurt to clarify a little bit. Maybe by
> >>> changing the first paragraph of section 3 as "
> >>>   Section 5.3 of [RFC8505] introduces the ROVR that is used to detect
> >>>   and reject duplicate registrations in the DAD process.  The ROVR is a
> >>>   generic object that is designed for backward compatibility with the
> >> 
> >> "backward compatibility with" is easy to misparse, so maybe add a comma, or
> >> go with "backward compatibility but adds the capability"?
> > 
> > I favor the comma over the "but" since it is not antagonistic (maybe my French?).
> > What about
> > 
> > "
> >   Section 5.3 of [RFC8505] introduces the ROVR that is used to detect
> >   and reject duplicate registrations in the DAD process.  The ROVR is a
> >   generic object that is designed for both backward compatibility and
> >   the capability to introduce new computation methods in the future.
> > "
> > 
> > ?
> > 
> > : )
> > 
> > Pascal
> >> 
> >>>   capability to introduce new computation methods in the future.  Using
> >>>   a Crypto-ID per this specification is the RECOMMENDED method.
> >>>   Section 7.3 discusses collisions when heterogeneous methods to
> >>>   compute the ROVR field coexist inside a same network.
> >>> "
> >>> Is that readable?
> >>> 
> >>> I'll publish this with the changes suggested by Roman
> >>> 
> >>> Thanks a million!
> >>> 
> >>> Pascal
> >> 
> >> _______________________________________________
> >> 6lo mailing list
> >> 6lo@ietf.org
> >> https://www.ietf.org/mailman/listinfo/6lo