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
