Re: [dhcwg] draft-ietf-dhc-dhcpv6-yang-04

Hi Bernie/Med,

Here’s a re-worked DUID section including UUID and a free, string based format that hopefully addresses the comments that have been raised:

+--rw duid
|  |  +--rw (duid-type)?
|  |     +--:(duid-llt)
|  |     |  +--rw duid-llt-hardware-type?      uint16
|  |     |  +--rw duid-llt-time?               yang:timeticks
|  |     |  +--rw duid-llt-link-layer-addr?    yang:mac-address
|  |     +--:(duid-en)
|  |     |  +--rw duid-en-enterprise-number?   uint32
|  |     |  +--rw duid-en-identifier?          string
|  |     +--:(duid-ll)
|  |     |  +--rw duid-ll-hardware-type?       uint16
|  |     |  +--rw duid-ll-time?                yang:timeticks
|  |     +--:(duid-uuid)
|  |     |  +--rw uuid?                        yang:uuid
|  |     +--:(duid-string)
|  |        +--rw string?                      string

Cheers,
Ian

> On 11. Dec 2017, at 16:33, Bernie Volz (volz) <volz@cisco.com> wrote:
> 
> Hi:
>  
> One comment regarding the 04 version is that for the DUID, you need to:
> 1.       Include the DUID-UUID (see RFC 6355)
> 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.
>  
> - Bernie
>  
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org <mailto:dhcwg@ietf.org>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>

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