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 <[email protected]> Sent: Tuesday, June 23, 2026 2:50 PM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> 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.)
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
