rfc9983.original   rfc9983.txt 
LSR R. Chen Internet Engineering Task Force (IETF) R. Chen
Internet-Draft D. Zhao Request for Comments: 9983 D. Zhao
Intended status: Standards Track ZTE Corporation Category: Standards Track ZTE Corporation
Expires: 23 July 2026 P. Psenak ISSN: 2070-1721 P. Psenak
K. Talaulikar K. Talaulikar
Cisco Systems Cisco Systems
C. Lin C. Lin
New H3C Technologies New H3C Technologies
19 January 2026 May 2026
OSPFv2 Anycast Property Advertisement OSPFv2 Anycast Property Advertisement
draft-ietf-lsr-anycast-flag-13
Abstract Abstract
An IP prefix may be configured as anycast and as such the same value An IP prefix may be configured as anycast and, as such, the same
can be advertised by multiple routers. It is useful for other value can be advertised by multiple routers. It is useful for other
routers to know that the advertisement is for an anycast prefix. routers to know that the advertisement is for an anycast prefix.
This document defines a new flag in the OSPFv2 Extended Prefix TLV This document defines a new flag in the OSPFv2 Extended Prefix TLV
Flags to advertise the anycast property. The document also specifies Flags to advertise the anycast property. The document also specifies
a companion YANG module for managing this function. a companion YANG module for managing this function.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 23 July 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9983.
Copyright Notice Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2. OSPFv2 Anycast Property Advertisement . . . . . . . . . . . . 3 2. OSPFv2 Anycast Property Advertisement
3. BGP-LS Advertisement . . . . . . . . . . . . . . . . . . . . 4 3. BGP-LS Advertisement
4. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 4 4. YANG Data Model
4.1. Tree for the YANG Data Model . . . . . . . . . . . . . . 4 4.1. Tree for the YANG Data Model
4.2. YANG Data Model for OSPFv2 Anycast Property 4.2. YANG Data Model for OSPFv2 Anycast Property Advertisement
Advertisement . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5.1. OSPFv2 Extended Prefix TLV Flags Registry
5.1. OSPFv2 Extended Prefix TLV Flags Registry . . . . . . . . 7 5.2. OSPFv2 Anycast Flag YANG Module Registration
5.2. OSPFv2 Anycast Flag YANG Module Registry . . . . . . . . 7 6. Security Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6.1. Protocol Security Considerations
6.1. Protocol Security Considerations . . . . . . . . . . . . 7 6.2. YANG Security Considerations
6.2. YANG Security Considerations . . . . . . . . . . . . . . 8 7. References
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References
7.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgements
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 Contributors
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
An IP prefix may be configured as anycast and as such the same value An IP prefix may be configured as anycast and, as such, the same
can be advertised by multiple routers. It is useful for other value can be advertised by multiple routers. It is useful for other
routers to know that the advertisement is for an anycast prefix. routers to know that the advertisement is for an anycast prefix.
[RFC7684] defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) [RFC7684] defines OSPFv2 Opaque Link State Advertisements (LSAs)
tuples that can be used to associate additional attributes with based on Type-Length-Value (TLV) tuples that can be used to associate
prefixes or links. The OSPFv2 Extended Prefix TLV that is contained additional attributes with prefixes or links. The OSPFv2 Extended
in the OSPFv2 Extended Prefix Opaque LSA is used to advertise Prefix TLV that is contained in the OSPFv2 Extended Prefix Opaque LSA
additional attributes associated with a prefix. is used to advertise additional attributes associated with a prefix.
Extensions related to the anycast property of prefixes have been Extensions related to the anycast property of prefixes have been
specified for IS-IS [RFC9352] and OSPFv3 [RFC9513], even though those specified for IS-IS [RFC9352] and OSPFv3 [RFC9513], even though those
documents are related to Segment Routing over IPv6, the anycast documents are related to Segment Routing over IPv6, the anycast
property applies to any IP prefix advertisement. This document property applies to any IP prefix advertisement. This document
defines a flag to advertise the anycast property for a prefix defines a flag to advertise the anycast property for a prefix
advertisement in OSPFv2 in the Flags field of the OSPFv2 Extended advertisement in OSPFv2 in the Flags field of the OSPFv2 Extended
Prefix TLV Flags (section 2.1 of [RFC7684]). The document also Prefix TLV Flags (Section 2.1 of [RFC7684]). The document also
specifies a companion YANG module for managing this function. specifies a companion YANG module for managing this function.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. OSPFv2 Anycast Property Advertisement 2. OSPFv2 Anycast Property Advertisement
An IP prefix may be configured as anycast and it is useful for other An IP prefix may be configured as anycast; it is useful for other
routers to know that the advertisement is for an anycast prefix. routers to know that the advertisement is for an anycast prefix.
In the context of the flags defined in this document, the term 'set' In the context of the flags defined in this document, the term "set"
means the bit is set to 1, and the term 'clear' means the bit is set means the bit is set to 1; "clear" means the bit is set to 0.
to 0.
A flag is introduced in OSPFv2 Extended Prefix TLV Flags [RFC7684] to A flag is introduced in the "OSPFv2 Extended Prefix TLV Flags" IANA
advertise the anycast property: registry (see [RFC7684]) to advertise the anycast property:
Value: TBD Value: 0x10
Description: Anycast Flag (AC-flag) Description: Anycast Flag (AC-Flag)
The only meaning of the AC-flag is that the prefix is intended to be The only meaning of the AC-Flag is that the prefix is intended to be
advertised by multiple nodes. advertised by multiple nodes.
When a prefix is configured as anycast, the AC-flag MUST be set. When a prefix is configured as anycast, the AC-Flag MUST be set.
Otherwise, this flag MUST be clear. Otherwise, this flag MUST be clear.
The AC-flag and the N-flag (section 2.1 of [RFC7684]) MUST NOT both The AC-Flag and the N-flag (Section 2.1 of [RFC7684]) MUST NOT both
be set. The reception of an advertisement with both the N-flag and be set. The reception of an advertisement with both the N-flag and
AC-flag set MUST be considered a configuration anomaly, and N-flag AC-Flag set MUST be considered a configuration anomaly, and the
MUST be ignored. Additionally, the detection of such a conflicting N-flag MUST be ignored. Additionally, the detection of such a
advertisement SHOULD be logged as an operational error(subject to conflicting advertisement SHOULD be logged as an operational error
rate-limiting). (subject to rate-limiting).
The AC-flag MUST be preserved when the OSPFv2 Extended Prefix Opaque The AC-Flag MUST be preserved when the OSPFv2 Extended Prefix Opaque
LSA is re-advertised into other areas. LSA is re-advertised into other areas.
The same prefix can be advertised by multiple routers, and that if at The same prefix can be advertised by multiple routers, and, if at
least one of them sets the AC-flag in its advertisement, the prefix least one of them sets the AC-Flag in its advertisement, the prefix
is considered as anycast. is considered to be anycast.
A prefix that is advertised by a single node and without an AC-flag A prefix that is advertised by a single node and without an AC-Flag
is considered a node-specific prefix. is considered to be a node-specific prefix.
Anycast prefixes SHOULD be consistently managed throughout the Anycast prefixes SHOULD be consistently managed throughout the
network. Since an AC-flag set takes precedence in identifying network. Since an AC-Flag set takes precedence in identifying the
anycast property, stale configurations should be strictly monitored. anycast property, stale configurations should be strictly monitored.
3. BGP-LS Advertisement 3. BGP-LS Advertisement
[RFC9085] defines the Prefix Attribute Flags TLV for BGP-LS that [RFC9085] defines the Prefix Attribute Flags TLV for Border Gateway
carries prefix attribute flags information, and the Flags field of Protocol - Link State (BGP-LS) that carries prefix attribute flags
this TLV is interpreted according to OSPFv2 [RFC7684]. Thus the information. The Flags field of this TLV is interpreted according to
Flags field of the BGP-LS Prefix Attribute Flags TLV also conveys the OSPFv2 [RFC7684]. Thus, the Flags field of the BGP-LS Prefix
anycast property introduced by this document. Attribute Flags TLV also conveys the anycast property introduced by
this document.
4. YANG Data Model 4. YANG Data Model
YANG [RFC7950] is a data definition language used to define the YANG [RFC7950] is a data definition language used to define the
contents of a conceptual data store that allows networked devices to contents of a conceptual data store that allows networked devices to
be managed using NETCONF [RFC6241] or RESTCONF [RFC8040]. be managed using Network Configuration Protocol (NETCONF) [RFC6241]
or RESTCONF [RFC8040].
This section defines a YANG data model that can be used to manage the This section defines a YANG data model that can be used to manage the
usage of OSPFv2 Anycast Property as defined in this document, which usage of the OSPFv2 Anycast Property as defined in this document,
augments the OSPF YANG data model [RFC9129] and the YANG Data Model which augments the OSPF YANG data model [RFC9129] and the YANG Data
for Routing Management [RFC8349]. Model for Routing Management [RFC8349].
4.1. Tree for the YANG Data Model 4.1. Tree for the YANG Data Model
This document uses the graphical representation of data models per This document uses the graphical representation of data models per
[RFC8340]. [RFC8340].
The following shows the tree diagram of the module: The following shows the tree diagram of the module:
module: ietf-ospf-anycast-flag module: ietf-ospf-anycast-flag
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
/ospf:interfaces/ospf:interface: /ospf:interfaces/ospf:interface:
+--rw anycast-flag? boolean +--rw anycast-flag? boolean
4.2. YANG Data Model for OSPFv2 Anycast Property Advertisement 4.2. YANG Data Model for OSPFv2 Anycast Property Advertisement
The "ietf-ospf-anycast-flag" module defined in this document imports The "ietf-ospf-anycast-flag" module defined in this document imports
typedefs from [RFC8349]and [RFC9129]. typedefs from [RFC8349] and [RFC9129].
<CODE BEGINS> file "ietf-ospf-anycast-flag@2026-01-14.yang" <CODE BEGINS> file "ietf-ospf-anycast-flag@2026-05-12.yang"
module ietf-ospf-anycast-flag { module ietf-ospf-anycast-flag {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag"; "urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag";
prefix ospf-anycast-flag; prefix ospf-anycast-flag;
import ietf-routing { import ietf-routing {
prefix rt; prefix rt;
reference reference
"RFC 8349: A YANG Data Model for Routing "RFC 8349: A YANG Data Model for Routing
skipping to change at page 5, line 45 skipping to change at line 226
<mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com>
Author: Ketan Talaulikar Author: Ketan Talaulikar
<mailto:ketant.ietf@gmail.com> <mailto:ketant.ietf@gmail.com>
Author: Changwang Lin Author: Changwang Lin
<mailto:linchangwang.04414@h3c.com>"; <mailto:linchangwang.04414@h3c.com>";
description description
"This YANG module adds the support of managing an OSPFv2 "This YANG module adds the support of managing an OSPFv2
prefix as anycast. prefix as anycast.
Copyright (c) 2025 IETF Trust and the persons identified as 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) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
All revisions of IETF and IANA published modules can All revisions of IETF and IANA published modules can
be found at the YANG Parameters registry group be found at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters); (https://www.iana.org/assignments/yang-parameters);
This version of this YANG module is part of RFC XXXX; This version of this YANG module is part of RFC 9983;
see the RFC itself for full legal notices."; see the RFC itself for full legal notices.";
revision 2026-01-14 { revision 2026-05-12 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: OSPFv2 Anycast Property Advertisement"; "RFC 9983: OSPFv2 Anycast Property Advertisement";
} }
identity ac-flag { identity ac-flag {
base ospf:ospfv2-extended-prefix-flag; base ospf:ospfv2-extended-prefix-flag;
description description
"Indicates that the prefix is configured as anycast."; "Indicates that the prefix is configured as anycast.";
} }
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/ospf:ospf/" + "rt:control-plane-protocol/ospf:ospf/"
skipping to change at page 7, line 13 skipping to change at line 297
description description
"Indicates that the prefix is an anycast address, "Indicates that the prefix is an anycast address,
if set to 1 (true)."; if set to 1 (true).";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
5. IANA Considerations 5. IANA Considerations
This document requests allocation for the following registry. IANA has allocated and/or registered the following values in their
respective registries.
5.1. OSPFv2 Extended Prefix TLV Flags Registry 5.1. OSPFv2 Extended Prefix TLV Flags Registry
This document requests the allocation of new value in the "OSPFv2 IANA has allocated the following value in the "OSPFv2 Extended Prefix
Extended Prefix TLV Flags" registry: TLV Flags" registry:
TBD:AC-flag (Anycast Flag). 0x10: AC-Flag (Anycast Flag)
5.2. OSPFv2 Anycast Flag YANG Module Registry 5.2. OSPFv2 Anycast Flag YANG Module Registration
IANA is requested to register the following URI in the "ns" registry IANA has registered the following URI in the "ns" registry within the
within the "IETF XML Registry" group ([RFC3688]): "IETF XML Registry" registry group (see [RFC3688]):
URI: urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag ID: yang:ietf-ospf-anycast-flag
Registrant Contact: The IESG. URI: urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag
XML: N/A, the requested URI is an XML namespace Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace
IANA is requested to register the following YANG module in the "YANG IANA has registered the following YANG module in the "YANG Module
Module Names" registry ([RFC6020]) within the "YANG Parameters" Names" registry ([RFC6020]) within the "YANG Parameters" registry
registry group. group.
name: ietf-ospf-anycast-flag Name: ietf-ospf-anycast-flag
Maintained by IANA? N Maintained by IANA? N
namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag Namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag
prefix: ospf-anycast-flag Prefix: ospf-anycast-flag
reference: RFC XXXX Reference: RFC 9983
6. Security Considerations 6. Security Considerations
6.1. Protocol Security Considerations 6.1. Protocol Security Considerations
Procedures and protocol extensions defined in this document do not Procedures and protocol extensions defined in this document do not
affect the OSPFv2 security model. See the "Security affect the OSPFv2 security model. See the "Security Considerations"
Considerations"section of [RFC7684] for a discussion of OSPFv2 section of [RFC7684] for a discussion of OSPFv2 security.
security.
The newly introduced AC-flag, which MUST be either set or clear, The newly introduced AC-Flag, which MUST be either set or clear,
introduces operational dependencies that impact the semantic validity introduces operational dependencies that impact the semantic validity
of the advertised prefix. The correct semantic interpretation of the of the advertised prefix. The correct semantic interpretation of the
AC-flag relies on both router implementation support for the flag and AC-Flag relies on both router implementation support for the flag and
accurate operator configuration of the anycast route. Consequently, accurate operator configuration of the anycast route. Consequently,
receivers MUST consider the possibility of misconfiguration or receivers MUST consider the possibility of misconfiguration or
inconsistent implementation when relying on the AC-flag for inconsistent implementation when relying on the AC-Flag for
forwarding or security decisions. forwarding or security decisions.
6.2. YANG Security Considerations 6.2. YANG Security Considerations
This section is modeled after the template described in Section 3.7 This section is modeled after the template described in Section 3.7
of [I-D.ietf-netmod-rfc8407bis]. of [RFC9907].
The "ietf-ospf-anycast-flag" YANG module defines a data model that is The "ietf-ospf-anycast-flag" YANG module defines a data model that is
designed to be accessed via YANG-based management protocols, such as designed to be accessed via YANG-based management protocols, such as
NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have to Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF
use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and [RFC8040]. These YANG-based management protocols (1) have to use a
QUIC [RFC9000]) and have to use mutual authentication. secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC
[RFC9000]) and (2) have to use mutual authentication.
The Network Configuration Access Control Model (NACM) [RFC8341] The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content. RESTCONF protocol operations and content.
There is a data node defined in this YANG module that is There is a data node defined in this YANG module that is
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). This data node can be considered sensitive or vulnerable default). This data node can be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to this data node without proper protection can have a negative and delete operations to this data node without proper protection or
effect on network operations. Specifically, the following subtree authentication can have a negative effect on network operations.
and data node have particular sensitivities/vulnerabilities: Specifically, the following subtree and data node have particular
sensitivities/vulnerabilities:
/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/ /ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/
ospf-anycast-flag:anycast-flag ospf-anycast-flag:anycast-flag
As specified in Section 2, the AC-flag and the N-flag MUST NOT both As specified in Section 2, the AC-Flag and the N-flag MUST NOT both
be set to 1. This rule is enforced by a "must" constraint in the be set to 1. This rule is enforced by a "must" constraint in the
YANG module to prevent configuration anomalies. The handling of such YANG module to prevent configuration anomalies. The handling of such
anomalies is defined in Section 2. Modifications to this data node anomalies is defined in Section 2. Modifications to this data node
without proper protection could prevent interpreting the IPv4 prefix without proper protection could prevent interpreting the IPv4 prefix
as anycast or node-specific. as anycast or node-specific.
The readable data node in this YANG module may be considered The readable data node in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to this data node. Specifically, the following subtree notification) to this data node. Specifically, the following subtree
skipping to change at page 10, line 18 skipping to change at line 448
DOI 10.17487/RFC9085, August 2021, DOI 10.17487/RFC9085, August 2021,
<https://www.rfc-editor.org/info/rfc9085>. <https://www.rfc-editor.org/info/rfc9085>.
[RFC9129] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, [RFC9129] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
"YANG Data Model for the OSPF Protocol", RFC 9129, "YANG Data Model for the OSPF Protocol", RFC 9129,
DOI 10.17487/RFC9129, October 2022, DOI 10.17487/RFC9129, October 2022,
<https://www.rfc-editor.org/info/rfc9129>. <https://www.rfc-editor.org/info/rfc9129>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-netmod-rfc8407bis]
Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
Authors and Reviewers of Documents Containing YANG Data
Models", Work in Progress, Internet-Draft, draft-ietf-
netmod-rfc8407bis-28, 5 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
rfc8407bis-28>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>. January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
skipping to change at page 11, line 15 skipping to change at line 484
[RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., [RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B.,
and Z. Hu, "IS-IS Extensions to Support Segment Routing and Z. Hu, "IS-IS Extensions to Support Segment Routing
over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352, over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352,
February 2023, <https://www.rfc-editor.org/info/rfc9352>. February 2023, <https://www.rfc-editor.org/info/rfc9352>.
[RFC9513] Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak, [RFC9513] Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak,
"OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)", "OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)",
RFC 9513, DOI 10.17487/RFC9513, December 2023, RFC 9513, DOI 10.17487/RFC9513, December 2023,
<https://www.rfc-editor.org/info/rfc9513>. <https://www.rfc-editor.org/info/rfc9513>.
[RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines
for Authors and Reviewers of Documents Containing YANG
Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907,
March 2026, <https://www.rfc-editor.org/info/rfc9907>.
Acknowledgements Acknowledgements
The authors would like to thank Acee Lindem for aligning the The authors would like to thank Acee Lindem for aligning the
terminology with existing OSPF documents and for editorial terminology with existing OSPF documents and for editorial
improvements. improvements.
Contributors Contributors
This document has the following contributor: This document has the following contributor:
 End of changes. 54 change blocks. 
133 lines changed or deleted 136 lines changed or added

This html diff was produced by rfcdiff 1.48.