Other than Justin’s postal address, this document is good to go; I approve once that’s resolved.
Justin, please send your current postal contact address you want listed in the draft — right now it still lists Google’s Kirkland address. > On Mar 4, 2025, at 2:11 PM, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > Hi all, > > Just checking in to see if you’ve had a chance to review the files posted > (see email below)? > > Please let us know if any further changes are necessary or if you’d like to > approve the current version. > > Once we have approvals from each author listed at the AUTH48 status page for > this document (see below), we will be ready to move it forward in the > publication process with its cluster. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9627 > > Please see the AUTH48 status page for all documents in the cluster here: > > https://www.rfc-editor.org/auth48/C324 > > Thank you. > > RFC Editor/mf > > >> On Feb 21, 2025, at 3:13 PM, Megan Ferguson <mfergu...@staff.rfc-editor.org> >> wrote: >> >> Jonathan, >> >> Thank you for spotting that! We have updated the files to include this >> change. >> >> 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 2:01 PM, Jonathan Lennox <jonathan.len...@8x8.com> >>> wrote: >>> >>> 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
