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@xxxxxxxxxxxxxx> 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@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)
> >
> >
_______________________________________________
dhcwg mailing list
dhcwg@xxxxxxxx
https://www.ietf.org/mailman/listinfo/dhcwg
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
