idnits 2.17.1 draft-ietf-idr-bgp-ls-registry-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC8126, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 30, 2021) is 1121 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Group A. Farrel 3 Internet-Draft Old Dog Consulting 4 Updates: 7752 (if approved) March 30, 2021 5 Intended status: Standards Track 6 Expires: October 1, 2021 8 Updates to the Allocation Policy for the Border Gateway Protocol - Link 9 State (BGP-LS) Parameters Registries 10 draft-ietf-idr-bgp-ls-registry-06 12 Abstract 14 RFC 7752 defines Border Gateway Protocol - Link State (BGP-LS). IANA 15 created a registry consistent with that document called the "Border 16 Gateway Protocol - Link State (BGP-LS) Parameters Registry" with a 17 number of sub-registries. The allocation policy applied by IANA for 18 those registries is "Specification Required" as defined in RFC 8126. 20 This document updates RFC 7752 by changing the allocation policy for 21 all of the registries to "Expert Review" and by updating the guidance 22 to the Designated Experts. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 1, 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Guidance for Designated Experts . . . . . . . . . . . . . 3 62 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Normative References . . . . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 Border Gateway Protocol - Link State (BGP-LS) [RFC7752] requested 70 IANA to create a registry called the "Border Gateway Protocol - Link 71 State (BGP-LS) Parameters Registry" with a number of sub-registries. 72 The allocation policy applied by IANA for those registries is 73 "Specification Required" as defined in [RFC8126]. 75 The "Specification Required" policy requires evaluation of any 76 assignment request by a "Designated Expert" and guidelines for any 77 such experts are given in section 5.1 of [RFC7752]. In addition, 78 this policy requires that "the values and their meanings must be 79 documented in a permanent and readily available public specification, 80 in sufficient detail so that interoperability between independent 81 implementations is possible" [RFC8126]. Further, the intention 82 behind "permanent and readily available" is that "a document can 83 reasonably be expected to be findable and retrievable long after IANA 84 assignment of the requested value" [RFC8126]. 86 Another allocation policy called "Expert Review" is defined in 87 [RFC8126]. This policy also requires Expert Review, but has no 88 requirement for a formal document. 90 All reviews by Designated Experts are guided by advice given in the 91 document that defined the registry and set the allocation policy. 93 This document updates RFC 7752 by changing the allocation policy for 94 all of the registries to "Expert Review" and updating the guidance to 95 the Designated Experts. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 2. IANA Considerations 107 IANA maintains a registry called the "Border Gateway Protocol - Link 108 State (BGP-LS) Parameters Registry". This registry contains four 109 sub-registries: 111 o BGP-LS NLRI-Types 113 o BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 114 Attribute TLVs 116 o BGP-LS Protocol-IDs 118 o BGP-LS Well-Known Instance-IDs 120 IANA is requested to change the assignment policy for each of these 121 registries to "Expert Review". 123 2.1. Guidance for Designated Experts 125 Section 5.1 of [RFC7752] gives guidance to Designated Experts. This 126 section replaces that guidance. 128 In all cases of review by the Designated Expert (DE) described here, 129 the DE is expected to check the clarity of purpose and use of the 130 requested code points. The following points apply to the registries 131 discussed in this document: 133 1. Application for a code point allocation may be made to the 134 Designated Experts at any time, and MUST be accompanied by 135 technical documentation explaining the use of the code point. 136 Such documentation SHOULD be presented in the form of an 137 Internet-Draft, but MAY arrive in any form that can be reviewed 138 and exchanged amongst reviewers. 140 2. The Designated Experts SHOULD only consider requests that arise 141 from I-Ds that have already been accepted as Working Group 142 documents or that are planned for progression as AD Sponsored 143 documents in the absence of a suitably chartered Working Group. 145 3. In the case of Working Group documents, the Designated Experts 146 MUST check with the Working Group chairs that there is consensus 147 within the Working Group to make the allocation at this time. In 148 the case of AD Sponsored documents, the Designated Experts MUST 149 check with the AD for approval to make the allocation at this 150 time. 152 4. If the document is not adopted by the IDR Working Group (or its 153 successor), the Designated Expert MUST notify the IDR mailing 154 list (or its successor) of the request and MUST provide access to 155 the document. The Designated Expert MUST allow two weeks for any 156 response. Any comments received MUST be considered by the 157 Designated Expert as part of the subsequent step. 159 5. The Designated Experts MUST then review the assignment requests 160 on their technical merit. The Designated Experts MAY raise 161 issues related to the allocation request with the authors and on 162 the IDR (or successor) mailing list for further consideration 163 before the assignments are made. 165 6. The Designated Expert MUST ensure that any request for a code 166 point does not conflict with work that is active or already 167 published within the IETF. 169 7. Once the Designated Experts have granted approval, IANA will 170 update the registry by marking the allocated code points with a 171 reference to the associated document. 173 8. In the event that the document is a Working Group document or is 174 AD Sponsored, and that document fails to progress to publication 175 as an RFC, the Working Group chairs or AD SHOULD contact IANA to 176 coordinate about marking the code points as deprecated. A 177 deprecated code point is not marked as allocated for use and is 178 not available for allocation in a future document. The WG chairs 179 may inform IANA that a deprecated code point can be completely 180 de-allocated (i.e., made available for new allocations) at any 181 time after it has been deprecated if there is a shortage of 182 unallocated code points in the registry. 184 3. Security Considerations 186 The security consideration of [RFC7752] still apply. 188 Note that the change to the expert review guidelines makes the 189 registry and the Designated Experts slightly more vulnerable to 190 denial of service attacks through excessive and bogus requests for 191 code points. It is expected that the registry cannot be effectively 192 attacked because the Designated Experts would, themselves, fall to 193 any such attack first. Designated Experts are expected to report to 194 the IDR working group chairs and responsible Area Director if they 195 believe an attack to be in progress, and should immediately halt all 196 requests for allocation. This may temporarily block all legitimate 197 requests until mitigations have been put in place. 199 4. Acknowledgements 201 This work is based on the IANA considerations section of [RFC7752]. 202 The author thanks the people who worked on that document. 204 The author would like to be able to thank John Scudder for suggesting 205 the need for this document. 207 Thanks to John Scudder, Donald Eastlake, Ketan Talaulikar, and Alvaro 208 Retana for review, comments, and discussion. 210 Additional thanks to Gyan Mishra, Acee Lindem, Ketan Talaulikar, Les 211 Ginsberg, Bruno Decraene, Benjamin Kaduk, and Martin Vigoureux for 212 engaging in discussion on the details of this work. 214 5. Normative References 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, 218 DOI 10.17487/RFC2119, March 1997, 219 . 221 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 222 S. Ray, "North-Bound Distribution of Link-State and 223 Traffic Engineering (TE) Information Using BGP", RFC 7752, 224 DOI 10.17487/RFC7752, March 2016, 225 . 227 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 228 Writing an IANA Considerations Section in RFCs", BCP 26, 229 RFC 8126, DOI 10.17487/RFC8126, June 2017, 230 . 232 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 233 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 234 May 2017, . 236 Author's Address 237 Adrian Farrel 238 Old Dog Consulting 240 Email: adrian@olddog.co.uk