[dhcwg] Re: AD review of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) draft-ietf-dhc-rfc8415bis-06

On 15.11.2024 22:46, Eric Vyncke (evyncke) wrote:
> Dear authors, shepherd, and DHC WG,
> 
> Thank you for your efforts to elevate DHCPv6 to Internet Standard.
> 
> As usual for any IETF draft, I have done an AD review. Before proceeding
> with the publication process, I am requesting either a revised text or a
> reply to all points below.
Thanks for the review and for pushing this forward. See my comments below.

> # Metadata
> 
> Should the intended status clearly indicate “Internet Standard” ? Tbh I
> am not sure as draft-ietf-6man-rfc2460bis also indicated “Standards Track”.
As Bernie suggested, I played with the status attribute of the
<seriesInfo> tag. It didn't work with the latest xml2rfc 3.25.0. I don't
know why, but I do have a theory. The status field is documented in
RFC7991, Section 2.47.1. However, the docs for xml2rfc
(https://ietf-tools.github.io/xml2rfc/#name-seriesinfo) have the section
for status attribute empty. Perhaps it's being deprecated?

Is this something the RFC editor could fix once we reach that stage?

We could reach out to xml2rfc authors and ask for guidance.

> # Generic
> 
> Should this document use “DHCP” or “DHCPv6” when referring to the
> protocol it specifies ? No hard feelings here but I would prefer to use
> “DHCP” everywhere (with perhaps a sentence about “In this document, DHCP
> is used to refer to the protocol specified in this document”.
As a person who remembers very bad I-Ds that were trying to send DHCPv4
options in DHCPv6 (and vice versa), I'd very much prefer to keep the
DHCPv6 convention. Also, this gets grossly confusing when discussing any
matters that involve both protocols (DHCP4o6 or many transition
technologies). Yes, it's 2 extra chars to type, but it avoids confusion.
Finally, DHCPv4 and DHCPv6 are similar, but different protocols.

> Suggest using the aasvg tool to generate a nicer version of this long-
> lasting document... Trust me, this tool is impressive ;-) but this is a
> matter of taste. No need to reply to this comment.
Will try. Haven't used it, but looks easy enough.

> s/This document replaces RFC8415/This document obsoletes RFC8415/ (as
> also written at the end of section 1.1)
Done.

> # Section 1.1
> 
> Do the DHC WG have any information whether the features in  `obsoleting
> two features that have not been widely implemented` are deployed and used ?
I can only speak about Kea. Kea never had temporary addresses
implemented. In its 13 years of existence I remember a single question
about TA from what I recall was a researcher.

Server unicast was implemented in Kea, but I don't remember any
discussions, bug reports or feature requests related to it. I suspect it
was rarely used for the exact reasons why it's being deprecated (one of
the improvements of DHCPv6 compared to DHCPv4 is that the traffic goes
through relays and server unicast broke that).

> `At the time of writing` does not age very well, suggest using “At the
> time of writing (2024)” or something less vague. This issue occurs
> several times in the document.
Updated two instances.

> More important `One other IA type was defined (see [RFC8947 <https://
> www.rfc-editor.org/info/rfc8947>])` please add this type to the previous
> enumeration and remove this sentence.
Reworded. Does this sound better:

  At the time of writing this document (2024), there are four IA types
  defined: IA_NA, IA_TA (obsoleted), IA_PD, and IA_LL (see [RFC8947]).
  New IA types may be defined in the future.

> Should IA_LL options be listed in “IA option(s)” ? I guess yes.
Added. The original reason why we chose to skip it, is that it's a niche
option and we didn't want to expand this already huge document.

> s/ See [RFC8415] for details on the now obsoleted IA_TA option./ This
> option is obsolete, see [RFC8415] for details./
Added.

> Should IA_LL (RFC 8947) be also listed in the terminology ?
I would prefer not to add separate item. It's not a popular feature and
it could add more complexity do the document. It's now listed in two
existing item: IA and IA option(s).

> # Section 6.3
> 
> What is ‘normal DHCP’ in ` That includes addressed leased out by normal
> DHCPv6 (IA_NA), prefixes via DHCPv6-PD (IA_PD), and addresses
> autoconfigured by IPv6 Router Advertisements.` ?
It does sound a bit odd. How about this:

  That includes addresses leased out by DHCPv6 (IA_NA), prefixes
  delegated via DHCPv6-PD (IA_PD), and addresses autoconfigured by IPv6
  Router Advertisements.

> # Section 7.2
> 
> What is “designated destination port” in their designated destination
> ports`?
Does this sound any better?

  Nevertheless, regardless of the source port used, DHCP messages MUST
  be sent to ports specified above (e.g., clients sending to port 547).

> # Section 14.2
> 
> There are now only “two” use cases and not ` there are three such
> cases:` ;-) (perhaps worth checking whether there are other occurrences
> of this mistake)
As they say, there are only two hard problems in computer science:
concurrency,
cache coherency and off-by-one errors :)

Fixed.

> # Section 18.4
> 
> Suggest using upper case BCP14 terms in this section for “may continue”
Added.

> # Section 21.5
> 
> Many of my fellow ADs will not be happy with “SHOULD” without any
> specific use case or consequences of bypassing the SHOULD.
Bernie suggested to turn this into MUST ignore, but I don't like it.
There's already a generic text in Section 16 that says unsupported
options MUST be ignored and message processing to continue as if the
option wasn't there.

How about we keep the SHOULD as it, but add an explanation what happens
if it's bypassed:

  As this option was never popular among server or client
  implementations before being deprecated, any implementations that
  still attempt to send it are unlikely to have the option being
  processed.

> # Section 21.12
> 
> As in section 21.5, strict normative BCP14 text should appear on when to
> send and what to do on receiving unicast traffic.
How about this:

  The client SHOULD NOT request this option in ORO.  The server SHOULD
  NOT send this option, even when requested by clients.  When any entity
  receives server unicast option, the option SHOULD be ignored and the
  message processing should continue as usual.

  As this option was not very popular and it typically required special
  configuration by those server implementations that did support it,
  clients still requesting this option in ORO are increasingly unlikely
  to get it.

Thanks again for a very thorough review.

Tomek

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]