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

[Ian Farrer <[e-mail]>]

Hi Bernie,

I think enumeration is correct - a DUID can only follow one of the formats and the enumeration is based on the name of the case, not it’s position in the list. The DUID type number is not currently being modelled so its value would be implicit from the duid name.

We could make the type code explicit for defined DUIDs, omitting it for duid-string (in the model I have put default values for the defined type codes, they don’t show in the tree):

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

(Includes the correct fields for duid-ll as pointed out by Ted)

Cheers,
Ian

> On 14. Dec 2017, at 14:23, Bernie Volz (volz) <[e-mail]> wrote:
> 
> Ian:
> 
> There is no type for this malformed (string) duid. It is just a string, such as:
> 
> Option 1, length 6, data: “S12345”.
> 
> So you cannot use enumeration of type.
> 
> Yes, this clearly violates duid rules but it exists and needs to be represented?
> 
> - Bernie (from iPad)
> 
> On Dec 14, 2017, at 5:13 AM, Ian Farrer <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> 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) <[e-mail] <mailto:[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)
>>> 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
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>