Subject: [dhcwg] Call for adoption for draft-cui-dhc-dhcpv6-yang-04

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 25 Sep 2015 14:42:28 +0200

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

---

From: Linhui Sun <[email-masked]>
Date: Sat, 26 Sep 2015 15:29:33 +0800

Dear Chairs,

As a co-author of this document, I support adopting this draft as a working
group item.

Thank you,
Linhui

2015-09-25 20:42 GMT+08:00 Tomek Mrugalski <[email-masked]>:

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

---

From: 李丽姗 <[email-masked]>
Date: Mon, 28 Sep 2015 12:27:27 +0800

Dear All,

I support the draft to be adopted. I have presented the DHCPv6 YANG in the
IETF92. There was a lot of interest for the draft. It was also presented
during the IETF93 meeting. I think it is a useful document for the DHC WG.

Best Regards,
Lishan

2015-09-26 15:29 GMT+08:00 Linhui Sun <[email-masked]>:

> Dear Chairs,
>
> As a co-author of this document, I support adopting this draft as a
> working group item.
>
> Thank you,
> Linhui
>

---

From: "Dushyant Raghuvanshi (draghuva)" <[email-masked]>
Date: Mon, 28 Sep 2015 05:15:54 +0000

Dear All,

I support this draft to be adopted as WG item.

Thanks,
Dushyant.

---

From: <[email-masked]>
Date: Mon, 28 Sep 2015 10:46:08 +0200

Hi,

As I co-author I support adoption of this draft. We are planning on using this model for DHCPv6 server configuration in our HGWs.

Thanks,
Ian

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Friday, September 25, 2015 2: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.

Bernie & Tomek

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 28 Sep 2015 10:31:24 +0000

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. 

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.

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

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.
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.
3. There are lot of stings defined without assigned length.
4. There are some description still empty, need to be filled.

Best regards,
Bing

> Sent: Friday, September 25, 2015 8:42 PM
> To: dhcwg
> 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.
>

---

From: Linhui Sun <[email-masked]>
Date: Mon, 28 Sep 2015 19:31:52 +0800

Hi Bing,

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

Best regards,
Linhui

2015-09-28 18:31 GMT+08:00 Liubing (Leo) <[email-masked]>:

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

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

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

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

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

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

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

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

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

> has
> as a

---

From: tianxiang li <[email-masked]>
Date: Mon, 28 Sep 2015 20:45:07 +0800

Hi,

The DHCPv6 YANG model provides a unified method to configure and manage the
DHCPv6 server, client, and relay.
I think it is a useful document for the dhc wg. I support adopting this
document.

Thanks,
Tianxiang

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 28 Sep 2015 15:33:49 +0200

> state your technical objections.
With my co-chair hat off, I support adoption of this work. Although
defining a YANG model that would map to every (most?) implementations
configuration models will be difficult, I believe it doable.

Tomek

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 29 Sep 2015 01:29:18 +0000

I also support the adoption of this work. It is useful to manage dhcp server and client using yang. It would enhance the controllability of the devices and the network.

Sheng

>Sent: Monday, September 28, 2015 9:34 PM
>To: dhcwg
>Subject: Re: [dhcwg] Call for adoption for draft-cui-dhc-dhcpv6-yang-04
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 29 Sep 2015 10:19:16 +0000

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:[email-masked]]
Sent: Monday, September 28, 2015 7:32 PM
To: Liubing (Leo)
Cc: Tomek Mrugalski; dhcwg; [email-masked]
Subject: Re: [dhcwg] Call for adoption for draft-cui-dhc-dhcpv6-yang-04

Hi Bing,

Best regards,
Linhui

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

General comments:

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

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

[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:

[Bing] Thanks.

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

[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

Best regards,
Bing

> From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tomek
> Mrugalski
> [email-masked]<mailto:[email-masked]>

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

---

From: Linhui Sun <[email-masked]>
Date: Tue, 29 Sep 2015 23:00:15 +0800

Hi Bing,

Thanks for separating the thread, please see comments inline.

Best regards,
Linhui

2015-09-29 18:19 GMT+08:00 Liubing (Leo) <[email-masked]>:

> *From:* Linhui Sun [mailto:[email-masked]]
> *Sent:* Monday, September 28, 2015 7:32 PM
> *To:* Liubing (Leo)
> *Cc:* Tomek Mrugalski; dhcwg; [email-masked]
> *Subject:* Re: [dhcwg] Call for adoption for draft-cui-dhc-dhcpv6-yang-04
>
>
>
> Hi Bing,
>
>
>
> [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.
>

[LH]: This does confuse people. I think we will take you suggestion to make
it as three separated modules in the next version. Thanks!

> [Bing] Actually I was talking about bringing the address pool out of the
> DHCP model, rather than bringing something inJ  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.
>
>
[LH]: Oh, that's interesting. I just have another thought, what about
making the addr/prefix pools as groupings? In this way, we could reuse the
pool but do not break the integrity of the server configuration at the same
time.

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

[LH]: Thanks, I think we will consider this feature.

> [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?
> [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?
>

[LH]: I think one of the benefits of assigning a length for a string is to
define some format for those names. Is that right? If so, I think this
should depend on the real users. Thus, maybe a more reasonable way to do
this is to write recommendations for those data nodes but not define in the
model?