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

[Ted Lemon <[e-mail]>]

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

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

> On 12/16/2017 11:53，Ted Lemon<[e-mail]> <[e-mail]> 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.
> 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)
>          |     |  +--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-link-layer-addr?     yang:mac-address
>          |     +--:(duid-uuid)
>          |     |  +--rw uuid?                        yang: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.
>
>
>