Ballot for draft-ietf-v6ops-dhcp-pd-per-device
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
# Internet AD comments for draft-ietf-v6ops-dhcp-pd-per-device-07 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Nits ### S12 * "makes the failures" -> "makes any failures" ### S16 * "Other delete" -> "Others delete"
# Éric Vyncke, INT AD, comments for draft-ietf-v6ops-dhcp-pd-per-device-07 Thank you for the work put into this document. It is easy to read and, while being simple, it is brilliant. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Timothy Winters for the shepherd's detailed write-up including the WG *rough* consensus *and* the justification of the intended status. Other thanks to Tim Chown, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-v6ops-dhcp-pd-per-device-07-intdir-telechat-chown-2024-03-27/ (I have yet to read any reply by the authors) I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Abstract "client" is rather vague... or was "node" intended ? "client" is only defined later in the terminology section. Unsure whether "large" is a requirement for this I-D to be used. ## Section 1 Is "large" required in `Often, large broadcast networks` ? `individual clients` should it be "individual nodes" or "individual hosts" ? s/prefixes/IPv6 prefixes/ in the first paragraph ? "(and often requires)" ? Beside link-local, I am not sure whether it is often a requirement. s/L2/layer-2/ ? As this section talks about DHCPv6, please already add a reference to DHCPv6. s/in this specification/in this document/ as the intended status is informational. ## Section 4 `The first-hop router acts as a DHCPv6 relay` AFAIK a DHCPv6 relay does not need to be a router (this point comes up again later). Even if "NUD" is an accepted abbreviation, suggest expanding it. `required by this specification.` is not suitable for an informational I-D. I love those clear SVG graphics :-) Just a very minor nit on the shared IPv6 link, there is a cross in the middle rather than a T (unsure whether it is fixable though) ## Section 5 For small networks, `SLAAC is a better and simpler option` is probably too assertive, suggest removing 'better' and only keep 'simpler'. ## Section 6.1 Should the routing table size reduction also be a benefit of using a big pool per link ? If so, let's state it already in this section rather than in the next ? ## Section 6.2 Is seems to me that one requirement of the proposed solution is that the DHCP relays *are* the routers, i.e., they can do DHCP snooping to learn the delegated prefixes. Or is the multicast nature of the DHCP traffic enough? All in all, I do not think that a separate DHCP relay is a problem but some words could be added to the text to state that separate DHCP relay(s) (or local DHCP servers) is also supported. ## Section 7 As usual, I am not a big fan of using normative BCP 14 language in an informational document. ## Section 8 I can only imagine the amount of discussions about the delegated prefix length... No need to reply. ## Section 10 Unsure whether such reference exists, but adding a reference to uRPF would be a plus. Should SLAAC be added to `When all clients are using the same shared link to form addresses`? ## Section 11 Currently, the IETF cannot publish this document as it includes `To allow the network to signal DHCPv6-PD support, [I-D.collink-6man-pio-pflag] defines a new PIO flag` and we do not know the fate of this other I-D yet. While I hope that it will be published, the sentence should be less assertive or make the 6MAN I-D normative in order to form a RFC editor cluster. ## Section 12 `Such information is much less dynamic than ND cache` moreover, the DHCP-PD logs are centralized and easier to collect. ## Section 15 `the DHCPv6 server or relay MUST support limiting the number of prefixes delegated to a given client at any given time` how can this be achieved if the client spoofs its MAC & link-local IPv6 addresses? # NITS (non-blocking / cosmetic) ## E.g. 'E.g.' is usually followed by a comma. ## 464XLAT Be consistent and always use "464XLAT" rather than "464xlat" in section 8. ## Section 16 Usually, appendixes are after the references ;-)
Thanks to Harald Alvestrand for his ARTART review. Please take a look and consider his feedback.
Thank you to Peter Yee for the GENART review. ** Section 13. Networks that use the proposed mechanism instead of SLAAC or in addition to SLAAC, SHOULD minimally: ... * Use short prefix lifetimes, to ensure that when a client disconnects and reconnects it gets a different prefix. Is there any guidance to provide on what constitutes a “short lifetime”? ** Section 13. To provide privacy roughly equivalent to SLAAC with temporary addresses ([RFC8981]), the network SHOULD ... I’m having trouble understanding this guidance. What should be done to provide SLAAC-privacy-equivalence if this guidance isn’t followed? There are multiple SHOULDs in this paragraph. Wouldn’t it be mandatory to follow them to provide SLAAC-privacy-equivalence?