[dhcwg] Re: Actions after the IETF last call of draft-ietf-d hc-rfc8415bis-07

Michael Richardson <[email protected]> Mon, 03 Feb 2025 11:38:12 +0100
Newsgroups	gmane.ietf.dhc
Message-ID	<668079.1738579092@dyas>
(I really wish we had done all this work in Markdown, and I wish I had pushed harder
to do that.  We did that for 8415)

https://github.com/dhcwg/rfc8415bis/pull/15

Eric Vyncke (evyncke) <[email protected]> wrote:
    > https://datatracker.ietf.org/doc/review-ietf-dhc-rfc8415bis-07-dnsdir-lc-reid-2025-01-12/
    > by Jim Reid [2]

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

The RFC editor already kicked that can when they did RFC8415.
We are aiming for Internet Standard:
   https://author-tools.ietf.org/diff?doc_1=RFC8415&doc_2=draft-ietf-dhc-rfc8415bis-07&iddiff=1

Basically I'm reluctang to change too much text, because I think they might
just want to change it back.

    jr> My biggest gripe is the section on rate-limiting. I do not understand
    jr> why relay- and server-side rate limiting could be deemed out of
    jr> scope. That seems to me to be every bit as important as client-side

Mostly, DHCPv6 servers (more than DHCPv4) only reply to queries from clients.
Clients manage retransmissions, with a few things like RECONFIGURE being
server initiated.  (often not used, not supported...)
So I'm not sure that there is much that servers can do to further limit
rates, except I guess they can drop requests from annoying clients.

Relays can similiarly be lossy if they need to be.
I don't see a protocol impact of this though.

    jr> rate limiting. I'm not sure if this counts as a nit or an
    jr> issue. Either way, this does need to be addressed - or explained if
    jr> the WG took a consensus decision on that while the doc was under
    jr> development.

I'm open to further suggestions.

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

I feel like we ligitiated this when the document was developed, and if
section 4.2 isn't enough, then what would really be enough?

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

okay.
https://github.com/dhcwg/rfc8415bis/pull/15/commits/bfcb89c6e532acaf4968387a4e94ea6b7301f6c1

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

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

https://github.com/dhcwg/rfc8415bis/pull/15/commits/471d288099371333ba9714d9e5accb77cf3d40d0

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

okay.
We say:
        Therefore, this document mostly replaces
        "requesting router" with "client" and "delegating router" with
        "server".

and I'm not sure what to do here.
    https://github.com/dhcwg/rfc8415bis/pull/15/commits/157ca2d13b264deae9a839b49277d1f382b31f1e

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

how about:

-        <t>DHCP makes use of the following multicast addresses:</t>
+        <t><xref target="RFC3315" /> registered the following multicast
+addresses, and this specification is now authoritative for:</t>

https://github.com/dhcwg/rfc8415bis/pull/15/commits/a6b1b9b8c1cd6e3e55dd1965155fa12530fc11ce

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

*THIS* is the new base DHCP spec.

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

I don't understand your comment.
The text seems fine to me.

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

How about:
-        <t>This section presents a table of values used to describe the
+        <t>This table of values used to describe the

https://github.com/dhcwg/rfc8415bis/pull/15/commits/b4c9d629378bab5bdd91816807b8d9ce389bdff0

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

This *is* vanila DHCPv6.  This will be the definitive document (once approved).

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

I simplified the text slightly, I'm unclear what was wrong with what was said already:
https://github.com/dhcwg/rfc8415bis/pull/15/commits/acdd5e0c8379f5a1701462532e295bbccbbc634d

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

It might not be unique over the whole "Internet", true.
I think the text is good.

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

If DUID-LLTs are not unique, then the link-layer address must have also been
non-unique, and things tend to go badly in other ways at that point.
We have no way to identify/defend this uniqueness.

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

This is intentional.

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

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

https://github.com/dhcwg/rfc8415bis/pull/15/commits/7ad0e9caeb94f74699bac7bb71ce4caba47731b5

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

I can not, can someone else?

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

Because servers do not initiate new messages.

    jr> Section 15: according to the retransmission strategy described below?

https://github.com/dhcwg/rfc8415bis/pull/15/commits/78f20acc11673d018564da76f45474e22778994e

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

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

I have opened issue
  https://github.com/dhcwg/rfc8415bis/issues/16

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

https://github.com/dhcwg/rfc8415bis/issues/18

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

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

https://github.com/dhcwg/rfc8415bis/issues/17

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

1. *HMAC* constructs are still safe.
2. almost nobody deploys this... maybe it should be removed entirely for IS.

RFC6151 says:
        It is not urgent to stop using MD5 in other ways, such as HMAC-MD5;
and it's section 2.3 goes on to confirm.

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

I think that there is some confusion here.
I don't find another diagram like that in 21.1.
What diagram did you see that was duplicated?

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

The IESG has said it's useful, and since we are going to IS, it's critical
that we tell them this.
   NOTE TO RFC EDITOR: Please remove this section before publication.
   It is intended for the IESG evaluation.

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

Yes, okay.

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 487 B)