Authors, The IANA actions are complete for this document. We will now proceed with the publication process.
Thank you to all for your time! Best regards, RFC Editor/kc > On Jun 2, 2025, at 11:09 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 this >>> context where we are referring to existing flags and not 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
