Re: [dhcwg] draft-ietf-dhc-dhcpv6-yang-04 - DUID representation in the model

[Simon Hobson <[e-mail]>]

Bernie Volz (volz) <[e-mail]> wrote:

> This is definitely a mess. But these devices are out there.

I can see both sides, but it does seem like setting the standard to fit what a vendor has done - sending the message that it's OK to ignore standards as the IETF will simply regularise it.

> Obviously there was is no collision today as my understanding is that these are ascii strings and so we have a lot of duid-types to assign before there would be a conflict.

Until someone reads the spec, sees that it's just a blob, and sets a binary string that conflicts.

> I just don’t see why we bother to separate out anything - just treat it as an opaque “blob” of data.


Indeed. It does seem odd to specify ways of generating a DUID, including a type identifier - and then prohibit using that information.


Ted Lemon <[e-mail]> wrote:

> This is a valid point; realistically, when we defined DUID, we defined it as a blob, and then specified ways of doing it, but insisted that from the perspective of being used as an identifier, it was just a blob; the "how to make" part of the spec is to avoid collisions, not to make the information in the DUID available for the server to parse.
> 
> It would be reasonable to say that the yang data model should just present that binary blob to whatever is talking to it, and if that thing wants to have heuristics for picking it apart, that's fine, but the data model doesn't need to do so.

We seem to get mixed messages. On the one hand there's this text that says "do not parse the DUID", yet on this list (IIRC) you've suggested that this was simply "not well worded" and it wasn't intended to prohibit doing that.