idnits 2.17.1 draft-ietf-isis-tlv-codepoints-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 14, 2014) is 3541 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 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group L. Ginsberg 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track August 14, 2014 5 Expires: February 15, 2015 7 Updates to IS-IS TLV Codepoints Registry 8 draft-ietf-isis-tlv-codepoints-02.txt 10 Abstract 12 This document recommends some editorial changes to the IANA IS-IS TLV 13 Codepoints registry to more accurately document the state of the 14 protocol. It also sets out new guidelines for Designated Experts to 15 apply when reviewing allocations from the registry. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 http://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 February 15, 2015. 40 Copyright Notice 42 Copyright (c) 2014 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 (http://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 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 2. IS Neighbor sub-TLV Registry . . . . . . . . . . . . . . . . 3 71 3. Prefix Reachability sub-TLV Registry . . . . . . . . . . . . 3 72 4. Guidance for Designated Experts . . . . . . . . . . . . . . . 3 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 78 8.2. Informational References . . . . . . . . . . . . . . . . 5 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 81 1. Introduction 83 The IS-IS TLV Codepoints registry was created by [RFC3563] and 84 extended by [RFC6233]. The assignment policy for the registry is 85 "Expert Review" as defined in [RFC5226]. As IS-IS related documents 86 are developed, the codepoints required for the protocol extensions 87 are reviewed by the Designated Experts and added to the IANA managed 88 registry. As these documents are published as RFCs, the registries 89 are updated to reference the relevant RFC. 91 In the case of TLVs supporting prefix advertisement, currently 92 separate sub-TLV registries are maintained for each TLV. These 93 registries need to be combined into a common sub-TLV registry similar 94 to what has been done for neighbor advertisement TLVs. 96 In some cases there is a need to allocate codepoints defined in 97 Internet-Drafts which seem likely to eventually gain WG approval 98 without waiting for those drafts to be published as RFCs. This can 99 be achieved using Expert Review, and this document sets out guidance 100 for the Designated Experts to apply when reviewing allocations from 101 the registry. 103 2. IS Neighbor sub-TLV Registry 105 There is an existing common sub-TLV registry for Sub-TLVs for TLV 22, 106 141, and 222. [RFC5311] defines the IS Neighbor Attribute TLV (23) 107 and the MT IS Neighbor Attribute TLV (223). Format of these TLVs is 108 identical to TLVs 22 and 222 respectively. The IS Neighbor sub-TLV 109 Registry needs to be extended to include these two TLVs. Settings 110 for inclusion of each sub-TLV are identical to the settings for TLVs 111 22 and 222 respectively. 113 3. Prefix Reachability sub-TLV Registry 115 Currently there exist separate sub-TLV registries for TLVs (135, 235, 116 236, 237). As in the case of the IS Neighbor TLVs discussed in the 117 previous section, assignment of sub-TLVs applicable to one or more of 118 these TLVs is intended to be common. Therefore the existing separate 119 sub-TLV registries need to be combined into a single registry 120 entitled "Sub-TLVs for TLVs 135, 235, 236, and 237". As existing 121 sub-TLV assignments are common to all the TLVs this represents no 122 change to the protocol - only a clearer representation of the 123 intended sub-TLV allocation strategy. Format of the registry would 124 be as shown below: 126 Type Description 135 235 236 237 Reference 127 ---- ------------ --- --- --- --- --------- 128 0 Unassigned 129 1 32-bit Administrative Tag Sub-TLV Y Y Y Y [RFC5130] 130 2 64-bit Administrative Tag Sub-TLV Y Y Y Y [RFC5130] 131 3-255 Unassigned 133 4. Guidance for Designated Experts 135 When new drafts are introduced requiring new codepoints, it is 136 advantageous to be able to allocate codepoints without waiting for 137 them to progress to RFC. The reasons this is advantageous are 138 described in [RFC7120]. However, [RFC7120] procedures for early 139 allocation do not apply to registries such as the IS-IS TLV 140 Codepoints Registry which utilize "Expert Review" allocation policy. 141 In such cases what is required is that a request be made to the 142 Designated Experts who MAY approve the assignments according to the 143 guidance that has been established for the registry concerned. 145 The following guidance applies specifically to the IS-IS TLV 146 Codepoints registry. 148 1. Application for a codepoint allocation MAY be made to the 149 Designated Experts at any time. 151 2. The Designated Experts SHOULD only consider requests that arise 152 from Internet-Drafts that have already been accepted as Working 153 Group documents or that are planned for progression as AD 154 Sponsored documents in the absence of a suitably chartered 155 Working Group. 157 3. In the case of Working Group documents, the Designated Experts 158 SHOULD check with the Working Group chairs that there is 159 consensus within the Working Group to make the allocation at this 160 time. In the case of AD Sponsored documents, the Designated 161 Experts SHOULD check with the AD for approval to make the 162 allocation at this time. 164 4. The Designated Experts SHOULD then review the assignment requests 165 on their technical merit. The Designated Experts SHOULD NOT seek 166 to overrule IETF consensus, but MAY raise issues for further 167 consideration before the assignments are made. 169 5. Once the Designated Experts have granted approval IANA will 170 update the registry marking the allocated codepoints with a 171 reference to the associated document as normal. 173 6. In the event that the document fails to progress to RFC the 174 Expiry and deallocation process defined in [RFC7120] MUST be 175 followed for the relevant code points - noting that the 176 Designated Experts perform the role assigned to Working Group 177 chairs. 179 5. IANA Considerations 181 This document provides guidance to the Designated Experts appointed 182 to manage allocation requests in the IS-IS TLV Codepoints Registry. 184 This document requires the addition of TLVs 23 and 223 to the 185 existing Sub-TLVs for TLV 22, 141, and 222 registry as described in 186 Section 2. 188 This document requires the existing sub-TLV registries for TLVs (135, 189 235, 236, 237) be combined into a single registry as described in 190 Section 3. 192 6. Security Considerations 194 This document introduces no new security issues. 196 7. Acknowledgements 198 The author wishes to thank Alia Atlas and Amanda Baber for their 199 input in defining the correct process to follow to get these changes 200 implemented. Special thanks to Adrian Farrel for crafting the text 201 in Section 4. 203 8. References 205 8.1. Normative References 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, March 1997. 210 [RFC5130] Previdi, S., Shand, M., and C. Martin, "A Policy Control 211 Mechanism in IS-IS Using Administrative Tags", RFC 5130, 212 February 2008. 214 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 215 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 216 May 2008. 218 [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, 219 "Simplified Extension of Link State PDU (LSP) Space for 220 IS-IS", RFC 5311, February 2009. 222 [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for 223 Purges", RFC 6233, May 2011. 225 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 226 Points", BCP 100, RFC 7120, January 2014. 228 8.2. Informational References 230 [RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF 231 and ISO/IEC Joint Technical Committee 1/Sub Committee 6 232 (JTC1/SC6) on IS-IS Routing Protocol Development", RFC 233 3563, July 2003. 235 Author's Address 237 Les Ginsberg 238 Cisco Systems 239 510 McCarthy Blvd. 240 Milpitas, CA 95035 241 USA 243 Email: ginsberg@cisco.com