See Mo: inline for 9626.
________________________________
From: Megan Ferguson <mfergu...@staff.rfc-editor.org>
Sent: Wednesday, February 19, 2025 2:49 PM
To: Mo Zanaty (mzanaty) <mzan...@cisco.com>; Jonathan Lennox
<jonathan.lennox=408x8....@dmarc.ietf.org>
Cc: Suhas Nandakumar (snandaku) <snand...@cisco.com>; Espen Berger (espeberg)
<espeb...@cisco.com>; Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com>;
Bernard Aboba <bernard.ab...@gmail.com>; Jonathan Lennox
<jonathan.lenno...@gmail.com>; da...@vidyo.com <da...@vidyo.com>;
dannyh...@google.com <dannyh...@google.com>; mflod...@google.com
<mflod...@google.com>; hol...@google.com <hol...@google.com>;
jus...@uberti.name <jus...@uberti.name>; rachel.hu...@huawei.com
<rachel.hu...@huawei.com>; Murray S. Kucherawy <superu...@gmail.com>; Francesca
Palombini <francesca.palomb...@ericsson.com>; Orie Steele
<orie@transmute.industries>; RFC Editor <rfc-edi...@rfc-editor.org>;
auth48archive@rfc-editor.org <auth48archive@rfc-editor.org>
Subject: Re: Cluster C324 questions: RFCs 9626
<draft-ietf-avtext-framemarking>, 9627 <draft-ietf-avtext-lrr>, and 9628
<draft-ietf-payload-vp9>
Hi Mo and Jonathan,
Thank you for your replies regarding these cluster-wide questions. We had some
follow up questions/comments for you to consider (numbering based on our
original numbering for these questions). We will await replies to the
following prior to moving this cluster forward in the publication process.
Question 1 (a-c): We have updated to use the forms Jonathan mentioned with:
-didactic caps when used with an abbreviation and
-hyphenation in attributive position
Please review these updates and confirm that you have no objections.
Mo: No objections beyond those noted in the 9626 specific email.
Question 2 (regarding the names of bits): We attempted to implement Mo’s
suggestion to add the bit names/expansions on first use and then use simply the
abbreviation; however, this became difficult as some of the names/expansions
are not readily apparent to us and/or conflict between the documents in cluster
or between these documents and their normative references (see below). Note:
This list is not comprehensive as regards normative references, it just
highlights a few of the bit names we spotted at a glance.
Abbreviation: 9626 9627 9628
Normative References
I Independent Frame idr_flag Picture ID
present PictureID present
D Discardable Frame n/a inter_layer
dependency used
S Start of Frame n/a n/a
Start of VP8 partition
E End of Frame n/a End of a frame
B Base Layer Sync n/a Start of a frame
TID Temporal-layer ID n/a n/a
LID Layer ID n/a n/a
C n/a used but not expanded n/a
used but not expanded
P Used not expanded n/a Inter-picture
predicted frame padding / Inverse key frame flag
Mo: As noted in 9626, this refers to the P (Predicted) bit in the VP9/VP8
payload header, which is called "Inter-picture predicted frame" in 9628/VP9 and
"Inverse key frame flag" in 7741/VP8. I think it's sufficient to leave 9626 as
is.
U Used not expanded n/a Switching up
point
Mo: As noted in 9626, this refers to the U (Upswitch) bit in the VP9 payload
descriptor, which is called "Switching up point" in 9628/VP9. I think it's
sufficient to leave 9626 as is.
M Used not expanded n/a Most
significant bit of the marker
first octet is
an ext flag
Mo: As noted in 9626, this refers to the M (Marker) bit in the RTP header. I
think it's sufficient to leave 9626 as is.
N Used not expanded n/a ? (unsure)
Non-reference frame
Mo: As noted in 9626, this refers to the N (Non-reference) bit in the VP8
payload descriptor, which is called "Non-reference frame" in 7741/VP8. I think
it's sufficient to leave 9626 as is.
Y Used not expanded used but not expanded Each spatial
layer’s frame resolution
is present.
Mo: As noted in 9626, this refers to the Y bit in the VP9 payload descriptor,
which is called "1 layer sync" in 9628/VP9. I think it's sufficient to leave
9626 as is.
L n/a n/a Layer indices
present TL0PICIDX present
F n/a n/a Flexible mode
V n/a n/a Scalability
Structure (SS) version
data present
As such, we can see two ways forward:
1. Simply remove the parenthetical with the expansion everywhere the
parenthetical appears and have bit names appear only as, e.g., “the I bit” when
used in text. However, we still believe that authors should review the table
above and let us know any updates.
2. Authors provide an expansion of the bit name to be included on the first
appearance of the bit name as well as information regarding if this name should
be used consistently throughout the cluster or if each document uses different
expansions.
Mo: As Jonathan indicated, the bit names may not be consistent across documents
because they may refer to different things. 9626 is explicit about bit names it
defines versus those it references from another standard, so no changes needed.
Further notes:
-We have updated to use “End of Frame” and “Start of Frame” throughout the
cluster.
-We have updated to remove double quotes around bit abbreviations (e.g., the I
bit not the “I” bit).
-We have cut the names in parentheses when used after the first occurrence.
Please let us know any objections.
Mo: No objections for 9626.
Question 4: We have not made updates to any instances of H264 to appear as
H.264 in any docs in this cluster per Mo’s response to RFC-to-be 9626. Please
let us know if we have misinterpreted your intention (i.e., specific old/new
text if updates are desired in certain places).
Mo: That is correct for 9626.
Please see each document’s individual AUTH48 thread for links to review the
documents as well as necessary further author actions.
Mo: See separate email for 9626.
You may track the progress of all documents in this cluster through AUTH48 at:
https://www.rfc-editor.org/auth48/C324
Thank you.
Mo: Thsnk you!
RFC Editor/mf
> On Feb 14, 2025, at 9:49 AM, Mo Zanaty (mzanaty) <mzan...@cisco.com> wrote:
>
> See Mo: inline for responses to cluster-wide questions. My responses are
> authoritative for FM. I think Jonathan will agree to this for LRR and VP9.
> Jonathan, please correct if you disagree.
>
> From: Megan Ferguson <mfergu...@staff.rfc-editor.org>
> Sent: Friday, January 24, 2025 7:08 PM
> To: Jonathan Lennox <jonathan.lennox=408x8....@dmarc.ietf.org>; Mo Zanaty
> (mzanaty) <mzan...@cisco.com>; Suhas Nandakumar (snandaku)
> <snand...@cisco.com>; Espen Berger (espeberg) <espeb...@cisco.com>;
> Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com>; Bernard Aboba
> <bernard.ab...@gmail.com>; Jonathan Lennox <jonathan.lenno...@gmail.com>;
> da...@vidyo.com <da...@vidyo.com>; dannyh...@google.com
> <dannyh...@google.com>; mflod...@google.com <mflod...@google.com>;
> hol...@google.com <hol...@google.com>; jus...@uberti.name
> <jus...@uberti.name>; rachel.hu...@huawei.com <rachel.hu...@huawei.com>;
> Murray S. Kucherawy <superu...@gmail.com>; Francesca Palombini
> <francesca.palomb...@ericsson.com>; Orie Steele <orie@transmute.industries>
> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; auth48archive@rfc-editor.org
> <auth48archive@rfc-editor.org>
> Subject: Re: Cluster C324 questions: RFCs 9626
> <draft-ietf-avtext-framemarking>, 9627 <draft-ietf-avtext-lrr>, and 9628
> <draft-ietf-payload-vp9>
>
> Greetings,
>
> [Please note the new email address on our end.]
>
> A friendly reminder that this document set awaits author attention.
>
> 1) We are awaiting responses to document-specific author queries and updates
> from your reviews. Please see our document-specific emails for further
> information and reply in those threads.
>
> Mo: See my FM document-specific email responses sent yesterday. I don't have
> visibility to other documents in the cluster since I'm not an author, chair,
> or AD. But I'm happy to respond if you add me to those other
> document-specific emails. I think Jonathan will agree with my responses, as
> we have discussed this cluster together in November.
>
> 2) Note also that we are awaiting further guidance as to which action to take
> regarding this from Jonathan in response to our cluster-wide queries in this
> email thread:
>
> Mo: I think Jonathan will agree with my response below.
>
> >
> > On Nov 7, 2024, at 7:51 AM, Jonathan Lennox
> > <jonathan.lennox=408x8....@dmarc.ietf.org> wrote:
> >
> >> 2) Please review the way bit names are treated throughout the cluster.
> >> Sometimes the
> >> names of the bits are included in parentheses (e.g., "the I (Independent
> >> Frame) and
> >> D (Discardable Frame) bits"), sometimes a pointer is given on where to see
> >> more about
> >> the bit (e.g., "B bit (described below"), sometimes the bit names are not
> >> included at
> >> all (e.g., "the D bit"), and sometimes we see the letters in quotes (e.g.,
> >> the "D" bit).
> >>
> >> We suggest making these uses uniform and/or explaining them in one place
> >> and pointing the
> >> reader there for more information upon introduction of the bit in the
> >> document. Upon careful
> >> review, please let us know what updates are necessary using Old/New or by
> >> updating the XML
> >> files as necessary.
> >
> > That sounds good.
>
> Mo: I think Jonathan meant making these uniform as suggested sounds good. I
> don't think it's necessary to add a new section explaining them that all
> other sections refer to. It should be sufficient to include the bit name in
> parenthesis upon first use, i. e. "I (Independent) bit", then optionally omit
> (based on the editor's discretion of clarity versus verbosity) the bit name
> upon subsequent use without any further reference, i. e. "I bit".
>
> 3) Further note:
> We have received bounce-message notifications for Justin Uberti and Danny
> Hong on at least one email address listed. Could they each respond
> confirming receipt and letting us know how their contact information should
> appear in the documents themselves?
>
> Mo: I don't know the current contact information for those authors, but I
> know their affiliations have changed, so the original contact information is
> stale.
>
> Please see the AUTH48 status page for this cluster at:
> https://www.rfc-editor.org/auth48/C324
>
> Thank you.
>
> Mo: Thank you, and apologies for the delay.
>
> RFC Editor/mf
>
> > On Nov 13, 2024, at 1:34 PM, Megan Ferguson <mfergu...@amsl.com> wrote:
> >
> > Jonathan,
> >
> > Thank you for your reply.
> >
> > Regarding the following question, please clarify how you would like us to
> > update or if you are planning to update the file yourself.
> >
> > RFC Editor/mf
> >
> >
> >> On Nov 7, 2024, at 7:51 AM, Jonathan Lennox
> >> <jonathan.lennox=408x8....@dmarc.ietf.org> wrote:
> >>
> >>> 2) Please review the way bit names are treated throughout the cluster.
> >>> Sometimes the
> >>> names of the bits are included in parentheses (e.g., "the I (Independent
> >>> Frame) and
> >>> D (Discardable Frame) bits"), sometimes a pointer is given on where to
> >>> see more about
> >>> the bit (e.g., "B bit (described below"), sometimes the bit names are not
> >>> included at
> >>> all (e.g., "the D bit"), and sometimes we see the letters in quotes
> >>> (e.g., the "D" bit).
> >>>
> >>> We suggest making these uses uniform and/or explaining them in one place
> >>> and pointing the
> >>> reader there for more information upon introduction of the bit in the
> >>> document. Upon careful
> >>> review, please let us know what updates are necessary using Old/New or by
> >>> updating the XML
> >>> files as necessary.
> >>
> >> That sounds good.
> >
>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
