Re: I-D Action: draft-templin-duid-ipv6-01.txt

It is clear from these last three that people are not reading all of my responses; especially
those in response to Bob Hinden's questions where the use case is clearly explained.
Perhaps you are hoping that by asking the same question over and over again I will give
a different answer. Please go back and read *all* of the posts; it is not a good use for
any of our time for me to repeat myself over and over again.

Fred

PS Bernie and Ted - I have already explained why DUID-EN was considered but found
to be too cumbersome and a DOWNREF.

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:volz@cisco.com]
> Sent: Friday, January 15, 2021 6:48 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Simon Hobson <linux@thehobsons.co.uk>uk>; dhcwg <dhcwg@ietf.org>rg>; IPv6 List <ipv6@ietf.org>
> Subject: RE: [dhcwg] Re: I-D Action: draft-templin-duid-ipv6-01.txt
>
> Fred:
> 
> I agree with Simon.
> 
> You have not explained why you cannot use one of the existing methods - even putting aside DUID-EN. Why can you not use DUID-LL,
> DUID-LLT, or DUID-UUID?
> 
> And, with DUID-EN, you can do whatever you want without anyone's input - of course, whether that usage is a good idea is a separate
> question. Yes, it may have a few additional bytes more than DUID-V6ADDR, but that hardly seems like a useful argument at this point
> as we still don't know why this is better than the existing DUID types for a STANDARDIZED type.
> 
> I still see no text in the 00 or 01 draft about why you need this over the existing methods - i.e., why none of the existing methods will
> work.
> 
> The other thing about a standardized DUID is that you have to assure it is not misused or misunderstood how it should be used. So,
> you need to be clear about when it MAY be used and when it MUST NOT be used.
> 
> - Bernie
> 
> -----Original Message-----
> From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of Simon Hobson
> Sent: Friday, January 15, 2021 9:08 AM
> To: dhcwg <dhcwg@ietf.org>rg>; IPv6 List <ipv6@ietf.org>
> Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
> 
> Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> 
> >> No. I questioned the purpose of having an IPv6 address in something that’s supposed to be an opaque identifier.
> >
> > And, I said that if it were *truly* opaque to *all* examinations and
> > references, then there would only ever be *one* DUID type for all
> > time. But, RFC8415 clearly shows that multiple DUID types are defined
> > and that new ones can be added through future standards action.
> 
> Ah, you are starting from a false premise there.
> 
> Just because something is opaque and never ever (in theory) used in any way other than "X == Y" doesn't mean there's no reason to
> only ever have one method of creating it.
> As the idea of DUID is that it should be globally unique, ideally the method used to create it should have the most sources of entropy
> possible. But different devices have different constraints. That's why we have LL and LLT since adding time of creation to the pot adds
> entropy, thus making LLT 'better' than LL, but some devices don't have a clock (and possibly, no persistent storage) making LLT
> unfeasible for them - i.e. LL is inferior to LLT, but real world constraints make it necessary.
> 
> So here the difference between LL and LLT is easy to see, as are the constraints that might force you to use the inferior one.
> 
> What people are asking you is : what makes this proposal so much better than what's already allowed, given that's what's in there is
> supposed to be opaque and so "it's an IPv6 address" has no bearing on it's "goodness" as a unique identifier. And more specifically,
> why is it better than an RFC4122 UUID as defined in RFC6355 - 'better' meaning sufficiently better to justify adding to the global code
> base required to support it.
> 
> Both are 16 octets/128 bits long, both are intended to be globally unique, both require persistent storage available to early boot
> loaders. So why is the proposed 128bit value better than the already defined 128bit value ?
> 
> Simon
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg