[Gen-art] Re: draft-ietf-avtcore-rtcp-green-metadata-09 ietf last call Genart review

[Yong He <[e-mail]>]

Hi Paul,

Thank you for your comments. I'll address comment #1, #2, and #4 in the next revision.

For comment #3, I referred to example #1 and #3 in RFC5104. I agree that the answer in example 2 rejects
tmmbr isn't a subject of this document, I'll change it to reject tsrr instead. The distinction between the two examples is whether the sender is capable of handling TSRR.

Please feel free to share any further comments, I'll prepare the revision for upload soon.

BR, Yong

________________________________
From: Paul Kyzivat <[e-mail]>
Sent: Tuesday, June 23, 2026 2:50 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: draft-ietf-avtcore-rtcp-green-metadata-09 ietf last call Genart review

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

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