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

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

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