I’m not an author on this draft, but as chair I thought I would try to answer these questions, to make sure the process could get done. I spoke with Mo about these issues in Dublin and I think he’ll agree with all of these. Mo, please correct me if I’ve misunderstood anything.
> On Aug 13, 2024, at 12:27 AM, rfc-edi...@rfc-editor.org wrote: > > Authors and *AD, > > [AD - please see question 4 below] > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> Scalable video, h.264, h.265, vp9, layered video > 2) <!--[rfced] Please review whether "e.g." in the following should > instead be "i.e.": > > Original: > Because of inter-frame dependencies, it should ideally switch video > streams at a point where the first frame from the new speaker can be > decoded by recipients without prior frames, e.g. switch on an > intra-frame. An intra frame is the most common situation where a stream can be decoded without prior frames, but there are others for some codecs, so I think e.g. is appropriate here. > --> > > > 3) <!--[rfced] Should "field" or some other noun follow > "refresh_frame_flags" in this sentence? Or is this referring to > the flags (as the verb "are" is plural)? > > Original: > The D bit MUST be 1 if the refresh_frame_flags in the VP9 payload > uncompressed header are all 0, otherwise it MUST be 0. > --> I think “refresh_frame_flags bits" > > 4) <!--[rfced] [*AD] We see several (similar) sentences like the example > below where it might be difficult for the reader to correclty > understand what part(s) of the sentence the keyword MUST applies > to. We wonder if a rewrite may be helpful to the reader, > possibly using a list... Please see the example below (again, > other similar instances exist in the document) and let us know if > an update like one of the following might work. > > Original: > > The D bit MUST be 1 when the NAL unit header NRI field is 0, or an > aggregation packet or fragmentation unit encapsulating only NAL units > with NRI=0, otherwise it MUST be 0. > > Perhaps A (the "when" clause applies to both the D bit being set to 1 or > NRI=0): > > When the NAL unit header NRI field is 0, the D bit MUST be either 1 or > an aggregation packet or fragmentation unit encapsulating only NAL > units with NRI=0. When the NAL unit header NRI field is not set to 0, > the D bit MUST be 0. > > Perhaps B (the "when" clause only applies to the D bit being 0): > > The D bit MUST be: > > -1 when the NAL unit header NRI field is 0, > > -an aggregation packet or fragmentation unit encapsulating only NAL units > with NRI=0, or > > - 0. The D bit MUST be 1 if either: - The payload's NAL unit header’s NRI field is 0, or - The payload is an aggregation packet or fragmentation unit encapsulating only NAL units with NRI=0. Otherwise, it MUST be 0. > > 5) <!-- [rfced] Please review whether any of the notes in this document > should be in the <aside> element. It is defined as "a container for > content that is semantically less important or tangential to the > content that surrounds it" > (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > --> > Both the two “Note:” comments could be <aside> elements. > > 6) <!--[rfced] May we update this sentence as follows for the ease of the > reader? Note that the introductory "when" phrase mentions a > single frame while the recommendation mentions plural frames: > please consider if further updates are necessary. > > Original: > When an RTP switch needs to discard a received video frame due to > congestion control considerations, it is RECOMMENDED that it > preferably drop frames marked with the D (Discardable) bit set, or the > highest values of TID and LID, which indicate the highest temporal and > spatial/quality enhancement layers, since those typically have fewer > dependenices on them than lower layers. > > > Perhaps A: > When an RTP switch needs to discard a received video frame due to > congestion control considerations, it is RECOMMENDED that it drop: > > - frames marked with the D (Discardable) bit set, or > > -frames with the highest values of TID and LID (which indicate the > highest temporal and spatial/quality enhancement layers) since those > typically have fewer dependencies on them than lower layers. > > Perhaps B (to upddate the sg/pl switch): > When an RTP switch needs to discard received video frames due to > congestion control considerations, it is RECOMMENDED that it drop: > > - frames marked with the D (Discardable) bit set, or > > -frames with the highest values of TID and LID (which indicate the > highest temporal and spatial/quality enhancement layers) since those > typically have fewer dependencies on them than lower layers. > > --> I’m missing something here because I don’t see the difference between these two options, but that text is fine. > 7) <!--[rfced] Please clarify what "and forward the same" means in this text. > > Original: > When an RTP switch wants to forward a new video stream to a receiver, > it is RECOMMENDED to select the new video stream from the first > switching point with the I (Independent) bit set in all spatial > layers and forward the same. > --> Perhaps “and forward the stream from that point on”. > 8) <!--[rfced] How may we update this text to more easily illustrate the > 1:1 mapping between initialism and expansion? > > Original: > ... source to generate a switching point by sending Full Intra > Request (RTCP FIR) as defined in [RFC5104]... > > Perhaps: > ... source to generate a switching point by sending RTCP Full Intra > Request (FIR) as defined in [RFC5104]... > > --> That’s fine. > > > 9) <!--[rfced] In the following, are "layer" and "refreshes" redundant > with what LRR stands for? Please let us know if any updates are > necessary. > > Original: > Because frame marking can only be used with temporally-nested > streams, temporal-layer LRR refreshes are unnecessary for frame- > marked streams. > > As expanded it would be: > Because frame marking can only be used with temporally nested > streams, temporal-layer Layer Refresh Request (LRR) refreshes are > unnecessary for frame-marked streams. > --> Perhaps “temporal-layer refreshes requested with an LRR message” would avoid the duplicative language? > 10) <!-- [rfced] Would you like the references to be alphabetized or left > in their current order? > --> This is something where the RFC Editor’s style guide should dictate, I don’t think there’s any particular preference for a specific reference order. > > > 11) <!-- [rfced] We had the following questions related to abbreviations > used throughout the document. > > a) Please note that we have expanded these abbreviations as follows on > first use. Please let us know any objections. > > MCU - Multipoint Control Unit (per RFC 7667) > SRTP - Secure Real-time Transport Protocol > IDR - Instantaneous Decoding Refresh (per RFC 6184) > SDES - source description > NAL - Network Abstraction Layer > CRA - Clean Random Access > BLA - Broken Link Access > RAP - Random Access Point > AVC - Advanced Video Coidng (per RFC 6184) > SVC - Scalable Video Coding (per RFC 6190) > PACSI - Payload Content Scalability Information > NRI - Network Remote Identification No; the field in the H.264 specification is actually formally named “nal_ref_idc”. I believe this stands for something like Network Adaptation Layer Reference Indication but as far as I can tell it’s never explicitly spelled out in that specification as far as I can tell. > VPS - Video Parameter Set > SPS - Sequence Parameter Set > PPS - Picture Parameter Set The other abbreviations all seem to be correct. > > b) Please clarify if/how we may expand the following abbreviations: > > VPX > PACI - is this intentionally different from PACSI? Yes; the protocol element field is called PACI in RFC 7798 (for H.265) vs. PACSI in RFC 6190 (for H.264-SVC). > c) Should "intra (IDR)" frames instead be "IDR intra-frames"? This > formation occurs twice in this document. Intra frames are the common term, IDR is the more formal term, so this is a clarification with two synonymous terms, not a restrictive adjective. > > d) Please note that the following similar abbreviations appear to be > differently treated with regard to punctuation: > > H264 (AVC) > H264-SVC > > We have expanded the abbreviations on first use, but please let us > know if/how these should be made uniform with regard to parens and > hyphantion. > > See also our cluster-wide question regarding H264 vs. H.264. > --> Names of ITU specs (H.264 and H.265) should include the dot character. AVC and SVC are not parallel; AVC is the title of the H.264 specification as a whole, whereas SVC refers specifically to the extensions to it specified in Annex F. Thus the parentheses for the former (as an explanatory synonym) vs. the hyphen for the latter (as a restriction). > 12) <!--[rfced] We had the following questions related to terminology used > throughout the document. > > a) Two questions about the header extension: > > Should this RTP header extension appear using "Video" throughout? We > see both of the following forms. > > Video Frame Marking RTP header extension vs. Frame Marking RTP header > extension Yes, I think having Video throughout is good. > > Secondly, in the Abstract, we see: > > Original: > This document describes a Video Frame Marking RTP header extension > used to convey information about video frames that is critical for > error recovery and packet forwarding in RTP middleboxes or network > nodes. > > Is the use of the indefinite article "a" intentional ("a Video Frame > Marking RTP header extension")? This seems (possibly) contradictory > with the capitalization of the proper noun and use in Section 3 (are > there more types of Video Frame Marking RTP header extensions?). > Please review. > --> There certainly are other RTP header extensions that mark video frames, though none of them have been standardized by the IETF as yet; I think that’s why there is the indefinite article here. > > > 13) <!-- [rfced] Please review the "Inclusive Language" portion of the > online Style Guide > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this > nature typically result in more precise language, which is > helpful for readers. > > Note that our script did not flag any words in particular, but this > should still be reviewed as a best practice. > > --> I don’t see any problems. > > > Thank you. > > RFC Editor/mf > > *****IMPORTANT***** > > Updated 2024/08/12 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info/). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * rfc-edi...@rfc-editor.org (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * auth48archive@rfc-editor.org, which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > auth48archive@rfc-editor.org will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9626.xml > https://www.rfc-editor.org/authors/rfc9626.html > https://www.rfc-editor.org/authors/rfc9626.pdf > https://www.rfc-editor.org/authors/rfc9626.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9626-diff.html > https://www.rfc-editor.org/authors/rfc9626-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9626-xmldiff1.html > > The following files are provided to facilitate creation of your own > diff files of the XML. > > Initial XMLv3 created using XMLv2 as input: > https://www.rfc-editor.org/authors/rfc9626.original.v2v3.xml > > XMLv3 file that is a best effort to capture v3-related format updates > only: > https://www.rfc-editor.org/authors/rfc9626.form.xml > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9626 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9626 (draft-ietf-avtext-framemarking-16) > > Title : Video Frame Marking RTP Header Extension > Author(s) : M. Zanaty, E. Berger, S. Nandakumar > WG Chair(s) : Dr. Bernard D. Aboba, Jonathan Lennox > Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
