Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt

[Ted Lemon <[e-mail]>]

On Jun 13, 2011, at 6:38 AM, Mark Stapp wrote:
> on the issue of the use of DUID, there's a disagreement. I understood Ted to say that he objected very strongly to any text that proposed 'moving' a DUID from one device to another, or administratively managing DUIDs. I'll let Ted speak for himself, of course, but that's a fundamental issue for this draft.

No, what I objected to was moving unique identifiers from device to device.   If you have a unique identifier, it identifies a device.   If you start moving it around, it loses that property.   The right way to use unique identifiers is to have a mapping between the identifier and whatever role it is that you want to assign to the thing that has been uniquely identified.

What you proposed, which I didn't particularly like, was simply putting the role identifier on the device.   The only reason I didn't like it is that it means we need to define some other identifier that's a unique identifier.  Perhaps a better way to put it is that I thought you were trying to uniquely identify the device, but it later turned out that that was not the case--you merely wanted to identify its role.

I still think it's better to uniquely identify the device, and have a central map between device identity and role.   But I agreed with you that if you really intended the semantics of the option to be that identifies the role of the device, and not the device, I would be okay with that.

However, if the identifier is a role identifier, and not a unique identifier, then you shouldn't use the term "UUID" to describe it, nor should you put a UUID in it, because in doing so you turn the UUID into a non-unique identifier.   And you shouldn't use a DUID, because a DUID is essentially a DHCP-specific UUID.

So yes, I object very strongly to defining an identifier that is "unique" but also might be transferred from device to device.   If you take away the uniqueness, I think what you're left with isn't useful to me, but I don't object to you defining it if it's useful to you.

I would also say that this is another reason why this ought not to be an option with a "type" field.   The option as Mark was defining it was going to have a very constrained function.   It wasn't going to be a unique identifier.   So the idea that it would be extended to support new identifier types in the future doesn't make a whole lot of sense to me.