diff options
Diffstat (limited to 'doc/rfc/rfc9029.txt')
| -rw-r--r-- | doc/rfc/rfc9029.txt | 248 |
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 |