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

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