Hi Justin, We have updated your postal address in both RFCs-to-be 9627 and 9628 (please refresh to view).
We don’t believe any further changes were necessary per your message; please let us know if this was in error. We have marked you as “Approved” for RFC-to-be 9627. We do not believe we’ve heard back regarding 9628’s readiness for publication. The files have been posted here: 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 diff files are posted here: https://www.rfc-editor.org/authors/rfc9627-diff.html https://www.rfc-editor.org/authors/rfc9627-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9627-auth48diff.html https://www.rfc-editor.org/authors/rfc9627-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9627-lastdiff.html https://www.rfc-editor.org/authors/rfc9627-lastrfcdiff.html (side by side) 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 here: https://www.rfc-editor.org/auth48/C324 Thank you. RFC Editor/mf > On Mar 9, 2025, at 6:16 PM, Justin Uberti <jus...@uberti.name> wrote: > > Regarding the codec names, VP8 is fine as-is, I was just suggesting what I > saw as the correct sub-headings for Section 4. > > Note that I still lean towards "H.264/SVC" rather than "H.264 SVC", but I > defer to the consensus of the group on this. Other than this nit and my > address update, I approve the publication of this document. > > Thanks, > Justin > > On Thu, Feb 20, 2025 at 8: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
