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
