Updates to Dynamic IPv6 Multicast Address Group IDs
draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-13

[Ballot comment]
Thank you to Sue Hares for the GENART review.

** idnits reports:
  -- The draft header indicates that this document updates RFC3307, but the
    abstract doesn't seem to directly say this. 

[Roman] Please explicitly state that this document updates RFC3307.

  == The document doesn't use any RFC 2119 keywords, yet seems to have RFC
    2119 boilerplate text.

[Roman] Remove the boilerplate text.

** Abstract.  Editorial.
  It recommends
  replacing these allocations with a new IANA registry in the IPv6
  Multicast Address Space registry group.

What does it mean to have a recommendation to replace allocations? Doesn’t it define a new allocation?  The current text reads like a suggestion is being made.

** Section 3.  Consider citing Section 4.1 and 4.2 of RFC8126 to explain the “Private Use” and “Experimental” ranges.

[Ballot comment]
Thanks to the WG and authors for their work on this document.

I have a few minor comments that should be fixed before publication.

1) No BCP14 keywords seem to be used in the document. Please remove that template and those references.

2) RFC2908 has been obsoleted by RFC6308

3) Section 1:
s/IPv multicast address/IP multicast address

[Ballot comment]

I note the Shepherd writeup says "Majority of the working group is silent, but believe most of the WG silently support it. No one is against." - This seems a very weak position for a PS, and perhaps reflects a lack of review - see Eric's comment on INTAREA.

Abstract
The wording used in the abstract seems to speculate about possible recommendations, and would be better written with terms that "define" and "specify":
/It recommends replacing these allocations with a new registry/ - could this be: /recommends/replaces/?
/The document also suggests initial contents of the new registry:/ - could this be: /suggests/defines/?

The GENART review notes several concerns around the details of the requested allocations. Please check carefully and ammend these.

[Ballot comment]
# Internet AD comments for draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-12
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/

## Comments

* Find the referencing of RFC 4291 to be confusing, as I can't see how this
  document connect the group ID to the 4291 prefix ff02::1: for
  this purpose.

[Ballot comment]
"Abstract", paragraph 0
>    This document describes limitations of the existing range of dynamic
>    IPv6 multicast addresses specified in RFC3307.  It recommends
>    replacing these allocations with a new IANA registry in the IPv6
>    Multicast Address Space registry group.  The document also defines
>    initial contents of the new registry: a reduced allocation for MADCAP
>    (RFC2730), a range for SSM, a Private Use range, a range for
>    Experimental Use, and Solicited-Node multicast addresses (which were
>    not previously noted in RFC3307, Allocation Guidelines for IPv6
>    Multicast Addresses).

Generally, the Abstract clearly states if the document is updating or obsoleting another document. This one mentions the document, but not that it is being updated. It is only later in the Introduction that you learn that RFC3307 is being updated.

I also agree with Gorry that for a PS document, the use of words such as "recommends" is a poor choice.

Section 1, paragraph 2
>    Only one server allocation protocol has been defined at the time of
>    writing (see [RFC2730]), but
>    [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] advocates developing a
>    decentralized, zero-configuration host allocation protocol.  This
>    document updates Section 4.3 of [RFC3307] to allow multiple dynamic
>    allocation protocols to coexist on the same network, and so that
>    dynamic IPv6 multicast group ID ranges better align with current
>    practices for protocol number assignment.

I find the last sentence of the paragraph to be confusing. Which "current practices" are being referred to? Can the sentence be simplified to say something like:
"... on the same network, and to enable that the dynamic IPv6 multicast group IP ranges suggested in this document should be followed."

Section 2, paragraph 2
>    However, SSM is not universally supported (see [RFC4607], Section 6
>    and [RFC8815], Section 3.1).  This document defines a range of
>    dynamic IPv6 multicast group IDs for use in environments that do
>    support SSM.

This section seems to be justifying why a range of addresses should be assigned for SSM, till it does not, based on the first sentence of the above paragraph. If SSM is not widely deployed, why not return the range to unassinged pool and maybe later, when the SSM usage picks up, a range could be allocated for it.

Section 4, paragraph 0
>    This document reduces the range of group ID values available for
>    MADCAP ([RFC2730]).  At the time of writing, there is only one known
>    implementation of MADCAP, and there are no known large-scale
>    deployments.  Any implementations of MADCAP (known or otherwise)
>    should be updated to reflect the new group ID range set forth in
>    Table 2.  Any existing deployments of MADCAP should either use an
>    updated implementation or operate in an environment without other
>    IPv6 multicast address allocation protocols.

I will note that the Shepherd report, on the question of any existing implementation says "Nothing to implement here". While I agree that it is not protocol implementation in a traditional sense of the word, nevertheless, this document does make a note of how existing implementations could be affected by the new allocation scheme. The Shepherd report should be updated to reflect that.

This document does not use RFC2119 keywords, but contains the RFC8174
boilerplate.

The IANA review of this document seems to not have concluded yet.

No reference entries found for these items, which were mentioned in the text:
[avoiding].

-------------------------------------------------------------------------------
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 1, paragraph 2
>    This document adheres to the IPv multicast address architecture
>    outlined in [RFC4291], [RFC3307], [RFC7371], et al.

What is "IPv"?

Reference [RFC2908] to RFC2908, which was obsoleted by RFC6308 (this may be on
purpose).

Document references draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-11, but -13 is
the latest available revision.

Found non-HTTP URLs in the document:

* lispers.net

These URLs in the document did not return content:

* lispers.net

[Ballot comment]
Hi Nate, Dino, and Mike,

Thank you for the discussion and for the changes.

The changes made in [1] addresses all the comments in my previous ballot [2]. Much appreciated.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10&url2=draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-12&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/pim/jJhkEw4kOdazy1-p7_Ou5a2JD-I/

[Ballot comment]
Thanks for the work in this document.

I STRONGLY really regret that this I-D was not in int-area and that the WGLC/CfA were not forwarded to int-area (AFAIK). In my opinion, it *does not fit* the PIM WG charter as it is not about protocol specifications.

But, the most important thing is the content and not the 'wrong' process.

Thanks also to Daniel Migault for his INT directorate review: https://datatracker.ietf.org/doc/review-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10-intdir-telechat-migault-2026-02-19/ and I have to read the authors' response.

Some non-blocking comments:

# Abstract

In a PS, s/the document also suggests/the document also defines/

Also be explicit on how the I-D updates RFC 3307.

# Section 2

s/for destination address G/for destination *group* address G/ ?

# Section 3

Please expand MADCAP.

# Section 5

Please use the (new) correct name rather than ""IPv6 Multicast Address Space Registry", also add a reference URI.

# Section 6

`National Marine Electronics Association` from which country ?

[Ballot discuss]
Hi Nate, Dino, and Mike,

Thank you for the effort put into this document.

Thank you to Dhruv Dhody for the OPSDIR review and for the authors for engaging and addressing the review.

Please find below some points for DISCUSSion:

# Be explicit about the update to 3307

Can we please indicate what is updated in 3307 and how one should interpret this?

For example, can we say that we update Section 4.3 of 3307 as follows

OLD:
Dynamic IPv6 multicast addresses can be allocated by an allocation server or by an end-host.

NEW:
Dynamic IPv6 multicast addresses can be allocated by an allocation server, an end-host, or coordinated via a global registry (e.g., IANA-maintained registry).

# De we need a range for experimentations?

CURRENT:
    +-----------------------+-----------------+-----------------------+
    | 0xFE000000-0xFEFFFFFF | Private Use    | [This document]      |
    +-----------------------+-----------------+-----------------------+

As SSM is the recommended inter-domain case (and putting aside real deployment cases): shouldn’t there be a range for experimentation? Such use doesn’t fall under private use.

# Operational Impact and Backward Compatibility

CURRENT:
  This reduces the range previously available for MADCAP, while still
  providing a sizable allocation. 

A key point missing in the spec is the backward compatibility of the changes.

Please add a discussion to a NEW Operational Considerations Section whether this is an issue or not.

More generally, I’d hope we can have a discussion recorded here about what are the implications of this changes, discuss if there is anything that is broken or all is OK (if so, say it explicitly there).

The use of the group ids is not impacted. Maybe indicate how the new mode will work/expected to work.

# IANA Actions

## Clarity

CURRENT:
  The "Standards Action" registration policy is required to update the
  registry. 

I guess you meant only 0x90000000-0xEFFFFFFF range, not all any entry in the table. Please check.

## Please s/MUST/must in the following per the guidance in https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ (Inappropriate Uses of Key Words
).

CURRENT:
      Values MUST be
      within the range for dynamic multicast address allocation
      mechanisms specified in [RFC3307]: 0x80000000 to 0xFFFFFFFF.

## RFC3307 as an additional reference to the new registry

Rather than having the text above under the range value, I think that this is better if this is placed as a note in the registry itself + add 3307 as an additional reference to the registry.

# Normative specification

CURRENT:
7.2.  Informative References

  [RFC2730]  Hanna, S., Patel, B., and M. Shah, "Multicast Address
              Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
              DOI 10.17487/RFC2730, December 1999,
              .

  [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, .

  [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
              .


## 2730 is normative IMO to assess the impact of the change on MADCAP.

## 4291 is needed for Solicited-Node multicast

## 4607: I’m less sure about this one, but this is the only reference we have here for SSM. A normative reference for SSM is needed, otherwise.

[Ballot comment]
# General: Correct Registry Name

Please update “IPv6 Multicast Address Space Registry” registry to “IPv6 Multicast Address Space” to use the exact name as maintained by IANA: https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

# Abstract

## Add title of RFC cited in the abstract so that we have a self-contained abstract per the following guidance:

  An Abstract is not a substitute for an Introduction; the RFC should
  be self-contained as if there were no Abstract.  Similarly, the
  Abstract should be complete in itself.  Given that the Abstract will
  appear independently in announcements and indices, uncommon
  abbreviations should be expanded, and mentions of other RFCs within
  the Abstract should include both an RFC number and either the full or
  short title.

## s/suggests/defines

# IPv6 Multicast Address Architecture

## I would add a pointer to the multicast address architecture (RFC7371), as that with 4291 are where to look for these matters. This would help set a context for where “global id” intervenes in an IPv6 multicast address.

## Also, I suggest we add a mention that this document adheres to that architecture

# Section 2

## No network-wide coordination

CURRENT:
  This reduces
  the need for coordinated dynamic assignment of G because multiple
  distinct hosts could use the same value for G and traffic would still
  be directed to the node that requested the stream.

Maybe add a pointer as well to the rfc8815#section-3.2.2 (BCP 229) as it discusses that specific point. This would back this statement.

## SSM Deployment

CURRENT:
  However, SSM is not universally supported ([RFC4607], Section 6 lists
  one example). 

I would refer to rfc8815#section-3.1 as it is more recent than 4607 and reflect more recent deployment status.

# nits

## Abstract

OLD: allocations with a new registry in

NEW: allocations with a new IANA registry in

## Introduction

OLD: Only one server allocation protocol has been defined so far

NEW:    Only one server allocation protocol has been defined at the time of writing

## IANA

OLD: IANA should create

NEW: This document requests IANA to create

Please let me know if any clarification is needed.

Cheers,
Med

[Ballot comment]
This is a partial set of comments... I plan to update my position.

I note the Shepherd writeup says "Majority of the working group is silent, but believe most of the WG silently support it. No one is against." - This seems a very weak position for a PS.

Abstract
The wording used in the abstract seems to speculate about possible recommendations, and would be better written with terms that "define" and "specify":
/It recommends replacing these allocations with a new registry/ - could this be: /recommends/replaces/?
/The document also suggests initial contents of the new registry:/ - could this be: /suggests/defines/?

The GENART review notes several concerns around the details of the requested allocations.

[Ballot comment]
This is a partial set of comments... I plan to update my position.

I note the Shepherd writeup says "Majority of the working group is silent, but believe most of the WG silently support it. No one is against." - This seems a very weak position for a PS.

The wording used iun thge abstract seems to speculate about the possible recommendations, and would be better written with terms that "define" and "specify".

Abstract
/It recommends
  replacing these allocations with a new registry/
/reommeds/replaces/?
/The document also suggests initial contents of the new registry:/
-is /suggests/defines/?

The GENART review notes several concerns around the details of the requested allocations.

# 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?
Majority of the working group is silent, but believe most of the WG silently support it. No one is against.

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

No controversy.

I was asked to point out why I believe this is in charter. The pim wg charter
includes the item 7) Develop multicast group address allocation protocols.
As part of this work, the WG realized that it would be ideal to create a registry
as there may be multiple allocation protocols, and also that it makes sense to have
different ranges for different mechanisms to avoid conflicts. The address space is
large, so there is no need to use the same ranges for multiple algorithms.


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.

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

Nothing to implement here.

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

No.

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

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?

Yes. Document is clearly written, complete and ready to be handed off.

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?
No such issues.

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. Updating proposed standard document. New IANA registry.

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.
Yes, authors have stated they are not aware of any IPR.

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

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

No nits. Except 2119 keywords are not used, boiler plate could be removed.
In that case, references to RFC 2119 and RFC 8174 can also be removed.

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

No.

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

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.
Update of 3307. This is listed on the title page and also in the abstract.

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

They look clear to me. They include where the registry should be created,
initial content, policy and registry name.

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 expert review. Requires standards action.

[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/

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-07. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, a new registry is to be created called the Dynamic Multicast Group IDs registry. The new registry will be located in the IPv6 Multicast Address Space registry group located at:

https://www.iana.org/assignments/ipv6-multicast-addresses/

The new registry will be managed via Standards Action as defined by RFC8126.

There are initial registrations in the new registry as follows:

Range Description Reference
------+-----------+----------
0x80000000-0x8FFFFFFF MADCAP [RFC2730]
0x90000000-0xFDFFFFFF Unassigned
0xFE000000-0xFEFFFFFF Private Use [ RFC-to-be ]
0xFF000000-0xFFFFFFFF Solicited-Node multicast addresses [RFC4291; Section 2.7.1]

Second, in the Unicast-based (Including SSM) Multicast Group IDs registry also in the IPv6 Multicast Address Space registry group located at:

https://www.iana.org/assignments/ipv6-multicast-addresses/

the existing registration for address range:

FF3X:0:0:0:0:0:8000:0-FF3X:0:0:0:0:0:FFFF:FFFF

will have its description changed to:

This range uses dynamic assignment according to the protocols listed in the new "Dynamic Multicast Group IDs

and its reference will be changed to [ RFC-to-be ].

In addition, the registration procedure for the registry will note that:

The FF3X:0:0:0:0:0:8000:0-FF3X:0:0:0:0:0:FFFF:FFFF range uses dynamic assignment according to the protocols listed in the new "Dynamic Multicast Group IDs" registry and include a reference to [ RFC-to-be ].

We understand that these are the only actions 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 2025-11-28):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id@ietf.org, gunter@vandevelde.cc, pim-chairs@ietf.org, pim@ietf.org, stig@venaas.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Updates to Dynamic IPv6 Multicast Address Group IDs) to Proposed Standard


The IESG has received a request from the Protocols for IP Multicast WG (pim)
to consider the following document: - 'Updates to Dynamic IPv6 Multicast
Address Group IDs'
  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 2025-11-28. 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


  Describes limitations of the existing range of dynamic IPv6 multicast
  addresses specified in RFC3307.  Recommends replacing these
  allocations with a new registry in the IPv6 Multicast Address Space
  Registry registry group.  Suggests initial contents of the new
  registry: a reduced allocation for MADCAP (RFC2730), a Private Use
  range, and Solicited-Node multicast addresses (which were not
  previously noted in RFC3307).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id/



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

# 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?
Majority of the working group is silent, but believe most of the WG silently support it. No one is against.

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

No controversy.

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.

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

Nothing to implement here.

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

No.

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

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?

Yes. Document is clearly written, complete and ready to be handed off.

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?
No such issues.

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. Updating proposed standard document. New IANA registry.

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.
Yes, authors have stated they are not aware of any IPR.

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

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

No nits. Except 2119 keywords are not used, boiler plate could be removed.
In that case, references to RFC 2119 and RFC 8174 can also be removed.

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

No.

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

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.
Update of 3307. This is listed on the title page and also in the abstract.

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

They look clear to me. They include where the registry should be created,
initial content, policy and registry name.

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 expert review. Requires standards action.

[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/

# 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?
Majority of the working group is silent, but believe most of the WG silently support it. No one is against.

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

No controversy.

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.

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

Nothing to implement here.

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

No.

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

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?

Yes. Document is clearly written, complete and ready to be handed off.

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?
No such issues.

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. Updating proposed standard document. New IANA registry.

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.
Yes, authors have stated they are not aware of any IPR.

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

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

No nits. Except 2119 keywords are not used, boiler plate could be removed.
In that case, references to RFC 2119 and RFC 8174 can also be removed.

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

No.

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

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.
Update of 3307. This is listed on the title page and also in the abstract.

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

They look clear to me. They include where the registry should be created,
initial content, policy and registry name.

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 expert review. Requires standards action.

[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/