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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 11 Dec 2017 15:33:16 +0000

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

---

From: Ian Farrer <[email-masked]>
Date: Mon, 11 Dec 2017 16:59:29 +0100

Hi Bernie,

Thanks for the comment. Please see inline.

Cheers,
Ian

> On 11. Dec 2017, at 16:33, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Hi:
>  

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

> 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:
>  
>    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>].
>  

[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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>

---

From: Ian Farrer <[email-masked]>
Date: Thu, 14 Dec 2017 11:13:05 +0100

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 14 Dec 2017 13:23:04 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bernie/Med,

+--rw duid
|  |  +--rw (duid-type)?
|  |     +--:(duid-llt)

Cheers,
Ian

On 11. Dec 2017, at 16:33, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

Hi:

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:

- Bernie

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Dec 2017 08:49:07 -0500

I think you got duid-ll wrong—you should have deleted the time from the copypasta, but instead you deleted the hardware address. :)

> On Dec 14, 2017, at 5:13 AM, Ian Farrer <[email-masked]> wrote:
> 
> Hi Bernie/Med,
> 
>> On 11. Dec 2017, at 16:33, Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi:
>>  
> [email-masked]

---

From: Ian Farrer <[email-masked]>
Date: Thu, 14 Dec 2017 15:22:20 +0100

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) <[email-masked]> wrote:
> 
> Ian:
> 
> On Dec 14, 2017, at 5:13 AM, Ian Farrer <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi Bernie/Med,
>>

---

From: Simon Hobson <[email-masked]>
Date: Thu, 14 Dec 2017 19:46:45 +0000

Ian Farrer <[email-masked]> wrote:

> We could make the type code explicit for defined DUIDs, omitting it for duid-string

Surely, if the DUID-String version does not have a defined type code, then there is nothing to stop the initial byte(s) of the string matching a defined type value - and thus screwing up anything that's trying to make sense of the DUID based on it's type.

Or put another way, if you allow an arbitrary string without a type code, then you might as well say that all DUIDs are freeform and it's impossible to reliably parse them.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 14 Dec 2017 23:04:26 +0000

This is definitely a mess. But these devices are out there.

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.

I just don’t see why we bother to separate out anything - just treat it as an opaque “blob” of data.

That’s at least my personal position.

- Bernie (from iPhone)

> On Dec 14, 2017, at 2:56 PM, Simon Hobson <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Dec 2017 18:13:15 -0500

> I just don’t see why we bother to separate out anything - just treat it as an opaque “blob” of data.

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.

---

From: hezihao9512 <[email-masked]>
Date: Fri, 15 Dec 2017 13:18:10 +0800

As
far as I am concerned, whether a DUID is presented in separated types or in a
blob, it can both be treated as a blob.

However,
it would be somewhat easier for a device to parse a DUID (if it does want to) in
a multi-type presentation than just in a ‘blob’ presentation.

So,
I think the separation of types might be better in a way.

On 12/15/2017 07:13，Ted Lemon<[email-masked]> wrote：

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Dec 2017 08:02:14 -0500

On Dec 15, 2017, at 12:18 AM, hezihao9512 <[email-masked]> wrote:
> So, I think the separation of types might be better in a way.

Understood.   But is this possible in the yang model?

---

From: Simon Hobson <[email-masked]>
Date: Fri, 15 Dec 2017 19:08:26 +0000

> 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.

> 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 fin…

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.

---

From: hezihao <[email-masked]>
Date: Sat, 16 Dec 2017 11:41:38 +0800

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<[email-masked]> wrote：

dhcwg mailing list

[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Dec 2017 22:53:10 -0500

I would suggest that you just have an "invalid type" for unknown types and malformed DUIDs, and have it have the type code in it:

|     +--:(duid-invalid)
|        +--rw type-code?                   uint16
|        +--rw data?                        yang:bytes

This would be used for any DUID that either has an unrecognized type, or doesn't contain enough bytes to satisfy the format corresponding to the type code that was received.

I used yang:bytes because I don't actually know how to represent raw bytes in a yang data model; hopefully it's something like that.

---

From: hezihao <[email-masked]>
Date: Sat, 16 Dec 2017 15:29:05 +0800

On 12/16/2017 11:53，Ted Lemon<[email-masked]> wrote：

|     +--:(duid-invalid)

|        +--rw data?                        yang:bytes

Zihao -

Hi Ted, thanks for your suggestion and I re-modeled DUID accordingly, which is shown in the tree diagram below.

I think the built-in type 'binary'  is a good choice to represent raw bytes in a yang model.

+--rw duid

|  +--rw type-code?                   uint16                         ---- default:0xffff

|  +--rw (duid-type)?                                                     ---- default: duid-invalid

|     +--:(duid-llt)

|     +--:(duid-en)

|     +--:(duid-ll)

|     +--:(duid-uuid)

|     +--:(duid-invalid)

|        +--rw data?                binary

(Since the identifiers of all child nodes must be unique within all cases in a choice, I moved 'type-code' out of 'duid-type'.)

Besides, I set the default value for 'type-code' as 0xffff and the default case of 'duid-type' as 'duid-invalid', thus reducing the possibility of a malformed DUID to be treated as a known type.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Dec 2017 19:26:42 -0500

That sounds right. I will trust that your yang knowledge is better than
mine!  :)

On Dec 16, 2017 02:28, "hezihao" <[email-masked]> wrote:

> On 12/16/2017 11:53，Ted Lemon<[email-masked]> <[email-masked]> wrote：
>
> *I would suggest that you just have an "invalid type" for unknown types
> and malformed DUIDs, and have it have the type code in it:*
>
> *|     +--:(duid-invalid)*
> *|        +--rw type-code?                   uint16*
> *|        +--rw data?                        yang:bytes*
>
> *This would be used for any DUID that either has an unrecognized type, or
> doesn't contain enough bytes to satisfy the format corresponding to the
> type code that was received.*
>
> *I used yang:bytes because I don't actually know how to represent raw
> bytes in a yang data model; hopefully it's something like that.*
>
>
> Zihao -
> Hi Ted, thanks for your suggestion and I re-modeled DUID accordingly,
> which is shown in the tree diagram below.
>     ---- default:0xffff
>         ---- default: duid-invalid
>          |     +--:(duid-llt)
> (Since the identifiers of all child nodes must be unique within all cases
> in a choice, I moved 'type-code' out of 'duid-type'.)
>
> Besides, I set the default value for 'type-code' as 0xffff and the default
> case of 'duid-type' as 'duid-invalid', thus reducing the possibility of a
> malformed DUID to be treated as a known type.
>
>
>