doc: Add RFC documents

1 files changed, 279 insertions, 0 deletions

diff --git a/doc/rfc/rfc9454.txt b/doc/rfc/rfc9454.txt
new file mode 100644
index 0000000..5c83fd2
--- /dev/null
+++ b/doc/rfc/rfc9454.txt
@@ -0,0 +1,279 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                            M. Fox
+Request for Comments: 9454                                           IBM
+Updates: 2328, 4222, 4811, 5243, 5340, 5614,                   A. Lindem
+         5838                                    LabN Consulting, L.L.C.
+Category: Standards Track                                      A. Retana
+ISSN: 2070-1721                             Futurewei Technologies, Inc.
+                                                             August 2023
+
+
+                       Update to OSPF Terminology
+
+Abstract
+
+   This document updates some OSPF terminology to be in line with
+   inclusive language used in the industry.  The IETF has designated
+   "Guidance for NIST Staff on Using Inclusive Language in Documentary
+   Standards" by the US National Institute of Standards and Technology
+   (NIST) for its inclusive language guidelines.  It is intended that
+   all future OSPF documents use this revised terminology even when they
+   reference the RFCs updated by this document.
+
+   This document updates RFCs 2328, 4222, 4811, 5243, 5340, 5614, and
+   5838.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   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/rfc9454.
+
+Copyright Notice
+
+   Copyright (c) 2023 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Update to RFC 2328
+   3.  Update to RFC 4222
+   4.  Update to RFC 4811
+   5.  Update to RFC 5243
+   6.  Update to RFC 5340
+   7.  Update to RFC 5614
+   8.  Update to RFC 5838
+   9.  IANA Considerations
+   10. Security Considerations
+   11. References
+     11.1.  Normative References
+     11.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   This document updates some OSPF terminology to be in line with
+   inclusive language used in the industry.  The IETF has designated
+   "Guidance for NIST Staff on Using Inclusive Language in Documentary
+   Standards" by the US National Institute of Standards and Technology
+   (NIST) [NISTIR8366] for its inclusive language guidelines.  It is
+   intended that all future OSPF documents use this revised terminology
+   even when they reference the RFCs updated by this document.
+
+   This document updates [RFC2328], [RFC4222], [RFC4811], [RFC5243],
+   [RFC5340], [RFC5614], and [RFC5838].
+
+2.  Update to RFC 2328
+
+   The base OSPFv2 specification "OSPF Version 2" [RFC2328] defines the
+   synchronization of databases as two routers forming a "master/slave"
+   relationship.  All instances of these terms are replaced by "Leader/
+   Follower", respectively.
+
+   In the Database Description packet, the "master (MS) bit" is renamed
+   the "Leader (L) bit".
+
+   The operation of OSPFv2 is not modified.  The Leader/Follower
+   terminology and Leader (L) bit definition changes impact the
+   following sections: "The Synchronization of Databases" (Section 7.2),
+   "The Neighbor Data Structure" (Section 10), "Neighbor states"
+   (Section 10.1), "Events causing neighbor state changes"
+   (Section 10.2), "The Neighbor state machine" (Section 10.3),
+   "Receiving Database Description Packets" (Section 10.6), "Sending
+   Database Description Packets" (Section 10.8), "An Example"
+   (Section 10.10), and "The Database Description packet"
+   (Appendix A.3.3).
+
+3.  Update to RFC 4222
+
+   "Prioritized Treatment of Specific OSPF Version 2 Packets and
+   Congestion Avoidance" [RFC4222] is a Best Current Practice (BCP)
+   document.  In Appendix C, Item (2), there is an example OSFPv2 packet
+   sequence that refers to the "slave" in a database exchange; this
+   reference is renamed to "Follower".
+
+4.  Update to RFC 4811
+
+   "OSPF Out-of-Band Link State Database (LSDB) Resynchronization"
+   [RFC4811] is an Informational document.  Section 2.4 includes a
+   Database Description packet (Figure 2) and a description of the
+   attendant encoding changes for Out-of-Band Resynchronization.  In the
+   figure and the description, all instances of "MS" (when referring to
+   the Database Description packet bit) are renamed to "L".  There is
+   also a reference to "Master" in this section that is renamed to
+   "Leader".
+
+5.  Update to RFC 5243
+
+   "OSPF Database Exchange Summary List Optimization" [RFC5243] is an
+   Informational document.  The Introduction (Section 1) references
+   "Master or Slave"; this is replaced by "Leader or Follower".
+   Section 3 includes an example of the optimized database exchange.  In
+   this example, all instances of "Master" and "Slave" are renamed to
+   "Leader" and "Follower", respectively.
+
+6.  Update to RFC 5340
+
+   The base OSPFv3 specification "OSPF for IPv6" [RFC5340] defines the
+   Database Description process between two routers as one being
+   "designated to be the master and the other is the slave".  All
+   instances of these terms are replaced by "Leader/Follower",
+   respectively.
+
+   In the Database Description packet, the "Master/Slave (MS) bit" is
+   renamed the "Leader (L) bit".
+
+   The operation of OSPFv3 is not modified.  The Leader/Follower
+   terminology and Leader (L) bit definition changes impact "The
+   Database Description Packet" (Appendix A.3.3).
+
+7.  Update to RFC 5614
+
+   "Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected
+   Dominating Set (CDS) Flooding" [RFC5614] is an Experimental document.
+   "Changes to the Neighbor State Machine" (Section 7.1) contains
+   modifications to the neighbor state machine that were updated from
+   [RFC2328].  In the neighbor state machine modifications, all
+   instances of "Master" and "Slave" are renamed to "Leader" and
+   "Follower", respectively.  Additionally, all instances of "MS" (when
+   referring to the Database Description packet bit) are renamed to "L".
+   And in "Receiving Database Description Packets" (Section 7.5),
+   "master or slave" is replaced by "Leader or Follower" in the
+   parenthetical.
+
+8.  Update to RFC 5838
+
+   "Support of Address Families in OSPFv3" [RFC5838] is a Standards
+   Track document.  "Database Description Maximum Transmission Unit
+   (MTU) Specification for Non-IPv6 AFs" (Section 2.7) contains a
+   Database Description packet change figure that includes the MS bit.
+   In this figure, the "MS" field is renamed the "L" field.
+
+   Additionally, in the first paragraph of "Changes to the Hello Packet
+   Processing" (Section 2.4), the text is updated to remove the non-
+   inclusive terms pertaining to unreachability handling as follows:
+
+   |  When an OSPFv3 router does not support this specification and an
+   |  interface is configured with the Instance ID corresponding to an
+   |  IPv4 AF, packets could be routed toward this interface and
+   |  dropped.  This could happen due to misconfiguration or a router
+   |  software downgrade.  For example, an IPv4 packet could be received
+   |  on an interface not supporting IPv4 since a router that doesn't
+   |  support this specification can still include the interface in an
+   |  SPF-calculated path as long as it establishes adjacencies using
+   |  the Instance ID corresponding to the IPv4 AF.  Note that OSPFv3
+   |  Router-LSAs and Network-LSAs are AF-agnostic.
+
+9.  IANA Considerations
+
+   In the "Database Description (DD) Packet Flags" registry, IANA has
+   updated the description for value 0x01 to "Leader (L-bit)" and has
+   added this document as a reference, as shown below.
+
+   Value:  0x01
+   Description:  Leader (L-bit)
+   Reference:  [RFC2328] [RFC9454]
+
+10.  Security Considerations
+
+   This document updates the terminology used in OSPF RFCs without any
+   modification to the specifications of the protocol.  As such, the
+   security characteristics of OSPF do not change.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
+              DOI 10.17487/RFC2328, April 1998,
+              <https://www.rfc-editor.org/info/rfc2328>.
+
+   [RFC4222]  Choudhury, G., Ed., "Prioritized Treatment of Specific
+              OSPF Version 2 Packets and Congestion Avoidance", BCP 112,
+              RFC 4222, DOI 10.17487/RFC4222, October 2005,
+              <https://www.rfc-editor.org/info/rfc4222>.
+
+   [RFC4811]  Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band Link
+              State Database (LSDB) Resynchronization", RFC 4811,
+              DOI 10.17487/RFC4811, March 2007,
+              <https://www.rfc-editor.org/info/rfc4811>.
+
+   [RFC5243]  Ogier, R., "OSPF Database Exchange Summary List
+              Optimization", RFC 5243, DOI 10.17487/RFC5243, May 2008,
+              <https://www.rfc-editor.org/info/rfc5243>.
+
+   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
+              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
+              <https://www.rfc-editor.org/info/rfc5340>.
+
+   [RFC5614]  Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET)
+              Extension of OSPF Using Connected Dominating Set (CDS)
+              Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009,
+              <https://www.rfc-editor.org/info/rfc5614>.
+
+   [RFC5838]  Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
+              R. Aggarwal, "Support of Address Families in OSPFv3",
+              RFC 5838, DOI 10.17487/RFC5838, April 2010,
+              <https://www.rfc-editor.org/info/rfc5838>.
+
+11.2.  Informative References
+
+   [NISTIR8366]
+              National Institute of Standards and Technology (NIST),
+              "Guidance for NIST Staff on Using Inclusive Language in
+              Documentary Standards", NIST Interagency/Internal Report
+              (NISTIR) 8366, April 2021,
+              <https://doi.org/10.6028/NIST.IR.8366>.
+
+Acknowledgements
+
+   Thanks to Dhruv Dhody, Adrian Farrel, Erik Kline, and Barry Leiba for
+   their reviews and comments.
+
+Authors' Addresses
+
+   Mike Fox
+   IBM
+   3039 E Cornwallis Rd.
+   Research Triangle Park, NC 27709
+   United States of America
+   Email: mjfox@us.ibm.com
+
+
+   Acee Lindem
+   LabN Consulting, L.L.C.
+   301 Midenhall Way
+   Cary, NC 27513
+   United States of America
+   Email: acee.ietf@gmail.com
+
+
+   Alvaro Retana
+   Futurewei Technologies, Inc.
+   2330 Central Expressway
+   Santa Clara, CA 95050
+   United States of America
+   Email: aretana@futurewei.com