[dhcwg] Re: Actions after the IETF last call of draft-ietf-d hc-rfc8415bis-07
Bernie Volz <[email protected]> Mon, 3 Feb 2025 05:59:46 -0500
| Newsgroups | gmane.ietf.dhc |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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) <[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> _______________________________________________ dhcwg mailing list -- [email protected] To unsubscribe send an email to [email protected]