Hi Megan, all, Thanks for your patience. Please see [ST] inline.
On Mon Mar 10 17:03:25 2025, mfergu...@staff.rfc-editor.org wrote: > 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 [ST] This change is complete: https://www.iana.org/assignments/rtp-parameters > >>> 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: [ST] Thanks for making these changes. Best regards, Sabrina > >>> 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
