<?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. --> encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. --> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-lsr-anycast-flag-13"
number="9983" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.38.1 -->
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** -->

  <front>
<!-- The abbreviated [rfced] We had the following question about the title is used in of the
     document:

We note that most of the page header recently published RFCs containing YANG
modules format their titles as "A YANG Data Model for...", for
example:

    RFC 9094 - it is only necessary if 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
        full title is longer than 39 characters of this document should be similarly
updated.

-->

   <title abbrev="Anycast Property advertisement">OSPFv2 Advertisement">OSPFv2 Anycast Property Advertisement</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-lsr-anycast-flag-13"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor --> name="RFC" value="9983"/>

   <author fullname="Ran Chen" initials="R." surname="Chen">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->
          <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>chen.ran@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>

    <author fullname="Detao Zhao" initials="D." surname="Zhao">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->
          <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>zhao.detao@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>

    <author fullname="Peter Psenak" initials="P." surname="Psenak">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city/>
          <region/>
          <code/>
          <country></country>
        </postal>
        <email>ppsenak@cisco.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>

    <author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city/>
          <region/>
          <code/>
          <country></country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>

    <author fullname="Changwang Lin" initials="C." surname="Lin">
      <organization>New H3C Technologies</organization>
      <address>
	<postal>
          <street/>
          <!-- Reorder these if your country does things differently -->
	  <city>Beijing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>linchangwang.04414@h3c.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>

    <date month="May" year="2026"/>

    <area>RTG</area>
    <workgroup>lsr</workgroup>

<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
        in the current day for you. If only the current year is specified, xml2rfc will fill [rfced] Please insert any keywords (beyond those that appear in
the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified title) for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>Routing</area>
    <workgroup>LSR</workgroup>
    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>Internet Draft</keyword>
    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect use on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

   <abstract>
      <t>An IP prefix may be configured as anycast and and, as such such, the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast prefix.</t>
      <t>This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. The document also specifies a companion YANG module for managing this function.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>An IP prefix may be configured as anycast and and, as such such, the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast prefix.</t>

<!--[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.

-->

     <t><xref target="RFC7684" format="default"></xref> format="default"/> defines OSPFv2 Opaque LSAs Link State Advertisements (LSAs) based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. 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.</t>
	 <t>Extensions related to the anycast property of prefixes have been specified for IS-IS <xref target="RFC9352" format="default"></xref> format="default"/> and OSPFv3 <xref target="RFC9513" format="default"></xref>, format="default"/>, even though those documents are related to Segment Routing over IPv6, the anycast property applies to any IP prefix advertisement. This document defines a flag to advertise the anycast property for a prefix advertisement in OSPFv2 in the Flags field of the OSPFv2 Extended Prefix TLV Flags (section 2.1 of <xref (<xref target="RFC7684" format="default"></xref>). section="2.1"/>). The document also specifies a companion YANG module for managing this function.</t>
     <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
        "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>

   <section numbered="true" toc="default"> toc="default" anchor="sect-2">
        <name>OSPFv2 Anycast Property Advertisement</name>
        <t>An IP prefix may be configured as anycast and anycast; it is useful for other routers to know that the advertisement is for an anycast prefix.</t>
	<t>In the context of the flags defined in this document, the term 'set' "set" means the bit is set to 1, and the term 'clear' 1; "clear" means the bit is set to 0.</t>
	<t>A flag is introduced in OSPFv2 the "OSPFv2 Extended Prefix TLV Flags Flags" IANA registry (see <xref target="RFC7684" format="default"></xref> format="default"/>) to advertise the anycast property:</t>
		<t>Value: TBD</t>
        <t>Description: Anycast
	<dl spacing="normal" newline="false">
	  <dt>Value:</dt><dd>0x10</dd>
          <dt>Description:</dt><dd>Anycast Flag (AC-flag)</t> (AC-Flag)</dd>
	</dl>
	<t>The only meaning of the AC-flag AC-Flag is that the prefix is intended to be advertised by multiple nodes.</t>
	<t>When a prefix is configured as anycast, the AC-flag MUST AC-Flag <bcp14>MUST</bcp14> be set. Otherwise, this flag MUST <bcp14>MUST</bcp14> be clear.</t>
		<t>The AC-flag AC-Flag and the N-flag (section 2.1 of <xref target="RFC7684" format="default"></xref>) MUST NOT (<xref section="2.1" target="RFC7684"/>) <bcp14>MUST NOT</bcp14> both be set. The reception of an advertisement with both the N-flag and AC-flag AC-Flag set MUST <bcp14>MUST</bcp14> be considered a configuration anomaly, and the N-flag MUST <bcp14>MUST</bcp14> be ignored. Additionally, the detection of such a conflicting advertisement SHOULD <bcp14>SHOULD</bcp14> be logged as an operational error(subject error (subject to rate-limiting).</t>
		<t>The AC-flag MUST AC-Flag <bcp14>MUST</bcp14> be preserved when the OSPFv2 Extended Prefix Opaque LSA is re-advertised into other areas.</t>
		<t>The same prefix can be advertised by multiple routers, and that and, if at least one of them sets the AC-flag AC-Flag in its advertisement, the prefix is considered as to be anycast.</t>
		<t>A prefix that is advertised by a single node and without an AC-flag AC-Flag is considered to be a node-specific prefix.</t>
		<t>Anycast prefixes SHOULD <bcp14>SHOULD</bcp14> be consistently managed throughout the network. Since an AC-flag AC-Flag set takes precedence in identifying the anycast property, stale configurations should be strictly monitored.</t>
   </section>
   <section numbered="true" toc="default">
        <name>BGP-LS Advertisement</name>
	<t><xref target="RFC9085"/> defines the Prefix Attribute Flags TLV for BGP-LS Border Gateway Protocol - Link State (BGP-LS) that carries prefix attribute flags information, and the information. The Flags field of this TLV is interpreted according to OSPFv2 <xref target="RFC7684" format="default"></xref>. Thus format="default"/>. Thus, the Flags field of the BGP-LS Prefix Attribute Flags TLV also conveys the anycast property introduced by this document.</t>
	 </section>
   <section title="YANG
   <section>
     <name>YANG Data Model"> Model</name>
      <t>
        YANG <xref target="RFC7950"></xref> target="RFC7950"/> is a data definition language
        used to define the contents of a conceptual data store
        that allows networked devices to be managed using NETCONF Network Configuration Protocol (NETCONF)
        <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>.
      </t>
      <t>
        This section defines a YANG data model that can be used to manage the usage of the OSPFv2 Anycast Property as defined in this document, which augments the OSPF YANG data model <xref target="RFC9129"/> and the YANG Data Model for Routing Management <xref target="RFC8349"/>.
      </t>
      <section title="Tree
      <section>
	<name>Tree for the YANG Data Model"> Model</name>
        <t>This document uses the graphical representation of data models per <xref target="RFC8340"/>.</t>
        <t>The following shows the tree diagram of the module:</t>
        <artwork align="left" name="" type="" alt=""><![CDATA[

<!--[rfced] FYI: we have put the YANG Tree in the "Tree for the YANG
     Data Model" section in <sourcecode> with type="yangtree". -->

        <sourcecode type="yangtree"><![CDATA[
module: ietf-ospf-anycast-flag

  augment /rt:routing/rt:control-plane-protocols
         /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
        /ospf:interfaces/ospf:interface:
    +--rw anycast-flag?   boolean

        ]]></artwork>   boolean]]></sourcecode>
      </section>
      <section title="YANG
      <section>
	<name>YANG Data Model for OSPFv2 Anycast Property Advertisement"> Advertisement</name>
        <t>The "ietf-ospf-anycast-flag" module defined in this document imports typedefs from <xref target="RFC8349"/>and target="RFC8349"/> and <xref target="RFC9129"/>.</t>

<!--[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.

-->

        <sourcecode name="ietf-ospf-anycast-flag@2026-01-14.yang" type="" name="ietf-ospf-anycast-flag@2026-05-12.yang" type="yang" markers="true"><![CDATA[
module ietf-ospf-anycast-flag {
  yang-version 1.1;
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag";
  prefix ospf-anycast-flag;

  import ietf-routing {
    prefix rt;
    reference
      "RFC 8349: A YANG Data Model for Routing
       Management (NMDA Version)";
  }
  import ietf-ospf {
    prefix ospf;
    reference
      "RFC 9129: YANG Data Model for the OSPF Protocol";
  }

  organization
    "IETF LSR - Link State Routing Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/lsr/>
     WG List:  <mailto:lsr@ietf.org>

     Author:   Ran Chen
               <mailto:chen.ran@zte.com.cn>
     Author:   Detao Zhao
               <mailto:zhao.detao@zte.com.cn>
     Author:   Peter Psenak
               <mailto:ppsenak@cisco.com>
     Author:   Ketan Talaulikar
               <mailto:ketant.ietf@gmail.com>
     Author:   Changwang Lin
               <mailto:linchangwang.04414@h3c.com>";

  description
    "This YANG module adds the support of managing an OSPFv2
     prefix as anycast.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.

     Copyright (c) 2025 2026 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     All revisions of IETF and IANA published modules can
     be found at the YANG Parameters registry group
    (https://www.iana.org/assignments/yang-parameters);

     This version of this YANG module is part of RFC XXXX; 9983;
     see the RFC itself for full legal notices.";

  revision 2026-01-14 2026-05-12 {
    description
      "Initial version";
    reference
      "RFC XXXX: 9983: OSPFv2 Anycast Property Advertisement";
  }

  identity ac-flag {
    base ospf:ospfv2-extended-prefix-flag;
    description
      "Indicates that the prefix is configured as anycast.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/ospf:ospf/"
        + "ospf:areas/ospf:area/ospf:interfaces/ospf:interface" {
    when "derived-from(/rt:routing/rt:control-plane-protocols/"
       + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')" {
      description
        "This augments the OSPFv2 interface.";
    }
    description
      "This augments OSPFv2 interface with anycast
       property advertisement.";
    leaf anycast-flag {
      type boolean;
      must "not(../anycast-flag = 'true' and "
         + "/rt:routing/rt:control-plane-protocols/"
         + "rt:control-plane-protocol/ospf:ospf/"
         + "ospf:areas/ospf:area/ospf:interfaces/"
         + "ospf:interface/ospf:node-flag = 'true')" {
        error-message "The anycast-flag and the node-flag MUST "
                    + "NOT both be set to 1 (true).";
        description
          "Ensures architectural consistency by preventing a prefix
           from being marked as both anycast and node-specific.";
      }
      default "false";
      description
        "Indicates that the prefix is an anycast address,
         if set to 1 (true).";
    }
  }
}
]]></sourcecode>
      </section>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

   <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
	 <t>This document requests allocation for
	 <t>IANA has allocated and/or registered the following registry.</t> values in their respective registries.</t>
      <section numbered="true" toc="default">
        <name>OSPFv2 Extended Prefix TLV Flags Registry</name>
      <t>This document requests
      <t>IANA has allocated the allocation of new following value in the "OSPFv2 Extended Prefix TLV Flags" registry:</t>
      <t>TBD:AC-flag
      <t>0x10: AC-Flag (Anycast Flag).</t> Flag)</t>
      </section>
      <section numbered="true" toc="default">
        <name>OSPFv2 Anycast Flag YANG Module Registry</name> Registration</name>
      <t>IANA is requested to register has registered the following URI in the "ns" registry within the "IETF XML Registry" registry group (<xref (see <xref target="RFC3688" format="default"/>):</t>
      <artwork align="left" name="" type="" alt=""><![CDATA[
URI: urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag
Registrant Contact: The IESG.
XML: N/A,
      <dl spacing="compact" newline="false">
	<dt>ID:</dt><dd>yang:ietf-ospf-anycast-flag</dd>
	<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag</dd>
	<dt>Registrant Contact:</dt><dd>The IESG</dd>
	<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace
]]></artwork> namespace</dd>
      </dl>
      <t>IANA is requested to register has registered the following YANG module in the "YANG Module Names" registry (<xref target="RFC6020" format="default"/>) within the "YANG Parameters" registry group.</t>
      <artwork align="left" name="" type="" alt=""><![CDATA[
name: ietf-ospf-anycast-flag
Maintained
      <dl spacing="compact" newline="false">
	<dt>Name:</dt><dd>ietf-ospf-anycast-flag</dd>
	<dt>Maintained by IANA?  N
namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag
prefix: ospf-anycast-flag
reference: RFC XXXX
]]></artwork> IANA?</dt><dd>N</dd>
	<dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag</dd>
	<dt>Prefix:</dt><dd>ospf-anycast-flag</dd>
	<dt>Reference:</dt><dd>RFC 9983</dd>
      </dl>
      </section>
    </section>

    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
	<section numbered="true" toc="default">
    <name>Protocol Security Considerations</name>
     <t>Procedures and protocol extensions defined in this document do not affect the OSPFv2 security model. See the "Security Considerations"section Considerations" section of <xref target="RFC7684" format="default"></xref> format="default"/> for a discussion of OSPFv2 security.</t>
	 <t>The newly introduced AC-flag, AC-Flag, which MUST <bcp14>MUST</bcp14> be either set or clear, introduces operational dependencies that impact the semantic validity of the advertised prefix. The correct semantic interpretation of the AC-flag AC-Flag relies on both router implementation support for the flag and accurate operator configuration of the anycast route. Consequently, receivers MUST <bcp14>MUST</bcp14> consider the possibility of misconfiguration or inconsistent implementation when relying on the AC-flag AC-Flag for forwarding or security decisions.</t>
	 </section>
	 <section numbered="true" toc="default">
    <name>YANG Security Considerations</name>
    <t>This section is modeled after the template described in Section 3.7 of <xref target="I-D.ietf-netmod-rfc8407bis"/>.</t> section="3.7" target="RFC9907"/>.</t>
<!--[DNE Begins] Security Boilerplate -->

     <t>The "ietf-ospf-anycast-flag" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF Network Configuration Protocol (NETCONF) <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref target="RFC8446"/>, and QUIC <xref target="RFC9000"/>) and (2) have to use mutual authentication.</t>
     <t>The Network Configuration Access Control Model (NACM) <xref target="RFC8341"/> provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.</t>

<!--[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...

-->

     <t>There is a data node defined in this YANG module that is writable/creatable/deletable (i.e., config true, which is the default). This data node can be considered sensitive or vulnerable in some network environments. 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. Specifically, the following subtree and data node have particular sensitivities/vulnerabilities:</t>
     <ul empty="true" spacing="normal">
        <li>/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/ospf-anycast-flag:anycast-flag</li>
      </ul>

     <t indent="3">/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/ospf-anycast-flag:anycast-flag</t>

     <t>As specified in Section 2, <xref target="sect-2"/>, the AC-flag AC-Flag and the N-flag MUST NOT <bcp14>MUST NOT</bcp14> both be set to 1. This rule is enforced by a "must" constraint in the YANG module to prevent configuration anomalies. The handling of such anomalies is defined in Section 2. <xref target="sect-2"/>. Modifications to this data node without proper protection could prevent interpreting the IPv4 prefix as anycast or node-specific.</t>
     <t>The readable data node in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to this data node. Specifically, the following subtree and data node have particular sensitivities/vulnerabilities:</t>
     <ul empty="true" spacing="normal">
        <li>/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/ospf-anycast-flag:anycast-flag</li>
      </ul>

     <t indent="3">/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/ospf-anycast-flag:anycast-flag</t>

     <t>Unauthorized access to the data node of this subtree can disclose specific anycast property information for OSPF prefixes on a device.</t>
     <t>There are no particularly sensitive RPC or action operations.</t>

<!--[DNE ENDS -->
	 </section>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

 <back>
    <!-- References split into informative and normative -->

   <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included files in the same
    directory as the including file. You can also define the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
        <?rfc include="reference.RFC.2119.xml"?>
        <?rfc include="reference.RFC.3688.xml"?>
        <?rfc include="reference.RFC.6020.xml"?>
	    <?rfc include="reference.RFC.7684.xml"?>
        <?rfc include="reference.RFC.7950.xml"?>
	    <?rfc include="reference.RFC.8174.xml"?>
        <?rfc include="reference.RFC.8341.xml"?>
        <?rfc include="reference.RFC.8349.xml"?>
	    <?rfc include="reference.RFC.9085.xml"?>
        <?rfc include="reference.RFC.9129.xml"?>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7684.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8349.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9085.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9129.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <?rfc include='reference.I-D.ietf-netmod-rfc8407bis'?>
		<?rfc include="reference.RFC.4252.xml"?>
        <?rfc include="reference.RFC.8340.xml"?>
        <?rfc include="reference.RFC.8446.xml"?>
        <?rfc include="reference.RFC.9000.xml"?>
		<?rfc include="reference.RFC.9513.xml"?>
		<?rfc include="reference.RFC.9352.xml"?>
		<?rfc include="reference.RFC.6241.xml"?>
		<?rfc include="reference.RFC.8040.xml"?>
        <!-- [I-D.ietf-netmod-rfc8407bis] published as RFC 9907
        -->

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9907.xml"/>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4252.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9513.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9352.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
      </references>
   </references>

   <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The numbered="false">
     <name>Acknowledgements</name>
     <t>The authors would like to thank <contact fullname="Acee Lindem"/> for aligning the terminology with existing OSPF documents and for editorial improvements. </t> improvements.</t>
   </section>

   <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <t indent="0" pn="section-appendix.b-1">This numbered="false">
      <name>Contributors</name>
      <t>This document has the following contributor:</t>
      <contact fullname="Yingzhen Qu">
        <organization showOnFrontPage="true">Futurewei
        <organization>Futurewei Technologies</organization>
        <address>
          <email>yingzhen.ietf@gmail.com</email>
        </address>
      </contact>
   </section>
    <!-- Change Log

v00 2006-03-15  EBD   Initial version

v01 2006-04-03  EBD   Moved PI location back to position 1 -
                     v3.1 of XMLmind is better with them at this location.
v02 2007-03-07  AH    removed extraneous nested_list attribute,
                     other minor corrections
v03 2007-03-09  EBD   Added comments on null IANA sections and fixed heading capitalization.
                     Modified comments around figure to reflect non-implementation of
                     figure indent control.  Put in reference using anchor="DOMINATION".
                     Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH     Major changes: shortened discussion of PIs,
                     added discussion of rfc include.
v05 2007-03-10 EBD    Added preamble to C program example to tell about ABNF and alternative
                     images. Removed meta-characters from comments (causes problems).

v06 2010-04-01 TT     Changed ipr attribute values

<!--[rfced] We had the following questions/comments related to latest ones. Changed date
     terminology use throughout the document:

a) We have updated to
                     year only, use AC-Flag consistently throughout to be consistent with match the comments. Updated
use in the IANA guidelines reference from section.
 -->

<!--[rfced] We had the I-D following questions/comments related to
     abbreviation use throughout the finished RFC.
v07 2020-01-21 HL    Converted document:

a) Please note that we have expanded abbreviations on first use.
Please review for accuracy.

-->
<!-- [rfced] Please review the template to use XML schema version 3. "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.
-->

 </back>
</rfc>