I have one more change to RFC 9627. In Section 3.2, the sentence "An LRR SHOULD be used only in situations where there is an explicit change in a decoders’ behavior:” should have “decoder’s” not “decoders’” (apostrophe-S not S-apostrophe), because given the article it is referring to a singular decoder.
> On Feb 21, 2025, at 10:10 AM, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > Danny, > > Thank you for sending along your updated contact information. We have rolled > this change into the previous version of the files. > > As you indicated your approval, we have also updated the AUTH48 status page > to capture that information. > > 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/rfc9627.txt > https://www.rfc-editor.org/authors/rfc9627.pdf > https://www.rfc-editor.org/authors/rfc9627.html > https://www.rfc-editor.org/authors/rfc9627.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9627-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9627-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9627-lastdiff.html (last to current > version only) > https://www.rfc-editor.org/authors/rfc9627-lastrfcdiff.html (ditto but side > by side) > > 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/rfc9627 > > Thank you. > > RFC Editor/mf > > >> On Feb 21, 2025, at 6:40 AM, Danny Hong <dannyh...@google.com> wrote: >> >> New affiliation for Danny Hong: >> Google, Inc. >> 315 Hudson St, >> New York, NY 10013 >> United States of America >> Email: dannyh...@google.com >> >> On Fri, Feb 21, 2025 at 8:37 AM Danny Hong <dannyh...@google.com> wrote: >> My sincere apologies for the late response. The emails have been piling up >> straight into a folder without any notifications. Fixed this so that now >> the emails go directly into my inbox. All the edits look good to me. My >> affiliation should now be Google, though. >> >> Thank you >> Danny >> >> On Thu, Feb 20, 2025 at 11:14 PM Megan Ferguson >> <mfergu...@staff.rfc-editor.org> wrote: >> Justin, >> >> Note that the following question/comments for you remain open: >> >> 1) Justin - we have updated your affiliation. Please review the physical >> address in these docs and let us know what (if any) updates are necessary. >> >> 2) Please provide further information on VP8 in this list as we don’t see >> any punctuation with VP* throughout the cluster: >>> the headings for Section 4 should probably include punctuation, e.g,. >>> H.264/SVC, VP8, H.265 >> >> Thank you. >> >> RFC Editor/mf >> >> >>> On Feb 20, 2025, at 9:12 PM, Megan Ferguson >>> <mfergu...@staff.rfc-editor.org> wrote: >>> >>> Hi Jonathan, >>> >>> Thanks for your reply and guidance. >>> >>> We have rolled these changes into the previous version. Please review and >>> let us know if any further updates are necessary. >>> >>> We now consider all document-specific and cluster-wide questions resolved. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9627.txt >>> https://www.rfc-editor.org/authors/rfc9627.pdf >>> https://www.rfc-editor.org/authors/rfc9627.html >>> https://www.rfc-editor.org/authors/rfc9627.xml >>> >>> The relevant diff files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9627-diff.html (comprehensive diff) >>> https://www.rfc-editor.org/authors/rfc9627-auth48diff.html (AUTH48 changes >>> only) >>> https://www.rfc-editor.org/authors/rfc9627-lastdiff.html (last to current >>> version only) >>> https://www.rfc-editor.org/authors/rfc9627-lastrfc diff.html (las to >>> current side by side) >>> >>> 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/rfc9627 >>> >>> Thank you. >>> >>> RFC Editor/mf >>> >>>> On Feb 20, 2025, at 3:28 PM, Jonathan Lennox <jonathan.len...@8x8.com> >>>> wrote: >>>> >>>> >>>> >>>>> On Feb 20, 2025, at 2:21 PM, Megan Ferguson >>>>> <mfergu...@staff.rfc-editor.org> wrote: >>>>> >>>>> >>>>> 3) Regarding the response to our cluster-wide question about bit names >>>>> (moving to this thread as now document-specific), Jonathan said: >>>>>> In 9627: >>>>>> C could be described as “Current layer information present” or “CTID and >>>>>> CLID present” if you want a name for it. >>>>>> Y is used in this document to reference the “Y” bit defined in RFC 7741, >>>>>> where it is named “1 layer sync bit”. >>>>> … >>>>>> I’m not sure what’s the best way to use this information, however. >>>>> >>>>> Perhaps no change to C as we already have: >>>>> >>>>> C (1 bit): >>>>> A flag bit indicating whether the Current Temporal-layer ID (CTID) >>>>> and Current Layer ID (CLID) fields are present in the FCI. If >>>>> this bit is 0, the sender of the LRR message is requesting refresh >>>>> of all layers up to and including the target layer. >>>> >>>> >>>> That seems good. >>>> >>>>> Perhaps just a citation for Y?: >>>>> A VP8 layer refresh point can be identified by the presence of the Y >>>>> bit (see [RFC7741]) in the VP8 payload header. >>>> >>>> Agreed. >>>> >>>> >>>>> 4) Please review points 3 and 4 from Madison’s mail (originally sent 13 >>>>> February) and let us know how you would like to proceed. Note also that >>>>> we will assume the other actions she described us taking in that same >>>>> mail are acceptable unless we hear objection. >>>>> >>>>>> >>>>>> >>>>>>>>> 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). >>>>>>> >>>>>>> These are nonce variables so we can talk about the specific values of >>>>>>> CTID and TTID sent in a hypothetical LRR message. Is there a clearer >>>>>>> way to express this? >>>>>> >>>>>> 3) Thank you for the clarification! Perhaps adding a note at the end of >>>>>> the sentence would clarify this for readers? >>>>>> >>>>>> Current: >>>>>> In this case, given current TID = TO and target TID = TN, layer refresh >>>>>> to TN is satisfied when a >>>>>> NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the way >>>>>> up to TID = TN. >>>>>> >>>>>> Perhaps: >>>>>> In this case, given current TID = TO and target TID = TN, layer refresh >>>>>> to TN is satisfied when a >>>>>> NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the way >>>>>> up to TID = TN (note that >>>>>> TN and TO refer to nonce variables in this instance). >>>> >>>> If you think that’s clearer, it works for me. >>>> >>>>>> 4) We have removed quotes surrounding field names upon first use for >>>>>> consistency. Also, please note that the following terms still need >>>>>> review: >>>>>> >>>>> [snip] >>>>>> Current Layer ID (CLID) vs. Current Layer Index >>>> >>>> Note the last paragraph of section 2: >>>> >>>> A "layer index" is a numeric label for a specific spatial and temporal >>>> layer of a scalable stream. It consists of both a "temporal-layer ID" >>>> identifying the temporal layer and a "layer ID" identifying the spatial or >>>> quality layer. The details of how layers of a scalable stream are labeled >>>> are codec specific. Details for several codecs are defined in Section 4.¶ >>>> >>>> So these are two separate things. >>>> >>>>> >>>>> 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/rfc9627.txt >>>>> https://www.rfc-editor.org/authors/rfc9627.pdf >>>>> https://www.rfc-editor.org/authors/rfc9627.html >>>>> https://www.rfc-editor.org/authors/rfc9627.xml >>>>> >>>>> The relevant diff files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9627-diff.html (comprehensive diff) >>>>> https://www.rfc-editor.org/authors/rfc9627-auth48diff.html (AUTH48 >>>>> changes only) >>>>> https://www.rfc-editor.org/authors/rfc9627-lastdiff.html (last to current >>>>> version only) >>>>> https://www.rfc-editor.org/authors/rfc9627-lastrfc diff.html (las to >>>>> current side by side) >>>>> >>>>> 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/rfc9627 >>>>> >>>>> Thank you. >>>>> >>>>> RFC Editor/mf >>>>> >>>>>> On Feb 20, 2025, at 12:06 AM, Justin Uberti <jus...@uberti.name> wrote: >>>>>> >>>>>> A few very minor nits that I encountered when reviewing this document: >>>>>> - the RFC9626 reference for frame marking mistakenly refers to RFC 9621 >>>>>> - the headings for Section 4 should probably include punctuation, e.g,. >>>>>> H.264/SVC, VP8, H.265 >>>>>> - my affiliation is now OpenAI rather than Google >>>>>> >>>>>> Thanks, >>>>>> Justin >>>>>> >>>>>> On Wed, Feb 19, 2025 at 2:28 PM Jonathan Lennox >>>>>> <jonathan.len...@8x8.com> wrote: >>>>>> A few changes: >>>>>> >>>>>> Section 2.1: since “FIR” is usually pronounced “eff-eye-arr” not “fir” >>>>>> like the tree, it begins with a vowel sound. Thus, presumably the >>>>>> second sentence of the third paragraph should be “This is the difference >>>>>> between a layer refresh and an FIR [RFC5104]”. I.e. “an” rather than “a”. >>>>>> >>>>>> Section 2.1 again, paragraphs after the figures: the text should remain >>>>>> “spatial layer S1” and “spatial layer S0”, not hyphenated. In this >>>>>> usage “spatial layer” is a noun, describing specific spatial layers >>>>>> named “S0” or “S1”, not an adjective. >>>>>> >>>>>> Section 3, third paragraph, should start “The design of LRR” (not “An >>>>>> LRR”), since this is discussing the overall mechanism, not a specific >>>>>> message. >>>>>> >>>>>>> On Feb 19, 2025, at 3:05 PM, Megan Ferguson >>>>>>> <mfergu...@staff.rfc-editor.org> wrote: >>>>>>> >>>>>>> Apologies for the noise, resending with our current email (please reply >>>>>>> to this address) >>>>>>> >>>>>>>> On Feb 19, 2025, at 12:48 PM, Megan Ferguson <mfergu...@amsl.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Greetings, >>>>>>>> >>>>>>>> This document has been updated with the responses to our cluster-wide >>>>>>>> queries we have received to date. Please review these updates >>>>>>>> carefully as we do not make changes once the document is published as >>>>>>>> an RFC. >>>>>>>> >>>>>>>> Note that we will await the following prior to moving forward in the >>>>>>>> publication process: >>>>>>>> -responses to the follow-up questions sent by Madison (see previous >>>>>>>> email) >>>>>>>> -resolution of outstanding cluster-wide issues (see separate email >>>>>>>> thread) >>>>>>>> -approvals from each author >>>>>>>> >>>>>>>> The files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9627.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9627.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9627.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9627.xml >>>>>>>> >>>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9627-diff.html (comprehensive >>>>>>>> diff) >>>>>>>> https://www.rfc-editor.org/authors/rfc9627-auth48diff.html (AUTH48 >>>>>>>> changes only) >>>>>>>> https://www.rfc-editor.org/authors/rfc9627-lastdiff.html (last to >>>>>>>> current version only) >>>>>>>> >>>>>>>> The AUTH48 status page for this document is available here: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9627 >>>>>>>> >>>>>>>> The AUTH48 status page for this cluster is available here: >>>>>>>> https://www.rfc-editor.org/auth48/C324 >>>>>>>> >>>>>>>> Please contact us with any further updates/questions/comments you may >>>>>>>> have. >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> RFC Editor/mf >>>>>>>> >>>>>>>>> On Feb 13, 2025, at 10:36 AM, Madison Church >>>>>>>>> <mchu...@staff.rfc-editor.org> wrote: >>>>>>>>> >>>>>>>>> Hi Jonathan, >>>>>>>>> >>>>>>>>> Thank you for your reply! We have updated the document per your >>>>>>>>> response. Please see the thread below for followup comments and >>>>>>>>> updated files. >>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> That’s fine. >>>>>>>>>> >>>>>>>>>>>> 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. >>>>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> Aren’t these all already defined in Section 2, or am I missing >>>>>>>>>> something? >>>>>>>>> >>>>>>>>> 1) Thank you for pointing this out. When re-reviewing Section 2.1, it >>>>>>>>> looks like the highlighted terms in question 3b are defined. >>>>>>>>> >>>>>>>>> For example (paragraph above Section 3): >>>>>>>>> "A 'layer index' is a numeric label for a specific spatial and >>>>>>>>> temporal layer of a scalable stream." >>>>>>>>> >>>>>>>>> We have left the definitions as is in this section. >>>>>>>>> >>>>>>>>>>>> 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. >>>>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> The latter seems good, including the word “Video”. >>>>>>>>> >>>>>>>>> 2) We have updated the sentence above to use the second option. If >>>>>>>>> there are any additional changes needed to the text above (in >>>>>>>>> reference to the current status of RFC 9626), please let us know and >>>>>>>>> we will make those updates as well. >>>>>>>>> >>>>>>>>>>>> 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). >>>>>>>>>> >>>>>>>>>> These are nonce variables so we can talk about the specific values >>>>>>>>>> of CTID and TTID sent in a hypothetical LRR message. Is there a >>>>>>>>>> clearer way to express this? >>>>>>>>> >>>>>>>>> 3) Thank you for the clarification! Perhaps adding a note at the end >>>>>>>>> of the sentence would clarify this for readers? >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> In this case, given current TID = TO and target TID = TN, layer >>>>>>>>> refresh to TN is satisfied when a >>>>>>>>> NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the >>>>>>>>> way up to TID = TN. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> In this case, given current TID = TO and target TID = TN, layer >>>>>>>>> refresh to TN is satisfied when a >>>>>>>>> NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the >>>>>>>>> way up to TID = TN (note that >>>>>>>>> TN and TO refer to nonce variables in this instance). >>>>>>>>> >>>>>>>>>>>> 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. >>>>>>>>>>>> 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 >>>>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> I think I’ve tended to use quotes on first reference to a field, and >>>>>>>>>> not use them subsequently, but if you think that’s confusing feel >>>>>>>>>> free to remove them. >>>>>>>>>> >>>>>>>>>> I think I’ve also tended to use capitalization when referring to a >>>>>>>>>> protocol element and use plain English when referring to the >>>>>>>>>> abstract concept carried in that protocol element, but if you want >>>>>>>>>> to normalize them that's fine. >>>>>>>>> >>>>>>>>> 4) We have removed quotes surrounding field names upon first use for >>>>>>>>> consistency. Also, please note that the following terms still need >>>>>>>>> review: >>>>>>>>> >>>>>>>>> LayerId field vs. layer ID field vs. LID field (see related cluster >>>>>>>>> query) >>>>>>>>> Current Layer ID (CLID) vs. Current Layer Index >>>>>>>>> >>>>>>>>> >>>>>>>>> The updated files have been posted here (please refresh): >>>>>>>>> https://www.rfc-editor.org/authors/rfc9627.txt >>>>>>>>> https://www.rfc-editor.org/authors/rfc9627.pdf >>>>>>>>> https://www.rfc-editor.org/authors/rfc9627.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9627.xml >>>>>>>>> >>>>>>>>> The updated diff files have been posted here (please refresh): >>>>>>>>> https://www.rfc-editor.org/authors/rfc9627-diff.html (comprehensive >>>>>>>>> diff) >>>>>>>>> https://www.rfc-editor.org/authors/rfc9627-rfcdiff.html (side by side) >>>>>>>>> https://www.rfc-editor.org/authors/rfc9627-auth48diff.html (AUTH48 >>>>>>>>> changes) >>>>>>>>> https://www.rfc-editor.org/authors/rfc9627-auth48rfcdiff.html (side >>>>>>>>> by side) >>>>>>>>> >>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9627 >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> RFC Editor/mc >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
