doc: Add RFC documents

1 files changed, 248 insertions, 0 deletions

diff --git a/doc/rfc/rfc9029.txt b/doc/rfc/rfc9029.txt
new file mode 100644
index 0000000..e979e36
--- /dev/null
+++ b/doc/rfc/rfc9029.txt
@@ -0,0 +1,248 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         A. Farrel
+Request for Comments: 9029                            Old Dog Consulting
+Updates: 7752                                                  June 2021
+Category: Standards Track                                               
+ISSN: 2070-1721
+
+
+Updates to the Allocation Policy for the Border Gateway Protocol - Link
+                  State (BGP-LS) Parameters Registries
+
+Abstract
+
+   RFC 7752 defines the Border Gateway Protocol - Link State (BGP-LS).
+   IANA created a registry consistent with that document called "Border
+   Gateway Protocol - Link State (BGP-LS) Parameters" with a number of
+   subregistries.  The allocation policy applied by IANA for those
+   registries is "Specification Required", as defined in RFC 8126.
+
+   This document updates RFC 7752 by changing the allocation policy for
+   all of the registries to "Expert Review" and by updating the guidance
+   to the designated experts.
+
+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/rfc9029.
+
+Copyright Notice
+
+   Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Requirements Language
+   2.  IANA Considerations
+     2.1.  Guidance for Designated Experts
+   3.  Security Considerations
+   4.  Normative References
+   Acknowledgements
+   Author's Address
+
+1.  Introduction
+
+   "North-Bound Distribution of Link-State and Traffic Engineering (TE)
+   Information Using BGP" [RFC7752] requested IANA to create a registry
+   called "Border Gateway Protocol - Link State (BGP-LS) Parameters"
+   with a number of subregistries.  The allocation policy applied by
+   IANA for those registries is "Specification Required", as defined in
+   [RFC8126].
+
+   The "Specification Required" policy requires evaluation of any
+   assignment request by a "designated expert", and guidelines for any
+   such experts are given in Section 5.1 of [RFC7752].  In addition,
+   this policy requires that "the values and their meanings must be
+   documented in a permanent and readily available public specification,
+   in sufficient detail so that interoperability between independent
+   implementations is possible" [RFC8126].  Further, the intention
+   behind "permanent and readily available" is that "a document can
+   reasonably be expected to be findable and retrievable long after IANA
+   assignment of the requested value" [RFC8126].
+
+   Another allocation policy called "Expert Review" is defined in
+   [RFC8126].  This policy also requires Expert Review but has no
+   requirement for a formal document.
+
+   All reviews by designated experts are guided by advice given in the
+   document that defined the registry and set the allocation policy.
+
+   This document updates [RFC7752] by changing the allocation policy for
+   all of the registries to "Expert Review" and updating the guidance to
+   the designated experts.
+
+1.1.  Requirements Language
+
+   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 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  IANA Considerations
+
+   IANA maintains a registry called "Border Gateway Protocol - Link
+   State (BGP-LS) Parameters".  This registry contains four
+   subregistries:
+
+   *  BGP-LS NLRI-Types
+
+   *  BGP-LS Protocol-IDs
+
+   *  BGP-LS Well-Known Instance-IDs
+
+   *  BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
+      Attribute TLVs
+
+   IANA has changed the assignment policy for each of these registries
+   to "Expert Review".
+
+   IANA has also added this document as a reference for the registries
+   mentioned above.
+
+2.1.  Guidance for Designated Experts
+
+   Section 5.1 of [RFC7752] gives guidance to designated experts.  This
+   section replaces that guidance.
+
+   In all cases of review by the designated expert described here, the
+   designated expert is expected to check the clarity of purpose and use
+   of the requested code points.  The following points apply to the
+   registries discussed in this document:
+
+   1.  Application for a code point allocation may be made to the
+       designated experts at any time and MUST be accompanied by
+       technical documentation explaining the use of the code point.
+       Such documentation SHOULD be presented in the form of an
+       Internet-Draft but MAY arrive in any form that can be reviewed
+       and exchanged amongst reviewers.
+
+   2.  The designated experts SHOULD only consider requests that arise
+       from Internet-Drafts that have already been accepted as working
+       group documents or that are planned for progression as AD-
+       Sponsored documents in the absence of a suitably chartered
+       working group.
+
+   3.  In the case of working group documents, the designated experts
+       MUST check with the working group chairs that there is consensus
+       within the working group to make the allocation at this time.  In
+       the case of AD-Sponsored documents, the designated experts MUST
+       check with the AD for approval to make the allocation at this
+       time.
+
+   4.  If the document is not adopted by the IDR Working Group (or its
+       successor), the designated expert MUST notify the IDR mailing
+       list (or its successor) of the request and MUST provide access to
+       the document.  The designated expert MUST allow two weeks for any
+       response.  Any comments received MUST be considered by the
+       designated expert as part of the subsequent step.
+
+   5.  The designated experts MUST then review the assignment requests
+       on their technical merit.  The designated experts MAY raise
+       issues related to the allocation request with the authors and on
+       the IDR (or successor) mailing list for further consideration
+       before the assignments are made.
+
+   6.  The designated expert MUST ensure that any request for a code
+       point does not conflict with work that is active or already
+       published within the IETF.
+
+   7.  Once the designated experts have granted approval, IANA will
+       update the registry by marking the allocated code points with a
+       reference to the associated document.
+
+   8.  In the event that the document is a working group document or is
+       AD Sponsored, and that document fails to progress to publication
+       as an RFC, the working group chairs or AD SHOULD contact IANA to
+       coordinate about marking the code points as deprecated.  A
+       deprecated code point is not marked as allocated for use and is
+       not available for allocation in a future document.  The WG chairs
+       may inform IANA that a deprecated code point can be completely
+       deallocated (i.e., made available for new allocations) at any
+       time after it has been deprecated if there is a shortage of
+       unallocated code points in the registry.
+
+3.  Security Considerations
+
+   The security considerations described in Section 8 of [RFC7752] still
+   apply.
+
+   Note that the change to the Expert Review guidelines makes the
+   registry and the designated experts slightly more vulnerable to
+   denial-of-service attacks through excessive and bogus requests for
+   code points.  It is expected that the registry cannot be effectively
+   attacked because the designated experts would, themselves, fall to
+   any such attack first.  Designated experts are expected to report to
+   the IDR Working Group chairs and responsible Area Director if they
+   believe an attack to be in progress and should immediately halt all
+   requests for allocation.  This may temporarily block all legitimate
+   requests until mitigations have been put in place.
+
+4.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
+              S. Ray, "North-Bound Distribution of Link-State and
+              Traffic Engineering (TE) Information Using BGP", RFC 7752,
+              DOI 10.17487/RFC7752, March 2016,
+              <https://www.rfc-editor.org/info/rfc7752>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+Acknowledgements
+
+   This work is based on the IANA Considerations described in Section 5
+   of [RFC7752].  The author thanks the people who worked on that
+   document.
+
+   The author would like to thank John Scudder for suggesting the need
+   for this document.
+
+   Thanks to John Scudder, Donald Eastlake 3rd, Ketan Talaulikar, and
+   Alvaro Retana for their review, comments, and discussion.
+
+   Additional thanks to Gyan Mishra, Acee Lindem, Ketan Talaulikar, Les
+   Ginsberg, Bruno Decraene, Benjamin Kaduk, and Martin Vigoureux for
+   engaging in discussion on the details of this work.
+
+Author's Address
+
+   Adrian Farrel
+   Old Dog Consulting
+
+   Email: adrian@olddog.co.uk