Subject: Re: [dhcwg] I-D Action: draft-templin-duid-ipv6-01.txt

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 15 Jan 2021 15:39:44 +0000

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:[email-masked]]
> Sent: Friday, January 15, 2021 6:48 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Simon Hobson <[email-masked]>; dhcwg <[email-masked]>; IPv6 List <[email-masked]>
> 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 <[email-masked]> On Behalf Of Simon Hobson
> Sent: Friday, January 15, 2021 9:08 AM
> To: dhcwg <[email-masked]>; IPv6 List <[email-masked]>
> Subject: Re: [dhcwg] [EXTERNAL] Re: I-D Action: draft-templin-duid-ipv6-01.txt
> 
> Templin (US), Fred L <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 15 Jan 2021 15:49:52 +0000

Fred:

You are clearly not answering our questions. As I said, put DUID-EN aside. Why are the others not usable. Under what conditions should a DHCP client implementer use DUID-V6ADDR (and under what conditions MUST NOT it be used).

There are clear reasons for having the various forms we do have and there are statements as to when a particular one must not be used.

We could have many more DUID types, but we don't because there have to be clear reasons to have a new type ... and for that you need to explain why the existing types CANNOT be used and thus a new type is REQUIRED. This is why the bar for defining a new type was Standards Actions - we wanted it to be very high so that it is fully clear as to when one type should be used over another.

For example, if you said well my interfaces have no "link-layer addresses", that would rule out DUID-LL and DUID-LLT. It does leave DUID-UUID (and DUID-EN - but we can put that aside). So, perhaps then there's a reason why DUID-UUID cannot be used (perhaps no storage in which to record this). This then would mean none of the (-LL, -LLT, -UUID) could work.

But just to say "hey, I have an idea to use this for a DUID" isn't sufficient without the details of why it is REQUIRED and none of the existing types can be used.

- Bernie

-----Original Message-----
From: Templin (US), Fred L <[email-masked]> 
Sent: Friday, January 15, 2021 10:40 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Simon Hobson <[email-masked]>; Ted Lemon <[email-masked]>; dhcwg <[email-masked]>; IPv6 List <[email-masked]>
Subject: 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.

> 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
> 
> > time. But, RFC8415 clearly shows that multiple DUID types are 
> > defined and that new ones can be added through future standards action.
> 
> 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.
> 
> 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
> 
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 15 Jan 2021 15:58:23 +0000

Bernie - go read my previous message responses. My text entered previously was
not intended to be "write-only"; it was intended to be read and commented on also.

Fred

> Sent: Friday, January 15, 2021 7:50 AM
> Subject: [EXTERNAL] RE: I-D Action: draft-templin-duid-ipv6-01.txt
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 
> Fred:
> 
> You are clearly not answering our questions. As I said, put DUID-EN aside. Why are the others not usable. Under what conditions
> should a DHCP client implementer use DUID-V6ADDR (and under what conditions MUST NOT it be used).
> 
> We could have many more DUID types, but we don't because there have to be clear reasons to have a new type ... and for that you
> need to explain why the existing types CANNOT be used and thus a new type is REQUIRED. This is why the bar for defining a new type
> was Standards Actions - we wanted it to be very high so that it is fully clear as to when one type should be used over another.
> 
> For example, if you said well my interfaces have no "link-layer addresses", that would rule out DUID-LL and DUID-LLT. It does leave
> DUID-UUID (and DUID-EN - but we can put that aside). So, perhaps then there's a reason why DUID-UUID cannot be used (perhaps no
> storage in which to record this). This then would mean none of the (-LL, -LLT, -UUID) could work.
> 
> 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
> 
> > 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.
> >
> > 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.
> >
> > 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.
> >