Subject: Re: [dhcwg] Erik Kline's No Objection on draft-ietf-dhc-dhcpv6-yang-24: (with COMMENT)

From: [email-masked]
Date: Mon, 24 Jan 2022 15:29:41 +0100

Hi Erik,

First of all, many thanks for your review and my apologies that it’s taken so long for me to
reply.

Please see inline below.

@Bernie/@Tim, please can you give me your view on the anonymity profile suggestion below.

Thanks,
Ian

> On 16. Dec 2021, at 05:28, Erik Kline via Datatracker <[email-masked]> wrote:
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-dhc-dhcpv6-yang-24: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [S1.2; nit]
> 
> * s/demonstrate how this is can be/demonstrate how this can be/

[if - done]

> [S3.1; nit]

> 
> * s/for an failure/for a failure/

[if - done]

> 
> [S3.2, S4.3]
> 
> * Should RFC 4649 remote-id be included here?  Or, perhaps, did RFC 8415
>  S21.18 OPTION_INTERFACE_ID effectively obsolete OPTION_REMOTE_ID use
>  cases (or perhaps I'm just confused)?

[if - Both OPTION_REMOTE_IS and OPTION_INTERFACE_ID are still current
Options (and about 50/50 available in commercial implementations IME). 
But we restricted the scope of the doc to only contain options defined in RFC8415,
So RFC4649 options will be in a future doc.]

> 
> [S3.3, 4.4; question]
> 
> * For the user class and vendor class options, should they be annotated as
>  "not anon-profile"?  I'm curious about these elements w.r.t. to
>  RFC7844 S4.8.

[if - Good point, but it’s a SHOULD NOT rather than a MUST NOT requirement in
RFC7844, so I don’t think the YANG module should prevent it’s configuration.

@Bernie/Tim, do you have a view on this?

Suggest adding the following text to the descriptions for user/vendor class options: 

Please note that if the DHCPv6 anonymity profile is in use, then this option 
Should not be included.

And adding a ref to RFC 7844 sec 4.8.]

> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg