Hi, These changes are complete:
https://www.iana.org/assignments/ospfv2-parameters https://www.iana.org/assignments/ospfv3-parameters Best regards, Amanda Baber IANA Operations Manager On Mon Jun 02 18:54:47 2025, kmo...@staff.rfc-editor.org wrote: > Dear IANA, > > Please make the following updates to match the edited document at > <https://www.rfc-editor.org/authors/rfc9792-diff.html>. > > 1) Under the "OSPFv2 Extended Prefix TLV Sub-TLVs” registry > <https://www.iana.org/assignments/ospfv2-parameters>: > > OLD: > 11 > OSPFv2 Prefix Attribute Flags > > NEW: > 11 > OSPFv2 Prefix Extended Flags > > > 2) Under the "OSPFv2 Prefix Attribute Flags” registry > <https://www.iana.org/assignments/ospfv2-parameters>, change the > registry title: > > OLD: > OSPFv2 Prefix Attribute Flags > > NEW: > OSPFv2 Prefix Extended Flags > > > 3) Under the "OSPFv3 Extended-LSA Sub-TLVs” registry > <https://www.iana.org/assignments/ospfv3-parameters>: > > OLD: > 37 > OSPFv3 Prefix Attribute Flags > > NEW: > 37 > OSPFv3 Prefix Extended Flags > > > 4) Under the "OSPFv3 Prefix Attribute Flags” registry > <https://www.iana.org/assignments/ospfv3-parameters>, change the > registry title: > > OLD: > OSPFv3 Prefix Attribute Flags > > NEW: > OSPFv3 Prefix Extended Flags > > > Thank you in advance! > RFC Editor/kc > > > > On Jun 2, 2025, at 11:11 AM, Karen Moore <kmo...@staff.rfc- > > editor.org> wrote: > > > > Hi Gunter, > > > > Thank you for your review. We have noted your approval on the AUTH48 > > status page (https://www.rfc-editor.org/auth48/rfc9792). > > > > We will now ask IANA to update their registries accordingly. We will > > inform you when the updates are complete. > > > > Best regards, > > RFC Edito/kc > >> > >>> On Jun 1, 2025, at 10:56 PM, Gunter van de Velde (Nokia) > >>> <gunter.van_de_velde=40nokia....@dmarc.ietf.org> wrote: > >>> > >>> Approved (all the changes made to the sub-TLV name, field name, and > >>> IANA registry names throughout the document). > >>> > >>> I reviewed all instances in the document where the keyword > >>> "attribute" was used and verified if changed appropriately to > >>> 'extended". > >>> > >>> G/ > >>> > >>> -----Original Message----- > >>> From: Karen Moore <kmo...@staff.rfc-editor.org> > >>> Sent: Thursday, May 29, 2025 8:35 PM > >>> To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; > >>> Ketan Talaulikar <ketant.i...@gmail.com>; > >>> gongli...@chinamobile.com; chen....@zte.com.cn; > >>> zhao.de...@zte.com.cn; ppse...@cisco.com > >>> Cc: Acee Lindem <acee.i...@gmail.com>; RFC Errata System <rfc- > >>> edi...@rfc-editor.org>; lsr-...@ietf.org; lsr-cha...@ietf.org; RFC > >>> Editor via auth48archive <auth48archive@rfc-editor.org> > >>> Subject: [AD] Re: [auth48] AUTH48: RFC-to-be 9792 <draft-ietf-lsr- > >>> ospf-prefix-extended-flags-07> for your review > >>> > >>> > >>> CAUTION: This is an external email. Please be very careful when > >>> clicking links or opening attachments. See the URL nok.it/ext for > >>> additional information. > >>> > >>> > >>> > >>> Hi Ketan and *Gunter (AD), > >>> > >>> Thank you for the clarification. We have updated both instances of > >>> “prefix attribute flags” to “prefix flags” in our files. > >>> > >>> *Gunter, please review the changes made to the sub-TLV name, field > >>> name, and IANA registry names throughout the document and let us > >>> know if you approve. A summary is provided below, and the updates > >>> can be viewed here: https://www.rfc-editor.org/authors/rfc9792- > >>> auth48diff.html. > >>> > >>> OLD: > >>> 1) OSPFv2/v3 Prefix Attribute Flags sub-TLV > >>> 2) Prefix Attribute Flags field > >>> 3) OSPFv2/v3 Prefix Attribute Flags Field registry > >>> > >>> NEW: > >>> 1) OSPFv2/v3 Prefix Extended Flags sub-TLV > >>> 2) Prefix Extended Flags field > >>> 3) OSPFv2/v3 Prefix Extended Flags registry > >>> > >>> > >>> —FILES (please refresh)— > >>> > >>> The updated XML file is here: > >>> https://www.rfc-editor.org/authors/rfc9792.xml > >>> > >>> The updated output files are here: > >>> https://www.rfc-editor.org/authors/rfc9792.txt > >>> https://www.rfc-editor.org/authors/rfc9792.pdf > >>> https://www.rfc-editor.org/authors/rfc9792.html > >>> > >>> These diff files show all changes made during AUTH48: > >>> https://www.rfc-editor.org/authors/rfc9792-auth48diff.html > >>> https://www.rfc-editor.org/authors/rfc9792-auth48rfcdiff.html (side > >>> by side) > >>> > >>> These diff files show only changes made during the last edit round: > >>> https://www.rfc-editor.org/authors/rfc9792-lastdiff.html > >>> https://www.rfc-editor.org/authors/rfc9792-lastrfcdiff.html (side > >>> by side) > >>> > >>> These diff files show all changes made to date: > >>> https://www.rfc-editor.org/authors/rfc9792-diff.html > >>> https://www.rfc-editor.org/authors/rfc9792-rfcdiff.html (side by > >>> side) > >>> > >>> For the AUTH48 status of this document, please see: > >>> https://www.rfc-editor.org/auth48/rfc9792 > >>> > >>> Best regards, > >>> RFC Editor/kc > >>> > >>> > >>>> On May 28, 2025, at 10:46 PM, Ketan Talaulikar > >>>> <ketant.i...@gmail.com> wrote: > >>>> > >>>> Hi Karen, > >>>> > >>>> Thanks again for your help and your patience on this. Please check > >>>> inline below. > >>>> > >>>> > >>>> On Thu, May 29, 2025 at 4:20 AM Karen Moore <kmo...@staff.rfc- > >>>> editor.org> wrote: > >>>> Hi Acee, Ketan, Peter, and Ran, > >>>> > >>>> Thank you for the discussion/comments regarding “Attribute Flags” > >>>> vs. “Extended Flags”. We have updated the document to reflect the > >>>> following forms: > >>>> > >>>> 1) OSPFv2/v3 Prefix Extended Flags (sub-TLV name) > >>>> 2) Prefix Extended Flags (field name) > >>>> 3) OSPFv2/v3 Prefix Extended Flags (IANA registry name) > >>>> > >>>> We have also updated Table 2 in Section 4.2.1 per your response. > >>>> Note that we have an additional question: > >>>> > >>>> KT> All the changes done in this iteration are as requested. > >>>> > >>>> > >>>> 1) Please review two instances of “prefix attribute flags”. Are > >>>> these correct as is, or should these instances be updated as > >>>> “prefix extended flags”? > >>>> > >>>> Current: > >>>> The rest of this document refers to these 8-bit fields in both > >>>> OSPFv2 and > >>>> OSPFv3 as the "existing fixed-size prefix attribute flags”. > >>>> > >>>> The advertisement and processing of the existing > >>>> fixed-size prefix attribute flags remain unchanged. > >>>> > >>>> KT> Please change "prefix attribute flags" to "prefix flags" in > >>>> KT> this context where we are referring to existing flags and not > >>>> KT> the "extended' flags being introduced by this document. > >>>> > >>>> Thanks, > >>>> Ketan > >>>> > >>>> > >>>> Next Steps: > >>>> Once the authors have responded to our question and confirmed that > >>>> the changes throughout the document are as desired, we will ask > >>>> the AD to approve the term updates. We will then ask IANA to > >>>> update the registries accordingly. > >>>> > >>>> > >>>> —FILES (please refresh)— > >>>> > >>>> The updated XML file is here: > >>>> https://www.rfc-editor.org/authors/rfc9792.xml > >>>> > >>>> The updated output files are here: > >>>> https://www.rfc-editor.org/authors/rfc9792.txt > >>>> https://www.rfc-editor.org/authors/rfc9792.pdf > >>>> https://www.rfc-editor.org/authors/rfc9792.html > >>>> > >>>> These diff files show all changes made during AUTH48: > >>>> https://www.rfc-editor.org/authors/rfc9792-auth48diff.html > >>>> https://www.rfc-editor.org/authors/rfc9792-auth48rfcdiff.html > >>>> (side by > >>>> side) > >>>> > >>>> These diff files show only changes made during the last edit > >>>> round: > >>>> https://www.rfc-editor.org/authors/rfc9792-lastdiff.html > >>>> https://www.rfc-editor.org/authors/rfc9792-lastrfcdiff.html (side > >>>> by > >>>> side) > >>>> > >>>> These diff files show all changes made to date: > >>>> https://www.rfc-editor.org/authors/rfc9792-diff.html > >>>> https://www.rfc-editor.org/authors/rfc9792-rfcdiff.html (side by > >>>> side) > >>>> > >>>> For the AUTH48 status of this document, please see: > >>>> https://www.rfc-editor.org/auth48/rfc9792 > >>>> > >>>> Best regards, > >>>> RFC Editor/kc > >>>> > >>>> > >>>>> On May 28, 2025, at 7:24 AM, <chen....@zte.com.cn> > >>>>> <chen....@zte.com.cn> wrote: > >>>>> > >>>>> Hi Acee，Ketan， > >>>>> Many thanks！I agree，this change is good for me. > >>>>> > >>>>> Best Regards， > >>>>> Ran > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> 发自我的zMail > >>>>> > >>>>> > >>>>> Original > >>>>> From:KetanTalaulikar<ketant.i...@gmail.com> > >>>>> To:Acee Lindem<acee.i...@gmail.com>; > >>>>> Cc:陈然00080434;赵德涛10132546;kmo...@staff.rfc- > >>>>> editor.org;gongliyan@chin > >>>>> amobile.com;Peter > >>>>> Psenak;rfc-edi...@rfc-editor.org;lsr-...@ietf.org;lsr- > >>>>> cha...@ietf.or > >>>>> g;gunter.van_de_ve...@nokia.com;auth48archive@rfc-editor.org; > >>>>> Date:2025-05-28 20:51:19 > >>>>> Subject:Re: [auth48] AUTH48: RFC-to-be 9792 > >>>>> <draft-ietf-lsr-ospf-prefix-extended-flags-07> for your review Hi > >>>>> Acee, > >>>>> > >>>>> Thanks. > >>>>> > >>>>> That gets us to: > >>>>> 1) Sub-TLV name: OSPFv2/v3 Prefix Extended Flags Sub-TLV > >>>>> 2) The field name: Prefix Extended Flags > >>>>> 3) The IANA Registry name: OSPFv2/v3 Prefix Extended Flags > >>>>> Registry > >>>>> > >>>>> It sounds good to me. Do any of my co-authors have concerns or > >>>>> objections? > >>>>> > >>>>> Thanks, > >>>>> Ketan > >>>>> > >>>>> > >>>>> On Wed, May 28, 2025 at 6:14 PM Acee Lindem <acee.i...@gmail.com> > >>>>> wrote: > >>>>> Hi Ketan, > >>>>> > >>>>> I would simply change "attribute flags" to "extended flags" > >>>>> throughout to reflect the title of the draft and the fact that > >>>>> these are prefix flags beyond the current flags. > >>>>> > >>>>> Thanks, > >>>>> Acee > >>>>> > >>>>>> On May 28, 2025, at 8:26 AM, Ketan Talaulikar > >>>>>> <ketant.i...@gmail.com> wrote: > >>>>>> > >>>>>> Hi Acee, > >>>>>> > >>>>>> I would really appreciate it if you could suggest better names. > >>>>>> It would be most welcome. > >>>>>> > >>>>>> Like I said, this aspect escaped the attention of most of us but > >>>>>> it is still not too late to change/fix considering it is just a > >>>>>> name change and we don't have any implementations as yet (that I > >>>>>> know of). > >>>>>> > >>>>>> Thanks, > >>>>>> Ketan > >>>>>> > >>>>>> > >>>>>> On Wed, May 28, 2025 at 5:52 PM Acee Lindem > >>>>>> <acee.i...@gmail.com> wrote: > >>>>>> I'll relent since I'm not an co-author but I wouldn't have named > >>>>>> the Sub-TLVs as such. Agree the registry should match the Sub- > >>>>>> TLVs. > >>>>>> > >>>>>> Thanks, > >>>>>> Acee > >>>>>> > >>>>>>> On May 28, 2025, at 8:02 AM, Ketan Talaulikar > >>>>>>> <ketant.i...@gmail.com> wrote: > >>>>>>> > >>>>>>> Hi Acee, > >>>>>>> > >>>>>>> We have the following in the document (as it stands currently > >>>>>>> in the auth48 stage): > >>>>>>> > >>>>>>> 1) Sub-TLV name: OSPFv2/v3 Prefix Attribute Flags Sub-TLV > >>>>>>> 2) The field name: Prefix Attribute Flags > >>>>>>> 3) The IANA Registry name: OSPFv2/v3 Prefix Attribute Flags > >>>>>>> Registry > >>>>>>> > >>>>>>> Could you please recommend your preferred names for each of the > >>>>>>> above? It would help us converge faster. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Ketan > >>>>>>> > >>>>>>> > >>>>>>> On Wed, May 28, 2025 at 3:52 PM Acee Lindem > >>>>>>> <acee.i...@gmail.com> wrote: > >>>>>>> We have already have: > >>>>>>> > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%25 > >>>>>>> 2Fwww.iana.org%2Fassignments%2Fospfv2-parameters%2Fospfv2- > >>>>>>> parame > >>>>>>> ters.xhtml%23extended-prefix-tlv- > >>>>>>> flags&data=05%7C02%7Cgunter.van > >>>>>>> _de_velde%40nokia.com%7Ca038906a13a84c73f68c08dd9edf7c6a%7C5d471 > >>>>>>> 7519675428d917b70f44f9630b0%7C0%7C0%7C638841405357472463%7CUnkno > >>>>>>> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA > >>>>>>> iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata > >>>>>>> =iFIk53RFDYRDZ8ImCZPJ1b2wyYOlVGFXhSximjttzy8%3D&reserved=0 > >>>>>>> > >>>>>>> https://www.iana.org/assignments/ospfv3-parameters/ospfv3- > >>>>>>> parameters.xhtml#ospfv3-parameters-4 which is merely the prefix > >>>>>>> options from RFC 5340. > >>>>>>> > >>>>>>> I'm not sure why we are now start calling these "attributes"??? > >>>>>>> > >>>>>>> > >>>>>>>> On May 28, 2025, at 5:55 AM, Ketan Talaulikar > >>>>>>>> <ketant.i...@gmail.com> wrote: > >>>>>>>> > >>>>>>>> Hi Ran, > >>>>>>>> > >>>>>>>> That is an ISIS RFC that you are referring to. Perhaps you > >>>>>>>> missed Acee's remarks to me about ISIS focus? ;-) > >>>>>>>> > >>>>>>>> Personally, I would prefer consistency within OSPF first, and > >>>>>>>> then perhaps across IGPs (is also good to have). > >>>>>>> > >>>>>>> Not when the IS-IS terminology isn't applicable. Note the > >>>>>>> encodings and granularity of advertisement it a key difference > >>>>>>> between the IGPs. > >>>>>>> > >>>>>>> Acee > >>>>>>> > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Ketan > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, May 28, 2025 at 3:17 PM <chen....@zte.com.cn> wrote: > >>>>>>>> Hi Acee,Ketan, > >>>>>>>> > >>>>>>>> I'd like to add a quick note on top of Ketan's point — RFC > >>>>>>>> 7794 uses the same term, "Prefix Attribute Flags sub-TLV". > >>>>>>>> From a consistency perspective, that's why I initially > >>>>>>>> suggested that "Prefix Attribute Flags" would be appropriate. > >>>>>>>> However, if the goal is to match better with the existing > >>>>>>>> field naming in OSPF, I agree that "Prefix Extended Flags" > >>>>>>>> makes more sense. > >>>>>>>> > >>>>>>>> Thanks! > >>>>>>>> Ran > >>>>>>>> > >>>>>>>> Original > >>>>>>>> From: KetanTalaulikar <ketant.i...@gmail.com> > >>>>>>>> To: Acee Lindem <acee.i...@gmail.com>; > >>>>>>>> Cc: 赵德涛10132546;kmo...@staff.rfc-editor.org > >>>>>>>> <kmo...@staff.rfc-editor.org>;陈然00080434;gongliyan@chinamobile > >>>>>>>> .com <gongli...@chinamobile.com>;Peter Psenak > >>>>>>>> <ppse...@cisco.com>;rfc-edi...@rfc-editor.org > >>>>>>>> <rfc-edi...@rfc-editor.org>;lsr-...@ietf.org > >>>>>>>> <lsr-...@ietf.org>;lsr-cha...@ietf.org > >>>>>>>> <lsr-cha...@ietf.org>;gunter.van_de_ve...@nokia.com > >>>>>>>> <gunter.van_de_ve...@nokia.com>;auth48archive@rfc-editor.org > >>>>>>>> <auth48archive@rfc-editor.org>; > >>>>>>>> Date: 2025年05月28日 17:11 > >>>>>>>> Subject: Re: [auth48] AUTH48: RFC-to-be 9792 > >>>>>>>> <draft-ietf-lsr-ospf-prefix-extended-flags-07> for your review > >>>>>>>> Hi Acee, This "attribute" has been there in this draft for > >>>>>>>> quite some time and through the WG and later phases. What the > >>>>>>>> RFC editor has caught and fixed are inconsistencies in the use > >>>>>>>> of that term within the document - by introducing "attributes" > >>>>>>>> everywhere for consistency. Please check > >>>>>>>> https://www.rfc-editor.org/authors/rfc9792-diff.html > >>>>>>>> > >>>>>>>> RFC7684 is all about "attributes" but the equivalent flags > >>>>>>>> field in that LSA is not called "attribute". Same/similar is > >>>>>>>> the case for OSPFv3. > >>>>>>>> > >>>>>>>> So I think it is perfectly OK to s/Prefix Attribute > >>>>>>>> Flags/Prefix Extended Flags so as to match better with the > >>>>>>>> existing field in OSPF. > >>>>>>>> > >>>>>>>> I will readily admit that I didn't pay much attention to this > >>>>>>>> naming, but neither did the entire WG and our experienced WG > >>>>>>>> chairs ;-) > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Ketan > >>>>>>>> > >>>>>>>> On Wed, May 28, 2025 at 1:47 PM Acee Lindem > >>>>>>>> <acee.i...@gmail.com> wrote: > >>>>>>>> All, > >>>>>>>> > >>>>>>>> Where is this "attribute" coming from? Refer to RFC 7684 and > >>>>>>>> RFC 83652. These are "Extended Flags'". The registries should > >>>>>>>> be: > >>>>>>>> > >>>>>>>> OSPFv2 Extended Prefix TLV Extended Flags > >>>>>>>> OSPFv3 Prefix TLV Extended Flags > >>>>>>>> > >>>>>>>> Ketan - why aren't you watching this thread? Are you now only > >>>>>>>> paying attention to IS-IS as well? > >>>>>>>> > >>>>>>>> Acee > >>>>>>>> > >>>>>>>>> On May 27, 2025, at 10:12 PM, zhao.de...@zte.com.cn wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Hi, Karen > >>>>>>>>> > >>>>>>>>> Option B is more intuitive and clear， we prefer Option B. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Many thanks > >>>>>>>>> > >>>>>>>>> Detao > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> <5ac0d332cfbe42149bb7e3c16b036327.jpg>赵德涛 > >>>>>>>>> 软件平台系统部/有线研究院/有线产品经营部 > >>>>>>>>> 中兴通讯股份有限公司 > >>>>>>>>> 南京市紫荆花路68号南研一期, 邮编: 210012 > >>>>>>>>> T: +86 15951883174 M: +86 15951883174 > >>>>>>>>> E: zhao.de...@zte.com.cn > >>>>>>>>> Original > >>>>>>>>> From: KarenMoore <kmo...@staff.rfc-editor.org> > >>>>>>>>> To: 陈然00080434;ketant.i...@gmail.com > >>>>>>>>> <ketant.i...@gmail.com>;gongli...@chinamobile.com > >>>>>>>>> <gongli...@chinamobile.com>;ppse...@cisco.com > >>>>>>>>> <ppse...@cisco.com>;赵德涛10132546; > >>>>>>>>> Cc: RFC Errata System > >>>>>>>>> <rfc-edi...@rfc-editor.org>;lsr-...@ietf.org > >>>>>>>>> <lsr-...@ietf.org>;lsr-cha...@ietf.org > >>>>>>>>> <lsr-cha...@ietf.org>;Acee Lindem > >>>>>>>>> <acee.i...@gmail.com>;Gunter van de Velde (Nokia) > >>>>>>>>> <gunter.van_de_ve...@nokia.com>;RFC Editor via auth48archive > >>>>>>>>> <auth48archive@rfc-editor.org>; > >>>>>>>>> Date: 2025年05月28日 06:12 > >>>>>>>>> Subject: 答复: [auth48] AUTH48: RFC-to-be 9792 > >>>>>>>>> <draft-ietf-lsr-ospf-prefix-extended-flags-07> for your > >>>>>>>>> review Authors, > >>>>>>>>> > >>>>>>>>> While we await the updates to the IANA registries, we have an > >>>>>>>>> additional question. > >>>>>>>>> > >>>>>>>>> 1) In Section 4.2.1, the following sentence was added: The > >>>>>>>>> entry in the "L2BM" field is “X”. Would you like to add more > >>>>>>>>> context here (option A)? Or would you like to remove this > >>>>>>>>> sentence and add the "L2BM” column to Table 2 to match the > >>>>>>>>> "OSPFv3 Extended-LSA Sub-TLVs” registry (option B)? See > >>>>>>>>> <https://www.iana.org/assignments/ospfv3-parameters/>. Please > >>>>>>>>> let us know your preference. > >>>>>>>>> > >>>>>>>>> Original: > >>>>>>>>> The entry in the "L2BM" field is “X". > >>>>>>>>> > >>>>>>>>> Perhaps A: > >>>>>>>>> The entry in the "L2BM" field is “X” (i.e., this is not a > >>>>>>>>> sub-TLV of the Router-Link TLV; > >>>>>>>>> it MUST NOT appear in the L2 Bundle Member Attributes sub- > >>>>>>>>> TLV). > >>>>>>>>> > >>>>>>>>> Perhaps B: > >>>>>>>>> | Value | Description | > >>>>>>>>> L2BM | Reference | > >>>>>>>>> +======+===============================+===========+ > >>>>>>>>> | 37 | OSPFv3 Prefix Attribute Flags | X > >>>>>>>>> | RFC 9792 | > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> RFC Editor/kc > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> On May 27, 2025, at 11:44 AM, Karen Moore <kmo...@staff.rfc- > >>>>>>>>>> editor.org> wrote: > >>>>>>>>>> > >>>>>>>>>> Dear Ran, Detao, Ketan, Liyan, and Peter, > >>>>>>>>>> > >>>>>>>>>> Thank you for your replies. We have noted your approvals on > >>>>>>>>>> the AUTH48 status page for this document (https://www.rfc- > >>>>>>>>>> editor.org/auth48/rfc9792). > >>>>>>>>>> > >>>>>>>>>> We will now ask IANA to update their registries to match the > >>>>>>>>>> edited document. We will inform you once the updates are > >>>>>>>>>> complete. > >>>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> RFC Editor/kc > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> On May 25, 2025, at 4:03 AM, <chen....@zte.com.cn> > >>>>>>>>>>> <chen....@zte.com.cn> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Dear Karen, > >>>>>>>>>>> > >>>>>>>>>>> Appreciate the work put into this document. I have reviewed > >>>>>>>>>>> all the changes, and they look good to me. I approve its > >>>>>>>>>>> publication as RFC. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Many thanks, > >>>>>>>>>>> > >>>>>>>>>>> Ran > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Original > >>>>>>>>>>> From: KarenMoore <kmo...@staff.rfc-editor.org> > >>>>>>>>>>> To: 陈然00080434;赵德涛10132546;ppse...@cisco.com > >>>>>>>>>>> <ppse...@cisco.com>;gongli...@chinamobile.com > >>>>>>>>>>> <gongli...@chinamobile.com>;ketant.i...@gmail.com > >>>>>>>>>>> <ketant.i...@gmail.com>; > >>>>>>>>>>> Cc: RFC Errata System > >>>>>>>>>>> <rfc-edi...@rfc-editor.org>;lsr-...@ietf.org > >>>>>>>>>>> <lsr-...@ietf.org>;lsr-cha...@ietf.org > >>>>>>>>>>> <lsr-cha...@ietf.org>;Acee Lindem > >>>>>>>>>>> <acee.i...@gmail.com>;Gunter van de Velde (Nokia) > >>>>>>>>>>> <gunter.van_de_ve...@nokia.com>;RFC Editor via > >>>>>>>>>>> auth48archive <auth48archive@rfc-editor.org>; > >>>>>>>>>>> Date: 2025年05月24日 03:55 > >>>>>>>>>>> Subject: Re: [auth48] AUTH48: RFC-to-be 9792 > >>>>>>>>>>> <draft-ietf-lsr-ospf-prefix-extended-flags-07> for your > >>>>>>>>>>> review Dear Ran, > >>>>>>>>>>> > >>>>>>>>>>> Thank you for your quick reply! We have updated our files > >>>>>>>>>>> accordingly. Please review the changes and let us know if > >>>>>>>>>>> any further updates are needed or if you approve the > >>>>>>>>>>> document in its current form. Note that we will await > >>>>>>>>>>> approvals from each author prior to moving forward with the > >>>>>>>>>>> publication process. > >>>>>>>>>>> > >>>>>>>>>>> —FILES— > >>>>>>>>>>> The updated XML file is here: > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9792.xml > >>>>>>>>>>> > >>>>>>>>>>> The updated output files are here: > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9792.txt > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9792.pdf > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9792.html > >>>>>>>>>>> > >>>>>>>>>>> These diff files show all changes made during AUTH48: > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9792-auth48diff.htm > >>>>>>>>>>> l > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9792-auth48rfcdiff. > >>>>>>>>>>> html (side by side) > >>>>>>>>>>> > >>>>>>>>>>> These diff files show all changes made to date: > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9792-diff.html > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9792-rfcdiff.html > >>>>>>>>>>> (side by side) > >>>>>>>>>>> > >>>>>>>>>>> Note that it may be necessary for you to refresh your > >>>>>>>>>>> browser to view the most recent version. Please review the > >>>>>>>>>>> document carefully to ensure satisfaction as we do not make > >>>>>>>>>>> changes once it has been published as an RFC. > >>>>>>>>>>> > >>>>>>>>>>> For the AUTH48 status of this document, please see: > >>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9792 > >>>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> RFC Editor/kc > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> On May 23, 2025, at 2:30 AM, ranchen via auth48archive > >>>>>>>>>>>> <auth48archive@rfc-editor.org> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Hi RFC Editor, > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Sorry, a typo correction,please see point 5) (b) > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Many thanks! > >>>>>>>>>>>> > >>>>>>>>>>>> Ran > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Original > >>>>>>>>>>>> From: 陈然00080434 > >>>>>>>>>>>> To: rfc-edi...@rfc-editor.org > >>>>>>>>>>>> <rfc-edi...@rfc-editor.org>; > >>>>>>>>>>>> Cc: 赵德涛10132546;ppse...@cisco.com > >>>>>>>>>>>> <ppse...@cisco.com>;ketant.i...@gmail.com > >>>>>>>>>>>> <ketant.i...@gmail.com>;gongli...@chinamobile.com > >>>>>>>>>>>> <gongli...@chinamobile.com>;rfc-edi...@rfc-editor.org > >>>>>>>>>>>> <rfc-edi...@rfc-editor.org>;lsr-...@ietf.org > >>>>>>>>>>>> <lsr-...@ietf.org>;lsr-cha...@ietf.org > >>>>>>>>>>>> <lsr-cha...@ietf.org>;acee.i...@gmail.com > >>>>>>>>>>>> <acee.i...@gmail.com>;gunter.van_de_ve...@nokia.com > >>>>>>>>>>>> <gunter.van_de_ve...@nokia.com>;auth48archive@rfc-editor > >>>>>>>>>>>> .org <auth48archive@rfc-editor.org>; > >>>>>>>>>>>> Date: 2025年05月23日 17:13 > >>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9792 > >>>>>>>>>>>> <draft-ietf-lsr-ospf-prefix-extended-flags-07> for your > >>>>>>>>>>>> review Hi RFC Editor, > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks for this mail. Please find my replies inline. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> From: rfc-edi...@rfc-editor.org > >>>>>>>>>>>> <rfc-edi...@rfc-editor.org> > >>>>>>>>>>>> To: 陈然00080434;赵德涛10132546;ppse...@cisco.com > >>>>>>>>>>>> <ppse...@cisco.com>;ketant.i...@gmail.com > >>>>>>>>>>>> <ketant.i...@gmail.com>;gongli...@chinamobile.com > >>>>>>>>>>>> <gongli...@chinamobile.com>; > >>>>>>>>>>>> Cc: rfc-edi...@rfc-editor.org > >>>>>>>>>>>> <rfc-edi...@rfc-editor.org>;lsr-...@ietf.org > >>>>>>>>>>>> <lsr-...@ietf.org>;lsr-cha...@ietf.org > >>>>>>>>>>>> <lsr-cha...@ietf.org>;acee.i...@gmail.com > >>>>>>>>>>>> <acee.i...@gmail.com>;gunter.van_de_ve...@nokia.com > >>>>>>>>>>>> <gunter.van_de_ve...@nokia.com>;auth48archive@rfc-editor > >>>>>>>>>>>> .org <auth48archive@rfc-editor.org>; > >>>>>>>>>>>> Date: 2025年05月23日 07:00 > >>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9792 > >>>>>>>>>>>> <draft-ietf-lsr-ospf-prefix-extended-flags-07> for your > >>>>>>>>>>>> review Authors, > >>>>>>>>>>>> > >>>>>>>>>>>> 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. --> I suggest：Prefix > >>>>>>>>>>>> attributes；IGP > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 2) <!-- [rfced] We note one instance of "variable-flag > >>>>>>>>>>>> fields"; should this perhaps be updated as > >>>>>>>>>>>> "variable-length Prefix Attribute Flags field" for clarity > >>>>>>>>>>>> and consistency as shown below? > >>>>>>>>>>>> > >>>>>>>>>>>> Original: > >>>>>>>>>>>> Such sub-TLV specifies the variable-flag > >>>>>>>>>>>> fields to advertise additional attributes associated with > >>>>>>>>>>>> OSPF > >>>>>>>>>>>> prefixes. > >>>>>>>>>>>> > >>>>>>>>>>>> Perhaps: > >>>>>>>>>>>> The sub-TLV specifies the variable-length Prefix Attribute > >>>>>>>>>>>> Flags > >>>>>>>>>>>> field to advertise additional attributes associated with > >>>>>>>>>>>> OSPF > >>>>>>>>>>>> prefixes. > >>>>>>>>>>>> -->Yes, that change looks good. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 3) <!-- [rfced] The following text points to > >>>>>>>>>>>> non-existent sections. [RFC3630] does not contain > >>>>>>>>>>>> Section 6.3, and [RFC8362] does not contain Section > >>>>>>>>>>>> 2.3.2. Was "Section 2.3.2 of [RFC3630] and Section 6.3 of > >>>>>>>>>>>> [RFC8362]" perhaps intended as shown below? > >>>>>>>>>>>> > >>>>>>>>>>>> Current: > >>>>>>>>>>>> An implementation that does not recognize the > >>>>>>>>>>>> OSPFv2/OSPFv3 Prefix > >>>>>>>>>>>> Attribute Flags sub-TLV would ignore the sub-TLV as per > >>>>>>>>>>>> normal TLV > >>>>>>>>>>>> processing operations (refer to Section 6.3 of [RFC3630] > >>>>>>>>>>>> and Section > >>>>>>>>>>>> 2.3.2 of [RFC8362]). > >>>>>>>>>>>> > >>>>>>>>>>>> Perhaps: > >>>>>>>>>>>> An implementation that does not recognize the > >>>>>>>>>>>> OSPFv2/OSPFv3 Prefix > >>>>>>>>>>>> Attribute Flags sub-TLV would ignore the sub-TLV as per > >>>>>>>>>>>> normal TLV > >>>>>>>>>>>> processing operations (refer to Section 2.3.2 of [RFC3630] > >>>>>>>>>>>> and Section > >>>>>>>>>>>> 6.3 of [RFC8362]). > >>>>>>>>>>>> -->You are correct. The intended references were > >>>>>>>>>>>> mistakenly reversed. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 4) <!-- [rfced] We have included some specific questions > >>>>>>>>>>>> about the IANA text below. In addition to responding to > >>>>>>>>>>>> those questions, please review all of the IANA-related > >>>>>>>>>>>> updates carefully and let us know if any further updates > >>>>>>>>>>>> are needed. > >>>>>>>>>>>> > >>>>>>>>>>>> a) We see the following note from IANA. Please confirm > >>>>>>>>>>>> if the additional sentence has been added or if it still > >>>>>>>>>>>> needs to be added. > >>>>>>>>>>>> > >>>>>>>>>>>> NOTE: The authors plan to upload an -08 that will > >>>>>>>>>>>> include an additional sentence in the IANA Considerations > >>>>>>>>>>>> section. > >>>>>>>>>>>> -->Yes, it still need to be added. Please add: The entry > >>>>>>>>>>>> -->in the "L2BM" field is "X" at the > >>>>>>>>>>>> > >>>>>>>>>>>> bottom of section 5.2.1. Please see blow: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 5.2.1. OSPFv3 Prefix Attribute Flags Sub-TLV Registry > >>>>>>>>>>>> This document requests IANA to make permanent the early > >>>>>>>>>>>> allocation of the following codepoint for the "OSPFv3 > >>>>>>>>>>>> Prefix Attribute Flags" in the "OSPFv3 Extended-LSA > >>>>>>>>>>>> sub-TLVs" registry: Value Description > >>>>>>>>>>>> Reference -------- > >>>>>>>>>>>> ---------------------------------- -------------- > >>>>>>>>>>>> 37 OSPFv3 Prefix Attribute Flags RFC to be > >>>>>>>>>>>> The entry in the "L2BM" field is "X". > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> b) Should the titles of the new registries created by > >>>>>>>>>>>> this document be updated to use "Flags" rather than > >>>>>>>>>>>> "Flag Field"? We ask because that seems to be the > >>>>>>>>>>>> pattern with other registry titles within both of the > >>>>>>>>>>>> registry groups (see links below). > >>>>>>>>>>>> > >>>>>>>>>>>> Also, the name of the field in Figure 1 of this document > >>>>>>>>>>>> is "Prefix Attribute Flags". Should the titles of the > >>>>>>>>>>>> registries be updated further to use "Prefix Attribute" > >>>>>>>>>>>> rather than "Prefix Extended"? Or is this okay? > >>>>>>>>>>>> > >>>>>>>>>>>> If the titles are updated, we will ask IANA to update > >>>>>>>>>>>> the registries accordingly. > >>>>>>>>>>>> > >>>>>>>>>>>> http://http/ > >>>>>>>>>>>> s%3A%2F%2Fwww.iana.org%2Fassignments%2Fospfv2-parameters > >>>>>>>>>>>> %2F&data=05%7C02%7Cgunter.van_de_velde%40nokia.com%7Ca03 > >>>>>>>>>>>> 8906a13a84c73f68c08dd9edf7c6a%7C5d4717519675428d917b70f4 > >>>>>>>>>>>> 4f9630b0%7C0%7C0%7C638841405357533921%7CUnknown%7CTWFpbG > >>>>>>>>>>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > >>>>>>>>>>>> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C& > >>>>>>>>>>>> sdata=PI5%2FmmSCIxNJWmQVdvKJSQdMY5LLYkcCuZANN8MyUoY%3D&r > >>>>>>>>>>>> eserved=0 > >>>>>>>>>>>> http://http/ > >>>>>>>>>>>> s%3A%2F%2Fwww.iana.org%2Fassignments%2Fospfv3-parameters > >>>>>>>>>>>> %2F&data=05%7C02%7Cgunter.van_de_velde%40nokia.com%7Ca03 > >>>>>>>>>>>> 8906a13a84c73f68c08dd9edf7c6a%7C5d4717519675428d917b70f4 > >>>>>>>>>>>> 4f9630b0%7C0%7C0%7C638841405357548778%7CUnknown%7CTWFpbG > >>>>>>>>>>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > >>>>>>>>>>>> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C& > >>>>>>>>>>>> sdata=7T1gxHw6%2Bcwe2h%2BFZ5sttp9O0g0xTjHJpls%2FxbXJuhM% > >>>>>>>>>>>> 3D&reserved=0 > >>>>>>>>>>>> > >>>>>>>>>>>> Current: > >>>>>>>>>>>> OSPFv2 Prefix Extended Flag Field > >>>>>>>>>>>> OSPFv3 Prefix Extended Flag Field > >>>>>>>>>>>> > >>>>>>>>>>>> Perhaps A: > >>>>>>>>>>>> OSPFv2 Prefix Extended Flags > >>>>>>>>>>>> OSPFv3 Prefix Extended Flags > >>>>>>>>>>>> > >>>>>>>>>>>> or > >>>>>>>>>>>> > >>>>>>>>>>>> Perhaps B: > >>>>>>>>>>>> OSPFv2 Prefix Attribute Flags > >>>>>>>>>>>> OSPFv3 Prefix Attribute Flags > >>>>>>>>>>>> --> We agree with the suggestion and prefer to rename > >>>>>>>>>>>> --> the registries as follows for > >>>>>>>>>>>> > >>>>>>>>>>>> clarity and consistency with the field name used in the > >>>>>>>>>>>> document: > >>>>>>>>>>>> > >>>>>>>>>>>> • OSPFv2 Prefix Attribute Flags > >>>>>>>>>>>> > >>>>>>>>>>>> • OSPFv3 Prefix Attribute Flags > >>>>>>>>>>>> > >>>>>>>>>>>> Please proceed to ask IANA to update the registry titles > >>>>>>>>>>>> accordingly. Many thanks! > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 5) <!-- [rfced] Terminology > >>>>>>>>>>>> > >>>>>>>>>>>> a) FYI - We see both of the following forms. We updated > >>>>>>>>>>>> the document to reflect the second form (i.e., with > >>>>>>>>>>>> capitalized "Flags") for consistency. > >>>>>>>>>>>> > >>>>>>>>>>>> flags field of the OSPFv2 Extended Prefix TLV Flags > >>>>>>>>>>>> field of the OSPFv2 Extended Prefix TLV > >>>>>>>>>>>> > >>>>>>>>>>>> --> Yes, that change looks good. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> b) Please review the capitalization of "prefix attribute > >>>>>>>>>>>> flags" and "Prefix Attribute Flags" in the text below. > >>>>>>>>>>>> We believe this should be capitalized in the name of the > >>>>>>>>>>>> TLV and the name of the field but lowercased in general > >>>>>>>>>>>> text. However, we are not sure if the capitalized form in > >>>>>>>>>>>> the following sentences is referring to the field. Are any > >>>>>>>>>>>> updates needed? > >>>>>>>>>>>> > >>>>>>>>>>>> Original: > >>>>>>>>>>>> Length (2 octets): Variable, dependent on the included > >>>>>>>>>>>> Prefix > >>>>>>>>>>>> Attribute Flags. This indicates the length of the prefix > >>>>>>>>>>>> attributes > >>>>>>>>>>>> flags in octets. > >>>>>>>>>>>> ... > >>>>>>>>>>>> For example, the most > >>>>>>>>>>>> significant bit in the fifth octet of an 8-octet Prefix > >>>>>>>>>>>> Attribute > >>>>>>>>>>>> Flags is referred to as bit 32. > >>>>>>>>>>>> > >>>>>>>>>>>> Perhaps (leave capitalized form and add "field" for > >>>>>>>>>>>> clarity): > >>>>>>>>>>>> Length (2 octets): Variable, dependent on the included > >>>>>>>>>>>> Prefix > >>>>>>>>>>>> Attribute Flags field. This indicates the length of > >>>>>>>>>>>> the prefix > >>>>>>>>>>>> attributes flags in octets. > >>>>>>>>>>>> ... > >>>>>>>>>>>> For example, the most > >>>>>>>>>>>> significant bit in the fifth octet of an 8-octet Prefix > >>>>>>>>>>>> Attribute > >>>>>>>>>>>> Flags field is referred to as bit 32. > >>>>>>>>>>>> --> Yes, I agree. > >>>>>>>>>>>> > >>>>>>>>>>>> There is one more place that needs to be updated. > >>>>>>>>>>>> > >>>>>>>>>>>> Original: > >>>>>>>>>>>> Length (2 octets): Variable, dependent on the included > >>>>>>>>>>>> Prefix > >>>>>>>>>>>> Attribute Flags. This indicates the length of the prefix > >>>>>>>>>>>> attributes > >>>>>>>>>>>> flags in octets. > >>>>>>>>>>>> > >>>>>>>>>>>> New: > >>>>>>>>>>>> > >>>>>>>>>>>> Length (2 octets): Variable, dependent on the included > >>>>>>>>>>>> Prefix > >>>>>>>>>>>> Attribute Flags field. This indicates the length of > >>>>>>>>>>>> the Prefix > >>>>>>>>>>>> Attributes Flags field in octets. > >>>>>>>>>>>> > >>>>>>>>>>>> Change to: > >>>>>>>>>>>> > >>>>>>>>>>>> Length (2 octets): Variable, dependent on the included > >>>>>>>>>>>> Prefix > >>>>>>>>>>>> Attribute Flags field. This indicates the length of > >>>>>>>>>>>> the Prefix > >>>>>>>>>>>> Attribute Flags field in octets. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 6) <!-- [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. > >>>>>>>>>>>> --> > >>>>>>>>>>>> After checking I believe the current text is OK in this > >>>>>>>>>>>> aspect. > >>>>>>>>>>>> > >>>>>>>>>>>> Many thanks, > >>>>>>>>>>>> > >>>>>>>>>>>> Ran > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Thank you. > >>>>>>>>>>>> > >>>>>>>>>>>> RFC Editor/rv/kc > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On May 22, 2025, at 3:57 PM, rfc-edi...@rfc-editor.org > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> *****IMPORTANT***** > >>>>>>>>>>>> > >>>>>>>>>>>> Updated 2025/05/22 > >>>>>>>>>>>> > >>>>>>>>>>>> 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/yb6l > >>>>>>>>>>>> pIGh-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/rfc9792.xml > >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9792.html > >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9792.pdf > >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9792.txt > >>>>>>>>>>>> > >>>>>>>>>>>> Diff file of the text: > >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9792-diff.html > >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9792-rfcdiff.html > >>>>>>>>>>>> (side by side) > >>>>>>>>>>>> > >>>>>>>>>>>> Diff of the XML: > >>>>>>>>>>>> > >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9792-xmldiff1.html > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Tracking progress > >>>>>>>>>>>> ----------------- > >>>>>>>>>>>> > >>>>>>>>>>>> The details of the AUTH48 status of your document are > >>>>>>>>>>>> here: > >>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9792 > >>>>>>>>>>>> > >>>>>>>>>>>> Please let us know if you have any questions. > >>>>>>>>>>>> > >>>>>>>>>>>> Thank you for your cooperation, > >>>>>>>>>>>> > >>>>>>>>>>>> RFC Editor > >>>>>>>>>>>> > >>>>>>>>>>>> -------------------------------------- > >>>>>>>>>>>> RFC9792 (draft-ietf-lsr-ospf-prefix-extended-flags-07) > >>>>>>>>>>>> > >>>>>>>>>>>> Title : Prefix Flag Extension for OSPFv2 and > >>>>>>>>>>>> OSPFv3 > >>>>>>>>>>>> Author(s) : R. Chen, D. Zhao, P. Psenak, K. > >>>>>>>>>>>> Talaulikar, L. Gong > >>>>>>>>>>>> WG Chair(s) : Acee Lindem, Christian Hopps, Yingzhen > >>>>>>>>>>>> Qu > >>>>>>>>>>>> > >>>>>>>>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, > >>>>>>>>>>>> Gunter Van de Velde > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> auth48archive mailing list -- > >>>>>>>>>>>> auth48archive@rfc-editor.org To unsubscribe send an > >>>>>>>>>>>> email to auth48archive-le...@rfc-editor.org > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
