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

[Linhui Sun <[e-mail]>]

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

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


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


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


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

>
>
> Best regards,
> Bing
>
> > -----Original Message-----
> > From: dhcwg [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]
> > https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>