Skip to main content

Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large Broadcast Networks
draft-ietf-v6ops-dhcp-pd-per-device-08

Revision differences

Document history

Date Rev. By Action
2024-04-04
08 (System) IANA Action state changed to No IANA Actions from In Progress
2024-04-04
08 (System) RFC Editor state changed to EDIT
2024-04-04
08 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-04-04
08 (System) Announcement was received by RFC Editor
2024-04-04
08 (System) IANA Action state changed to In Progress
2024-04-04
08 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2024-04-04
08 Cindy Morgan IESG has approved the document
2024-04-04
08 Cindy Morgan Closed "Approve" ballot
2024-04-04
08 Cindy Morgan Ballot approval text was generated
2024-04-04
08 (System) Removed all action holders (IESG state changed)
2024-04-04
08 Cindy Morgan IESG state changed to Approved-announcement to be sent from IESG Evaluation
2024-04-04
08 Sabrina Tanamal IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2024-04-04
08 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2024-04-04
08 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2024-04-04
08 Murray Kucherawy [Ballot comment]
Thanks to Harald Alvestrand for his ARTART review.  Please take a look and consider his feedback.
2024-04-04
08 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2024-04-03
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2024-04-03
08 Jen Linkova New version available: draft-ietf-v6ops-dhcp-pd-per-device-08.txt
2024-04-03
08 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2024-04-03
08 Jen Linkova Uploaded new revision
2024-04-03
07 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2024-04-03
07 Roman Danyliw
[Ballot comment]
Thank you to Peter Yee for the GENART review.

** Section 13.

  Networks that use the proposed mechanism instead of SLAAC or …
[Ballot comment]
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?
2024-04-03
07 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2024-04-03
07 Éric Vyncke
[Ballot 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, …
[Ballot 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 ;-)
2024-04-03
07 Éric Vyncke [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke
2024-04-01
07 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2024-03-30
07 Erik Kline
[Ballot comment]
# 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 …
[Ballot comment]
# 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"
2024-03-30
07 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2024-03-27
07 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2024-03-27
07 Tim Chown Request for Telechat review by INTDIR Completed: Ready. Reviewer: Tim Chown. Sent review to list.
2024-03-08
07 Klaas Wierenga Request for Telechat review by SECDIR Completed: Ready. Reviewer: Klaas Wierenga.
2024-03-06
07 Peter Yee
Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier …
Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier date.
2024-03-06
07 Peter Yee Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee.
2024-02-29
07 Tero Kivinen Request for Telechat review by SECDIR is assigned to Klaas Wierenga
2024-02-28
07 Bernie Volz Request for Telechat review by INTDIR is assigned to Tim Chown
2024-02-27
07 Éric Vyncke Requested Telechat review by INTDIR
2024-02-27
07 Cindy Morgan Placed on agenda for telechat - 2024-04-04
2024-02-27
07 Warren Kumari Ballot has been issued
2024-02-27
07 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2024-02-27
07 Warren Kumari Created "Approve" ballot
2024-02-27
07 Warren Kumari IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2024-02-26
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2024-02-26
07 Jen Linkova New version available: draft-ietf-v6ops-dhcp-pd-per-device-07.txt
2024-02-26
07 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2024-02-26
07 Jen Linkova Uploaded new revision
2024-02-12
06 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-02-08
06 Klaas Wierenga Request for Last Call review by SECDIR Completed: Ready. Reviewer: Klaas Wierenga. Sent review to list.
2024-02-06
06 Harald Alvestrand Request for Last Call review by ARTART Completed: Almost Ready. Reviewer: Harald Alvestrand. Sent review to list. Submission of review completed at an earlier date.
2024-02-06
06 Harald Alvestrand Request for Last Call review by ARTART Completed: Almost Ready. Reviewer: Harald Alvestrand.
2024-02-06
06 Barry Leiba Request for Last Call review by ARTART is assigned to Harald Alvestrand
2024-02-06
06 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2024-02-06
06 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-v6ops-dhcp-pd-per-device-06, which is currently in Last Call, and has the following comments:

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

IANA has completed its review of draft-ietf-v6ops-dhcp-pd-per-device-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

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
2024-02-04
06 Jürgen Schönwälder Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Jürgen Schönwälder. Sent review to list.
2024-02-02
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Klaas Wierenga
2024-02-01
06 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2024-01-31
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder
2024-01-29
06 Cindy Morgan IANA Review state changed to IANA - Review Needed
2024-01-29
06 Cindy Morgan
The following Last Call announcement was sent out (ends 2024-02-12):

From: The IESG
To: IETF-Announce
CC: draft-ietf-v6ops-dhcp-pd-per-device@ietf.org, tim@qacafe.com, v6ops-chairs@ietf.org, v6ops@ietf.org, warren@kumari.net …
The following Last Call announcement was sent out (ends 2024-02-12):

From: The IESG
To: IETF-Announce
CC: draft-ietf-v6ops-dhcp-pd-per-device@ietf.org, tim@qacafe.com, v6ops-chairs@ietf.org, v6ops@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large Broadcast Networks) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document: - 'Using DHCPv6-PD to Allocate Unique IPv6
Prefix per Client in Large
  Broadcast Networks'
  as Informational RFC

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-02-12. 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 discusses an IPv6 deployment scenario when individual
  clients connected to large broadcast networks (such as enterprise
  networks or public Wi-Fi networks) are allocated unique prefixes via
  DHCPv6 Prefix Delegation (DHCPv6-PD).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcp-pd-per-device/



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




2024-01-29
06 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2024-01-29
06 Warren Kumari Last call was requested
2024-01-29
06 Warren Kumari Last call announcement was generated
2024-01-29
06 Warren Kumari Ballot approval text was generated
2024-01-29
06 Warren Kumari IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2024-01-29
06 Warren Kumari Changed consensus to Yes from Unknown
2024-01-24
06 (System) Changed action holders to Warren Kumari (IESG state changed)
2024-01-24
06 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-01-24
06 Jen Linkova New version available: draft-ietf-v6ops-dhcp-pd-per-device-06.txt
2024-01-24
06 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2024-01-24
06 Jen Linkova Uploaded new revision
2024-01-19
05 Warren Kumari Ballot writeup was changed
2024-01-19
05 Warren Kumari AD Review: https://mailarchive.ietf.org/arch/msg/v6ops/fsYLMqZjeCm-KBRB9egIZ6FrLCQ/
2024-01-19
05 (System) Changed action holders to Warren Kumari, Lorenzo Colitti, Jen Linkova, Xiao Ma (IESG state changed)
2024-01-19
05 Warren Kumari IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2024-01-08
05 Jenny Bui Intended Status changed to Informational from None
2024-01-08
05 XiPeng Xiao
# 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 …
# 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 large email discussion over its lifecycle.  In the end there were a few
individuals that had reservations about this document.  The working group chairs called consensus on this document, which caused some additional emails about this that are documented below.


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


Martin Hunek was concerned about having to adjust his university network address plan from 2009.  It wouldn't support giving host prefixes,
so he was concerned about that aspect of the document.  After some discussion at IETF 118, he send this email (https://mailarchive.ietf.org/arch/msg/v6ops/_HW4E-oGLBZPDR6JfM9nkMHJ1vw/) which states he understands the need but won't be able to deploy it on this network.  I think this was a good outcome from a long technical discussion.


Gert Doering objected with the following thoughts,


"I do consider this actively harmful.  It establishes a "each host gets
a /64" as best practice, disguising as "because existing hosts do not
know other ways" (they do not know how to do DHCPv6-PD in the first place,
so this is a very weak statement)."


His objection is around the /64 prefix boundary which is a long
standing discussion in the IETF between 6MAN/V6OPS.  This draft
does highlight this issue for networks wanted to not use /64 for all host.
The issue he is pointing out that additional drafts will be needed and if
they aren't written it may cause issues with IPv6 deployments.  He does seemed
resigned to allow this draft thru, but wonders about the future.




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.)


I don't think there is extreme discontent with this draft.  Concerns were raised, but not
to a level of 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)?


N/A.  This is a document for IPv6 deployment using existing implementations of DHCPv6 Clients using IA_PD. 


## 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 a v6ops working group document, but was sent to the DHC working group for review.  The DHC working group did send comments back that were addressed by the authors. 


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.


  There were no additional required reviews


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]?


  N/A


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?


  As document shepherd, I reviewed this document to assure that it is following the WG consensus and discussions and is of good quality. In my opinion, the document is ready for  publication.


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?


This is an IPv6 document that passed through both v6ops and dhc working groups. There is no need for subsequent review from other areas.

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?


    The RFC requested is Informational. And, this is appropriate for this
    document as it describes how to utilize DHCPv6 Prefix Delegation to assign prefixes to
    Devices.


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.


I reached out to authors about IPR and they responded they aren’t aware of any.


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, all the authors have expressed interest in being listed.


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.)


    I was not able to find any additional nits.


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


  Yes, every reference that I located had a valid reference.


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


All references are publicly available.


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.


There are no downward references.


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, this document is stand alone.


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]).


This document requires no action from IANA.


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.


N/A


[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/
2024-01-08
05 XiPeng Xiao IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2024-01-08
05 XiPeng Xiao IESG state changed to Publication Requested from I-D Exists
2024-01-08
05 (System) Changed action holders to Warren Kumari (IESG state changed)
2024-01-08
05 XiPeng Xiao Responsible AD changed to Warren Kumari
2024-01-08
05 XiPeng Xiao Document is now in IESG state Publication Requested
2024-01-08
05 XiPeng Xiao
# 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 …
# 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 large email discussion over its lifecycle.  In the end there were a few
individuals that had reservations about this document.  The working group chairs called consensus on this document, which caused some additional emails about this that are documented below.


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


Martin Hunek was concerned about having to adjust his university network address plan from 2009.  It wouldn't support giving host prefixes,
so he was concerned about that aspect of the document.  After some discussion at IETF 118, he send this email (https://mailarchive.ietf.org/arch/msg/v6ops/_HW4E-oGLBZPDR6JfM9nkMHJ1vw/) which states he understands the need but won't be able to deploy it on this network.  I think this was a good outcome from a long technical discussion.


Gert Doering objected with the following thoughts,


"I do consider this actively harmful.  It establishes a "each host gets
a /64" as best practice, disguising as "because existing hosts do not
know other ways" (they do not know how to do DHCPv6-PD in the first place,
so this is a very weak statement)."


His objection is around the /64 prefix boundary which is a long
standing discussion in the IETF between 6MAN/V6OPS.  This draft
does highlight this issue for networks wanted to not use /64 for all host.
The issue he is pointing out that additional drafts will be needed and if
they aren't written it may cause issues with IPv6 deployments.  He does seemed
resigned to allow this draft thru, but wonders about the future.




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.)


I don't think there is extreme discontent with this draft.  Concerns were raised, but not
to a level of 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)?


N/A.  This is a document for IPv6 deployment using existing implementations of DHCPv6 Clients using IA_PD. 


## 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 a v6ops working group document, but was sent to the DHC working group for review.  The DHC working group did send comments back that were addressed by the authors. 


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.


  There were no additional required reviews


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]?


  N/A


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?


  As document shepherd, I reviewed this document to assure that it is following the WG consensus and discussions and is of good quality. In my opinion, the document is ready for  publication.


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?


This is an IPv6 document that passed through both v6ops and dhc working groups. There is no need for subsequent review from other areas.

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?


    The RFC requested is Informational. And, this is appropriate for this
    document as it describes how to utilize DHCPv6 Prefix Delegation to assign prefixes to
    Devices.


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.


I reached out to authors about IPR and they responded they aren’t aware of any.


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, all the authors have expressed interest in being listed.


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.)


    I was not able to find any additional nits.


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


  Yes, every reference that I located had a valid reference.


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


All references are publicly available.


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.


There are no downward references.


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, this document is stand alone.


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]).


This document requires no action from IANA.


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.


N/A


[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/
2024-01-03
05 Timothy Winters
# 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 …
# 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 large email discussion over its lifecycle.  In the end there were a few
individuals that had reservations about this document.  The working group chairs called consensus on this document, which caused some additional emails about this that are documented below.


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


Martin Hunek was concerned about having to adjust his university network address plan from 2009.  It wouldn't support giving host prefixes,
so he was concerned about that aspect of the document.  After some discussion at IETF 118, he send this email (https://mailarchive.ietf.org/arch/msg/v6ops/_HW4E-oGLBZPDR6JfM9nkMHJ1vw/) which states his understands the need but won't be able to deploy it on this network.  I think this was a good outcome from a long technical discussion.


Gert Doering objected with the following thoughts,


"I do consider this actively harmful.  It establishes a "each host gets
a /64" as best practice, disguising as "because existing hosts do not
know other ways" (they do not know how to do DHCPv6-PD in the first place,
so this is a very weak statement)."


His objection is around the /64 prefix boundary which is a long
standing discussion in the IETF between 6MAN/V6OPS.  This draft
does highlight this issue for networks wanted to not use /64 for all host.
The issue he is pointing out that additional drafts will be needed and if
they aren't written it may cause issues with IPv6 deployments.  He does seemed
resigned to allow this draft thru, but wonders about the future.




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.)


I don't think there is extreme discontent with this draft.  Concerns were raised, but not
to a level of 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)?


N/A.  This is a document for IPv6 deployment using existing implementations of DHCPv6 Clients using IA_PD. 


## 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 a v6ops working group document, but was sent to the DHC working group for review.  The DHC working group did send comments back that were addressed by the authors. 


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.


  There were no additional required reviews


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]?


  N/A


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?


  As document shepherd, I reviewed this document to assure that it is following the WG consensus and discussions and is of good quality. In my opinion, the document is ready for  publication.


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?


All the proper IETF working groups and areas have reviewed this document, it’s IPv6 document that passed through both v6ops and dhc working groups.


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?


    The RFC requested is Informational. And, this is appropriate for this
    document as it describes how to utilize DHCPv6 Prefix Delegation to assign prefixes to
    Devices.


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.


I reached out to authors about IPR and they responded they aren’t aware of any.


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, all the authors have expressed interest in being listed.


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.)


    I was not able to find any additional nits.


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


  Yes, every reference that I located had a valid reference.


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


All references are publicly available.


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.


There are no downward references.


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, this document is stand alone.


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]).


This document requires no action from IANA.


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.


N/A


[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/
2023-11-13
05 XiPeng Xiao Notification list changed to tim@qacafe.com because the document shepherd was set
2023-11-13
05 XiPeng Xiao Document shepherd changed to Timothy Winters
2023-11-05
05 Jen Linkova New version available: draft-ietf-v6ops-dhcp-pd-per-device-05.txt
2023-11-05
05 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2023-11-05
05 Jen Linkova Uploaded new revision
2023-11-01
04 XiPeng Xiao IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2023-10-20
04 Jen Linkova New version available: draft-ietf-v6ops-dhcp-pd-per-device-04.txt
2023-10-20
04 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2023-10-20
04 Jen Linkova Uploaded new revision
2023-10-06
03 Jen Linkova New version available: draft-ietf-v6ops-dhcp-pd-per-device-03.txt
2023-10-06
03 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2023-10-06
03 Jen Linkova Uploaded new revision
2023-09-08
02 Jen Linkova New version available: draft-ietf-v6ops-dhcp-pd-per-device-02.txt
2023-09-08
02 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2023-09-08
02 Jen Linkova Uploaded new revision
2023-07-10
01 Jen Linkova New version available: draft-ietf-v6ops-dhcp-pd-per-device-01.txt
2023-07-10
01 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2023-07-10
01 Jen Linkova Uploaded new revision
2023-05-18
00 XiPeng Xiao This document now replaces draft-collink-v6ops-ent64pd instead of None
2023-05-18
00 Jen Linkova New version available: draft-ietf-v6ops-dhcp-pd-per-device-00.txt
2023-05-18
00 XiPeng Xiao WG -00 approved
2023-05-18
00 Jen Linkova Set submitter to "Jen Linkova ", replaces to draft-collink-v6ops-ent64pd and sent approval email to group chairs: v6ops-chairs@ietf.org
2023-05-18
00 Jen Linkova Uploaded new revision