Well written. I have been following this draft in 6man and realize it has been discussed significant with energy and emotions> Great to see this work completed

Thanks for this well-written document. I have one comment: Section 9.1 uses “OLD” as if it’s going to be in classic OLD/NEW format, but instead in the “NEW TEXT” (not “NEW”) section it describes the change to be made, instead. 

All told I think the document would be clearer if you just used OLD/NEW. That is, instead of describing the mutation the reader needs to apply to the original text, just provide the complete replacement text in a NEW block.

No reference entries found for these items, which were mentioned in the text:
[draft-ietf-v6ops-dhcp-pd-per-device].

Perhaps because the reference says I-D.ietf-v6ops-dhcp-pd-per-device (instead of draft-). In other words, change all references of draft-ietf-v6ops-dhcp-pd-per-device to I-D.ietf-v6ops-dhcp-pd-per-device.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 5, paragraph 3
> +-+-+ Figure 1 The P flag is independent from the value of the M and O flags
>                              ^^^^^^^^^^^^^^^^
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of"?

Section 7.1, paragraph 9
> face. If the host does so, and it has has formed addresses from the prefix, 
>                                   ^^^^^^^
Possible typo: you repeated a word.

Section 7.3, paragraph 1
> tion [RFC6724], if the host forms addresses from a delegated prefix, it SHOUL
>                                   ^^^^^^^^^
"forms" is a plural noun. It appears that the verb form is incorrect.

Section 9.1, paragraph 7
>  load on the DHCP infrastructure. However Section 14.1 of [RFC8415] requires
>                                   ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Thank you to Susan Hares for the GENART review.

# Éric Vyncke, INT AD, comments for draft-ietf-6man-pio-pflag-10

Thank you for the work put into this document. And thanks for your patience waiting for this ballot (I was on PTO...).

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education, 2 of the comments should really be addressed).

Special thanks to Bob Hinden for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to Dirk Von Hugo, the Internet directorate reviewer (at my request), thanks to Jen for having reacted on his int-dir review:
https://datatracker.ietf.org/doc/review-ietf-6man-pio-pflag-09-intdir-telechat-von-hugo-2024-09-27/

Other thanks to Erik Nordmark, the IoT directorate reviewer (at my request), thanks to Jen for having reacted on his iot-dir review:
https://datatracker.ietf.org/doc/review-ietf-6man-pio-pflag-10-iotdir-telechat-nordmark-2024-09-30/

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Abstract

Suggest to add a RFC editor note requesting (even if we can trust the RFC editor to do their job as usual):
1) to delay the publication of this document until draft-ietf-v6ops-dhcp-pd-per-device is published
2) to replace all draft-ietf-v6ops-dhcp-pd-per-device by the actual RFC number

## Section 1

Perhaps a weird suggestion, and I will defer to the authors and to the 6MAN WG, but there is a draft-ietf-dhc-rfc8415bis in the cooking (currently in WGLC and with a Internet Standard as intended status) and even if it moves slowly, why not using this I-D rather than RFC 8415? It would only delay for a couple of months. Again, a weak and probably weird suggestion.

s/large amounts of address space/large amounts of addresses/ or /large address spaces/ ?

s/extend the network to downstream devices/extend the network to tethered devices/ ?

If VXLAN is mentioned, then please add an informal reference to this informational RFC 7348.

About `because many home routers support hundreds of neighbor cache entries` unsure whether it is correct (a reference would help) and whether it helps to justify this I-D anyway. Suggest removing it.

s/smaller/small/ as "smaller" looks like a pejorative term in this context. Also, there is a mix of 'smaller' and 'home' in the text and there are different IMHO, a small enterprise has much more requirements and resources than a residential user.

## Section 3

Thanks for this clear rationale, the second bullet addresses all my individual contributor's reservation about RA flag vs. PIO flag. Good job!

s/in a PIO option/in a PIO/ as the O is for option ;-)

s/operator's preference/network operator's preference/ (previous text uses "network").

## Section 4

`This implies that the network has a DHCPv6 server capable of making DHCPv6 Prefix Delegations to every device on the network` with 2^48 potential devices on a IEEE 802.11 or 802.3 layer-2 network, how can a DHCPv6 server be capable to have a prefix for *every* device ?

Suggest removing `Adding the P flag reduces the PIO Reserved1 field ([RFC4861], [RFC8425]) from 5 bits to 4 bits. ` as it will look weird in a published RFC.

About the last paragraph, I was about to raise a DISCUSS point because `The P flag is independent from the value of the M and O flags in the Router Advertisement` contradicts RFC 4861 section 4.2 `Note: If neither M nor O flags are set, this indicates that no information is available via DHCPv6.` This contradiction should be addressed.

Unsure about the usefulness of the last sentence. It does not hurt though.

## Section 5

s/for any given prefix/for any given prefix advertised in a PIO/

## Section 6

I find the redefinition of 'host' confusing, why not simply using the well-known term 'node' ?

## Section 6.1

Should there be some text about "a host SHOULD only request the minimum amount of delegated prefix that is enough for its own use" ? I.e., there could be several DHCP servers/relays advertising different prefixes (rare case of course). Could possibly be specified in section 6.2.

Should the text be clear about the hint length? I.e., 64 or less ?

I was also about to ballot a DISCUSS on the ambiguity of "interface" in the 3rd bullet, the 'interface' should not (i.e., "MUST NOT") be the interface where the RA with P-flag was received. Or did I miss something ?

The use of "host" rather "node" is really confusing in the section 6, my brain chocked when reading `host MUST NOT forward packets` as host never forwards, only routers do.

## Section 6.3

Should there be some text specifying that, in the absence of the P-flag, the prefix MAY be used to form SLAAC or request DHCP_IA ?

## Section 6.4

Please add some text about the consequences (i.e., router overload) if the last SHOULD is not followed.

## Section 7

This section should actually be included in section 6.5

## Section 10

Consider removing this section as it is rather about the deployment model and not about the P-flag itself.