Looks good to me, I approve Thanks, -Magnus
On Tue, Mar 18, 2025 at 7:14 AM Jonathan Lennox <jonathan.len...@8x8.com> wrote: > Reminder to Stefan and Magnus - we need your approvals on 9627 (LRR) as > well. Thanks! > > > On Mar 12, 2025, at 1:24 AM, Megan Ferguson < > mfergu...@staff.rfc-editor.org> wrote: > > > > 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
