Authors, Just a friendly reminder that this document awaits author action.
Please see the AUTH48 status page at http://www.rfc-editor.org/auth48/rfc9626. Thank you. RFC Editor/mf > On Nov 4, 2024, at 3:54 PM, Megan Ferguson <mfergu...@amsl.com> wrote: > > Authors, > > Please see mail below regarding this document as well as our cluster-wide > email with questions relating to all three related documents. > > This document set has been in AUTH48 since mid-August. Please let us know if > there is anything we can do to facilitate moving the AUTH48 review forward. > > Thank you. > > RFC Editor/mf > > >> On Oct 21, 2024, at 9:58 AM, Megan Ferguson <mfergu...@amsl.com> wrote: >> >> Authors, >> >> Just a ping that this reply from Zahed requires author action. Please also >> see our list of document-specific questions and our email regarding queries >> affecting the cluster of documents as a whole (originally sent 8/12/24). >> >> We will await your response prior to moving this document (and its >> companions) forward in the publication process. >> >> Please see the AUTH48 status of this document at >> https://www.rfc-editor.org/auth48/rfc9626. >> >> Please see further cluster information at >> https://www.rfc-editor.org/cluster_info.php?cid=C324. >> >> We look forward to hearing from you at your earliest convenience. >> >> Thank you. >> >> RFC Editor/mf >> >>> On Oct 7, 2024, at 9:31 AM, Zaheduzzaman Sarker >>> <zahed.sarker.i...@gmail.com> wrote: >>> >>> Hi, >>> >>> For bullet 4 where AD opinion has been asked, I would first like to get the >>> opinion from the authors if they are OK with the changes or not. >>> >>> So, Authors please review the proposed changes in bullet 4 and send your >>> opinion. >>> >>> //Zahed >>> >>> On Mon, Sep 23, 2024 at 11:06 PM Megan Ferguson <mfergu...@amsl.com> wrote: >>> Authors and *AD, >>> >>> Just a friendly weekly reminder that this document awaits your attention. >>> Please see the message below as well as our separate email detailing >>> questions about the full cluster. >>> >>> Please let us know if we can be of assistance during your AUTH48 review. >>> >>> Thank you. >>> >>> RFC Editor/mf >>> >>> >>> >>> >>>> On Aug 12, 2024, at 10:27 PM, 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. --> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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. >>>> --> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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). >>>> --> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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. >>>> --> >>>> >>>> >>>> 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]... >>>> >>>> --> >>>> >>>> >>>> 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. >>>> --> >>>> >>>> >>>> 10) <!-- [rfced] Would you like the references to be alphabetized or left >>>> in their current 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 >>>> VPS - Video Parameter Set >>>> SPS - Sequence Parameter Set >>>> PPS - Picture Parameter Set >>>> >>>> b) Please clarify if/how we may expand the following abbreviations: >>>> >>>> VPX >>>> PACI - is this intentionally different from PACSI? >>>> >>>> >>>> c) Should "intra (IDR)" frames instead be "IDR intra-frames"? This >>>> formation occurs twice in this document. >>>> >>>> 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. >>>> --> >>>> >>>> >>>> 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 >>>> >>>> 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. >>>> --> >>>> >>>> >>>> 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. >>>> >>>> --> >>>> >>>> >>>> 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
