No remaining issues from my side, Looks good to me. -Magnus
On Wed, Feb 19, 2025 at 8:55 AM Stefan Holmer <hol...@google.com> wrote: > Sorry for the delayed response. > > Looks good to me overall, I found one nit in the text for "Figure 1": > > "Figure 1: General RTP Payload Format for VP" > > Just missing the "9". > > /Stefan > > On Fri, Feb 14, 2025 at 5:45 PM Zaheduzzaman Sarker < > zahed.sarker.i...@gmail.com> wrote: > >> >> >> On Fri, Feb 7, 2025 at 9:21 PM Jonathan Lennox <jonathan.len...@8x8.com> >> wrote: >> >>> >>> >>> On Oct 10, 2024, at 6:28 AM, Zaheduzzaman Sarker < >>> zahed.sarker.i...@gmail.com> wrote: >>> >>> >>> >>> On Mon, Oct 7, 2024 at 8:35 PM Megan Ferguson <mfergu...@amsl.com> >>> wrote: >>> >>>> Zahed, >>>> >>>> Thank you for your reply and guidance. >>>> >>>> It looks like we note that questions 10, 19, and 21F could also benefit >>>> from AD approval/guidance on the AUTH48 status page - and we’ve thrown in >>>> question 11 in case you had thoughts (questions and previous replies copied >>>> below for your convenience): >>>> >>>> >>>> >> 10) <!--[rfced] If TID expands to "temporal layer ID", does this >>>> text say >>>> >> "with TID equal to TID"? Please clarify (and see our related >>>> cluster-wide question). >>>> >> >>>> >> Original: >>>> >> If this bit is set to 1 for the current picture with temporal layer >>>> ID >>>> >> equal to TID... >>>> >> >>>> >> --> >>>> > >>>> > Yes, that’s poorly worded, but I’m having some trouble expressing it >>>> clearly. >>>> > >>>> > The sentence is trying to talk about a specific frame’s value of SID, >>>> so that it can talk about that value later in the sentence. >>>> > >>>> > Possibly change the variable to “T”, as in: >>>> > >>>> > Switching up point. If this bit is set to 1 for the current picture >>>> with a temporal-layer ID equal to T, then "switch up" to a higher frame >>>> rate is possible as subsequent higher temporal-layer pictures will not >>>> depend on any picture before the current picture (in coding order) with >>>> temporal-layer ID greater than T.¶ >>>> > >>>> > >>>> > The point is that when the bit is set, then if the current frame has >>>> a temporal-layer ID value X, then subsequent frames with TID>X will not >>>> depend on earlier frames with TID>X. >>>> > >>>> > Can you help me come up with a clearer way to express this? >>>> >>>> Perhaps: >>>> Switching up point. When this bit is set to 1, if the current picture >>>> has a temporal-layer ID equal to value T, then subsequent pictures with >>>> temporal-layer ID values higher than T will not depend on any picture >>>> before the current picture (in coding order) with a temporal-layer ID value >>>> greater than T. >>>> >>> >>> This should be OK. However, as we are introducing a new variable, I >>> would like the authors to ping the working group to see if there could be >>> any issues with that or not. Authors please send an email to the mailing >>> list regarding this proposal. >>> >>> >>> This isn’t a new variable semantically, it’s just naming a nonce value >>> to express the existing concept more clearly. Do you really think it needs >>> WG approval? >>> >> >> It's not a MUST, but I would be good to inform the wg about this change. >> >> >>> >>> >>> >> 11) <!--[rfced] We note that not all fields that appear in Figure 4 >>>> are >>>> >> described following it. Please review and let us know if text >>>> >> (or a pointer to where the reader can get more information on >>>> >> these fields) should be added. >>>> >> >>>> >> --> >>>> > >>>> > R is only specified in the diagram - it is the number of P_DIFF >>>> fields that are present. (I agree this is not great.) TID, U, and P_DIFF >>>> have the same semantics as they do in the previous section, except that >>>> they apply to the picture described in the picture group, rather than the >>>> current picture. >>>> >>>> -Regarding question 11, please provide any updates you would like us to >>>> make to add description or pointers to descriptions for the items in the >>>> figure. >>>> >>> >>> I will wait for the authors to respond to it. I noted that here we use >>> TID, this should be changed to T according to the previous change, right? >>> >>> >>> Agreed, these two descriptions should be parallel. >>> >>> >> >>>> >> 19) <!--[rfced] Please review the entry for "Change Controller" in >>>> Section >>>> >> 7. While we see similar text for the vp8 and vc2 entries, we >>>> want to >>>> >> confirm that this entry has been reviewed with the following in >>>> >> mind from >>>> >> https://www.iana.org/help/protocol-registration: >>>> >> >>>> >> "The IESG shouldn't be listed as a change controller unless the >>>> >> RFC that created the registry (e.g. port numbers, XML namespaces >>>> >> and schemas) requires it. The IETF should be named instead." >>>> >> >>>> >> --> >>>> > >>>> > I’d be happy for the change controller to be something like "IETF >>>> AVTCore Working Group delegated from the IETF”, but I think this should be >>>> an AD question. ADs? >>>> >>> >>> This is fine. >>> >>> >>>> >>>> >>>> >>>> >>>> >> f) Is N_S an abbreviation for "Number of Spatial layers"? Might the >>>> >> explanation in Section 4.2.1 be made clearer? >>>> >> >>>> >> Original: >>>> >> N_S: N_S + 1 indicates the number of spatial layers present in the >>>> VP9 >>>> >> stream. >>>> >> >>>> >> Perhaps: >>>> >> N_S: Number of Spatial layers. N_S + 1 indicates the number of >>>> >> spatial layers present in the VP9 stream. >>>> > >>>> > Let’s call it “Number of Spatial Layers Minus 1” to be clear? >>>> >>> >>> why the "plus 1" is becoming "minus 1", is not clear to me. Jonathan, >>> could you explain? >>> >>> //Zahed >>> >>> >>> The semantic value is the number of spatial layers, the protocol element >>> on the wire is one less than that (since it’s impossible to have zero >>> spatial layers). >>> >>> So if N_S is the protocol element, >>> >>> N_S + 1 = number of spatial layers >>> >>> Or rearranging >>> N_S = number of spatial layers minus 1. >>> >> >> I see. It's fine with me. >> >> @rfc-editor. Are there any remaining issues with this document other than >> the author's approval? >> >> //Zahed >> >> >>> >>> >>> >>>> We have updated the files to reflect Zahed's guidance for question 6. >>>> >>>> Please review the files carefully as we do not make changes after >>>> publication. >>>> >>>> The files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9628.txt >>>> https://www.rfc-editor.org/authors/rfc9628.pdf >>>> https://www.rfc-editor.org/authors/rfc9628.html >>>> https://www.rfc-editor.org/authors/rfc9628.xml >>>> >>>> The relevant diff files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9628-diff.html (comprehensive >>>> diff) >>>> https://www.rfc-editor.org/authors/rfc9628-auth48diff.html (AUTH48 >>>> changes only) >>>> https://www.rfc-editor.org/authors/rfc9628-lastdiff.html (last to >>>> current version only) >>>> >>>> Please contact us with any further updates/questions/comments you may >>>> have. >>>> >>>> We will await approvals from each of the parties listed on the AUTH48 >>>> status page prior to moving forward to publication. >>>> >>>> The AUTH48 status page for this document is available here: >>>> >>>> https://www.rfc-editor.org/auth48/rfc9628 >>>> >>>> Thank you. >>>> >>>> RFC Editor/mf >>>> >>>> >>>> >>>> >>>> >>>> >>>> > On Oct 7, 2024, at 9:36 AM, Zaheduzzaman Sarker < >>>> zahed.sarker.i...@gmail.com> wrote: >>>> > >>>> > Hi, >>>> > >>>> > For question 6, I would prefer to pick alternative B, for both cases. >>>> This option does make it clear without adding the extra "MUST" in the >>>> sentence, I am expecting the defaults value is Zero here. >>>> > >>>> > //Zahed >>>> > >>>> > On Tue, Aug 13, 2024 at 6:28 AM <rfc-edi...@rfc-editor.org> wrote: >>>> > Authors and *AD, >>>> > >>>> > [AD - please see question 6 below] >>>> > >>>> > While reviewing this document during AUTH48, please resolve (as >>>> necessary) the following questions, which are also in the XML file. >>>> > >>>> > 1) <!--[rfced] Please note that we have updated the title of Section >>>> 2 to >>>> > more accurately describe its contents. Please let us know any >>>> > objections.--> >>>> > >>>> > >>>> > 2) <!--[rfced] Might replacing the slash in the following with "and", >>>> > "or", or "and/or" be helpful to the reader? >>>> > >>>> > Original: >>>> > ...for a particular resolution/quality,... >>>> > --> >>>> > >>>> > >>>> > 3) <!-- [rfced] FYI: We've updated the following sentence by adding >>>> "a" >>>> > before "previously coded frame in time". Please let us know if >>>> > this changes the intended meaning. >>>> > >>>> > Original: >>>> > This "inter-layer" dependency can result in additional coding gain >>>> > compared to the case where only traditional "inter-picture" >>>> dependency is >>>> > used, where a frame depends on previously coded frame in time. >>>> > >>>> > Updated: >>>> > This "inter-layer" dependency can result in additional coding gain >>>> > compared to the case where only traditional "inter-picture" >>>> dependency is >>>> > used, where a frame depends on a previously coded frame in time. >>>> > --> >>>> > >>>> > >>>> > 4) <!-- [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). >>>> > --> >>>> > >>>> > >>>> > 5) <!--[rfced] Should "the specifications" in this text be clarified >>>> for >>>> > the reader? >>>> > >>>> > Original: >>>> > All integer fields in the specifications are encoded as unsigned >>>> > integers in network octet order. >>>> > --> >>>> > >>>> > >>>> > 6) <!--[rfced] [*AD] In the following, we believe restructuring the >>>> text >>>> > may clarify the applicability of the BCP 14 keywords (are both >>>> > parts of the sentence MUSTs?). Please review. >>>> > >>>> > Instance 1: >>>> > >>>> > Original: >>>> > Marker bit (M): MUST be set to 1 for the final packet of the >>>> highest >>>> > spatial layer frame (the final packet of the picture), and 0 >>>> > otherwise. >>>> > >>>> > Perhap A: >>>> > Marker bit (M): This bit MUST be set to 1 for the final packet of >>>> > the highest spatial-layer frame (the final packet of the picture); >>>> > otherwise, it MUST be 0. >>>> > >>>> > Perhaps B: >>>> > Marker bit (M): This bit MUST be set to 1 for the final packet of >>>> > the highest spatial-layer frame (the final packet of the picture); >>>> > otherwise, it is 0. >>>> > >>>> > Instance 2: >>>> > >>>> > Original: >>>> > MUST be set to 1 for the final RTP packet of a >>>> > VP9 frame, and 0 otherwise >>>> > >>>> > Perhaps A: >>>> > This bit MUST be set to 1 for the final RTP packet of a VP9 frame; >>>> > otherwise, it MUST be 0. >>>> > >>>> > Perhaps B: >>>> > This bit MUST be set to 1 for the final RTP packet of a VP9 frame; >>>> > otherwise, it is 0. >>>> > --> >>>> > >>>> > >>>> > 7) <!--[rfced] Section 4.2: It seems the descriptions following >>>> Figure 3 >>>> > apply to both Figures 2 and 3. If that is so, might a note of >>>> this appear somewhere earlier in that section for the ease of the >>>> reader?--> >>>> > >>>> > >>>> > 8) <!-- [rfced] FYI: We've removed quotes from around certain bit >>>> names, >>>> > e.g., ""D" bit" for consistency with similar uses in this >>>> > document. Please let us know if this is not preferred. Please >>>> > also see our cluster-wide question regarding bit names prior to >>>> > reply. >>>> > --> >>>> > >>>> > >>>> > 9) <!--[rfced] Might a clarification of "This information" be helpful >>>> to the reader? >>>> > >>>> > Original: >>>> > >>>> > Layer indices: This information is optional but RECOMMENDED >>>> whenever >>>> > encoding with layers. >>>> > >>>> > Perhaps: >>>> > >>>> > Layer indices: This field is optional but RECOMMENDED whenever >>>> > encoding with layers. >>>> > --> >>>> > >>>> > >>>> > 10) <!--[rfced] If TID expands to "temporal layer ID", does this text >>>> say >>>> > "with TID equal to TID"? Please clarify (and see our related >>>> cluster-wide question). >>>> > >>>> > Original: >>>> > If this bit is set to 1 for the current picture with temporal layer ID >>>> > equal to TID... >>>> > >>>> > --> >>>> > >>>> > >>>> > 11) <!--[rfced] We note that not all fields that appear in Figure 4 >>>> are >>>> > described following it. Please review and let us know if text >>>> > (or a pointer to where the reader can get more information on >>>> > these fields) should be added. >>>> > >>>> > --> >>>> > >>>> > >>>> > 12) <!--[rfced] Section 5.1 is titled "Reference Picture Selection >>>> > Indication (RPSI)". The first sentence of this section uses >>>> > "reference picture selection index". Please review if "index" is >>>> > correct or if it should be made "indication" (or vice versa).--> >>>> > >>>> > >>>> > 13) <!--[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://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-aside-2). >>>> > --> >>>> > >>>> > >>>> > 14) <!-- [rfced] In the following sentences: >>>> > >>>> > a) does the receiver want to upgrade to {2,1}? How might we clarify >>>> > "which"? >>>> > >>>> > b) please review the use of commas between the braced values. Is our >>>> > suggestion correct? >>>> > >>>> > Original: >>>> > LRR {1,0}, {2,1} is sent by an MCU when it is currently relaying >>>> > {1,0} to a receiver and which wants to upgrade to {2,1}. In >>>> > response the encoder should encode the next frames in layers {1,1} >>>> > and {2,1} by only referring to frames in {1,0}, or {0,0}. >>>> > >>>> > >>>> > Perhaps: >>>> > LRR {1,0} {2,1} is sent by an MCU when it is currently relaying >>>> > {1,0} to a receiver that wants to upgrade to {2,1}. In response, >>>> > the encoder should encode the next frames in layers {1,1} and {2,1} >>>> > by only referring to frames in {1,0} or {0,0}. >>>> > >>>> > --> >>>> > >>>> > >>>> > 15) <!--[rfced] In the following, please review the use of "value" >>>> > (singular) and "receivers" (not possessive?). >>>> > >>>> > Original: >>>> > ...where a media sender does not have media available that fits within >>>> > a receivers max-fs and max-fr value;... >>>> > >>>> > Perhaps: >>>> > ...where a media sender does not have media available that fits within >>>> > a receiver's max-fs and max-fr values;... >>>> > >>>> > --> >>>> > >>>> > >>>> > 16) <!--[rfced] Might adding "each" to the following text be helpful >>>> for >>>> > the reader? Or is the intention that the width and height be >>>> > taken together? (Same question for the last sentence of this >>>> > paragraph.) >>>> > >>>> > Original: >>>> > The decoder is capable of decoding this frame size as long as >>>> the >>>> > width and height of the frame in macroblocks are less than >>>> > int(sqrt(max-fs * 8)) - 8))... >>>> > >>>> > Perhaps: >>>> > The decoder is capable of decoding this frame size as long as >>>> the >>>> > width and height of the frame in macroblocks are each less than >>>> > int(sqrt(max-fs * 8)) - 8))... >>>> > >>>> > --> >>>> > >>>> > >>>> > 17) <!--[rfced] Please note that we have shortened the title of Table >>>> 2 >>>> > and rephrased to avoid awkward hyphenation. Please review and >>>> > let us know any objections. >>>> > >>>> > Original: >>>> > Table of profile-id integer values representing the VP( profile >>>> > corresponding to the set of coding tools supported Current: profile-id >>>> > to VP9 Profile Integer Comparison >>>> > >>>> > Current: >>>> > Comparison of profile-id to VP9 Profile Integer >>>> > --> >>>> > >>>> > >>>> > 18) <!--[rfced] Please note that after AUTH48 concludes, we will >>>> > communicate any changes to the media type template in Section 7 >>>> > to IANA for corresponding updates to >>>> > https://www.iana.org/assignments/media-types/video/VP9 to be >>>> > made.--> >>>> > >>>> > >>>> > 19) <!--[rfced] Please review the entry for "Change Controller" in >>>> Section >>>> > 7. While we see similar text for the vp8 and vc2 entries, we >>>> want to >>>> > confirm that this entry has been reviewed with the following in >>>> > mind from >>>> > https://www.iana.org/help/protocol-registration: >>>> > >>>> > "The IESG shouldn't be listed as a change controller unless the >>>> > RFC that created the registry (e.g. port numbers, XML namespaces >>>> > and schemas) requires it. The IETF should be named instead." >>>> > >>>> > --> >>>> > >>>> > >>>> > 20) <!--[rfced] Should any further information on the IANA >>>> Considerations >>>> > for the "RTP Payload Format Media Types" registry be given? >>>> > >>>> > Perhaps: >>>> > The media type has also been added to the "RTP Payload Format Media >>>> > Types" subregistry of th e"Real-Time Transport Protocol (RTP) >>>> > Parameters" registry as follows: >>>> > >>>> > Media Type: video >>>> > Subtype: VP9 >>>> > Clock Rate (Hz): 90000 >>>> > Reference: RFC 9628 >>>> > --> >>>> > >>>> > >>>> > 21) <!-- [rfced] Terminology and abbreviations: We had the following >>>> > questions related to terminology or abbreviation use throughout >>>> > the document. >>>> > >>>> > a) The following terms had different forms throughout this >>>> > document. Please let us know if/how these may be made uniform. >>>> > >>>> > reference indices vs. Reference Indices >>>> > >>>> > b) We have updated these terms to be the form on the right to match >>>> > use in the companion documents and/or be consistent within this >>>> > document. >>>> > >>>> > key frame vs. keyframe >>>> > "max-fs" vs. max-fs >>>> > "max-fr" vs. max-fr >>>> > "profile-id" vs. profile-id >>>> > >>>> > c) How may we expand "SRGB"? Segment Routing Global Block? If so, >>>> > would you like to add as a note to the table? Or is this something >>>> > that could be housed in the Terminology section? >>>> > >>>> > d) Is SID expanded to spatial-layer ID? It seems so here: >>>> > >>>> > Original: >>>> > ...temporal-layer ID (TID) and spatial layer ID (SID)... >>>> > >>>> > If SID is spatial-layer ID (please also see our cluster-wide question >>>> > regarding this abbreviation as well as our related question about TID >>>> > before responding), please review the following text as it seems to >>>> > state the SID is equal to SID: >>>> > >>>> > Original: >>>> > Within a picture, a frame with spatial layer ID equal to SID... >>>> > >>>> > >>>> > >>>> > e) We note that TL0PICIDX is expanded in RFC-to-be 9626 as "Temporal >>>> > Layer 0 Picture Index". Please let us know if/how we may update the >>>> > following to make this document consistent within the cluster. >>>> > >>>> > Original: >>>> > TL0PICIDX: 8 bits temporal-layer zero index. >>>> > >>>> > and >>>> > >>>> > ...is used to represent temporal layer 0 index (TL0PICIDX)... >>>> > >>>> > Further, may we update to either "8-bit" or rephrase to put this >>>> > information in parentheses (as was done in RFC 9626)? >>>> > >>>> > f) Is N_S an abbreviation for "Number of Spatial layers"? Might the >>>> > explanation in Section 4.2.1 be made clearer? >>>> > >>>> > Original: >>>> > N_S: N_S + 1 indicates the number of spatial layers present in the VP9 >>>> > stream. >>>> > >>>> > Perhaps: >>>> > N_S: Number of Spatial layers. N_S + 1 indicates the number of >>>> > spatial layers present in the VP9 stream. >>>> > >>>> > g) Please note that we have expanded these abbreviations as follows. >>>> > Please let us know any objections. >>>> > >>>> > MCU - Multipoint Control Unit (per RFC 5104) >>>> > >>>> > --> >>>> > >>>> > >>>> > 22) <!-- [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. >>>> > >>>> > We see the use of "native" but note that it is a quote from RFC 4585. >>>> > >>>> > In addition, please consider whether "tradition" and "traditionally" >>>> > should be updated for clarity. While the NIST website >>>> > < >>>> https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1 >>>> > >>>> > indicates that this term is potentially biased, it is also ambiguous. >>>> > "Tradition" is a subjective term, as it is not the same for everyone. >>>> > --> >>>> > >>>> > >>>> > 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/rfc9628.xml >>>> > https://www.rfc-editor.org/authors/rfc9628.html >>>> > https://www.rfc-editor.org/authors/rfc9628.pdf >>>> > https://www.rfc-editor.org/authors/rfc9628.txt >>>> > >>>> > Diff file of the text: >>>> > https://www.rfc-editor.org/authors/rfc9628-diff.html >>>> > https://www.rfc-editor.org/authors/rfc9628-rfcdiff.html (side by >>>> side) >>>> > >>>> > Diff of the XML: >>>> > https://www.rfc-editor.org/authors/rfc9628-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/rfc9628.original.v2v3.xml >>>> > >>>> > XMLv3 file that is a best effort to capture v3-related format updates >>>> > only: >>>> > https://www.rfc-editor.org/authors/rfc9628.form.xml >>>> > >>>> > >>>> > Tracking progress >>>> > ----------------- >>>> > >>>> > The details of the AUTH48 status of your document are here: >>>> > https://www.rfc-editor.org/auth48/rfc9628 >>>> > >>>> > Please let us know if you have any questions. >>>> > >>>> > Thank you for your cooperation, >>>> > >>>> > RFC Editor >>>> > >>>> > -------------------------------------- >>>> > RFC9628 (draft-ietf-payload-vp9-16) >>>> > >>>> > Title : RTP Payload Format for VP9 Video >>>> > Author(s) : J. Uberti, S. Holmer, M. Flodman, D. Hong, J. >>>> Lennox >>>> > 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
