Maybe like this?
Regards, Pascal > Le 6 févr. 2020 à 10:48, Pascal Thubert (pthubert) <[email protected]> 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 <[email protected]> >> Sent: mercredi 5 février 2020 22:20 >> To: Pascal Thubert (pthubert) <[email protected]> >> Cc: The IESG <[email protected]>; [email protected]; Shwetha Bhandari >> (shwethab) <[email protected]>; [email protected]; [email protected] >> 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 _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
