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
