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 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
