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) <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
