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

From: "Liushucheng (Will LIU, Strategy & Industry Development)" <[email-masked]>
Date: Thu, 16 Dec 2021 07:05:45 +0000

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: [email-masked] [mailto:[email-masked]]
> Sent: Friday, November 19, 2021 3:18 PM
> To: Liushucheng (Will LIU, Strategy & Industry Development)
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> 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 <[email-masked]>
> 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)

---

From: "Ms. Li HUANG" <[email-masked]>
Date: Thu, 23 Dec 2021 14:06:16 +0800

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=[email-masked]> 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].
>
> [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?
>
>           "Enable/disable to specify the unicast communication between
> client and server in the address renewal process.";
>       }
> }
>
> >
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>