# Document Shepherd Write-Up for Group Documents
This uses the shepherd write-up template version dated 4 July 2022.
Below are the answers to the shepherd’s questions regarding this document.
## 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?**
The working group consensus was broad. In discussions on the 6LoWPAN and RPL
mailing lists, most participants actively contributed to the evolution of the
draft. There was general agreement on the need to extend address registration
to cover prefixes, and improvements were made iteratively based on widespread
feedback rather than the viewpoints of only a few individuals.
2. **Was there controversy about particular points, or were there decisions
where the consensus was particularly rough?**
While some discussion took place regarding the use and encoding of the new
flags (for example, the F flag and the extended use of the P-field for prefix
registrations), the WG discussions were productive. The alternative approaches
were debated with data and simulation results where available. In the end, the
consensus reflected a balanced choice that improved backward compatibility and
interoperability with existing implementations. There were no extremely
contentious points or rough consensus blocks.
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.)**
To date, there have been no threats of appeal or indications of extreme
discontent regarding this document.
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)?**
While the document provides a comprehensive framework for prefix registration,
there are currently no known implementations.
## 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 closely interacts with technologies
developed in other IETF working groups, particularly those related to IPv6
Neighbor Discovery and RPL (Routing Protocol for Low-Power and Lossy Networks).
Reviews from these 6man h have been solicited and incorporated to ensure
compatibility and coherence across protocols. Also early GenART and INTDir
directorates have been consulted and completed early reviews.
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.** The document does not specify the need for formal expert reviews
such as MIB Doctor or YANG Doctor.
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]?** The document does not contain a YANG module.
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.**
The document primarily details protocol extensions and updated message formats,
rather than formal encodings such as CBOR’s CDDL or BNF rules. Automated text
checks (using idnits for instance) have been run and minor nits were addressed
in the revision process. There were no unresolved issues with formal syntax
present in the document.
## 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?**
Based on my review, the document is well-written, complete, and correctly
designed. It effectively addresses the need for prefix registration in IPv6
Neighbor Discovery and is ready for submission to the responsible Area Director.
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?**
Common issues related to normative versus informative references, clarity in
terminology, and security considerations have been identified and addressed in
the draft. Specific checks against the IETF's "Content Guidelines" have been
performed, ensuring compliance with RFC formatting and reference standards.
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 document is intended for publication as a Standards Track RFC. This
designation is appropriate given its purpose to update existing standards
(RFC4861, RFC8505, RFC8928, RFC7400) and define new normative behaviors. The
Datatracker state attributes accurately reflect this intent.
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.**
All authors have been reminded of their IPR disclosure obligations as described
in BCP 79. To the best of my knowledge, no IPR disclosures have been filed
related to this document.
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.** The sole author, Pascal
Thubert, has confirmed his willingness to be listed as such.
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 has been reviewed
using the idnits tool. No significant issues were found, and any minor nits
have been addressed in the current version.
15. **Should any informative references be normative or vice-versa? See the
[IESG Statement on Normative and Informative References][16].** The references
have been reviewed to ensure appropriate classification as normative or
informative. No changes are necessary.
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 normative references are to RFCs and publicly avaiable
documents.
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 normative downward references in this document.
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, all normative references are
to existing RFCs. There are no references to documents in an unclear state that
would impact the publication of this draft.
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.**
Yes, this document updates RFC 4861, RFC 6550, RFC 6553, RFC 7400, RFC 8505,
RFC 8928 and RFC 9010. The Datatracker metadata correctly reflects this, and
these RFCs are listed in the title page and discussed in the abstract and
introduction. The relationship to these RFCs is explicitly covered in the
document, ensuring clarity on how this update affects them.
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, allocation
procedures, and a reasonable name (see [RFC 8126][11]).**
The IANA considerations section has been reviewed for consistency with the
document body. It correctly specifies updates to existing IANA registries.
All referenced IANA registries are clearly identified, and any new registry
follows the guidelines in RFC 8126. The document provides clear
instructions for allocations, ensuring smooth implementation.
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 being created; instead, existing registries are being updated
with new values. As such, there are no additional Designated Expert Reviews
required beyond those applicable to the **ICMPv6 Parameters** and **6LoWPAN
Capability Bits** registries. The instructions provided to the designated
experts are clear and adhere to standard IANA procedures.
[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/