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
