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
