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

[[e-mail]]

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

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

> 
> ** Editorial **
> 
> No.
> 
> Regards,
> Will (Shucheng LIU)
> 
>