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

[hezihao <[e-mail]>]

Would it be reasonable if we also add a ‘(pseudo-)type-code’ under DUID-string? This way, the format of DUID-string in the YANG model conforms to that of other four conventional types, which might help a device differentiate among the 5 types of DUID.

Of course, the assumption here is that there are indeed some devices trying to parse a DUID. Were it not true, I’d prefer that we not bother to separate out different types.

On 12/16/2017 03:09，Simon Hobson<[e-mail]> wrote：

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.

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg