idnits 2.17.1 draft-ietf-idr-bgp-ls-registry-00.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 (November 19, 2019) is 1613 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) November 19, 2019 5 Intended status: Standards Track 6 Expires: May 22, 2020 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-00 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 policies 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 May 22, 2020. 41 Copyright Notice 43 Copyright (c) 2019 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 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Guidance for Designated Experts . . . . . . . . . . . . . 3 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Normative References . . . . . . . . . . . . . . . . . . . . 4 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1. Introduction 68 Border Gateway Protocol - Link State (BGP-LS) [RFC7752] requested 69 IANA to create a registry consistent called the "Border Gateway 70 Protocol - Link State (BGP-LS) Parameters Registry" with a number of 71 sub-registries. The allocation policy applied by IANA for those 72 policies is "Specification Required" as defined in [RFC8126]. 74 The "Specification Required" policy requires evaluation of any 75 assignment request by a "Designated Expert" and guidelines for any 76 such experts are given in section 5.1 of [RFC7752]. In addition, 77 this policy requires "the values and their meanings must be 78 documented in a permanent and readily available public specification, 79 in sufficient detail so that interoperability between independent 80 implementations is possible" [RFC8126]. Further, the intention 81 behind "permanent and readily available" is that "a document can 82 reasonably be expected to be findable and retrievable long after IANA 83 assignment of the requested value" [RFC8126]. 85 It is often considered that it is the responsibility of the 86 Designated Expert to make a determination as to whether a 87 specification meets the requirement to be permanent and readily 88 publicly available. A degree of contention arises in this case 89 because Internet-Drafts are now permanently archived in the IETF&s 90 tools archive, yet each such document is marked with a piece of 91 boilerplate text as follows that brings doubt about its suitability 92 as a permanent record: 94 Internet-Drafts are draft documents valid for a maximum of six 95 months and may be updated, replaced, or obsoleted by other 96 documents at any time. It is inappropriate to use Internet-Drafts 97 as reference material or to cite them other than as "work in 98 progress." 100 Another allocation policy called "Expert Review" is defined in 101 [RFC8126]. This policy also requires Expert Review, but has no 102 requirement for a formal document. 104 All reviews by Designated Experts are guided by advice given in the 105 document that defined the registry and set the allocation policy. 107 This document updates RFC 7752 by changing the allocation policy for 108 all of the registries to "Expert Review" and updating the guidance to 109 the Designated Experts. 111 2. IANA Considerations 113 IANA maintains a registry called the "Border Gateway Protocol - Link 114 State (BGP-LS) Parameters Registry". This registry contains four 115 sub-registries: 117 o BGP-LS NLRI-Types 119 o BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 120 Attribute TLVs 122 o BGP-LS Protocol-IDs 124 o BGP-LS Well-Known Instance-IDs 126 IANA is requested to change the assignment policy for each of these 127 registries to "Expert Review". 129 2.1. Guidance for Designated Experts 131 Section 5.1 of [RFC7752] gives guidance to Designated Experts. This 132 section replaces that guidance. 134 In all cases of review by the Designated Expert (DE) described here, 135 the DE is expected to check the clarity of purpose and use of the 136 requested code points. Additionally, the DE must verify that any 137 request for one of these code points has been made available for 138 review and comment within the IETF: the DE will post the request to 139 the IDR Working Gorup mailing list (or a successor mailing list 140 designated by the IESG). If the request comes from within the IETF, 141 it should be documented in an Internet-Draft. Lastly, the DE must 142 ensure that any other request for a code point does not conflict with 143 work that is active or already published within the IETF. 145 3. Security Considerations 147 The security consideration of [RFC7752] still apply. 149 Note that the change to the expert review guidelines make the 150 registry and the Designated Experts slightly more vulnerable to 151 denial of service attacks through excessive and bogus requests for 152 code points. It is expected that the registry cannot be effectively 153 attacked because the Designated Experts would, themselves, fall to 154 any such attack first. Designated Experts are expected to report to 155 the IDR working group chairs and responsible Area Director if they 156 believe an attack to be in progress, and should immediately halt all 157 requests for allocation. This may temporarily block all legitimate 158 risks until mitigations have been put in place. 160 This change in allocation policy should not have any effect on the 161 integrity of BGP-LS since there is no change to the review 162 requirements for the work that underlies the request. 164 4. Acknowledgements 166 This work is based on the IANA considerations section of [RFC7752]. 167 The author thanks the people who worked on that document. 169 The author would like to be able to thank John Scudder for suggesting 170 the need for this document. 172 Thanks to John Scudder, Donald Eastlake, and Ketan Talaulikar for 173 review, comments, and discussion. 175 5. Normative References 177 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 178 S. Ray, "North-Bound Distribution of Link-State and 179 Traffic Engineering (TE) Information Using BGP", RFC 7752, 180 DOI 10.17487/RFC7752, March 2016, 181 . 183 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 184 Writing an IANA Considerations Section in RFCs", BCP 26, 185 RFC 8126, DOI 10.17487/RFC8126, June 2017, 186 . 188 Author's Address 189 Adrian Farrel 190 Old Dog Consulting 192 Email: adrian@olddog.co.uk