Skip to main content

IETF Last Call Review of draft-ietf-avtcore-rtcp-green-metadata-09
review-ietf-avtcore-rtcp-green-metadata-09-genart-lc-kyzivat-2026-06-23-00

Request Review of draft-ietf-avtcore-rtcp-green-metadata
Requested revision No specific revision (document currently at 13)
Type IETF Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2026-06-19
Requested 2026-06-05
Authors Yong He , Christian Herglotz , Edouard Francois
I-D last updated 2026-07-09 (Latest revision 2026-07-02)
Completed reviews Secdir IETF Last Call review of -08 by Vincent Roca (diff)
Genart IETF Last Call review of -09 by Paul Kyzivat (diff)
Genart Telechat review of -10 by Paul Kyzivat (diff)
Assignment Reviewer Paul Kyzivat
State Completed
Request IETF Last Call review on draft-ietf-avtcore-rtcp-green-metadata by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/18YgU3r7XR69jTLPlBUQpEjnvzE/
Reviewed revision 09 (document currently at 13)
Result Ready w/issues
Completed 2026-06-23
review-ietf-avtcore-rtcp-green-metadata-09-genart-lc-kyzivat-2026-06-23-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-avtcore-rtcp-green-metadata-09
Reviewer: Paul Kyzivat
Review Date: 2026-06-23
IETF LC End Date: 2026-06-19
IESG Telechat date: 2026-07-09

Summary: This draft is on the right track but has open issues, described 
in the review.

(Sorry this is late. I didn't get the assignment till the due date.)

Major issues: 0
Minor issues: 1
Nits/editorial comments: 4

1) Minor Issue: Incomplete and Unclear IANA Considerations

Section 8 has multiple IANA action requests that are run together, 
without cleae typographical distinction. I suggest that each distinct 
action be placed in a separate sub-section.

Also, they are providing the values for new rows in tables, but the text 
isn't clear about this.

Also note that the sdp ccm registry has another column, Mux, added by 
RFC8859. This document needs to specify what value is appropriate for 
it. (This is what elevates this to a minor issue.)

I suggest revising to something like the following:

---------------------
8.1  FMT Values

IANA is requested to allocate the following two new Values in the 
"Real-Time Transport Protocol (RTP) Parameters, FMT Values for PSFB 
Payload Types" registry.  [IANA-RTCP-FMT-PSFB-PT]:

       Value:       12
       Name:        TSRR
       Long name:   Temporal-Spatial Resolution Request
       Reference:   Section 4.1 of this RFC

       Value:       13
       Name:        TSRN
       Long name:   Temporal-Spatial Resolution Notification
       Reference:   Section 4.2 of this RFC

8.2 SDP Parameters

IANA is requested to register a new SDP parameter in the “Session 
Description Protocol (SDP) Parameters, Codec Control Messages" registry 
[IANA-SDP]:

       Value name:       tsrr
       Long name:        Temporal-Spatial Resolution Request
       Usable with:      ccm
       Mux:              ???
       Reference:        Section 6.1 of this RFC
---------------------

2) NIT: Clarifying the ABNF update

Section 6.1 ends with a line of ABNF. I think it would be clearer with a 
bit more introduction. For instance:

---------------------
The following ABNF rule extends the definition of "rtcp-fb-ccm-param" in 
section 7.1 of RFC 5104:

   rtcp-fb-ccm-param =/ SP "tsrr" ; Temporal-Spatial Resolution
---------------------

It may be that this then calls for marking this document as updating RFC 
5104, but I am uncertain about that.

3) NIT: Examples are hard to follow

The two examples in section 6.2 are run together, without typographical 
distinction. This makes them hard to read. I recommend that each example 
be distinguished with a sub-heading, and that the SDP be placed in a Figure.

Also, I fail to understand the distinction between the two examples. 
They are presumably both offer/answer, though the first doesn't show the 
answer. I gather one point is that the answer in example 2 rejects 
tmmbr. But that isn't a subject of this document.

Could you please add some additional explanation of what points you are 
trying to make?

4) NIT: Unnecessary use of non-Ascii characters:

IdNits reports several non-Ascii characters. I checked, and they all 
seem to be non-Ascii variations on Ascii characters: angled single and 
double quotes, and em-dashes. I recommend changing them to the Ascii 
equivalents.

There are also several cases of line-too-long that will probably be 
cured by removing the non-Ascii characters.

5) NIT: Lack of IPv6 usage:

All the examples in this document use IPv4. The IdNits tool flags this, 
recommending that should also be some IPv6 usage. (I don't care.)