Thanks for keeping us in the loop, Sabrina! RFC Editor/mf
> On Mar 7, 2025, at 12:24 PM, Sabrina Tanamal via RT <iana-mat...@iana.org> > wrote: > > 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
