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
