idnits 2.17.1 draft-farrel-idr-bgp-ls-registry-01.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 (July 26, 2019) is 1729 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) July 26, 2019 5 Intended status: Standards Track 6 Expires: January 27, 2020 8 Updates to the Allocation Policy for the Border Gateway Protocol - Link 9 State (BGP-LS) Parameters Registries 10 draft-farrel-idr-bgp-ls-registry-01 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." 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 27, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Guidance for Designated Experts . . . . . . . . . . . . . 3 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Normative References . . . . . . . . . . . . . . . . . . . . 4 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1. Introduction 67 Border Gateway Protocol - Link State (BGP-LS) [RFC7752] requested 68 IANA to create a registry consistent called the "Border Gateway 69 Protocol - Link State (BGP-LS) Parameters Registry" with a number of 70 sub-registries. The allocation policy applied by IANA for those 71 policies is "Specification Required" as defined in [RFC8126]. 73 The "Specification Required" policy requires evaluation of any 74 assignment request by a "Designated Expert" and guidelines for any 75 such experts are given in section 5.1 of [RFC7752]. In addition, 76 this policy requires "the values and their meanings must be 77 documented in a permanent and readily available public specification, 78 in sufficient detail so that interoperability between independent 79 implementations is possible" [RFC8126]. Further, the intention 80 behind "permanent and readily available" is that "a document can 81 reasonably be expected to be findable and retrievable long after IANA 82 assignment of the requested value" [RFC8126]. 84 It is often considered that it is the responsibility of the 85 Designated Expert to make a determination as to whether a 86 specification meets the requirement to be permanent and readily 87 publicly available. A degree of contention arises in this case 88 because Internet-Drafts are now permanently archived in the IETF&s 89 tools archive, yet each such document is marked with a piece of 90 boilerplate text as follows that brings doubt about its suitability 91 as a permanent record: 93 Internet-Drafts are draft documents valid for a maximum of six 94 months and may be updated, replaced, or obsoleted by other 95 documents at any time. It is inappropriate to use Internet-Drafts 96 as reference material or to cite them other than as "work in 97 progress." 99 Another allocation policy called "Expert Review" is defined in 100 [RFC8126]. This policy also requires Expert Review, but has no 101 requirement for a formal document. 103 All reviews by Designated Experts are guided by advice given in the 104 document that defined the registry and set the allocation policy. 106 This document updates RFC 7752 by changing the allocation policy for 107 all of the registries to "Expert Review" and updating the guidance to 108 the Expert Review. 110 2. IANA Considerations 112 IANA maintains a registry called the "Border Gateway Protocol - Link 113 State (BGP-LS) Parameters Registry". This registry contains four 114 sub-registries: 116 o BGP-LS NLRI-Types 118 o BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 119 Attribute TLVs 121 o BGP-LS Protocol-IDs 123 o BGP-LS Well-Known Instance-IDs 125 IANA is requested to change the assignment policy for each of these 126 registries to "Expert Review". 128 2.1. Guidance for Designated Experts 130 Section 5.1 of [RFC7752] gives guidance to Designated Experts. This 131 section replaces that guidance. 133 In all cases of review by the Designated Expert (DE) described here, 134 the DE is expected to check the clarity of purpose and use of the 135 requested code points. Additionally, the DE must verify that any 136 request for one of these code points has been made available for 137 review and comment within the IETF: the DE will post the request to 138 the IDR Working Gorup mailing list (or a successor mailing list 139 designated by the Area Director). If the request comes from within 140 the IETF, it should be documented in an Internet-Draft. Lastly, the 141 DE must ensure that any other request for a code point does not 142 conflict with work that is active or already published within the 143 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 and Donald Eastlake for review and comments. 174 5. Normative References 176 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 177 S. Ray, "North-Bound Distribution of Link-State and 178 Traffic Engineering (TE) Information Using BGP", RFC 7752, 179 DOI 10.17487/RFC7752, March 2016, 180 . 182 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 183 Writing an IANA Considerations Section in RFCs", BCP 26, 184 RFC 8126, DOI 10.17487/RFC8126, June 2017, 185 . 187 Author's Address 189 Adrian Farrel 190 Old Dog Consulting 192 Email: adrian@olddog.co.uk