Hi Pascal, On Thu, Feb 06, 2020 at 12:13:43PM +0000, Pascal Thubert (pthubert) wrote: > Hello Benjamin > > <truncated again, retrying> > > 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! > 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. Thanks! > > > > > 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? [covered above] > > > > > > > > > > > > > > > > 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 "backward compatibility with" is easy to misparse, so maybe add a comma, or go with "backward compatibility but adds the capability"? -Ben > 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
