Hello again Benjamin Provided we make the change, would a sentence like
" This specification depends on [CURVE-REPRESENTATIONS] to install the necessary codepoints in IANA registries for some of the listed curves above. " Work for you? Many thanks again and again! Pascal > -----Original Message----- > From: 6lo <[email protected]> On Behalf Of Benjamin Kaduk > Sent: jeudi 6 février 2020 18:31 > To: Pascal Thubert (pthubert) <[email protected]> > Cc: [email protected]; [email protected]; The IESG > <[email protected]>; Shwetha Bhandari (shwethab) <[email protected]>; > [email protected] > Subject: Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with > DISCUSS and COMMENT) > > 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 _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
