Ballot for draft-ietf-avtcore-rtcp-green-metadata
Discuss
Yes
No Objection
No Record
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
# Éric Vyncke INT AD comments for draft-ietf-avtcore-rtcp-green-metadata-13 CC @evyncke Thank you for the work put into this document. Please find below some blocking DISCUSS points (some easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## DISCUSS (blocking) As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. ### Abstract As detected by [idnits](https://author-tools.ietf.org/idnits3/results?url=https://www.ietf.org/archive/id/draft-ietf-avtcore-rtcp-green-metadata-13.txt) the abstract must have a reference to the updated RFC, i.e., RFC 5104. It seems to me that the only use case of this RFC is for P2P real-time communication and not for streaming or multi-point conferencing, be explicit about this use case in the abstract *and* in the title. ### Section 1 I am possibly missing the context but this section contains `about the decoding complexity of the delivered bitstream` and I am unable to find a link to this "decoding complexity" in the message format as the format is only about frame rate & picture size. ### Sections 4.1.1 & 4.2.1 (and possibly others) What should the decoder/receiver do when `The value of Frame Rate equal to 0 MUST NOT be sent` is violated ? ### Sections 4.1.3 & 4.2.3 Why not a BCP14 "MUST" in `This request message is not time critical and SHOULD be sent using regular RTCP timing.` ? See also https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ if the authors want to keep the "SHOULD" by providing guidance to the implementers about interoperation. ### Section 5 Why not a BCP "MUST" in ` senders and receivers SHOULD behave conservatively` ? At least, please explain the consequences of bypassing the SHOULD even if they are obvious to the authors.
## COMMENTS (non-blocking) ### Abstract As there are *two* messages defined in this I-D, please use the plural form for `The RTCP message format specified in this document enables ` as well as for the rest of the abstract. ### Section 1 Outside of the use case of p2p video-conferencing described in the last paragraph, the previous paragraphs are not always correct as the "encoder" is not always the source of the RTP flow. Please move the last paragraph at the start of the section. ### Section 4.1.1 Should 'retransmission' be used in `A repetition SHALL NOT increase the sequence number` rather than `repetition`? About `The FCI field SHALL contain at least one TSRR FCI entries.` : 1) should there be a limit (e.g., to avoid IP fragmentation) in the number of FCI entries ? 2) please use singular for `entries` ### Section 6.2 It is a pity that the 2 provided examples are using IPv4 and not IPv6... After all, we are in 2026 ;-) ### Section 7 Should there be text about the rate of changes and its impact on congestion ? ### SHALL vs MUST It is usually clearer for the reader to use BCP14 "MUST" than "SHALL" even if BCP14 defines them as synonyms.
One issue I'd like to discuss here that is hopefully a simple fix. I see no mention of congestion control handling, yet TSRR lets the sender request arbitrary frame rates and resolutions, substantially changing the rate of the flow. RTP requires that "congestion control SHOULD be defined in each RTP profile as appropriate," so likely this is covered in some dependency; it's just worth noting that the receiver's request is still subordinate to that request fitting in the bandwidth the congestion controller will allow.
The reference to [GreenMetadata] calls it an FDIS = Final Draft International Standard. It's my understanding that this is a pre-publication ballot revision, similar to an IETF Last Call. The referenced ISO spec was finalized in 2023; you probably just need to drop FDIS from the reference text. In the introduction, you refer to the third edition, :2023; it might be worth including that identifier in the reference as well, though it's already implied by the publication year. The definition of AVPF points to RFC5104, but that RFC points to RFC4585 for the definition of AVPF. Frame Rate, Picture Width, and Picture Height are each specified as "MUST NOT be sent" as 0; I don't see any definition of how a receiver handles such invalid values. Please note in the Abstract what about RFC5104 is being updated by this document (the ABNF; anything else?). ===NITS FOLLOW=== §6.2.1: "resolutionas indicated in the RTCP TSRN feedback message"; missing space ("resolutionas"). §4.2.2 and §4.1.1: "It is to note that" => "Note that" would be more standard RFC style.
# Charles Eckel, ART AD, IESG ballot for draft-ietf-avtcore-rtcp-green-metadata-13 CC @eckelcu ## Nits ### Incomplete sentence 129 conferencing session may be scheduled in advance. When a receiver 130 operating on battery power can estimate its power consumption rate 131 and, if necessary, request a reduction in pixel rate to ensure 132 completion of the scheduled session. Furthermore, when multiple It seems a part of the sentence that begins with "When a receiver .." is missing as the condition is not completed. Perhaps the simple solution, and the intended meaning, is achieved by the following: s/When a/A
Thanks to Vincent R. for the SECDIR review; thanks to Marius K. for the shepherd's write up. Thanks for the short concise draft. * Sect 4: “ The message may be sent in a regular full compound RTCP packet or in an early RTCP packet, as per the RTP/AVPF rules.” - If one wanted to find those rules, where would one look? * “Note that the highest sequence number could be a smaller integer value due to the wrapping of the field. Appendix A.1 of [~[RFC3550](https://www.ietf.org/archive/id/draft-ietf-avtcore-rtcp-green-metadata-13.html#RFC3550)~] has an algorithm for keeping track of the highest received sequence number for RTP packets; it could be adapted for this usage.” - is this algorithm needed for determinism or is that not a problem? (Put another way - why not just use that algorithm?)
Thanks to Vincent Roca for their secdir review. I do see that the authors have added the suggestion made in this review. This subject is well outside my area of expertise. Section 5, second to last para: There is discussion about needing to apply integrity and authentication to the feedback messages. The references are to RFC 3711 and RFC 5124, where it appears that most of the integrity and authentication information is in RFC 3711. I will say that RFC3711, written in 2004, is pretty dated with respect to the integrity mechanisms. HMAC-SHA1 isn't technically vulnerable today, but it is being deprecated (by US NIST, and possibly by others). HMACs with SHA2 (say SHA-256) are more modern and definitely more secure. I wonder if this section could suggest that there are newer integrity options available (such as RFC 6234), or that underlying modern security protocols should be used.
Thanks to the authors and the WG for their work on this document. I would like to cross-check whether this document "updates" RFC5104. To me, it seems like an optional extension on top of the base RFC5104 but I don't know enough of the subject to be sure. Some quotes from the document text: "This document defines a new parameter "tsrr" to the "ccm" feedback value defined in CCM [RFC5104] to indicate support of the Temporal-Spatial Resolution Request/Notification (TSRR/TSRN)." "The following ABNF [RFC5234] rule extends the definition of "rtcp-fb-ccm-param" in section 7.1 of [RFC5104]:" Request the authors/WG/Responsible AD to consider.
Section 4.1.2, Semantics, and Section 4.2.1, field description: 263 > TSRR message for future coding of pictures. The temporal and spatial 264 > resolutions in a TSRR message SHALL be less than or equal to the 265 > temporal and spatial resolutions negotiated via SDP. 353 > resolution, or when the requested temporal and spatial resolutions 354 > are larger than the temporal and spatial resolutions negotiated via 355 > SDP, or when pre-recorded content is used. Both of these normative statements depend on "the temporal and spatial resolutions negotiated via SDP," but I could not find anywhere in the document, or in a citation to another RFC, that defines how a frame rate or picture resolution ceiling is actually established in SDP for the codecs this document targets. Section 6 defines only the "tsrr" rtcp-fb parameter, which signals support for the feedback messages, not the resolution/frame-rate bounds themselves. I would ask the authors to add a reference to whatever mechanism they have in mind (e.g., codec-specific fmtp parameters, profile/level constraints, or RFC 6236 imageattr), since as written an implementer has no way to determine the value against which these SHALL/comparisons are supposed to be evaluated. --- Section 5, Security Considerations: 419 > * severely frequent requests that set the picture width, height and/ 420 > or frame rate. 421 > 422 > To prevent these attacks, there is a need to apply authentication and 423 > integrity protection of the feedback messages. This can be 424 > accomplished against threats external to the current RTP session 425 > using the RTP profile that combines Secure RTP [SRTP] and AVPF into 426 > SAVPF [SAVPF]. The SECDIR review of -08 suggested opening this section with a pointer to RFC 4585's own Security Considerations, noting that RFC 4585 discusses timing-rule violations and recommends that "Senders as well as receivers SHOULD behave conservatively when observing strange reporting behavior." I did not see this incorporated in -11. I think it is directly relevant to the "severely frequent requests" bullet already present here: RFC 4585 Section 3's timing rules are the mechanism a compliant TSRR sender is supposed to follow, and a cross-reference would connect the frequent- request threat back to a concrete, existing recommendation rather than leaving authentication as the only stated mitigation. --- Section 6.1, ABNF extension: 446 > The following ABNF [RFC5234] rule extends the definition of "rtcp-fb- 447 > ccm-param" in section 7.1 of [RFC5104]: 448 > 449 > rtcp-fb-ccm-param =/ SP "tsrr" ; Temporal-Spatial Resolution The GEN-ART review (thanks Paul) of -09 raised the question of whether extending this ABNF production calls for an "Updates: 5104" header on this document, and noted uncertainty about the answer. I did not see this resolved in -11, and the document still carries no Updates header. I would appreciate the authors, or the responsible AD, confirming one way or the other, since this is exactly the kind of normative-change-without-Updates question the IESG is expected to catch :-) --- Section 6.2.2, Example 2: 479 > This example illustrates how support for codec control messages is 480 > negotiated using the SDP Offer/Answer model. The offerer includes 481 > support for "tstr", "fir", and "tsrr". The answerer accepts only 482 > "tstr" and "fir", thus rejecting "tstr". Both the offer and the answer include "tstr," so nothing is actually rejected on that parameter; it is "tsrr" that the answer drops. I believe this is a plain error (the last word of the passage should read "tsrr" rather than "tstr"), but since "tstr" (RFC 5104's Temporal-Spatial Trade-off Request) and "tsrr" (this document's Temporal-Spatial Resolution Request) are easy to confuse even for a careful reader, I suspect this is also the source of the GEN-ART reviewer's comment on -09 that they "fail[ed] to understand the distinction between the two examples." I would recommend fixing the text and, per that GEN-ART comment, adding a sentence spelling out that the point of Example 2 is that "tsrr" specifically is not carried forward into the answer. --- Shepherd write-up, Document History question 13: > Yong He and Christian Herglotz are willing to be listed as authors. I > wasn't able to get a confirmation from Edouard Francois. I would like to understand whether this has since been resolved. BCP 79 obligations and simple author consent to be listed are normally confirmed before a document reaches IESG review, and I did not find a follow-up note in the shepherd write-up or the list archive indicating that Edouard Francois's consent was subsequently obtained. ---------------------------------------------------------------------- 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, and Sections 4.1.1 / 4.2.1 headings: 15 > The RTCP payload format specified in this document enables receivers 200 > 4.1.1. Message format The shepherd write-up already flagged the mix of "message format" and "payload format" in -09; it is still present in -11. Picking one term throughout would help. --- Section 4.1, FCI cardinality, compared with Section 4.2: 198 > The FCI field MUST contain one or more TSRR FCI entries. 300 > The FCI field SHALL contain at least one TSRN FCI entry. These two sentences say the same thing about parallel constructs but use different BCP 14 keywords and phrasing. Consider making them consistent. --- Section 4.1.1 and 4.2.1, Rsvd field: 255 > Rsvd (4 bits): Reserved bits. All reserved bits SHALL be set to 0 by 256 > the sender and SHALL be ignored on reception. s/Rsvd (4 bits): Reserved bits./Reserved (4 bits):/ The 14-bit field earlier in the same message is labeled "Reserved" while this one is labeled "Rsvd"; using one label consistently would read more cleanly. --- Section 6.2.1, Example 1: 474 > capable of adjusting the trade-off as indicated in the RTCP TSRN 475 > feedback message. s/adjusting the trade-off/adjusting its coding parameters/ "Trade-off" is RFC 5104 TSTR/TSTN terminology for its single 0-31 scalar; this document conveys explicit frame rate and picture dimensions rather than a trade-off value, so reusing the term here is likely to confuse readers into conflating the two mechanisms. --- Section 6.2.2, Example 2: 484 > The offerer wishes to support "tstr", "fir" and "tsrr", The offered 485 > SDP is s/"tsrr", The offered/"tsrr". The offered/ --- Section 6.2.2, closing sentence: 519 > This demonstrates that only the intersection of supported codec 520 > ontrol messages is retained after negotiation. s/ontrol/control/ --- Section 7, Operational Considerations: 528 > * Remote support for this RFC is indicated by receiving a a TSRR s/receiving a a TSRR/receiving a TSRR/
Hi Yong, Christian, and Edouard, The changes made since -10 [1] adequately address ALL points raised in my previous DISCUSS ballot [2]. Appreciated. Cheers, Med [1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-avtcore-rtcp-green-metadata-10&url2=draft-ietf-avtcore-rtcp-green-metadata-13&difftype=--html [2] https://mailarchive.ietf.org/arch/msg/avt/tg7l3R7a4bIrHVs5xiVIXhP5OWk/
Thank you to Paul Kyzivat for the GENART review. From idnits: -- The draft header indicates that this document updates RFC5104, but the abstract doesn't seem to mention this, which it should.