All,
Thank you for your replies. We have updated accordingly with the responses we
have received thus far to our document-specific and cluster-wide queries.
To follow up on a few of these items:
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
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.
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.
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).
>
> 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
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
