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

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

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).

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.

> 
> > 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