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

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

Maybe like this?


Regards,

Pascal

> Le 6 févr. 2020 à 10:48, Pascal Thubert (pthubert) <[e-mail]> a écrit :
> 
> Hello Benjamin
> 
> 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).
> 
> More below:
> 
>> -----Original Message-----
>> From: Benjamin Kaduk <[e-mail]>
>> Sent: mercredi 5 février 2020 22:20
>> To: Pascal Thubert (pthubert) <[e-mail]>
>> Cc: The IESG <[e-mail]>; [e-mail]; Shwetha Bhandari
>> (shwethab) <[e-mail]>; [e-mail]; [e-mail]
>> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with
>> DISCUSS and COMMENT)
>> 
>>> On Tue, Feb 04, 2020 at 02:22:23PM +0000, Pascal Thubert (pthubert) wrote:
>>> This was truncated when I received the echo, retrying...
>> 
>> It appears different here as well; interesting.
>> I will remove a layer of quoting to make it easier for me to write a reply.
>> 
>>> Hello Benjamin
>>> 
>>> Whao, that was quick. Many thanks again!
>>> 
>>> I got a comment on the change to BCP201 and looked it up. Seems there
>>> was a confusion, BCP 201 is RFC 7696 not RFC 7748. So I rolled back
>>> the overload. Did you expect something else?
>> 
>> I think I did expect something else; I thought I wrote:
>> 
>> % It's probably better to cite RFC 7696 as BCP 201 directly.
>> I guess maybe there was a copy/paste glitch.
> 
> Oups then : ) I changed the reference, also for BCP 26.
> 
>> 
>>> I'm publishing 17 for the delta below, we still have the 3 open
>>> points. Please check the diffs at
>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-
>>> 17.txt
>>> 
>>> More below:
>>> 
>>>>> Why do we need to allow ambiguity/flexibility as to the point
>>>> representation
>>>>>> within a given Crypto-Type value (as opposed to fixing the
>>>>>> representation
>>>> as a
>>>>>> parameter of the Crypto-Type)?  Alternately, what does
>>>> "(un)compressed"
>>>>>> mean, as it's not really clarified directly?  Furthermore, Table
>>>>>> 2 lists an "(un)compressed" representation for type 0 (over
>>>>>> P-256), but RFC 7518
>>>> notes
>>>>>> that the compressed representation is not supported for P-256
>>>>>> (Section 6.2.1.1).  I also am not finding the needed codepoints
>>>>>> registered in the
>>>> JOSE
>>>>>> registries to use ECDSA25519 (crypto-type 2) -- do we need to
>>>>>> register anything there?
>>>>> 
>>>>> Let us take this one separately in a thread with the co authors
>>> 
>>> I keep this item in the thread, to track that it's progressing
>>> separately
> 
> Please consider the changes in  https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-18.txt 
> Did we clear the DISCUSS?
> 
> 
> 
>>> 
>>> 
>>>> 
>>>> Perhaps it goes without saying (as part of DAD), but the 6LBR has to
>>>> consult its database of ROVR/IP address to determine what response
>>>> to give in the DAC.  Part of my question above was about what state
>>>> the 6LBR needs and what verification the 6LBR does as part of the
>>>> process
>>>> -- am I correct that it's just checking whether (1) the requested
>>>> address is already registered and (if so) (2) that the ROVR in the
>>>> EARO matches the one registered with the requested address?
>>> 
>>> Yes, per RFC 8505, inherited from RFC 6775. I'd say that DAD expressed
>>> as you did is the core function of RFC 6775.
>>> This draft does not really change the 6LBR, just adds the capability
>>> to stimulate a revalidation by the 6LR.
>> 
>> It sounds like it does go without saying :) Thanks for confirming.
> 
> This draft is really an extension of RFC 8505 and cannot be implemented separately.
> 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
>   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