Signaling DHCPv6 Prefix per Client Availability to Hosts
draft-ietf-6man-pio-pflag-12

[Ballot comment]

# É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.

[Ballot comment]
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".

[Ballot comment]
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.

[Ballot comment]
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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-6man-pio-pflag-09. If any part of this review is inaccurate, please let us know.

We understand that, upon approval of this document, there is a single action which we must complete.

In the IPv6 Neighbor Discovery Prefix Information Option Flags registry in the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry group located at:

https://www.iana.org/assignments/icmpv6-parameters/

A single new registration is to be made as follows:

PIO Option Bit: [ TBD-at-Registration ]
Description: P - DHCPv6-PD preferred flag
Reference: [ RFC-to-be ]

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-09-09):

From: The IESG
To: IETF-Announce
CC: 6man-chairs@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-pio-pflag@ietf.org, ek.ietf@gmail.com, ipv6@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Signalling DHCPv6 Prefix per Client Availability to Hosts) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'Signalling DHCPv6 Prefix per Client
Availability to Hosts'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-09-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a "P" flag in the Prefix Information Option
  (PIO) of IPv6 Router Advertisements (RAs).  The flag is used to
  indicate that the network prefers that clients use the draft-ietf-
  v6ops-dhcp-pd-per-device deployment model instead of using individual
  adresses in the on-link prefix assigned using SLAAC or DHCPv6 IA_NA.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-pio-pflag/



No IPR declarations have been submitted directly on this I-D.

# Internet AD comments for draft-ietf-6man-pio-pflag-09
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Comments

### S6.1

* I think the wording here is less clear than it might be regarding what
  activity is supposed to be stopped or continued:

  """
  *  When the length of the list decreases to zero, the host SHOULD
    stop requesting or renewing prefixes via DHCPv6 prefix delegation
    if it has no other reason to do so.
  """

  Perhaps something like:

  """
  *  When the length of the list decreases to zero, the host SHOULD
    stop requesting or renewing prefixes via DHCPv6 prefix delegation
    unless it has some other, unrelated reason to know that is should
    continue requesting or renewing.
  """

  Or something.

* I think this text is less clear than it might about which list of prefixes
  is observed for modifications:

  """
  *  If the host has already received delegated prefix(es) from one or
    more servers, then any time a prefix is added to or removed from
    the list, ...
  """

  Perhaps something like:

  """
  *  If the host has already received delegated prefix(es) from one or
    more servers, then any time a prefix is added to or removed from
    the list of prefixes with the P-flag set, ...
  """

### S6.2

* It might be better to be more explicit about when "prefix" refers to the
  PIO with the P-flag set and when it refers to a PD-delegated prefix.

  """
  *  The host MAY form as many IPv6 addresses from the [PD-delegated] prefix
    as it chooses.
  """

* Should we explicitly say that the re-advertisement of prefixes MUST NOT
  be done via the same interface over which the PD delegation was obtained?

  """
  *  The host MAY use the prefix to allow devices directly connected to
    it to obtain IPv6 addresses, e.g., by routing traffic for that
    prefix to the interface and sending a Router Advertisement
    containing the prefix on the interface.
  """

  This just says "the interface"; I think perhaps if it said "another
  interface" that might convey the requisite behaviour?  The next paragraph
  says not to forward dst addresses within the delegated prefix to the
  delegating interface, but it should also not even advertise, IMHO.

## Nits

### Abstract

* I-D nits says the doc should mention updating 4862 in the Abstract.

### S3

* "would be disruptive for applications that are using them" ->
  "would be disruptive for any applications that had begun using them"?

### S4

* "indicates that that the network" ->
  "indicates that the network" or "indicates that that network"

Signalling DHCPv6 Prefix per Client Availability to Hosts
draft-ietf-6man-pio-pflag-09
https://datatracker.ietf.org/doc/html/draft-ietf-6man-pio-pflag-09

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad
  agreement?

This document had a lot of discussion in the working group, with many
strong opinions in support as well as raising issues.  The last call generated
about 255 direct emails in response, many related emails, and
six new versions of the draft were published resolving issues raised.  The authors were
responsive to the issues raised and there is now support to advance from the
people who raised issues.

For example:

https://mailarchive.ietf.org/arch/msg/ipv6/46Y-nXvoZydf2WeHgpA-RL5Dr00
https://mailarchive.ietf.org/arch/msg/ipv6/3lEwKlJCVA5oBnrC_b0e4KDteic


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were a number of issues raised, these were responded to on the list
by the authors.    The laset of issues were raised by Ole Troan and
documented in a git hub issue tracker

https://github.com/ietf-6man/pio-pflag/issues?q=is%3Aclosed

These were responded to by the authors.  These issues were reviewed by
the document Shepard and Internet ADs, and closed by the document Shepard.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No one has threatened an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is an in progress open source implementation and unit test CL on Android:

    https://r.android.com/2864098


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is the protocol specification for a document from V6OPS:

https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-dhcp-pd-per-device-08

The V6OPS document was approved by the IESG and is now in the RFC-Editor
queue.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Yang model.


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this document is ready to advance.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this
    intent?

Proposed Standard.  This document defines a "P" flag in the Prefix
Information Option (PIO) of IPv6 Router Advertisements (RAs) and needs to
be a protocol standard.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
   
No IPR listed on this draft.  All authors have confirmed the IPR
disclosure requirements.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, and only four authors.


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The document updates RFC4862, but this is not called out in the abstract
and Introduction.  I have asked the authors to fix this in the next
version.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Looks good.  All normative references are published RFCs.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.


17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.


No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is
    discussed.

No.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document ask for a new flag in the Prefix Information Option (PIO) of
IPv6 Router Advertisements (RAs).  IANA considerations text is consistant with this.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries are created.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Signalling DHCPv6 Prefix per Client Availability to Hosts
draft-ietf-6man-pio-pflag-09
https://datatracker.ietf.org/doc/html/draft-ietf-6man-pio-pflag-09

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad
  agreement?

This document had a lot of discussion in the working group, with many
strong opinions in support as well as raising issues.  The last call generated
about 255 direct emails in response, many related emails, and
six new versions of the draft were published resolving issues raised.  The authors were
responsive to the issues raised and there is now support to advance from the
people who raised issues.

For example:

https://mailarchive.ietf.org/arch/msg/ipv6/46Y-nXvoZydf2WeHgpA-RL5Dr00
https://mailarchive.ietf.org/arch/msg/ipv6/3lEwKlJCVA5oBnrC_b0e4KDteic


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were a number of issues raised, these were responded to on the list
by the authors.    The laset of issues were raised by Ole Troan and
documented in a git hub issue tracker

https://github.com/ietf-6man/pio-pflag/issues?q=is%3Aclosed

These were responded to by the authors.  These issues were reviewed by
the document Shepard and Internet ADs, and closed by the document Shepard.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No one has threatened an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is an in progress open source implementation and unit test CL on Android:

    https://r.android.com/2864098


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is the protocol specification for a document from V6OPS:

https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-dhcp-pd-per-device-08

The V6OPS document was approved by the IESG and is now in the RFC-Editor
queue.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Yang model.


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this document is ready to advance.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this
    intent?

Proposed Standard.  This document defines a "P" flag in the Prefix
Information Option (PIO) of IPv6 Router Advertisements (RAs) and needs to
be a protocol standard.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

No IPR listed on this draft.  All authors, except for David Lamparter, have
confirmed disclosure requirements.  The Shepard writeup will be updated once he does.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, and only four authors.


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The document updates RFC4862, but this is not called out in the abstract
and Introduction.  I have asked the authors to fix this in the next
version.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Looks good.  All normative references are published RFCs.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.


17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.


No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is
    discussed.

No.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document ask for a new flag in the Prefix Information Option (PIO) of
IPv6 Router Advertisements (RAs).  IANA considerations text is consistant with this.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries are created.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Signalling DHCPv6 Prefix per Client Availability to Hosts
draft-ietf-6man-pio-pflag-09
https://datatracker.ietf.org/doc/html/draft-ietf-6man-pio-pflag-09

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad
  agreement?

This document had a lot of discussion in the working group, with many
strong opinions in support as well as raising issues.  The last call generated
about 255 direct emails in response, many related emails, and
six new versions of the draft were published resolving issues raised.  The authors were
responsive to the issues raised and there is now support to advance from the
people who raised issues.

For example:

https://mailarchive.ietf.org/arch/msg/ipv6/46Y-nXvoZydf2WeHgpA-RL5Dr00
https://mailarchive.ietf.org/arch/msg/ipv6/3lEwKlJCVA5oBnrC_b0e4KDteic


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were a number of issues raised, these were responded to on the list
by the authors.    The laset of issues were raised by Ole Troan and
documented in a git hub issue tracker

https://github.com/ietf-6man/pio-pflag/issues?q=is%3Aclosed

These were responded to by the authors.  These issues were reviewed by
the document Shepard and Internet ADs, and closed by the document Shepard.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No one has threatened an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is an in progress open source implementation and unit test CL on Android:

    https://r.android.com/2864098


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is the protocol specification for a document from V6OPS:

https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-dhcp-pd-per-device-08

The V6OPS document was approved by the IESG and is now in the RFC-Editor
queue.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Yang model.


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this document is ready to advance.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this
    intent?

Proposed Standard.  This document defines a "P" flag in the Prefix
Information Option (PIO) of IPv6 Router Advertisements (RAs) and needs to
be a protocol standard.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

No IPR listed on this draft.  All authors, except for David Lamparter, have
confirmed disclosure requirements.  The Shepard writeup will be updated once he does.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, and only four authors.


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The document updates RFC4862, but this is not called out in the abstract
and Introduction.  I have asked the authors to fix this in the next
version.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Looks good.  All normative references are published RFCs.


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.


17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.


No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is
    discussed.

No.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document ask for a new flag in the Prefix Information Option (PIO) of
IPv6 Router Advertisements (RAs).  IANA considerations text is consistant with this.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries are created.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/