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@xxxxxxx [mailto:ianfarrer@xxxxxxx] > Sent: Friday, November 19, 2021 3:18 PM > To: Liushucheng (Will LIU, Strategy & Industry Development) > <liushucheng@xxxxxxxxxx> > Cc: ops-dir@xxxxxxxx; dhcwg@xxxxxxxx; draft-ietf-dhc-dhcpv6-yang.all@xxxxxxxx; > last-call@xxxxxxxx > 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@xxxxxxxx> > 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) > > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
