Hi Megan, all, I received the following note from the RTP Compact Header Extensions expert:
I am looking into this. But currently I am running a period of feedback with the WG before answering. So expect me to come back on this during the week of the IETF meeting. ==== We will let you know as soon as we're able to complete the change. Best regards, Sabrina Tanamal Lead IANA Services Specialist On Fri Feb 28 22:43:53 2025, sabrina.tanamal wrote: > Hi Megan, all, > > We're just checking with the RTP Compact Header Extensions expert > before making this change. We'll follow up again once this is > complete. > > Thank you for your patience. > > Best regards, > > Sabrina Tanamal > Lead IANA Services Specialist > > On Wed Feb 26 16:22:05 2025, mfergu...@staff.rfc-editor.org wrote: > > IANA, > > > > Regarding this document’s entry at > > https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml, > > please update as follows to match the document: > > > > Old: > > Extension URI: urn:ietf:params:rtp-hdrext:framemarkinginfo > > > > New: > > Extension URI: urn:ietf:params:rtp-hdrext:framemarking > > > > Note also: We will update to use "registry" and "registry group" > > instead of > > "subregistry" and "registry” unless IANA has objection: > > > > Current: > > This document defines a new extension URI listed in the "RTP > > Compact > > Header Extensions" subregistry of the "Real-Time Transport > > Protocol > > (RTP) Parameters" registry, according to the following data: > > > > Perhaps: > > This document defines a new extension URI listed in the "RTP > > Compact > > Header Extensions" registry of the "Real-Time Transport Protocol > > (RTP) Parameters" registry group, according to the following data: > > > > Once we hear back from IANA resolving the above, this document will > > be > > ready to move forward in the publication process. > > > > Please see the AUTH48 status page for this document here: > > https://www.rfc-editor.org/auth48/rfc9626 > > > > Please see the AUTH48 status page for this cluster here: > > https://www.rfc-editor.org/auth48/C324 > > > > Thank you. > > > > RFC Editor/mf > > > > > > > On Feb 26, 2025, at 8:58 AM, Murray S. Kucherawy > > > <superu...@gmail.com> wrote: > > > > > > 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- > > > > > a...@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- > > > > > > a...@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- > > > > > > a...@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
