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

["Pascal Thubert (pthubert)" <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo