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

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 <ianfarrer@gmx.com<mailto:ianfarrer@gmx.com>> 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) <volz@cisco.com<mailto: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, 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

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