Hi Megan, Noted those, and it looks good to me.
Thanks, Ketan PS: My approval on this is as a co-author and Gunter would handle the AD approval, if required. On Wed, May 13, 2026 at 8:51 PM Megan Ferguson < [email protected]> wrote: > Hi Ketan, > > Thanks for your reply. We have recorded your approval at the AUTH48 > status page for this document (see link below). > > Note: we have made two slight tweaks to the module per pyang formatting > guidance: > 1) Moved the namespace “urn…” onto the same line. > 2) Fixed the indent of the yang parameters url. > > You may see the changes highlighted in the side-by-side diffs (htmlwdiff > does not highlight). Please let us know any objections. > > The files have been posted here: > https://www.rfc-editor.org/authors/rfc9983.txt > https://www.rfc-editor.org/authors/rfc9983.pdf > https://www.rfc-editor.org/authors/rfc9983.html > https://www.rfc-editor.org/authors/rfc9983.xml > > The diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9983-diff.html (comprehensive) > https://www.rfc-editor.org/authors/rfc9983-rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9983-auth48diff.html (AUTH48 > changes only) > https://www.rfc-editor.org/authors/rfc9983-auth48rfcdiff.html (side by > side) > > The AUTH48 status page is viewable here: > https://www.rfc-editor.org/auth48/rfc9983 > > Thank you. > > Megan Ferguson > RFC Production Center > > > > On May 13, 2026, at 12:01 PM, Ketan Talaulikar <[email protected]> > wrote: > > > > Hi Megan, > > > > Thanks for your help with this document and please consider this email > my approval for publication. > > > > Thanks, > > Ketan > > > > > > On Wed, May 13, 2026 at 6:08 PM Megan Ferguson < > [email protected]> wrote: > > Hi Ran, > > > > Thank you for responding to our issues/queries. We have noted that all > RPC queries have been resolved at this document’s AUTH48 status page (see > link below). > > > > Please contact us with any further changes you may have to the document > or your approval of the document in its current form. Once we have > approvals from each party listed at the AUTH48 status page, we will be > ready to move this document forward in the publication process. > > > > The files have been posted here: > > https://www.rfc-editor.org/authors/rfc9983.txt > > https://www.rfc-editor.org/authors/rfc9983.pdf > > https://www.rfc-editor.org/authors/rfc9983.html > > https://www.rfc-editor.org/authors/rfc9983.xml > > > > The diff files have been posted here: > > https://www.rfc-editor.org/authors/rfc9983-diff.html (comprehensive) > > https://www.rfc-editor.org/authors/rfc9983-rfcdiff.html (side by > side) > > > > https://www.rfc-editor.org/authors/rfc9983-auth48diff.html (AUTH48 > changes only) > > https://www.rfc-editor.org/authors/rfc9983-auth48rfcdiff.html (side > by side) > > > > The AUTH48 status page is viewable here: > > https://www.rfc-editor.org/auth48/rfc9983 > > > > Thank you. > > > > Megan Ferguson > > RFC Production Center > > > > > Hi RFC Editor, > > > > > > Thanks for this mail. Please find my replies inline. > > > > > > From: [email protected] <[email protected]> > > > To: 陈然00080434;赵德涛10132546;[email protected] <[email protected]>; > [email protected]<[email protected]>;[email protected] < > [email protected]>; > > > Cc: [email protected] <[email protected]>; > [email protected] <[email protected]>;[email protected] < > [email protected]>;[email protected] <[email protected]>; > [email protected]<[email protected]>; > [email protected] <[email protected]>; > > > Date: 2026年05月13日 02:53 > > > Subject: Re: AUTH48: RFC-to-be 9983 <draft-ietf-lsr-anycast-flag-13> > for your review > > > Authors, > > > > > > While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the source file. > > > > > > 1) <!-- [rfced] We had the following question about the title of the > document: > > > > > > We note that most of the recently published RFCs containing YANG > > > modules format their titles as "A YANG Data Model for...", for > > > example: > > > > > > RFC 9094 - A YANG Data Model for Wavelength Switched Optical > Networks (WSONs) > > > RFC 9093 - A YANG Data Model for Layer 0 Types > > > RFC 9067 - A YANG Data Model for Routing Policy > > > > > > Please consider whether the title of this document should be similarly > > > updated. > > > > > > -->Ran：Please keep the current title "OSPFv2 Anycast Property > Advertisement". > > > The document primarily defines a protocol extension (AC‑flag) for > OSPFv2; > > > the YANG module is a companion. Changing to "A YANG Data Model for ..." > > > would misrepresent the main content. > > > > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > > > the title) for use on https://www.rfc-editor.org/search. > -->Ran：Extended Prefix TLV, AC‑flag, YANG > > > > > > > > > 3) <!--[rfced] Should "Flag" be added to this text to match use in the > > > Abstract? > > > > > > Original: > > > The OSPFv2 Extended Prefix TLV that is contained in the OSPFv2 > > > Extended Prefix Opaque LSA is used to advertise additional attributes > > > associated with a prefix. > > > > > > Perhaps: > > > The OSPFv2 Extended Prefix TLV Flag that is contained in the OSPFv2 > > > Extended Prefix Opaque LSA is used to advertise additional attributes > > > associated with a prefix. > > > > > > --> Ran：We suggest keeping the original text as is. The phrase > > > "OSPFv2 Extended Prefix TLV" correctly refers to the entire TLV > > > structure, not just its Flag field. Adding "Flag" would therefore be > inaccurate. > > > > > > > > > 4) <!--[rfced] FYI: we have put the YANG Tree in the "Tree for the YANG > > > Data Model" section in <sourcecode> with type="yangtree". > > > -->Ran：Acknowledged, fine. > > > > > > > > > 5) <!--[rfced] We had the following questions, comments, concerns > regarding the YANG Data Model in Section 4.2 itself: > > > > > > a) Please note that we have added the BCP 14 keywords paragraph as we > > > see at least one use of MUST NOT in the description fields. > > > > > > --> Ran：Acknowledged, thanks. > > > > > > > > > 6) <!--[rfced] We note the following deviations from the template at > > > https://wiki.ietf.org/group/ops/yang-security-guidelines: > > > > > > a) All writable data nodes vs. This data node > > > > > > Template: > > > All writable data nodes are likely to be reasonably sensitive or > > > vulnerable... > > > > > > This document: > > > This data node can be considered sensitive or vulnerable... > > > > > > Please let us know if/how to update. > > > -->Ran：We appreciate the guidance provided in the template. > > > In this specific module, only one writable data node exists. > > > Therefore, we would prefer to keep the phrase "This data node" > > > as it accurately reflects the module’s content. Following the > > > template's plural form would not be precise in this case. > > > > > > b) We have added "and delete operations" and "or authentication" in > > > the text below. Please let us know any objections. > > > > > > Original: > > > Write operations (e.g., edit-config) to this > > > data node without proper protection can have a negative effect on > > > network operations. > > > > > > Current (matches template): > > > Write operations (e.g., edit-config) and delete operations to this > > > data node without proper protection or authentication can have a > > > negative effect on network operations. > > > -->Ran: Thank you for adding “and delete operations”and “or > > > authentication”to align with the template. We fully agree with > > > these changes and accept them. > > > > > > c) FYI - We have left this variance as was. Please let us know > > > objections. > > > > > > At the template: > > > The following subtrees and data nodes... > > > > > > In the doc: > > > Specifically, the following subtree and data node... > > > -->Ran: We recognise the template uses the plural form. However, > > > as there is only one relevant data node in this module, we prefer > > > to keep the singular “subtree and data node” for accuracy. > > > > > > d) FYI - We have left this variance as was. Please let us know > objections. > > > > > > At the template: > > > Some of the readable data nodes... > > > > > > In the doc: > > > The readable data node... > > > -->Ran: Similarly, because the module contains just one readable data > node, > > > we would prefer to retain “The readable data node” as originally > written. > > > > > > > > > 7) <!--[rfced] We had the following questions/comments related to > > > terminology use throughout the document: > > > > > > We have updated to use AC-Flag consistently throughout to match the > > > use in the IANA section. > > > -->Ran: Acknowledged, thanks. > > > > > > 8) <!--[rfced] We had the following questions/comments related to > > > abbreviation use throughout the document: > > > > > > Please note that we have expanded abbreviations on first use. > > > Please review for accuracy. > > > -->Ran:We have reviewed the abbreviations expanded on first use and > > > confirm that they are accurate for this document. No further changes > are needed. > > > Thanks. > > > > > > 9) <!-- [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. > > > -->Ran: Reviewed; no issues found. Thanks! > > > > > > Many thanks！ > > > Ran. > > > > > > Thank you. > > > > > > Megan Ferguson > > > RFC Production Center > > > > > > *****IMPORTANT***** > > > > > > Updated 2026/05/12 > > > > > > 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 > > > > > > * [email protected] (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). > > > > > > * [email protected], 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, > > > [email protected] 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/rfc9983.xml > > > https://www.rfc-editor.org/authors/rfc9983.html > > > https://www.rfc-editor.org/authors/rfc9983.pdf > > > https://www.rfc-editor.org/authors/rfc9983.txt > > > > > > Diff file of the text: > > > https://www.rfc-editor.org/authors/rfc9983-diff.html > > > https://www.rfc-editor.org/authors/rfc9983-rfcdiff.html (side by > side) > > > > > > Diff of the XML: > > > https://www.rfc-editor.org/authors/rfc9983-xmldiff1.html > > > > > > > > > Tracking progress > > > ----------------- > > > > > > The details of the AUTH48 status of your document are here: > > > https://www.rfc-editor.org/auth48/rfc9983 > > > > > > Please let us know if you have any questions. > > > > > > Thank you for your cooperation, > > > > > > RFC Editor > > > > > > -------------------------------------- > > > RFC9983 (draft-ietf-lsr-anycast-flag-13) > > > > > > Title : OSPFv2 Anycast Property Advertisement > > > Author(s) : R. Chen, D. Zhao, P. Psenak, K. Talaulikar, C. Lin > > > WG Chair(s) : Acee Lindem, Christian Hopps, Yingzhen Qu > > > > > > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > > > > > > > On May 12, 2026, at 12:53 PM, [email protected] wrote: > > > > > > Authors, > > > > > > While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the source file. > > > > > > 1) <!-- [rfced] We had the following question about the title of the > document: > > > > > > We note that most of the recently published RFCs containing YANG > > > modules format their titles as "A YANG Data Model for...", for > > > example: > > > > > > RFC 9094 - A YANG Data Model for Wavelength Switched Optical > Networks (WSONs) > > > RFC 9093 - A YANG Data Model for Layer 0 Types > > > RFC 9067 - A YANG Data Model for Routing Policy > > > > > > Please consider whether the title of this document should be similarly > > > updated. > > > > > > --> > > > > > > > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > > > the title) for use on https://www.rfc-editor.org/search. --> > > > > > > > > > 3) <!--[rfced] Should "Flag" be added to this text to match use in the > > > Abstract? > > > > > > Original: > > > The OSPFv2 Extended Prefix TLV that is contained in the OSPFv2 > > > Extended Prefix Opaque LSA is used to advertise additional attributes > > > associated with a prefix. > > > > > > Perhaps: > > > The OSPFv2 Extended Prefix TLV Flag that is contained in the OSPFv2 > > > Extended Prefix Opaque LSA is used to advertise additional attributes > > > associated with a prefix. > > > > > > --> > > > > > > > > > 4) <!--[rfced] FYI: we have put the YANG Tree in the "Tree for the YANG > > > Data Model" section in <sourcecode> with type="yangtree". --> > > > > > > > > > 5) <!--[rfced] We had the following questions, comments, concerns > regarding the YANG Data Model in Section 4.2 itself: > > > > > > a) Please note that we have added the BCP 14 keywords paragraph as we > > > see at least one use of MUST NOT in the description fields. > > > > > > --> > > > > > > > > > 6) <!--[rfced] We note the following deviations from the template at > > > https://wiki.ietf.org/group/ops/yang-security-guidelines: > > > > > > a) All writable data nodes vs. This data node > > > > > > Template: > > > All writable data nodes are likely to be reasonably sensitive or > > > vulnerable... > > > > > > This document: > > > This data node can be considered sensitive or vulnerable... > > > > > > Please let us know if/how to update. > > > > > > b) We have added "and delete operations" and "or authentication" in > > > the text below. Please let us know any objections. > > > > > > Original: > > > Write operations (e.g., edit-config) to this > > > data node without proper protection can have a negative effect on > > > network operations. > > > > > > Current (matches template): > > > Write operations (e.g., edit-config) and delete operations to this > > > data node without proper protection or authentication can have a > > > negative effect on network operations. > > > > > > c) FYI - We have left this variance as was. Please let us know > > > objections. > > > > > > At the template: > > > The following subtrees and data nodes... > > > > > > In the doc: > > > Specifically, the following subtree and data node... > > > > > > d) FYI - We have left this variance as was. Please let us know > objections. > > > > > > At the template: > > > Some of the readable data nodes... > > > > > > In the doc: > > > The readable data node... > > > > > > --> > > > > > > > > > 7) <!--[rfced] We had the following questions/comments related to > > > terminology use throughout the document: > > > > > > We have updated to use AC-Flag consistently throughout to match the > > > use in the IANA section. > > > --> > > > > > > > > > 8) <!--[rfced] We had the following questions/comments related to > > > abbreviation use throughout the document: > > > > > > Please note that we have expanded abbreviations on first use. > > > Please review for accuracy. > > > > > > --> > > > > > > > > > 9) <!-- [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. > > > --> > > > > > > > > > Thank you. > > > > > > Megan Ferguson > > > RFC Production Center > > > > > > *****IMPORTANT***** > > > > > > Updated 2026/05/12 > > > > > > 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 > > > > > > * [email protected] (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). > > > > > > * [email protected], 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, > > > [email protected] 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/rfc9983.xml > > > https://www.rfc-editor.org/authors/rfc9983.html > > > https://www.rfc-editor.org/authors/rfc9983.pdf > > > https://www.rfc-editor.org/authors/rfc9983.txt > > > > > > Diff file of the text: > > > https://www.rfc-editor.org/authors/rfc9983-diff.html > > > https://www.rfc-editor.org/authors/rfc9983-rfcdiff.html (side by > side) > > > > > > Diff of the XML: > > > https://www.rfc-editor.org/authors/rfc9983-xmldiff1.html > > > > > > > > > Tracking progress > > > ----------------- > > > > > > The details of the AUTH48 status of your document are here: > > > https://www.rfc-editor.org/auth48/rfc9983 > > > > > > Please let us know if you have any questions. > > > > > > Thank you for your cooperation, > > > > > > RFC Editor > > > > > > -------------------------------------- > > > RFC9983 (draft-ietf-lsr-anycast-flag-13) > > > > > > Title : OSPFv2 Anycast Property Advertisement > > > Author(s) : R. Chen, D. Zhao, P. Psenak, K. Talaulikar, C. Lin > > > WG Chair(s) : Acee Lindem, Christian Hopps, Yingzhen Qu > > > > > > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > > > > > > > > > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
