Last Call Review of draft-ietf-dhc-rfc8415bis-07
review-ietf-dhc-rfc8415bis-07-dnsdir-lc-reid-2025-01-12-00

I don't have enough knowledge of DHCP((v6) to comment on the detail of
this I-D, except in general terms. There's no significant DNS content.

Overall, the I-D is in fairly good shape. However there are a few places
where the text is clumsy and IMO lacks clarity. There's some unwelcome
duplication too. Terms are used inconsistently: server vs DHCP server for
instance. I think the document needs to do a better job of making a
distinction between DHCP in general and DHCPv6. A technical writer could
easily clean up these nits and save the RFC Editor from doing that.

My biggest gripe is the section on rate-limiting. I do not understand why
relay- and server-side rate limiting could be deemed out of scope. That
seems to me to be every bit as important as client-side rate limiting. I'm
not sure if this counts as a nit or an issue. Either way, this does need to
be addressed - or explained if the WG took a consensus decision on that while
the doc was under development.

It is confusing (and IMO misleading) to say DHCP in the document when the
authors really mean DHCPv6. Although this is explained in the definitions
in Section 4.2, that text is easily overlooked. It would be far clearer to say
"DHCP" when discussing DHCP in general and use DHCPv4 and DHCPv6 when
referring to the specifics of how DHCP is used with these transports.

Section 5 says "A DHCP client sends messages using a reserved,
link-scoped multicast destination address". It's not clear to me where
this term is defined. Providing an example might help too.

The first para of 6.1 is clunky. I think the following is clearer:

    Stateless DHCP [RFC3736] can be used to obtain host configuration parameters
    such as a list of NTP or DNS recursive name servers. DHCP leases are not
    involved in these transactions. Stateless DHCP can be used at any time,
    typically when a node initially boots.

In Sections 6.2 and 6.3, say "DHCPv6 server", not "server".

Section 7.1: Are All_DHCP_Servers and All_DHCP_Servers being defined here
or do they come from another RFC or an IANA registry?

Sections 7.2 and 7.3 seem redundant and unnecessary. Isn't this text
already in the base DHCP spec? If so, why repeat it here? What stuff in
Section 7 is unique to DHCPv6?

The text in 7.4 and 7.5 is garbled IMO. Both could be removed or replaced
with a sentence saying the option and status codes used in this I-D are
documented in Section 21.

Section 7.6: I'm irritated by introductory text which starts "This section..."

Section 8 & 9: Are these message formats special in some way? Are they any
different from those for "vanilla" DHCP?

Section 10: Just say all domain names used in DHCP(v6) MUST be encoded in the
format defined in Section 3.1 of RFC1035. The message compression scheme
described in Section 4.1.4 of RFC1035 MUST NOT be used.

Section 11: The DUID MUST be globally unique? If so, how? And does global
mean global (ie over the whole Internet) or is it just within the scope of
a given DHCP server's administrative domain?

Section 11.2: The I-D needs to explain how DUID-LLT collisions get handled
even if they're rare events. Do these collisions matter?

Section 13 should say "DHCPv6 server" and not "server"

Section 14.1 "reverts back" is a tautology. The text in this Section is
clumsy. I don't like "does not like". :-)  How about the following?

	A DHCPv6 client MUST limit the rate of DHCP messages it transmits or
	retransmits. This will minimise the impact of prolonged message bursts or
	loops, for example when a client rejects a server's response, repeats the
	request and gets the same server response which again gets rejected by the
	client.

"A possible default could be 20 packets in 20 seconds." [Citation
needed.] Please explain where these numbers come from and why.

"Rate limiting of forwarded DHCP messages and server-side messages is out
of scope for this specification." WHY??? IMO these *have* to be in
scope. They're part of the protocol.

Section 15: according to the retransmission strategy described below?

Section 16: I'm even more fed up with introductory text which starts "This
section..."

The text in Section 16 is confusing and ambiguous. It first says messages
containing unknown options can be discarded. Then it says they can't. It's
not clear what unknown options "should be ignored as if they were not
present" means in practice. Why not just say clients, relay agents, and
servers MUST NOT discard messages containing unknown options or interfere
with the content of those unknown options?

Section 18: The para beginning "A DHCP client" seems to be discussing
Stateless DHCP but uses different RFC references to those in Section
7. These need to be aligned. There seems to be unnecessary duplication
here. There seems to be unnecessary duplication here. :-)

I *really like* the detailed explanation of how messages are created,
transmitted and received in Section 18.2 and 19. It tells implementers how
their DHCPv6 server/client/relay is expected to behave.

Section 20: Now I'm getting annoyed by introductory text which starts "This
section...". Please make this go away.

Section 20.4.2. Is it wise to insist on HMAC-MD5? See RFC6151.

Section 21 repeats option formats documented elsewhere in the I-D. Please
put this stuff in exactly one place. There's no need for repetition. There's
no need for repetition. :-)

I'm not sure Section 22 is helpful or germane to the IESG's evaluation. It's
harmless though. Of course, it *must* get removed before publication
because implementation status info is (a) inappropriate for an RFC; (b)
by definition always out of date as implementations come and go.

Section 24: Now I'm getting angry about introductory text which starts "This
section...". :-) Stop it!