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

[Ian Farrer <[e-mail]>]

Hi Bernie,

Thanks for the comment. Please see inline.

Cheers,
Ian

> On 11. Dec 2017, at 16:33, Bernie Volz (volz) <[e-mail]> wrote:
> 
> Hi:
>  
> One comment regarding the 04 version is that for the DUID, you need to:
> 1.       Include the DUID-UUID (see RFC 6355)

[if - I saw that this had been omitted. There is already a github issue raised to include this.

> 2.       Handle DUIDs that do NOT follow these conventions (I know of at least one model device that does not). So, you need a way to represent that (the vendor sadly has no type even before the text serial number of the device). This would also accommodate new DUID types that are not yet defined for a new model.
>  
> Frankly, I’d prefer that we NOT explode these fields at all and just treat the data as binary data. Exploding out values here just causes issues for the above cases and makes the model harder to implement. If you see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-10#section-11 <https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-10#section-11>, you will notice the following text:
>  
>    Clients and servers MUST treat DUIDs as opaque values and MUST only
>    compare DUIDs for equality.  Clients and servers SHOULD NOT in any
>    other way interpret DUIDs.  Clients and servers MUST NOT restrict
>    DUIDs to the types defined in this document, as additional DUID types
>    may be defined in the future.  It should be noted that an attempt to
>    parse a DUID to obtain a client's link-layer address is unreliable as
>    there is no guarantee that the client is still using the same link-
>    layer address as when it generated its DUID.  And, such an attempt
>    will be more and more unreliable as more clients adopt privacy
>    measures, such as those defined in [RFC7844 <https://tools.ietf.org/html/rfc7844>].  It is recommended to
>    rely on the mechanism defined in [RFC6939 <https://tools.ietf.org/html/rfc6939>].
>  
> By exploding out the values you are just encouraging people to violate these MUSTs.

[if - I can see your point here, but from an operator’s side, when configuring the DHCP client, being able to specify a format is useful if I can just tell the client to use e.g. DUID type 1 and have a very high probability of uniqueness then it’s one less client configuration parameter that I need to manage.

However, looking back at the model, this isn’t really what it’s doing at the moment, so it needs some re-work (e.g. the time and link-layer addresses really should be state data as they are taken from the device).

What about adding another option for an arbitrary binary DUID type (in addition to adding DUID-UUID and re-working the existing ones)?


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