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

[Mark Stapp <[e-mail]>]

Bharat,
I originally introduced the reference to DUID to address a need that did seem 
real to me. it seemed reasonable to describe a couple of ways an admin might 
come up with an identifier. one possibility was "make one up - use a string that 
means something to you in your network." another possibility was "ask the device 
to generate an id that's got a really good chance of being robust and unique." I 
pointed to the DUID-generating algorithm as an example.

I do think it would/will be helpful if a device acting as a relay were willing 
to generate a relay-id. but I don't think that's an interoperability issue - it 
can always be a vendor value-add. all that's necessary is that the ids be 
administratively unique.

-- Mark

On 6/14/11 12:46 PM, Bharat Joshi wrote:
>> Regarding the DUID, that is a complex issue and question. For a device
>> with storage, if you moved the storage to another device, it would
>> retain the DUID. So, the DUID is not really something that is hardwired
>> in this case. Of course, this really only applies to DUID-LLT as that is
>> the only type that needs to be stored. (The other types are generated
>> from 'hardwired' data and thus need no storage.)
>>
>>
>> I really don't see why you don't do both?
> Actually we end up removing DUID from the draft because we could not find a use-case for DUID as relay-id.
>
> The two use-cases in this draft needs an administratively configured relay-id.
>
> Can you think of any scenario where a DUID relay-id could be useful?