Lgtm, approved! On Wed, 19 Mar 2025, 11:35 Magnus Flodman, <mflod...@google.com> wrote:
> 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
