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;gongli...@chinamobile.com;Peter
Psenak;rfc-edi...@rfc-editor.org;lsr-...@ietf.org;lsr-cha...@ietf.org;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://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
