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

Hi Bing,

Thanks for separating the thread, please see comments inline.

Best regards,
Linhui

2015-09-29 18:19 GMT+08:00 Liubing (Leo) <leo.liubing@huawei.com>:

> 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:lh.sunlinh@gmail.com]
> *Sent:* Monday, September 28, 2015 7:32 PM
> *To:* Liubing (Leo)
> *Cc:* Tomek Mrugalski; dhcwg; draft-cui-dhc-dhcpv6-yang@tools.ietf.org
> *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) <leo.liubing@huawei.com>:
>
> 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.
>

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

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

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

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

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

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

>
>
> 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:dhcwg-bounces@ietf.org] 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
> > dhcwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>