[v6ops] Éric Vyncke's Yes on draft-ietf-v6ops-dhcp-pd-per-device-07: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-v6ops-dhcp-pd-per-device-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcp-pd-per-device/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# É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 ;-)