Closing the RTP Payload Format Media Types IANA Registry
draft-ietf-avtcore-rtp-payload-registry-04

[Ballot comment]
I support Gunter's discuss and agree with Éric's comments.

It seems the document need not be a proposed standard to update an informational document and close a registry.

[Ballot comment]
Thanks for the work done in this document, let's indeed close a redundant registry (this is always dangerous to have duplicate/redundant pieces of information).

Like Gunter, I think that "informational" would have been enough pending an expert review, but I do not mind too much as the origin of this IANA registry is rather unclear indeed.

Strong suggestion to use the OLD / NEW format in section 3 (if only to be consistent with the end of section 4).

Please remove section 2 as no uppercase terms of BCP14 appears to be used in the I-D.

[Ballot comment]
This document does not use RFC2119 keywords, but contains the RFC8174
boilerplate.

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

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

"Abstract", paragraph 1
>    It has been observed that specifications of new Real-time Transport
>    Protocol (RTP) payload formats often forget to specify registration
>    of the format's media type in the IANA registry "RTP Payload Formats
>    Media Types" as recommended by RFC 8088.  In practice this has no
>    real impact.  One reason is that the Media Types registry is the
>    crucial registry to register any Media Type to establish the media
>    type used to identified the format in various signaling usage.

s/to identified/to identify/

These URLs in the document can probably be converted to HTTPS:

* http://www.iana.org/assignments/rtp-parameters

Section 4, paragraph 5
> er motivation see (RFC-TBD1)." In addition it is requested that the existing
>                                  ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "addition".

[Ballot comment]
This document does not use RFC2119 keywords, but contains the RFC8174
boilerplate.

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

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

"Abstract", paragraph 1
+ s/to identified/to identify/

"Abstract", paragraph 1
>    It has been observed that specifications of new Real-time Transport
>    Protocol (RTP) payload formats often forget to specify registration
>    of the format's media type in the IANA registry "RTP Payload Formats
>    Media Types" as recommended by RFC 8088.  In practice this has no
>    real impact.  One reason is that the Media Types registry is the
>    crucial registry to register any Media Type to establish the media
>    type used to identified the format in various signaling usage.

s/to identified/to identify/

These URLs in the document can probably be converted to HTTPS:

* http://www.iana.org/assignments/rtp-parameters

Section 4, paragraph 5
> er motivation see (RFC-TBD1)." In addition it is requested that the existing
>                                  ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "addition".

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-avtcore-rtp-payload-registry-04

# line numbers are derived with the idnits tool https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-payload-registry-04.txt

# After reviewing the document, I did not identify any significant typographical errors. The document is short and to the point.

# idnits gives some warnings about the references

# You will find a blocking DISCUSS requesting to clarify why IETF stream "proposed standard" was selected and 2 non-blocking comments.

#DISCUSS COMMENTS
#================

# The shepherd writeup indicates that the document is proposed Standards Track, representing an upgrade from Informational status, driven by its impact on RFC 8008. However, a search within the document reveals no references to RFC 8008. Additionally, the document does not define any formal procedures, nor does it specify a protocol. Including text that explains the reasoning behind classifying this document as a Proposed Standard instead of Informational would enhance understanding for documentation purposes.

[Ballot comment]
#DETAILED COMMENTS
#=================
## classified as [minor] and [major]

11 Abstract

13   It has been observed that specifications of new Real-time Transport
14   Protocol (RTP) payload formats often forget to specify registration
15   of the format's media type in the IANA registry "RTP Payload Formats
16   Media Types" as recommended by RFC 8088.  In practice this has no
17   real impact.  One reason is that the Media Types registry is the
18   crucial registry to register any Media Type to establish the media
19   type used to identified the format in various signaling usage.

21   This document resolves the situation by first updating the RTP
22   Payload Format Media Type registry to include all the known RTP
23   payload formats at the time of writing, then it closes this IANA
24   Registry for any future registration.  Beyond instructing IANA to
25   close this registry, the instructions to authors in RFC 8088 are
26   updated to reflect this.

[minor]

GV> What about the following rewrite making the abstract higher level explaining the intent of the document. The valuable first paragraph seems more at its place within an introduction section. A possible derived shortened abstract proposal:

"
This document specifies the procedures for registering media types for Real-time Transport Protocol (RTP) payload formats with the Internet Assigned Numbers Authority (IANA). It updates and clarifies the guidelines for authors defining new RTP payload formats (rfc8088), ensuring consistent and well-documented registrations. By standardizing the registration process and media type specifications, this document facilitates interoperability and efficient implementation of RTP-based multimedia applications across diverse platforms and systems.
"

111   It is unclear how the "RTP Payload formats Media Types" [RTP-FORMATS]
112   registry came into existence.  The registry references [RFC4855] as
113   the instructions for this registry.  However, reviewing that RFC we
114   have been unable to find any text that defines its purpose and rules.
115   Further attempts to find how the registry was created have failed to
116   find any reference to its creation.  It is likely this was created
117   based on email or AD request.  Thus, there is no known existing
118   specification for this registry that needs to be updated when closing
119   the registry.

[minor] A small rewrite proposal to make the text more formal sounding:

"
The origins of the "RTP Payload Formats Media Types" registry, as referenced in [RTP-FORMATS], are unclear. The registry cites [RFC4855] as providing the instructions for its maintenance. However, upon reviewing RFC 4855, no text has been found that defines the registry's purpose and operational rules. Further attempts to trace the registry's creation have failed to uncover any references to its establishment. It is likely that the registry was created based on correspondence via email or at the request of an Area Director (AD). Consequently, there is no known existing specification for this registry that requires updating upon its closure.
"

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

IANA has completed its review of draft-ietf-avtcore-rtp-payload-registry-03. If any part of this review is inaccurate, please let us know.

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

First, in the RTP Payload Format Media Types registry in the Real-Time Transport Protocol (RTP) Parameters registry group located at:

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

the following RTP payload types will be added to the registry:

Media Type Sub Type Clock Rate (Hz) Channels (audio) Reference
application flexfec RFC8627
audio EVRCNW 16000 RFC6884
audio EVRCNW0 16000 RFC6884
audio EVRCNW1 16000 RFC6884
audio aptx RFC7310
audio opus 48000 RFC7587
audio G711-0 RFC7650
audio flexfec RFC8627
text flexfec RFC8627
text ttml+xml RFC8759
video VP8 90000 RFC7741
video AV1 90000 https://www.iana.org/assignments/media-types/video/AV1
video HEVC 90000 RFC7798
video smpte291 RFC8331
video VVC 90000 RFC9328
video EVC 90000 RFC9584
video flexfec RFC8627

Second, also in the RTP Payload Format Media Types registry in the Real-Time Transport Protocol (RTP) Parameters registry group located at:

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

the following two RTP payload types will be updated in the registry:

Media Type: audio
Sub Type: MP4A-LATM
Clock Rate (Hz):
Channels (audio):
Reference: RFC6416

Media Type: video
Sub Type: MP4V-ES
Clock Rate (Hz): 90000
Channels (audio):
Reference: RFC6416

Third, the RTP Payload Format Media Types registry in the Real-Time Transport Protocol (RTP) Parameters registry group located at:

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

will then be marked closed to any further registrations and its entry on the IANA Matrix will also be marked closed. The following Note will be added to the top of the registry:

This registry has been closed as it was considered redundant as all RTP Payload formats are part of the Media Types registry . For further motivation see [ 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 2024-10-07):

From: The IESG
To: IETF-Announce
CC: avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com, draft-ietf-avtcore-rtp-payload-registry@ietf.org, zahed.sarker.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Closing the RTP Payload Format Media Types IANA Registry) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document: - 'Closing the
RTP Payload Format Media Types IANA Registry'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-10-07. 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


  It has been observed that specifications of new RTP payload formats
  often forget to register themselves in the IANA registry "RTP Payload
  Formats Media Types".  In practice this has no real impact.  One
  reason is that the Media Types registry is the crucial registry to
  register any Media Type to establish the media type used to
  identified the format in various signaling usage.

  This document resolves the situation by first updating the RTP
  Payload Format Media Type registry to include all the known RTP
  payload formats at the time of writing, then it closes this IANA
  Registry for any future registration.  Beyond instructing IANA to
  close this registry, the instructions to authors in RFC 8088 are
  updated to reflect this.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-payload-registry/



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8088: How to Write an RTP Payload Format (Informational - Internet Engineering Task Force (IETF) stream)

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

From: The IESG
To: IETF-Announce
CC: avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com, draft-ietf-avtcore-rtp-payload-registry@ietf.org, zahed.sarker.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Closing the RTP Payload Format Media Types IANA Registry) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document: - 'Closing the
RTP Payload Format Media Types IANA Registry'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-10-04. 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


  It has been observed that specifications of new RTP payload formats
  often forget to register themselves in the IANA registry "RTP Payload
  Formats Media Types".  In practice this has no real impact.  One
  reason is that the Media Types registry is the crucial registry to
  register any Media Type to establish the media type used to
  identified the format in various signaling usage.

  This document resolves the situation by first updating the RTP
  Payload Format Media Type registry to include all the known RTP
  payload formats at the time of writing, then it closes this IANA
  Registry for any future registration.  Beyond instructing IANA to
  close this registry, the instructions to authors in RFC 8088 are
  updated to reflect this.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-payload-registry/



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8088: How to Write an RTP Payload Format (Informational - Internet Engineering Task Force (IETF) stream)

# Document Shepherd Write-Up for Group Documents

Document:  Closing the RTP Payload Format Media Types IANA Registry
Link: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-payload-registry
Shepard: Bernard Aboba

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

The consensus represented broad agreement.
WG Last Call summary: https://mailarchive.ietf.org/arch/msg/avt/Aorv6tEQep128MkGUr_ccPZ00KU/

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 threats of appeal or indications of discontent.

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

Not a protocol document, so not applicable.

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

The closing of the RTP Payload registry should not affect other IETF working
groups or external organizations since the Media Types registry remains open.

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.

No need for formal expert review.

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

No YANG modules.

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.

No use of formal languages 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?

Yes.

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?

There are no areas identified where a review of common issues would be needed.

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. The reasoning behind this is that the advice provided in RFC 8008 to all RTP Payload
format specifications (including the standards track) is to register the RTP Payload format, and this
document changes the expectations for authors, affecting future standards track documents.

Processing this document as a Proposed Standard ensures that we have sufficient consensus to make this
change and close this registry which was created as a result of Standards Track RFC 4855 (though the
process by which this ocurred is not clear).

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.

Author has indicated awareness of disclosure obligations:
https://mailarchive.ietf.org/arch/msg/avt/x50AyRE2RkfYiVHmccLpTHTRQLw/

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.

Author has indicated willingness to be listed as an author:
https://mailarchive.ietf.org/arch/msg/avt/x50AyRE2RkfYiVHmccLpTHTRQLw/

No contributors.

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 apparent "Content Guidelines" issues.

I-D nits are clean:

idnits 2.17.1

draft-ietf-avtcore-rtp-payload-registry-01.txt:

  Showing Errors (**), Flaws (~~), Warnings (==), and Comments (--).
  Errors MUST be fixed before draft submission.  Flaws SHOULD be fixed before draft submission.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Running in submission checking mode -- *not* checking nits according to
  https://www.ietf.org/id-info/checklist .
  ----------------------------------------------------------------------------


    No nits found.
--------------------------------------------------------------------------------

15. Should any informative references be normative or vice-versa? See the [IESG

All the normative references appear appropriate as such.
Only one informative reference (RFC 4855), which does not need to be normative. 

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

There is a Normative reference to an Informational RFC: RFC 8088

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 Normative references to documents in an unclear state.

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.

This document updates RFC 8088, but does not change it's status (Informational).

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

I have reviewed the IANA considerations section and it appears consistent with the
body of the document.

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.

This document does not create any new IANA registries. It's purpose is to close
the RTP Payload Format Media Types IANA Registry.

[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

Document:  Closing the RTP Payload Format Media Types IANA Registry
Link: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-payload-registry
Shepard: Bernard Aboba

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

The consensus represented broad agreement.
WG Last Call summary: https://mailarchive.ietf.org/arch/msg/avt/Aorv6tEQep128MkGUr_ccPZ00KU/

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 threats of appeal or indications of discontent.

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

Not a protocol document, so not applicable.

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

The closing of the RTP Payload registry should not affect other IETF working
groups or external organizations since the Media Types registry remains open.

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.

No need for formal expert review.

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

No YANG modules.

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.

No use of formal languages 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?

Yes.

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?

There are no areas identified where a review of common issues would be needed.

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.

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.

Author has indicated awareness of disclosure obligations:
https://mailarchive.ietf.org/arch/msg/avt/x50AyRE2RkfYiVHmccLpTHTRQLw/

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.

Author has indicated willingness to be listed as an author:
https://mailarchive.ietf.org/arch/msg/avt/x50AyRE2RkfYiVHmccLpTHTRQLw/

No contributors.

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 apparent "Content Guidelines" issues.

I-D nits are clean:

idnits 2.17.1

draft-ietf-avtcore-rtp-payload-registry-01.txt:

  Showing Errors (**), Flaws (~~), Warnings (==), and Comments (--).
  Errors MUST be fixed before draft submission.  Flaws SHOULD be fixed before draft submission.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Running in submission checking mode -- *not* checking nits according to
  https://www.ietf.org/id-info/checklist .
  ----------------------------------------------------------------------------


    No nits found.
--------------------------------------------------------------------------------

15. Should any informative references be normative or vice-versa? See the [IESG

All the normative references appear appropriate as such.
Only one informative reference (RFC 4855), which does not need to be normative. 

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

There is a Normative reference to an Informational RFC: RFC 8088

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 Normative references to documents in an unclear state.

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.

This document updates RFC 8088, but does not change it's status (Informational).

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

I have reviewed the IANA considerations section and it appears consistent with the
body of the document.

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.

This document does not create any new IANA registries. It's purpose is to close
the RTP Payload Format Media Types IANA Registry.

[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

Document:  Closing the RTP Payload Format Media Types IANA Registry
Link: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-payload-registry
Shepard: Bernard Aboba

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

The consensus represented broad agreement.
WG Last Call summary: https://mailarchive.ietf.org/arch/msg/avt/Aorv6tEQep128MkGUr_ccPZ00KU/

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 threats of appeal or indications of discontent.

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

Not a protocol document, so not applicable.

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

The closing of the RTP Payload registry should not affect other IETF working
groups or external organizations since the Media Types registry remains open.

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.

No need for formal expert review.

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

No YANG modules.

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.

No use of formal languages 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?

Yes.

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?

There are no areas identified where a review of common issues would be needed.

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.

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.

Author has indicated awareness of disclosure obligations:
https://mailarchive.ietf.org/arch/msg/avt/x50AyRE2RkfYiVHmccLpTHTRQLw/

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.

Author has indicated willingness to be listed as an author:
https://mailarchive.ietf.org/arch/msg/avt/x50AyRE2RkfYiVHmccLpTHTRQLw/

No contributors.

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 apparent "Content Guidelines" issues.

I-D nits are clean:

idnits 2.17.1

draft-ietf-avtcore-rtp-payload-registry-01.txt:

  Showing Errors (**), Flaws (~~), Warnings (==), and Comments (--).
  Errors MUST be fixed before draft submission.  Flaws SHOULD be fixed before draft submission.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Running in submission checking mode -- *not* checking nits according to
  https://www.ietf.org/id-info/checklist .
  ----------------------------------------------------------------------------


    No nits found.
--------------------------------------------------------------------------------

15. Should any informative references be normative or vice-versa? See the [IESG

All the normative references appear appropriate as such.
Only one informative reference (RFC 4855), which does not need to be normative. 

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

There is a Normative reference to an Informational RFC: RFC 8088

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 Normative references to documents in an unclear state.

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.

This document updates RFC 8088, but does not change it's status (Informational).

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

I have reviewed the IANA considerations section and it appears consistent with the
body of the document.

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.

This document does not create any new IANA registries. It's purpose is to close
the RTP Payload Format Media Types IANA Registry.

[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

Document:  Closing the RTP Payload Format Media Types IANA Registry
Link: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-payload-registry
Shepard: Bernard Aboba

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

The consensus represented broad agreement.

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 threats of appeal or indications of discontent.

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

Not applicable.

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

Potential intersection with MEDIAMAN WG.

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.

No need for formal expert review.

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

No YANG modules.

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.

No use of formal languages 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?

Yes.

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?

There are no areas identified where a review of common issues would be needed.

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.

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.

Author has indicated awareness of disclosure obligations:
https://mailarchive.ietf.org/arch/msg/avt/x50AyRE2RkfYiVHmccLpTHTRQLw/

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.

No contributors.

Author has indicated willingness to be listed as an author:
https://mailarchive.ietf.org/arch/msg/avt/x50AyRE2RkfYiVHmccLpTHTRQLw/

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 apparent "Content Guidelines" issues.

I-D nits are clean:

idnits 2.17.1

draft-ietf-avtcore-rtp-payload-registry-01.txt:

  Showing Errors (**), Flaws (~~), Warnings (==), and Comments (--).
  Errors MUST be fixed before draft submission.  Flaws SHOULD be fixed before draft submission.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Running in submission checking mode -- *not* checking nits according to
  https://www.ietf.org/id-info/checklist .
  ----------------------------------------------------------------------------


    No nits found.
--------------------------------------------------------------------------------

15. Should any informative references be normative or vice-versa? See the [IESG

All the normative references appear appropriate as such.
Only one informative reference (RFC 4855), which does not need to be normative. 

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

There is a Normative reference to an Informational RFC: RFC 8088

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 normative references to documents in an unclear state.

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.

This document updates RFC 8088, but does not change it's status (Informational).

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

I have reviewed the IANA considerations section and it appears consistent with the
body of the document.

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.

This document does not create any new IANA registries. It's purpose is to close
the RTP Payload Format Media Types IANA Registry.

[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

Document:  Closing the RTP Payload Format Media Types IANA Registry
Link: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-payload-registry
Shepard: Bernard Aboba

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

The consensus represented broad agreement.

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 threats of appeal or indications of discontent.

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

Not applicable.

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

Potential intersection with MEDIAMAN WG.

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.

No need for formal expert review.

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

No YANG modules.

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.

No use of formal languages 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?

Yes.

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?

There are no areas identified where a review of common issues would be needed.

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.

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.

Author has indicated awareness of disclosure obligations:
https://mailarchive.ietf.org/arch/msg/avt/x50AyRE2RkfYiVHmccLpTHTRQLw/

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.

No contributors.

Author has indicated willingness to be listed as an author:
https://mailarchive.ietf.org/arch/msg/avt/x50AyRE2RkfYiVHmccLpTHTRQLw/

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 apparent "Content Guidelines" issues.

I-D nits are clean:

idnits 2.17.1

draft-ietf-avtcore-rtp-payload-registry-01.txt:

  Showing Errors (**), Flaws (~~), Warnings (==), and Comments (--).
  Errors MUST be fixed before draft submission.  Flaws SHOULD be fixed before draft submission.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Running in submission checking mode -- *not* checking nits according to
  https://www.ietf.org/id-info/checklist .
  ----------------------------------------------------------------------------


    No nits found.
--------------------------------------------------------------------------------

15. Should any informative references be normative or vice-versa? See the [IESG
:x

All the normative references appear appropriate as such.
Only one informative reference (RFC 4855), which does not need to be normative. 

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

There is a Normative reference to an Informational RFC: RFC 8088

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 normative references to documents in an unclear state.

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.

This document updates RFC 8088, but does not change it's status (Informational).

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

I have reviewed the IANA considerations section and it appears consistent with the
body of the document.

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.

This document does not create any new IANA registries. It's purpose is to close
the RTP Payload Format Media Types IANA Registry.

[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

Document:  Closing the RTP Payload Format Media Types IANA Registry
Link: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-payload-registry
Shepard: Bernard Aboba

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

The consensus represented broad agreement.

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 threats of appeal or indications of discontent.

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

Not applicable.

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

Potential intersection with MEDIAMAN WG.

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.

No need for formal expert review.

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

No YANG modules.

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.

No use of formal languages 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?

Yes.

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?

There are no areas identified where a review of common issues would be needed.

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.

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.

Author has indicated awareness of disclosure obligations.

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.

Author has indicated willingness to be listed as an author.

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-D nits run:

idnits 2.17.1

draft-ietf-avtcore-rtp-payload-registry-00.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  -- The draft header indicates that this document updates RFC8088, but the
    abstract doesn't seem to directly say this.  It does mention RFC8088
    though, so this could be OK.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

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

  -- The document date (22 July 2024) is 36 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  ** Downref: Normative reference to an Informational RFC: RFC 8088

  -- Possible downref: Non-RFC (?) normative reference: ref. 'RTP-FORMATS'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'MEDIA-TYPES'


    Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

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

No informative references. All the normative references appear appropriate as such.

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

There is a Normative reference to an Informational RFC: RFC 8088

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 normative references to documents in an unclear state.

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.

This document updates RFC 8088, but does not change it's status (Informational).

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

I have reviewed the IANA considerations section and it appears consistent with the
body of the document.

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.

This document does not create any new IANA registries. It's purpose is to close
the RTP Payload Format Media Types IANA Registry.

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