Authors, Just a friendly reminder that this document awaits author action.
Please see the AUTH48 status page at http://www.rfc-editor.org/auth48/rfc9627. Thank you. RFC Editor/mf > On Nov 4, 2024, at 3:54 PM, Megan Ferguson <mfergu...@amsl.com> wrote: > > [Removing Ben and adding Zahed and Murray] > > 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: >> >> All, >> >> Just a friendly reminder that this document (and its companions) requires >> further author action. Please see mail below as to document-specific >> queries as well as the separately sent cluster-wide queries (originally sent >> 8/12/24) for this document group. >> >> 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/rfc9627. >> >> 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 4, 2024, at 12:38 PM, Megan Ferguson <mfergu...@amsl.com> wrote: >>> >>> Greetings, >>> >>> Please note that this document cluster awaits author action. >>> Please see mail below and let us know if we can be of assistance during >>> your AUTH48 review. >>> >>> Thank you. >>> >>> RFC Editor/mf >>> >>>> On Sep 23, 2024, at 3:06 PM, Megan Ferguson <mfergu...@amsl.com> wrote: >>>> >>>> Authors, >>>> >>>> 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, >>>>> >>>>> While reviewing this document during AUTH48, please resolve (as >>>>> necessary) the following questions, which are also in the XML file. >>>>> >>>>> 1) <!--[rfced] In the Abstract, may we clarify "it" as follows? >>>>> >>>>> Original: >>>>> It also defines its use with several RTP payloads for scalable media >>>>> formats. >>>>> >>>>> Perhaps: >>>>> This document also defines the use of LRR with several RTP payloads >>>>> for scalable media formats. >>>>> --> >>>>> >>>>> >>>>> 2) <!--[rfced] May we update the following to clarify the antecedent of >>>>> "it" and break up the long sentence? >>>>> >>>>> Original: >>>>> >>>>> This memo describes an RTCP [RFC3550] Payload-Specific Feedback >>>>> Message [RFC4585] "Layer Refresh Request" (LRR). It is designed to >>>>> allow a receiver of a layered media stream to request that one or more >>>>> of its substreams be refreshed, such that it can then be decoded by an >>>>> endpoint which previously was not receiving those layers, without >>>>> requiring that the entire stream be refreshed (as it would be if the >>>>> receiver sent a Full Intra Request (FIR); [RFC5104] see also >>>>> [RFC8082]). >>>>> >>>>> >>>>> Perhaps: >>>>> This memo describes an RTCP [RFC3550] Payload-Specific Feedback >>>>> Message [RFC4585] "Layer Refresh Request" (LRR), which is designed to >>>>> allow a receiver of a layered media stream to request that one or more >>>>> of its substreams be refreshed. As such, it can then be decoded by an >>>>> endpoint that previously was not receiving those layers, without >>>>> requiring that the entire stream be refreshed (as it would be if the >>>>> receiver sent a Full Intra Request (FIR); [RFC5104] see also >>>>> [RFC8082]). >>>>> >>>>> --> >>>>> >>>>> >>>>> 3) <!--[rfced] We had the following questions regarding Section 2. >>>>> Section 2 was titled "Conventions, Definitions, and Acronyms". >>>>> It contains the BCP 14 boilerplate and a single subsection that >>>>> is titled "Terminology". >>>>> >>>>> a) There is no list of acronyms in this section. Please review our >>>>> updates to the title of this section and let us know any objections >>>>> (of if a list of abbreviations was missing). >>>>> >>>>> Original: >>>>> Conventions, Definitions and Acronyms >>>>> >>>>> Current: >>>>> Conventions and Terminology >>>>> >>>>> b) We see several terms throughout the document that it may be useful >>>>> to include in this section (as they are seemingly introduced in >>>>> sections that follow). For example: >>>>> >>>>> temporally nested >>>>> Layer Index >>>>> temporal ID >>>>> layer ID >>>>> >>>>> Please let us know if you'd like to add any terms to the Terminology >>>>> section. >>>>> --> >>>>> >>>>> >>>>> 4) <!--[rfced] Please review if the slash in the following to see if >>>>> "and", "or", or "and/or" might be clearer. >>>>> >>>>> Original: >>>>> A sender MAY request an upgrade in both temporal and spatial/quality >>>>> layers simultaneously. >>>>> --> >>>>> >>>>> >>>>> 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] In the text below, are you referring to the title of the >>>>> document? >>>>> >>>>> Original: >>>>> If the payload also specifies how it is used with the Frame Marking >>>>> RTP Header Extension [I-D.ietf-avtext-framemarking], the syntax MUST >>>>> be defined in the same manner as the TID and LID fields in that >>>>> header. >>>>> >>>>> Perhaps: >>>>> If the payload also specifies how it is used with "Video Frame Marking >>>>> RTP Header Extension" [RFC9626], the syntax MUST be defined in the >>>>> same manner as the TID and LID fields in that header. >>>>> >>>>> Or perhaps: >>>>> If the payload also specifies how it is used with the [Video?] Frame >>>>> Marking RTP Header Extension described in [RFC9626], the syntax MUST >>>>> be defined in the same manner as the TID and LID fields in that >>>>> header. >>>>> --> >>>>> >>>>> >>>>> 7) <!--[rfced] Section 3.7 of RFC 7656 is not titled "RTP Taxonomy" but >>>>> instead "Layered Multi-Stream". Please review this citation for >>>>> clarity/accuracy. >>>>> >>>>> Original: >>>>> The RTP Taxonomy [RFC7656] Section 3.7 defines three mechanisms: >>>>> Single RTP Stream on a Single Media Transport (SRST), Multiple RTP >>>>> Streams on a Single Media Transport (MRST), and Multiple RTP Streams >>>>> on Multiple Media Transports (MRMT). >>>>> >>>>> Perhaps (caps also edited to match RFC 7656): >>>>> Section 3.7 of "The RTP Taxonomy" [RFC7656] defines three mechanisms: >>>>> Single RTP stream on a Single media Transport (SRST), Multiple RTP >>>>> streams on a Single media Transport (MRST), and Multiple RTP streams >>>>> on Multiple media Transports (MRMT). >>>>> --> >>>>> >>>>> >>>>> 8) <!--[rfced] In the following, please clarify the antecedent of "it". >>>>> >>>>> Original: >>>>> For MRMT, it is sent on the RTP session on which this stream is sent. >>>>> --> >>>>> >>>>> >>>>> 9) <!--[rfced] We note that only Figure 9 has a title. Please review if >>>>> you would like all figures to have titles (and supply them) or >>>>> if the title of Figure 9 should be removed for consistency. --> >>>>> >>>>> >>>>> 10) <!--[rfced] We had the following questions related to the >>>>> abbreviations and initialisms used throughout the document: >>>>> >>>>> a) In the following equation, will it be clear to the reader what TO >>>>> and TN refer to? >>>>> >>>>> TID = TO and target TID = TN >>>>> >>>>> If these are abbreviations, they should be expanded on first use (per >>>>> RFC 7322). >>>>> >>>>> b) We see: >>>>> >>>>> CLID - Current Layer ID >>>>> >>>>> and also Current Layer Index (or current layer indices or layer >>>>> indices) >>>>> >>>>> Please review these occurrences and let us know if they should be made >>>>> uniform. >>>>> >>>>> c) We have expanded these abbreviations as follows. Please let us >>>>> know any objections. >>>>> >>>>> FCI - Feedback Control Information >>>>> SSRC - Synchronization Source >>>>> PLI - Picture Loss Indication >>>>> NAL - Network Abstraction Layer >>>>> PACSI - Payload Content Scalability Information >>>>> IDR - Instantaneous Decoding Refresh >>>>> SDP - Session Description Protocol >>>>> >>>>> d) We will update the following to be consistent with the first line >>>>> (below) in capping and initialism formation throughout the document. >>>>> We will remove the citations after the first use (outside the >>>>> Abstract). Please let us know any objections. >>>>> >>>>> RTCP Payload-Specific Feedback Message >>>>> RTCP [RFC3550] Payload-Specific Feedback Message [RFC4585] >>>>> RTP Control Protocol (RTCP) [RFC3550] payload-specific feedback message >>>>> RTP Control Protocol (RTCP) [RFC3550] payload-specific feedback message >>>>> [RFC4585] >>>>> >>>>> e) FYI: We've updated the usage of "LRR" by adding an article (i.e., >>>>> "the" or "an") before it for consistency with the majority of uses in this >>>>> document (primarily in Sections 3.2 and 4). Please let us know if this >>>>> is in error. >>>>> >>>>> Original: >>>>> Upon reception of LRR, the encoder MUST send a.. >>>>> ... >>>>> In order for LRR to be used with a scalable codec >>>>> ... >>>>> Senders which support receiving LRR for non-temporally-nested streams >>>>> MUST... >>>>> >>>>> Updated: >>>>> Upon reception of an LRR, the encoder MUST send a.. >>>>> ... >>>>> In order for an LRR to be used with a scalable codec >>>>> ... >>>>> Senders that support receiving LRRs for non-temporally-nested streams >>>>> MUST... >>>>> >>>>> >>>>> >>>>> --> >>>>> >>>>> >>>>> 11) <!--[rfced] We had the following questions related to the terminology >>>>> used throughout the document. >>>>> >>>>> a) Please review the way field names are treated with regard to >>>>> capitalization and quotation and let us know if/how they should be >>>>> made uniform. >>>>> >>>>> For example, we see: >>>>> >>>>> "R" field >>>>> "RES" field >>>>> layer index field >>>>> LayerId field vs. layer ID field vs. LID field (see related cluster query) >>>>> "media source" field >>>>> "Current Temporal Layer ID (CTID)" and "Current Layer ID (CLID)" fields >>>>> payload type field >>>>> "SSRC of packet sender" field >>>>> DID, QID, and TID fields >>>>> --> >>>>> >>>>> >>>>> 12) <!-- [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/rfc9627.xml >>>>> https://www.rfc-editor.org/authors/rfc9627.html >>>>> https://www.rfc-editor.org/authors/rfc9627.pdf >>>>> https://www.rfc-editor.org/authors/rfc9627.txt >>>>> >>>>> Diff file of the text: >>>>> https://www.rfc-editor.org/authors/rfc9627-diff.html >>>>> https://www.rfc-editor.org/authors/rfc9627-rfcdiff.html (side by side) >>>>> >>>>> Diff of the XML: >>>>> https://www.rfc-editor.org/authors/rfc9627-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/rfc9627.original.v2v3.xml >>>>> >>>>> XMLv3 file that is a best effort to capture v3-related format updates >>>>> only: >>>>> https://www.rfc-editor.org/authors/rfc9627.form.xml >>>>> >>>>> >>>>> Tracking progress >>>>> ----------------- >>>>> >>>>> The details of the AUTH48 status of your document are here: >>>>> https://www.rfc-editor.org/auth48/rfc9627 >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you for your cooperation, >>>>> >>>>> RFC Editor >>>>> >>>>> -------------------------------------- >>>>> RFC9627 (draft-ietf-avtext-lrr-07) >>>>> >>>>> Title : The Layer Refresh Request (LRR) RTCP Feedback Message >>>>> Author(s) : J. Lennox, D. Hong, J. Uberti, S. Holmer, M. Flodman >>>>> WG Chair(s) : Jonathan Lennox, Rachel Huang >>>>> Area Director(s) : Murray Kucherawy, Orie Steele >>>>> >>>>> >>>> >>> >> >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
