[dhcwg] Comments to DHCPv6 YANG-//RE: Call for adoption for draft-cui-dhc-dhcpv6-yang-04

["Liubing (Leo)" <[e-mail]>]

Hi Linhui,

Thanks for your quick response. I rename this thread to distinguish it from the adoption call.

Please see inline.

From: Linhui Sun [mailto:[e-mail]]
Sent: Monday, September 28, 2015 7:32 PM
To: Liubing (Leo)
Cc: Tomek Mrugalski; dhcwg; [e-mail]
Subject: Re: [dhcwg] Call for adoption for draft-cui-dhc-dhcpv6-yang-04

Hi Bing,

Thanks for your comments, please see inline with [LH].

Best regards,
Linhui

2015-09-28 18:31 GMT+08:00 Liubing (Leo) <[e-mail]<mailto:[e-mail]>>:
Hi, all

I think the DHCPv6 (and also DHCPv4) YANG model is necessary work, and DHC WG should be the most suitable place to work on it. So I support this adoption.

And we have some comments to the current draft:

General comments:
1. The Server, Relay, Client are defined as three containers in one DHCPv6 module in the draft. But considering the three roles are actually independent from each other, we thought maybe defining them as three separated YANG modules (still in one draft) is more proper. This might be more convenient to maintain and use them.

[LH]: Actually, they are not just three common containers, I would prefer to call it the "feature". Since we use the "feature" statement defined in RFC6020 which allows the device to flexible choose which feature it will support (only the supported feature is valid). This could make the model more flexible and allow the device to be free to change its role.
[Bing] If the roles are defined as “feature”, my understanding is that it implies the roles are different aspects of one function. When one device is configured with multiple dhcp roles simultaneously, actually those roles are more like different functions that have no direct relationship with each other.
I would probably still work if defined them as features, but my concern is that the logic seems a bit confusing.

Besides, do you also consider making address pool a separated module? Since the address pool could be considered as a common resource that might be utilized by functions other than DHCP.

[LH]: This model is only for DHCPv6 configuration, I'm not sure whether there is enough benefits to bring other functions to this model. And in the context of DHCPv6, the addr/prefix pools should be only considered in the server side, am I right?
[Bing] Actually I was talking about bringing the address pool out of the DHCP model, rather than bringing something in☺  Because I think not only DHCP would use address pool. If it is a separated model, then could be easily re-used by other functions.


(I think this comment also applies to the current DHCPv4 YANG model draft.)

2. (This is also a question to the WG) Do you consider this DHCPv6 YANG Model as a universal model focusing on the standard functions, or you consider it as a specific usage, e.g. HGW?
My personal opinion tends to agree with the former one.

[LH]: I also prefer the first one. The current model is mainly based on the HGW. But we will do check other implementations as Tomek suggested (we've already started to look at the Kea). The ultimate goal is to propose a model that could be applied to multiple implementations.
[Bing] It sounds great.



Specific comments:
1. In Client model, the "client-interfaces" container seems redundant? I think the "list client-if" could be directly under the "client" container.

[LH]: Thanks for pointing out, will modify it.
[Bing] Thanks.

2. In Server model, Do you consider to support a feature that multiple DHCPv6 servers could be grouped together? This is an important feature in carrier networks.

[LH]: This sounds like an interesting feature, but I don't know what are those groups for. Does it require us to add a new data node in the server portion to describe the group?
[Bing] Sorry, actually I meant “Relay Server”, not server. Several relays grouped together to present as a single one. This is mostly for carrier grade reliability consideration. You might refer to draft-liu-dhc-dhcp-yang-model for the group definition. And we welcome your comment if you find some flaws.

3. There are lot of stings defined without assigned length.

[LH]: I think most strings defined in the model are variable length, and is there any requirement that we have to define the string with a length? since I find previous RFCs are also defining strings without assigning length.
[Bing] I haven’t worked through all the string elements one by one. My understanding is that it might depend on the specific element. E.g., for the Name element, maybe it’s better to assign it a length?

Best regards,
Bing

4. There are some description still empty, need to be filled.

[LH]: Thanks, will complete them in the next version.


Best regards,
Bing

> -----Original Message-----
> From: dhcwg [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Tomek
> Mrugalski
> Sent: Friday, September 25, 2015 8:42 PM
> To: dhcwg
> Subject: [dhcwg] Call for adoption for draft-cui-dhc-dhcpv6-yang-04
>
> Hi,
> Authors of draft-cui-dhc-dhcpv6-yang-04 requested adoption. This draft has
> been presented twice and received favourable comments. It defines a YANG
> data model for configuration and management of the DHCPv6 server, client
> and relay agent. This I-D is over 80 pages long, but most of the text is taken
> by formal YANG definition.
>
> This mail initiates a call for adoption of draft-cui-dhc-dhcpv6-yang-04 as a
> WG item. If you would like the working group to work on this document,
> please say so. If you would like the WG to not adopt, please state your
> technical objections.
>
> There are currently no IPR claimed against this draft.
>
> Bernie and I will determine the consensus after Oct. 9th.
>
> Bernie & Tomek
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dhcwg

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