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
