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
