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

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

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 <[e-mail]> On Behalf Of Benjamin Kaduk
> Sent: jeudi 6 février 2020 18:31
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: [e-mail]; [e-mail]; The IESG
> <[e-mail]>; Shwetha Bhandari (shwethab) <[e-mail]>;
> [e-mail]
> 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 <[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.
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo