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). 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;gongli...@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.html >> > >> 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. >> > >>> >> > >>> https://www.iana.org/assignments/ospfv2-parameters/ >> > >>> https://www.iana.org/assignments/ospfv3-parameters/ >> > >>> >> > >>> 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/yb6lpIGh-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
