We have already have: https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#extended-prefix-tlv-flags
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;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
