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

["Liushucheng (Will LIU, Strategy & Industry Development)" <[e-mail]>]

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