Subject: Re: [dhcwg] I-D Action:draft-narten-dhc-duid-uuid-00.txt

From: Jarrod Johnson <[email-masked]>
Date: Wed, 23 Jun 2010 15:05:51 -0400

So what is the next logical step?  I'm unfamiliar with how this works (i.e.
when the 'tbd' duid type number should get set, etc etc)

On Mon, May 31, 2010 at 12:51 PM, Ted Lemon <[email-masked]> wrote:

> On May 31, 2010, at 6:15 AM, Jarrod Johnson wrote:
> > Making firmware manage arbitrary DUID storage would be an approach that
> is theoretically a way of getting at the same goal, DUID-UUID is a means to
> reuse a particular piece of info already central to many standards (at least
> on x86) that happens to exhibit the characteristics that are desired in a
> DUID
>
> Right, that makes sense.
>
> In any case, the main intention of the language on DUIDs in RFC3315 was to
> make sure that they had certain characteristics: persistence and uniqueness.
>   Any DUID that has these qualities is perfectly fine from the perspective
> of RFC3315.   The only reason _not_ to allow a new DUID for which someone
> has a clear use case is that it doesn't have these qualities.   So this
> proposal seems reasonable to me.
>
>