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

[Bernie Volz <[e-mail]>]

There’s a bunch of stuff to work through here … thanks for initiating Michael.

I do want to just add that as this document has had two major reviews (for 3315 and then also for 8415), including many more, I think we should minimize changes unless there are real technical issues. Non technical issues are stylistic issues and will vary by reviewer.

More later, though it may be a few days as traveling.

- Bernie (from iPad)

> On Feb 3, 2025, at 5:38 AM, Michael Richardson <[e-mail]> wrote:
> 
> 
> (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) <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
> 
> 
> 
> _______________________________________________
> dhcwg mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> <signature.asc>