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
