Re: [dhcwg] Eric Rescorla's No Objection on draft-ietf-dhc-rfc3315bis-10: (with COMMENT)

[Michael Richardson <[e-mail]>]

    ekr>    The benefit is that you have a pile of different mechanisms which
    ekr> are redundant. This would simplkify that.

    ted>    Except that this is a -bis document, so the mechanisms don't go away
    ted> with this optimization, and the optimization itself is actually more
    ted> work than doing what the document currently specifies, since the server
    ted> doesn't care which option you pick, and the client is going to pick
    ted> exactly one.

What Ted said (at most we can deprecate features, but not unify some features
into a new feature.  There is an xkcd for that...)... but also: the DUID
generation is essentially a local client matter, so this multiplicity of
formats does not really affect the protocol or require any extra code.

Servers can and do treat all DUIDs as opaque blobs of bytes, and that's it.
(Mine does this.)

Some DUID formats can elucidate more info for the servers and operators that
care, but as the trend on clients (dnsmasq, I think) is towards feeding
some stuff into a hash function and saving the result for later on.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [




--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-