Hi, These changes are complete:
https://www.iana.org/assignments/ospfv2-parameters https://www.iana.org/assignments/ospfv3-parameters thanks, Amanda On Tue May 27 21:52:01 2025, kmo...@staff.rfc-editor.org wrote: > Dear IANA, > > Please make the following updates to match the edited document at > https://www.rfc-editor.org/authors/rfc9792-diff.html <https://www.rfc- > editor.org/authors/rfc9792-diff.html>. > > 1) At https://www.iana.org/assignments/ospfv2-parameters/ > <https://www.iana.org/assignments/ospfv2-parameters/>, please update > the title of the registry: > > Old: > OSPFv2 Prefix Extended Flag Field > > New: > OSPFv2 Prefix Attribute Flags > > > 2) At https://www.iana.org/assignments/ospfv3-parameters > <https://www.iana.org/assignments/ospfv3-parameters>, please update > the title of the registry: > > OLD: > OSPFv3 Prefix Extended Flag Field > > NEW: > OSPFv3 Prefix Attribute Flags > > > Thank you in advance! > > RFC Editor/kc > > > > Begin forwarded message: > > > > From: Karen Moore <kmo...@staff.rfc-editor.org> > > Subject: Re: [auth48] AUTH48: RFC-to-be 9792 <draft-ietf-lsr-ospf- > > prefix-extended-flags-07> for your review > > Date: May 27, 2025 at 11:44:57 AM PDT > > To: chen....@zte.com.cn, ketant.i...@gmail.com, > > gongli...@chinamobile.com, ppse...@cisco.com, zhao.de...@zte.com.cn > > Cc: RFC Errata System <rfc-edi...@rfc-editor.org>, lsr-...@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> > > > > 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- > >>> a...@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
