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
