Re: [dhcwg] Opsdir last call review of draft-ietf-dhc-dhcpv6-yang-24

Dec. 23 2021 14:04.hk

You are so right, in dhcpv6 srv, for prefix, name pools getting more
complex in rfc3315 duid changed motherboard sub-mac env.

Sincerely
Li HUANG

On Thu, Dec 16, 2021, 15:06 Liushucheng (Will LIU, Strategy & Industry
Development) <liushucheng=40huawei.com@dmarc.ietf.org> wrote:

> Dear Ian,
>
> Sorry for being late.
> Thanks for your reply. I had a long discussion on with several people to
> try to provide some content example. My reply inline with  [Will].
>
> > -----Original Message-----
> > From: ianfarrer@gmx.com [mailto:ianfarrer@gmx.com]
> > Sent: Friday, November 19, 2021 3:18 PM
> > To: Liushucheng (Will LIU, Strategy & Industry Development)
> > <liushucheng@huawei.com>
> > Cc: ops-dir@ietf.org; dhcwg@ietf.org;
> draft-ietf-dhc-dhcpv6-yang.all@ietf.org;
> > last-call@ietf.org
> > Subject: Re: Opsdir last call review of draft-ietf-dhc-dhcpv6-yang-24
> >
> > Hi Will
> >
> > Many thanks for your review and comments. Please see inline below.
> >
> > Best regards,
> > Ian
> >
> > > On 18. Nov 2021, at 10:37, Will LIU via Datatracker <noreply@ietf.org>
> > wrote:
> > >
> > > Reviewer: Will LIU
> > > Review result: Has Nits
> > >
> > > Hi all,
> > >
> > > I have reviewed draft-ietf-dhc-dhcpv6-yang-24 as part of the
> > > Operational directorate's ongoing effort to review all IETF documents
> > > being processed by the IESG.  These comments were written with the
> > > intent of improving the operational aspects of the IETF drafts.
> > > Comments that are not addressed in last call may be included in AD
> > > reviews during the IESG review.  Document editors and WG chairs should
> > > treat these comments just like any other last call comments.
> > >
> > > “This document describes YANG data modules for the configuration and
> > >   management of DHCPv6 (Dynamic Host Configuration Protocol for IPv6
> > >   RFC8415) servers, relays, and clients.”
> > >
> > > My overall view of the document is 'Has Nits'.
> > >
> > > ** Technical **
> > >
> > > Page54,
> > > 1. The DHCPv6 server may be bound to an interface to specify the
> > > DHCPv6 address pool of the corresponding interface.
> >
> > [if - Interface configuration and binding the server function to specific
> > interfaces/addresses is not covered in the ietf-dhc6-server module.
> There is a
> > lot of variance in the way that individual implementations configure
> this (e.g.
> > server/router/BNG), and also the class-selection logic that defines how
> an
> > individual request’s address/prefix pool and options are selected that
> this best
> > left to the implementor to define implementation specific YANG to cover
> these
> > areas.
> >
> > Examples of vendor specific configuration modules for the server’s base
> > configuration and class-selector logic are given in Appendixes C & D.
> > ]
>
> [Will] Agree this is not covered in the module and a lot of variance
> exist. After checking the examples in Appendix, there is no example about
> DHCPv6 server bounding to an interface to specific interfaces/addresses,
> may I suggest add a short example like below?
>
> augment /if:interfaces/if:interface {
>     description
>       "Extend interface attribute.";
>     container dhcpv6-server-attribute {
>       description
>         "Configure DHCPv6 server interface function.";
>
>       choice server-mode {
>         description
>           "Set dhcpv6 server mode in the Interface.";
>         case automatic-enable {
>           description
>             "Enable/disable dhcpv6 server automatic mode.";
>           leaf server-automatic-anable {
>             type boolean;
>             default "false";
>             description
>               "Enable/disable dhcpv6 server automatic mode.";
>           }
>         }
>         case pool-name {
>           description
>             "Pool name.";
>           leaf pool-name {
>             type string {
>               length "1..31";
>             }
>             description
>               "Pool name.";
>           }
>         }
>       }
>       leaf is-allow-hint {
>         type boolean;
>         default "false";
>         description
>           "Enable/disable to allow the server to assign prefix according
> to the client expectation.";
>       }
>       leaf preference {
>         type uint8 {
>           range "0..255";
>         }
>         default "0";
>         description
>           "The server priority in the advertise packet.";
>       }
>       leaf is-rapid {
>         type boolean;
>         default "false";
>         description
>           "Enable/disable to support for fast allocation.";
>       }
>       leaf is-unicast {
>         type boolean;
>         default "false";
>         description
>           "Enable/disable to specify the unicast communication between
> client and server in the address renewal process.";
>       }
> }
>
> >
> > > 2. The key of container address-pools and container prefix-pools in
> > > the DHCPv6 server may be changed to pool-name.
> >
> > [if - ‘pool-id’ was originally typed as being uint32 with the intention
> that it
> > was just a unique ID number for the pool. The type got changed to string
> due
> > to a recent review comment, But I think the intended use remains the
> same - it
> > is a unique identifier for the pool, whether the user choses a numeric
> or a
> > string based identifier as suits their requirements.
> >
> > My feeling is that pool-id is a suitable name for this function, but
> would be
> > happy to change if there is a good reason to use pool-name.
> > ]
> >
> [Will] Agree to change 'pool-id’ to string.
>
> Regards,        |   致礼!
> Will LIU        |   刘树成
>
> > >
> > > ** Editorial **
> > >
> > > No.
> > >
> > > Regards,
> > > Will (Shucheng LIU)
> > >
> > >
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>