Hi Megan,

Correct me if I'm wrong, but I believe that's all the approvals outstanding?

-MSK, ART AD

On Thu, Feb 20, 2025 at 1:33 PM Megan Ferguson <
mfergu...@staff.rfc-editor.org> wrote:

> Murray,
>
> Thank you for the quick reply and your help getting this AUTH48
> restarted!  We’ve recorded your approval here:
>
> https://www.rfc-editor.org/auth48/rfc9626
>
> RFC Editor/mf
>
>
> > On Feb 20, 2025, at 1:56 PM, Murray S. Kucherawy <superu...@gmail.com>
> wrote:
> >
> > I've reviewed the comprehensive diff link and in particular the various
> "D bit" changes.
> >
> > I approve those changes.
> >
> > -MSK, ART AD
> >
> > On Thu, Feb 20, 2025 at 11:21 AM Megan Ferguson <
> mfergu...@staff.rfc-editor.org> wrote:
> > Authors and *AD,
> >
> > Thank you for your replies.  We have updated according to the responses
> we have received thus far regarding the document-specific and cluster-wide
> questions.
> >
> > 1) We believe the only outstanding issue remaining from all of these
> questions is *AD approval of the following change to text involving BCP 14
> keywords:
> >
> > > Hi,
> > >
> > > For bullet 4 where AD opinion has been asked, I would first like to
> get the opinion from the authors if they are OK with the changes or not.
> > >
> > > So, Authors please review the proposed changes in bullet 4 and send
> your opinion.
> > >
> > > //Zahed
> > >
> > >> 4) <!--[rfced] [*AD] We see several (similar) sentences like the
> example
> > >>    below where it might be difficult for the reader to correclty
> > >>    understand what part(s) of the sentence the keyword MUST applies
> > >>    to.  We wonder if a rewrite may be helpful to the reader,
> > >>    possibly using a list...  Please see the example below (again,
> > >>    other similar instances exist in the document) and let us know if
> > >>    an update like one of the following might work.
> > >>
> > >> Original:
> > >>
> > >>  The D bit MUST be 1 when the NAL unit header NRI field is 0, or an
> > >>  aggregation packet or fragmentation unit encapsulating only NAL units
> > >>  with NRI=0, otherwise it MUST be 0.
> > >>
> > >> Perhaps A (the "when" clause applies to both the D bit being set to 1
> or NRI=0):
> > >>
> > >> When the NAL unit header NRI field is 0, the D bit MUST be either 1 or
> > >> an aggregation packet or fragmentation unit encapsulating only NAL
> > >> units with NRI=0.  When the NAL unit header NRI field is not set to 0,
> > >> the D bit MUST be 0.
> > >>
> > >> Perhaps B (the "when" clause only applies to the D bit being 0):
> > >>
> > >> The D bit MUST be:
> > >>
> > >> -1 when the NAL unit header NRI field is 0,
> > >>
> > >> -an aggregation packet or fragmentation unit encapsulating only NAL
> units
> > >> with NRI=0, or
> > >>
> > >> - 0.
> > >
> > > The D bit MUST be 1 if either:
> > > - The payload's NAL unit header’s NRI field is 0, or
> > > - The payload is an aggregation packet or fragmentation unit
> encapsulating only NAL units with NRI=0.
> > > Otherwise, it MUST be 0.
> >
> > 2) Please further note that the URN change to the IANA registry that
> Justin mentioned will be communicated to IANA once AUTH48 completes.
> >
> > Old:
> > urn:ietf:params:rtp-hdrext:framemarkinginfo
> >
> > New:
> > urn:ietf:params:rtp-hdrext:framemarking
> >
> > 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/rfc9626.txt
> >    https://www.rfc-editor.org/authors/rfc9626.pdf
> >    https://www.rfc-editor.org/authors/rfc9626.html
> >    https://www.rfc-editor.org/authors/rfc9626.xml
> >
> > The relevant diff files have been posted here (please refresh):
> >    https://www.rfc-editor.org/authors/rfc9626-diff.html (comprehensive
> diff)
> >    https://www.rfc-editor.org/authors/rfc9626-auth48diff.html (AUTH48
> changes only)
> >    https://www.rfc-editor.org/authors/rfc9626-lastdiff.html (last to
> current version only)
> >    https://www.rfc-editor.org/authors/rfc9626-lastrfcdiff.html (last 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/rfc9626
> >
> > Thank you.
> >
> > RFC Editor/mf
> >
> > > On Feb 19, 2025, at 10:24 PM, Mo Zanaty (mzanaty) <mzan...@cisco.com>
> wrote:
> > >
> > > A few changes needed. All the rest looks good.
> > >
> > > 3.1: memo -> document
> > >
> > > 3.3.2: replace this sentence:
> > > OLD: “These ranges cover non-reference frames as well as filler data.”
> > > with this: (from 3.3.3/3.3.4)
> > > NEW: “The NRI = 0 condition signals non-reference frames.”
> > >
> > > 3.3.3: add “(DID)” and “(QID)” in the first sentence:
> > > “…spatial/dependency layer (DID)…”
> > > “…quality layer (QID)…”
> > >
> > > Thanks,
> > > Mo
> > >
> > > From: Megan Ferguson <mfergu...@staff.rfc-editor.org>
> > > Sent: Wednesday, February 19, 2025 2:49 PM
> > > To: Espen Berger (espeberg) <espeb...@cisco.com>; Suhas Nandakumar
> (snandaku) <snand...@cisco.com>; Mo Zanaty (mzanaty) <mzan...@cisco.com>
> > > Cc: RFC Editor <rfc-edi...@rfc-editor.org>; avtcore-...@ietf.org <
> avtcore-...@ietf.org>; avtcore-cha...@ietf.org <avtcore-cha...@ietf.org>;
> auth48archive@rfc-editor.org <auth48archive@rfc-editor.org>; Jonathan
> Lennox <jonathan.len...@8x8.com>; Murray S. Kucherawy <superu...@gmail.com
> >
> > > Subject: Re: AUTH48: RFC-to-be 9626
> <draft-ietf-avtext-framemarking-16> for your review
> > >
> > > Authors,
> > >
> > > Thank you for your replies to our queries!
> > >
> > > We have updated our files accordingly with your responses to both the
> document-specific and cluster-wide questions we have received to date.
>  Please review these updates carefully as we do not make changes once the
> document is published as an RFC.  Please pay particular attention to our
> updates to Section 3.3.2 as we are unsure if this was your intent.
> > >
> > > Note that we will await the following prior to moving forward in the
> publication process:
> > > -resolution of outstanding cluster-wide queries (see separate email
> thread)
> > > -approvals from each author
> > >
> > > The files have been posted here (please refresh):
> > >    https://www.rfc-editor.org/authors/rfc9626.txt
> > >    https://www.rfc-editor.org/authors/rfc9626.pdf
> > >    https://www.rfc-editor.org/authors/rfc9626.html
> > >    https://www.rfc-editor.org/authors/rfc9626.xml
> > >
> > > The relevant diff files have been posted here (please refresh):
> > >    https://www.rfc-editor.org/authors/rfc9626-diff.html
> (comprehensive diff)
> > >    https://www.rfc-editor.org/authors/rfc9626-auth48diff.html (AUTH48
> changes only)
> > >
> > > The AUTH48 status page for this document is available here:
> > > https://www.rfc-editor.org/auth48/rfc9626
> > >
> > > 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 18, 2025, at 12:39 PM, Murray S. Kucherawy <
> superu...@gmail.com> wrote:
> > > >
> > > > Thanks, that's all three authors.  Good stuff.
> > > >
> > > > But DON'T GO ANYWHERE!  The RFC Editor will probably now produce a
> proposed final version and that too will need all three of you to approve
> before it can move forward to publication.  Please keep checking this
> thread (and your inbox generally) until this process is done.
> > > >
> > > > -MSK
> > > >
> > > > On Tue, Feb 18, 2025 at 2:38 PM Espen Berger (espeberg) <
> espeb...@cisco.com> wrote:
> > > > I agree with Mo's comments.
> > > >
> > > > -Espen
> > > >
> > > > From: Suhas Nandakumar (snandaku) <snand...@cisco.com>
> > > > Sent: Tuesday, February 18, 2025 20:20
> > > > To: Mo Zanaty (mzanaty) <mzan...@cisco.com>; RFC Editor <
> rfc-edi...@rfc-editor.org>; Espen Berger (espeberg) <espeb...@cisco.com>
> > > > Cc: avtcore-...@ietf.org <avtcore-...@ietf.org>;
> avtcore-cha...@ietf.org <avtcore-cha...@ietf.org>; superu...@gmail.com <
> superu...@gmail.com>; auth48archive@rfc-editor.org <
> auth48archive@rfc-editor.org>; Jonathan Lennox <jonathan.len...@8x8.com>
> > > > Subject: Re: AUTH48: RFC-to-be 9626
> <draft-ietf-avtext-framemarking-16> for your review
> > > >
> > > > Thanks Mo for addressing the questions. After perusing it , I agree
> with Mo's responses.
> > > >
> > > > Cheers
> > > > Suhas
> > > > From: Mo Zanaty (mzanaty) <mzan...@cisco.com>
> > > > Sent: Tuesday, February 18, 2025 11:11 AM
> > > > To: RFC Editor <rfc-edi...@rfc-editor.org>; Espen Berger (espeberg)
> <espeb...@cisco.com>; Suhas Nandakumar (snandaku) <snand...@cisco.com>
> > > > Cc: avtcore-...@ietf.org <avtcore-...@ietf.org>;
> avtcore-cha...@ietf.org <avtcore-cha...@ietf.org>; superu...@gmail.com <
> superu...@gmail.com>; auth48archive@rfc-editor.org <
> auth48archive@rfc-editor.org>; Jonathan Lennox <jonathan.len...@8x8.com>
> > > > Subject: Re: AUTH48: RFC-to-be 9626
> <draft-ietf-avtext-framemarking-16> for your review
> > > >
> > > > Suhas, Espen,
> > > >
> > > > Please reply to this email indicating whether you agree with all my
> responses below, or provide your responses if you disagree.
> > > >
> > > > Thanks,
> > > > Mo
> > > >
> > > > From: Mo Zanaty (mzanaty) <mzan...@cisco.com>
> > > > Sent: Thursday, February 13, 2025 11:54 PM
> > > > To: Jonathan Lennox <jonathan.len...@8x8.com>; RFC Editor <
> rfc-edi...@rfc-editor.org>
> > > > Cc: Espen Berger (espeberg) <espeb...@cisco.com>; Suhas Nandakumar
> (snandaku) <snand...@cisco.com>; avtcore-...@ietf.org <
> avtcore-...@ietf.org>; avtcore-cha...@ietf.org <avtcore-cha...@ietf.org>;
> superu...@gmail.com <superu...@gmail.com>; auth48archive@rfc-editor.org <
> auth48archive@rfc-editor.org>
> > > > Subject: Re: AUTH48: RFC-to-be 9626
> <draft-ietf-avtext-framemarking-16> for your review
> > > >
> > > > See Mo: inline for responses specific to frame marking. Apologies
> for the delay. I thought Jonathan’s responses to the cluster-wide questions
> (C324 FM, LRR, VP9), which we discussed together in November as he noted in
> his response, were sufficient to progress the cluster. To be clear, I agree
> with all his responses, as we discussed and agreed on this together prior
> to his response.
> > > >
> > > >
> > > > From: Jonathan Lennox <jonathan.len...@8x8.com>
> > > > Sent: Friday, February 7, 2025 4:05 PM
> > > > To: RFC Editor <rfc-edi...@rfc-editor.org>
> > > > Cc: Mo Zanaty (mzanaty) <mzan...@cisco.com>; Espen Berger
> (espeberg) <espeb...@cisco.com>; Suhas Nandakumar (snandaku) <
> snand...@cisco.com>; avtcore-...@ietf.org <avtcore-...@ietf.org>;
> avtcore-cha...@ietf.org <avtcore-cha...@ietf.org>; superu...@gmail.com <
> superu...@gmail.com>; auth48archive@rfc-editor.org <
> auth48archive@rfc-editor.org>
> > > > Subject: Re: AUTH48: RFC-to-be 9626
> <draft-ietf-avtext-framemarking-16> for your review
> > > >
> > > > I’m not an author on this draft, but as chair I thought I would try
> to answer these questions, to make sure the process could get done.  I
> spoke with Mo about these issues in Dublin and I think he’ll agree with all
> of these.  Mo, please correct me if I’ve misunderstood anything.
> > > >
> > > > Mo: Thanks, Jonathan. Yes, I agree with all these.
> > > >
> > > > > On Aug 13, 2024, at 12:27 AM, rfc-edi...@rfc-editor.org wrote:
> > > > >
> > > > > Authors and *AD,
> > > > >
> > > > > [AD - please see question 4 below]
> > > > >
> > > > > While reviewing this document during AUTH48, please resolve (as
> necessary) the following questions, which are also in the XML file.
> > > > >
> > > > > 1) <!-- [rfced] Please insert any keywords (beyond those that
> appear in
> > > > > the title) for use on https://www.rfc-editor.org/search. -->
> > > >
> > > > Scalable video, h.264, h.265, vp9, layered video
> > > >
> > > > Mo: Agreed.
> > > >
> > > > > 2) <!--[rfced] Please review whether "e.g." in the following should
> > > > >     instead be "i.e.":
> > > > >
> > > > > Original:
> > > > > Because of inter-frame dependencies, it should ideally switch video
> > > > > streams at a point where the first frame from the new speaker can
> be
> > > > > decoded by recipients without prior frames, e.g. switch on an
> > > > > intra-frame.
> > > >
> > > > An intra frame is the most common situation where a stream can be
> decoded without prior frames, but there are others for some codecs, so I
> think e.g. is appropriate here.
> > > >
> > > > Mo: Agreed, keep e.g., or expand as ‘for example’ at the editor’s
> discretion.
> > > >
> > > > > -->
> > > > >
> > > > >
> > > > > 3) <!--[rfced] Should "field" or some other noun follow
> > > > >     "refresh_frame_flags" in this sentence?  Or is this referring
> to
> > > > >     the flags (as the verb "are" is plural)?
> > > > >
> > > > > Original:
> > > > >   The D bit MUST be 1 if the refresh_frame_flags in the VP9 payload
> > > > >   uncompressed header are all 0, otherwise it MUST be 0.
> > > > > -->
> > > >
> > > > I think “refresh_frame_flags bits"
> > > >
> > > > Mo: Agreed, append ‘bits’ at the editor’s discretion if it helps
> clarify, although I see no reader confusion without it. Do not append
> ‘field’ as that would also require changing ‘are all 0’ to ‘is equal to 0’
> which is confusing for a field of separate flags that are not treated as a
> single numeric value.
> > > >
> > > > >
> > > > > 4) <!--[rfced] [*AD] We see several (similar) sentences like the
> example
> > > > >     below where it might be difficult for the reader to correclty
> > > > >     understand what part(s) of the sentence the keyword MUST
> applies
> > > > >     to.  We wonder if a rewrite may be helpful to the reader,
> > > > >     possibly using a list...  Please see the example below (again,
> > > > >     other similar instances exist in the document) and let us know
> if
> > > > >     an update like one of the following might work.
> > > > >
> > > > > Original:
> > > > >
> > > > >   The D bit MUST be 1 when the NAL unit header NRI field is 0, or
> an
> > > > >   aggregation packet or fragmentation unit encapsulating only NAL
> units
> > > > >   with NRI=0, otherwise it MUST be 0.
> > > > >
> > > > > Perhaps A (the "when" clause applies to both the D bit being set
> to 1 or NRI=0):
> > > > >
> > > > > When the NAL unit header NRI field is 0, the D bit MUST be either
> 1 or
> > > > > an aggregation packet or fragmentation unit encapsulating only NAL
> > > > > units with NRI=0.  When the NAL unit header NRI field is not set
> to 0,
> > > > > the D bit MUST be 0.
> > > > >
> > > > > Perhaps B (the "when" clause only applies to the D bit being 0):
> > > > >
> > > > > The D bit MUST be:
> > > > >
> > > > > -1 when the NAL unit header NRI field is 0,
> > > > >
> > > > > -an aggregation packet or fragmentation unit encapsulating only
> NAL units
> > > > > with NRI=0, or
> > > > >
> > > > > - 0.
> > > >
> > > > The D bit MUST be 1 if either:
> > > >  - The payload's NAL unit header’s NRI field is 0, or
> > > >  - The payload is an aggregation packet or fragmentation unit
> encapsulating only NAL units with NRI=0.
> > > > Otherwise, it MUST be 0.
> > > >
> > > > Mo: Agreed, this makes the or conditions clear. At the editor’s
> discretion, if bullets interrupt the reading flow, it is equally clear to
> put the or conditions as inline text prefaced with labels 1), 2), a), b),
> etc. Please use the chosen style for all similar sentences.
> > > >
> > > > >
> > > > > 5) <!-- [rfced] Please review whether any of the notes in this
> document
> > > > > should be in the <aside> element. It is defined as "a container
> for
> > > > > content that is semantically less important or tangential to the
> > > > > content that surrounds it" (
> https://authors.ietf.org/en/rfcxml-vocabulary#aside).
> > > > > -->
> > > > >
> > > >
> > > > Both the two “Note:” comments could be <aside> elements.
> > > >
> > > > Mo: Agreed, both notes could be <aside> elements, assuming that
> renders in all target formats without hiding.
> > > >
> > > > >
> > > > > 6) <!--[rfced] May we update this sentence as follows for the ease
> of the
> > > > >     reader?  Note that the introductory "when" phrase mentions a
> > > > >     single frame while the recommendation mentions plural frames:
> > > > >     please consider if further updates are necessary.
> > > > >
> > > > > Original:
> > > > > When an RTP switch needs to discard a received video frame due to
> > > > > congestion control considerations, it is RECOMMENDED that it
> > > > > preferably drop frames marked with the D (Discardable) bit set, or
> the
> > > > > highest values of TID and LID, which indicate the highest temporal
> and
> > > > > spatial/quality enhancement layers, since those typically have
> fewer
> > > > > dependenices on them than lower layers.
> > > > >
> > > > >
> > > > > Perhaps A:
> > > > > When an RTP switch needs to discard a received video frame due to
> > > > > congestion control considerations, it is RECOMMENDED that it drop:
> > > > >
> > > > > - frames marked with the D (Discardable) bit set, or
> > > > >
> > > > > -frames with the highest values of TID and LID (which indicate the
> > > > > highest temporal and spatial/quality enhancement layers) since
> those
> > > > > typically have fewer dependencies on them than lower layers.
> > > > >
> > > > > Perhaps B (to upddate the sg/pl switch):
> > > > > When an RTP switch needs to discard received video frames due to
> > > > > congestion control considerations, it is RECOMMENDED that it drop:
> > > > >
> > > > > - frames marked with the D (Discardable) bit set, or
> > > > >
> > > > > -frames with the highest values of TID and LID (which indicate the
> > > > > highest temporal and spatial/quality enhancement layers) since
> those
> > > > > typically have fewer dependencies on them than lower layers.
> > > > >
> > > > > -->
> > > >
> > > > I’m missing something here because I don’t see the difference
> between these two options, but that text is fine.
> > > >
> > > > Mo: Option B with plural frames sounds best.
> > > >
> > > > > 7) <!--[rfced] Please clarify what "and forward the same" means in
> this text.
> > > > >
> > > > > Original:
> > > > >   When an RTP switch wants to forward a new video stream to a
> receiver,
> > > > >   it is RECOMMENDED to select the new video stream from the first
> > > > >   switching point with the I (Independent) bit set in all spatial
> > > > >   layers and forward the same.
> > > > > -->
> > > >
> > > > Perhaps “and forward the stream from that point on”.
> > > >
> > > > Mo: Agreed, and perhaps ‘video stream’ not just ‘stream’, and
> ‘switching point’ not just ‘point’, depending on the editor’s discretion of
> clarity versus verbosity.
> > > >
> > > > > 8) <!--[rfced] How may we update this text to more easily
> illustrate the
> > > > >     1:1 mapping between initialism and expansion?
> > > > >
> > > > > Original:
> > > > > ...  source to generate a switching point by sending Full Intra
> > > > > Request (RTCP FIR) as defined in [RFC5104]...
> > > > >
> > > > > Perhaps:
> > > > > ...  source to generate a switching point by sending RTCP Full
> Intra
> > > > > Request (FIR) as defined in [RFC5104]...
> > > > >
> > > > > -->
> > > >
> > > > That’s fine.
> > > >
> > > > Mo: Agreed.
> > > >
> > > > >
> > > > >
> > > > > 9) <!--[rfced] In the following, are "layer" and "refreshes"
> redundant
> > > > >     with what LRR stands for?  Please let us know if any updates
> are
> > > > >     necessary.
> > > > >
> > > > > Original:
> > > > >   Because frame marking can only be used with temporally-nested
> > > > >   streams, temporal-layer LRR refreshes are unnecessary for frame-
> > > > >   marked streams.
> > > > >
> > > > > As expanded it would be:
> > > > >  Because frame marking can only be used with temporally nested
> > > > >  streams, temporal-layer Layer Refresh Request (LRR) refreshes are
> > > > >  unnecessary for frame-marked streams.
> > > > > -->
> > > >
> > > > Perhaps “temporal-layer refreshes requested with an LRR message”
> would avoid the duplicative language?
> > > >
> > > > Mo: Agreed, Jonathan’s wording sounds best.
> > > >
> > > > > 10) <!-- [rfced] Would you like the references to be alphabetized
> or left
> > > > >     in their current order?
> > > > > -->
> > > >
> > > > This is something where the RFC Editor’s style guide should dictate,
> I don’t think there’s any particular preference for a specific reference
> order.
> > > >
> > > > Mo: Agreed. The authors have no order preference.
> > > >
> > > > >
> > > > >
> > > > > 11) <!-- [rfced] We had the following questions related to
> abbreviations
> > > > >     used throughout the document.
> > > > >
> > > > > a) Please note that we have expanded these abbreviations as
> follows on
> > > > > first use.  Please let us know any objections.
> > > > >
> > > > > MCU - Multipoint Control Unit (per RFC 7667)
> > > > > SRTP - Secure Real-time Transport Protocol
> > > > > IDR - Instantaneous Decoding Refresh (per RFC 6184)
> > > > > SDES - source description
> > > > > NAL - Network Abstraction Layer
> > > > > CRA - Clean Random Access
> > > > > BLA - Broken Link Access
> > > > > RAP - Random Access Point
> > > > > AVC - Advanced Video Coidng (per RFC 6184)
> > > > > SVC - Scalable Video Coding (per RFC 6190)
> > > > > PACSI - Payload Content Scalability Information
> > > > > NRI - Network Remote Identification
> > > >
> > > > No; the field in the H.264 specification is actually formally named
> “nal_ref_idc”.  I believe this stands for something like Network Adaptation
> Layer Reference Indication but as far as I can tell it’s never explicitly
> spelled out in that specification as far as I can tell.
> > > >
> > > > > VPS - Video Parameter Set
> > > > > SPS - Sequence Parameter Set
> > > > > PPS - Picture Parameter Set
> > > >
> > > > The other abbreviations all seem to be correct.
> > > >
> > > > Mo: Agreed, all correct, except NRI is NAL Reference Indication.
> > > >
> > > > >
> > > > > b) Please clarify if/how we may expand the following abbreviations:
> > > > >
> > > > > VPX
> > > > > PACI - is this intentionally different from PACSI?
> > > >
> > > > Yes; the protocol element field is called PACI in RFC 7798 (for
> H.265) vs. PACSI in RFC 6190 (for H.264-SVC).
> > > >
> > > > Mo: Agreed on PACI. VPX denotes VP8/VP9.
> > > >
> > > > > c) Should "intra (IDR)" frames instead be "IDR intra-frames"?  This
> > > > > formation occurs twice in this document.
> > > >
> > > > Intra frames are the common term, IDR is the more formal term, so
> this is a clarification with two synonymous terms, not a restrictive
> adjective.
> > > >
> > > > Mo: Agreed, keep the original text. Intra, IDR, Independent, and
> Keyframe are synonymous terms that appear in various video standards.
> Unfortunately, there is no alignment on a single term across all video
> standards.
> > > >
> > > > >
> > > > > d) Please note that the following similar abbreviations appear to
> be
> > > > > differently treated with regard to punctuation:
> > > > >
> > > > > H264 (AVC)
> > > > > H264-SVC
> > > > >
> > > > > We have expanded the abbreviations on first use, but please let us
> > > > > know if/how these should be made uniform with regard to parens and
> > > > > hyphantion.
> > > > >
> > > > > See also our cluster-wide question regarding H264 vs. H.264.
> > > > > -->
> > > >
> > > > Names of ITU specs (H.264 and H.265) should include the dot
> character.
> > > >
> > > > AVC and SVC are not parallel; AVC is the title of the H.264
> specification as a whole, whereas SVC refers specifically to the extensions
> to it specified in Annex F.  Thus the parentheses for the former (as an
> explanatory synonym) vs. the hyphen for the latter (as a restriction).
> > > >
> > > > Mo: Please keep the exact original text. These refer to the RTP
> payload format names (SDP a=rtpmap name) registered in RFC 6184 for H264
> (AVC for clarification) and RFC 6190 for H264-SVC (no parenthesis because
> it’s part of the actual name not a clarification).  Dots are used when
> referring to the underlying ITU specs, not the RTP formats.
> > > >
> > > > > 12) <!--[rfced] We had the following questions related to
> terminology used
> > > > >     throughout the document.
> > > > >
> > > > > a) Two questions about the header extension:
> > > > >
> > > > > Should this RTP header extension appear using "Video" throughout?
> We
> > > > > see both of the following forms.
> > > > >
> > > > > Video Frame Marking RTP header extension vs. Frame Marking RTP
> header extension
> > > >
> > > > Yes, I think having Video throughout is good.
> > > >
> > > > Mo: Agreed, video throughout.
> > > >
> > > > >
> > > > > Secondly, in the Abstract, we see:
> > > > >
> > > > > Original:
> > > > >   This document describes a Video Frame Marking RTP header
> extension
> > > > >   used to convey information about video frames that is critical
> for
> > > > >   error recovery and packet forwarding in RTP middleboxes or
> network
> > > > >   nodes.
> > > > >
> > > > > Is the use of the indefinite article "a" intentional ("a Video
> Frame
> > > > > Marking RTP header extension")? This seems (possibly) contradictory
> > > > > with the capitalization of the proper noun and use in Section 3
> (are
> > > > > there more types of Video Frame Marking RTP header extensions?).
> > > > > Please review.
> > > > > -->
> > > >
> > > > There certainly are other RTP header extensions that mark video
> frames, though none of them have been standardized by the IETF as yet; I
> think that’s why there is the indefinite article here.
> > > >
> > > > Mo: Agreed, keep the original text with ‘a’.
> > > >
> > > > >
> > > > >
> > > > > 13) <!-- [rfced] Please review the "Inclusive Language" portion of
> the
> > > > >     online Style Guide
> > > > >     <
> https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> > > > >     and let us know if any changes are needed.  Updates of this
> > > > >     nature typically result in more precise language, which is
> > > > >     helpful for readers.
> > > > >
> > > > > Note that our script did not flag any words in particular, but this
> > > > > should still be reviewed as a best practice.
> > > > >
> > > > > -->
> > > >
> > > > I don’t see any problems.
> > > >
> > > > Mo: Agreed, no changes.
> > > >
> > > > >
> > > > >
> > > > > Thank you.
> > > >
> > > > Mo: Thank you, and apologies for the delay.
> > > >
> > > > >
> > > > > RFC Editor/mf
> > > > >
> > > > > *****IMPORTANT*****
> > > > >
> > > > > Updated 2024/08/12
> > > > >
> > > > > RFC Author(s):
> > > > > --------------
> > > > >
> > > > > Instructions for Completing AUTH48
> > > > >
> > > > > Your document has now entered AUTH48.  Once it has been reviewed
> and
> > > > > approved by you and all coauthors, it will be published as an
> RFC.
> > > > > If an author is no longer available, there are several remedies
> > > > > available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> > > > >
> > > > > You and you coauthors are responsible for engaging other parties
> > > > > (e.g., Contributors or Working Group) as necessary before
> providing
> > > > > your approval.
> > > > >
> > > > > Planning your review
> > > > > ---------------------
> > > > >
> > > > > Please review the following aspects of your document:
> > > > >
> > > > > *  RFC Editor questions
> > > > >
> > > > >   Please review and resolve any questions raised by the RFC Editor
> > > > >   that have been included in the XML file as comments marked as
> > > > >   follows:
> > > > >
> > > > >   <!-- [rfced] ... -->
> > > > >
> > > > >   These questions will also be sent in a subsequent email.
> > > > >
> > > > > *  Changes submitted by coauthors
> > > > >
> > > > >   Please ensure that you review any changes submitted by your
> > > > >   coauthors.  We assume that if you do not speak up that you
> > > > >   agree to changes submitted by your coauthors.
> > > > >
> > > > > *  Content
> > > > >
> > > > >   Please review the full content of the document, as this cannot
> > > > >   change once the RFC is published.  Please pay particular
> attention to:
> > > > >   - IANA considerations updates (if applicable)
> > > > >   - contact information
> > > > >   - references
> > > > >
> > > > > *  Copyright notices and legends
> > > > >
> > > > >   Please review the copyright notice and legends as defined in
> > > > >   RFC 5378 and the Trust Legal Provisions
> > > > >   (TLP – https://trustee.ietf.org/license-info/).
> > > > >
> > > > > *  Semantic markup
> > > > >
> > > > >   Please review the markup in the XML file to ensure that elements
> of
> > > > >   content are correctly tagged.  For example, ensure that
> <sourcecode>
> > > > >   and <artwork> are set correctly.  See details at
> > > > >   <https://authors.ietf.org/rfcxml-vocabulary>.
> > > > >
> > > > > *  Formatted output
> > > > >
> > > > >   Please review the PDF, HTML, and TXT files to ensure that the
> > > > >   formatted output, as generated from the markup in the XML file,
> is
> > > > >   reasonable.  Please note that the TXT will have formatting
> > > > >   limitations compared to the PDF and HTML.
> > > > >
> > > > >
> > > > > Submitting changes
> > > > > ------------------
> > > > >
> > > > > To submit changes, please reply to this email using ‘REPLY ALL’ as
> all
> > > > > the parties CCed on this message need to see your changes. The
> parties
> > > > > include:
> > > > >
> > > > >   *  your coauthors
> > > > >
> > > > >   *  rfc-edi...@rfc-editor.org (the RPC team)
> > > > >
> > > > >   *  other document participants, depending on the stream (e.g.,
> > > > >      IETF Stream participants are your working group chairs, the
> > > > >      responsible ADs, and the document shepherd).
> > > > >
> > > > >   *  auth48archive@rfc-editor.org, which is a new archival
> mailing list
> > > > >      to preserve AUTH48 conversations; it is not an active
> discussion
> > > > >      list:
> > > > >
> > > > >     *  More info:
> > > > >
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> > > > >
> > > > >     *  The archive itself:
> > > > >        https://mailarchive.ietf.org/arch/browse/auth48archive/
> > > > >
> > > > >     *  Note: If only absolutely necessary, you may temporarily opt
> out
> > > > >        of the archiving of messages (e.g., to discuss a sensitive
> matter).
> > > > >        If needed, please add a note at the top of the message that
> you
> > > > >        have dropped the address. When the discussion is concluded,
> > > > >        auth48archive@rfc-editor.org will be re-added to the CC
> list and
> > > > >        its addition will be noted at the top of the message.
> > > > >
> > > > > You may submit your changes in one of two ways:
> > > > >
> > > > > An update to the provided XML file
> > > > > — OR —
> > > > > An explicit list of changes in this format
> > > > >
> > > > > Section # (or indicate Global)
> > > > >
> > > > > OLD:
> > > > > old text
> > > > >
> > > > > NEW:
> > > > > new text
> > > > >
> > > > > You do not need to reply with both an updated XML file and an
> explicit
> > > > > list of changes, as either form is sufficient.
> > > > >
> > > > > We will ask a stream manager to review and approve any changes
> that seem
> > > > > beyond editorial in nature, e.g., addition of new text, deletion
> of text,
> > > > > and technical changes.  Information about stream managers can be
> found in
> > > > > the FAQ.  Editorial changes do not require approval from a stream
> manager.
> > > > >
> > > > >
> > > > > Approving for publication
> > > > > --------------------------
> > > > >
> > > > > To approve your RFC for publication, please reply to this email
> stating
> > > > > that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> > > > > as all the parties CCed on this message need to see your approval.
> > > > >
> > > > >
> > > > > Files
> > > > > -----
> > > > >
> > > > > The files are available here:
> > > > >   https://www.rfc-editor.org/authors/rfc9626.xml
> > > > >   https://www.rfc-editor.org/authors/rfc9626.html
> > > > >   https://www.rfc-editor.org/authors/rfc9626.pdf
> > > > >   https://www.rfc-editor.org/authors/rfc9626.txt
> > > > >
> > > > > Diff file of the text:
> > > > >   https://www.rfc-editor.org/authors/rfc9626-diff.html
> > > > >   https://www.rfc-editor.org/authors/rfc9626-rfcdiff.html (side
> by side)
> > > > >
> > > > > Diff of the XML:
> > > > >   https://www.rfc-editor.org/authors/rfc9626-xmldiff1.html
> > > > >
> > > > > The following files are provided to facilitate creation of your
> own
> > > > > diff files of the XML.
> > > > >
> > > > > Initial XMLv3 created using XMLv2 as input:
> > > > >   https://www.rfc-editor.org/authors/rfc9626.original.v2v3.xml
> > > > >
> > > > > XMLv3 file that is a best effort to capture v3-related format
> updates
> > > > > only:
> > > > >   https://www.rfc-editor.org/authors/rfc9626.form.xml
> > > > >
> > > > >
> > > > > Tracking progress
> > > > > -----------------
> > > > >
> > > > > The details of the AUTH48 status of your document are here:
> > > > >   https://www.rfc-editor.org/auth48/rfc9626
> > > > >
> > > > > Please let us know if you have any questions.
> > > > >
> > > > > Thank you for your cooperation,
> > > > >
> > > > > RFC Editor
> > > > >
> > > > > --------------------------------------
> > > > > RFC9626 (draft-ietf-avtext-framemarking-16)
> > > > >
> > > > > Title            : Video Frame Marking RTP Header Extension
> > > > > Author(s)        : M. Zanaty, E. Berger, S. Nandakumar
> > > > > WG Chair(s)      : Dr. Bernard D. Aboba, Jonathan Lennox
> > > > > Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini
> > > > >
> > > > >
> > > >
> > >
> >
> >
> >
>
>
-- 
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org

Reply via email to