idnits 2.17.1 draft-andersson-mpls-iana-registries-structure-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 2, 2020) is 1264 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) == Unused Reference: 'G-ACh-generic' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'LSP-Ping' is defined on line 417, but no explicit reference was found in the text == Unused Reference: 'Multi-Topology' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'Prot-ID' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'SPL-Labels' is defined on line 449, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G-ACh-generic' -- Possible downref: Non-RFC (?) normative reference: ref. 'G-ACh-prot-adv' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-LSP-PING' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-prot-reg' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-Sub-1-16-21' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-TLV-reg' -- Possible downref: Non-RFC (?) normative reference: ref. 'LSP-Ping' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-arch' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-code-points' -- Possible downref: Non-RFC (?) normative reference: ref. 'Multi-Topology' -- Possible downref: Non-RFC (?) normative reference: ref. 'Prot-ID' -- Possible downref: Non-RFC (?) normative reference: ref. 'SPL-Labels' -- Possible downref: Non-RFC (?) normative reference: ref. 'TLVs' Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group L. Andersson 3 Internet-Draft Bronze Dragon Consulting 4 Intended status: Standards Track November 2, 2020 5 Expires: May 6, 2021 7 MPLS IANA Registries Structure 8 draft-andersson-mpls-iana-registries-structure-00 10 Abstract 12 The structure of the MPLS IANA registries is not entirely intuitive. 13 This document proposes a clarification. The intention is to make a 14 structure that is implicit in the MPLS IANA registries clearly 15 visible. 17 This document does not change any RFC, nor are the content of any 18 registry touched. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 6, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 2 56 1.2. Terminology Used in this Document . . . . . . . . . . . . 2 57 2. MPLS IANA Registry Structure . . . . . . . . . . . . . . . . 3 58 2.1. Lack of Structure . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Implicit Structure . . . . . . . . . . . . . . . . . . . 4 60 2.3. Structure made Explicit . . . . . . . . . . . . . . . . . 5 61 3. Multiprotocol Label Switching Architecture (MPLS) . . . . . . 5 62 4. Comments on Section 3 . . . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 8.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 This document describes a re-organization of the IANA web pages that 74 hold the MPLS IANA registries [MPLS-code-points]. The intent is to 75 make the structure of the MPLS IANA registries clearer, and 76 registries and code points easier to find. 78 1.1. Requirement Language 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 82 "OPTIONAL" in this document are to be interpreted as described in BCP 83 14 [RFC2119] [RFC8174] when, and only when, they appear in all 84 capitals, as shown here. 86 1.2. Terminology Used in this Document 88 This document uses some terms that relates to IANA registries in this 89 way: 91 Top Level Registry 92 E.g. the entry to the MPLS IANA registries [MPLS-code-points] as 93 captured on the main IANA web page [IANA-prot-reg]. 94 Note: It might be that we want to call the IANA Protocol Registry 95 "Top Level", in which case we call this level "First Level 96 Registry". 98 IANA Name Space, 99 a name space is an optional grouping immediately below top level 100 registry. An example could be "Multiprotocol Label Switching 101 (MPLS) Label Switched Paths (LSPs) Ping Parameters" 102 [IANA-LSP-PING]. A name space is most often a container for 103 registries that hold code points that share some affinity. 105 IANA Registry, 106 an IANA registry holds code points, and lists the registration 107 procedures and allocation of code points these code points. One 108 example would be the "TLVs" registry [IANA-TLV-reg]. 110 IANA Sub-registry, 111 a sub-registry is used when a code point allocated in a registry 112 needs code points scoped by that or a set of code points. An 113 example of a sub-registry that holds code points for more than one 114 TLV is "Sub-TLVs for TLV Types 1, 16, and 21" [IANA-Sub-1-16-21] 116 RFC 8126 [RFC8126] discusses the terminology used to describe 117 different level registries, but in Section 2.1. also say "Regardless 118 of the terminology used, ... related registries (should) be grouped 119 together". This leaves us some freedom when it comes the 120 terminology, however if we converge on a terminology it will be used 121 for this document. 123 It is not the intent of this document to change registry names and/or 124 structure in such a way that that the "IANA Consideration" sections 125 of any RFCs need to be updated. 127 2. MPLS IANA Registry Structure 129 2.1. Lack of Structure 131 On the main IANA web page "Protocol Registries" [IANA-prot-reg] there 132 one header for MPLS code points 133 "Multiprotocol Label Switching Architecture (MPLS)" [MPLS-arch]. 134 MPLS registries (name spaces and sub-registries excluded) are listed 135 under this heading alphabetically. 137 "Guidelines for Writing an IANA Considerations Section in RFCs" 138 section 2.1 [RFC8126] stresses 140 "... document authors should pay attention to the registry 141 groupings, should request that related registries be grouped 142 together to make related registries easier to find, and, when 143 creating a new registry, should check whether that registry might 144 best be included in an existing group." 146 The listing under "Multiprotocol Label Switching Architecture (MPLS)" 147 does not seem to consider which registries and code points that 148 should be grouped together. Nor does "alphabetic order" supply 149 enough of grouping. 151 2.2. Implicit Structure 153 However, just by scratching a little bit on what actually is there in 154 the MPLS IANA registries, it becomes clear that there is an intended 155 (but not immediately visible) structure. 157 For example, starting on the MPLS IANA main page clicking on the 158 "G-ACh Advertisement Protocol Application Registry" [G-ACh-prot-adv] 159 and a page with the title 160 "Generic Associated Channel (G-ACh) Parameters" will show up. 162 This page very neatly lists all the registries that are related to 163 the G-ACh. This seems to be a good way to group registries that 164 belong together on the same page. 166 Like wise, starting on the MPLS IANA main page clicking on the "TLVs" 167 [TLVs] and a page with the title "Multiprotocol Label Switching 168 (MPLS) Label Switched Paths (LSPs) Ping Parameters" will show up. 170 This page lists all the registries that are related to LSP Ping. 172 Actually there are five such pages forming a good structure for the 173 MPLS IANA registries. Those pages are: 175 o G-ACh Advertisement Protocol Application Registry 176 Listing all code points that relates to the Generic Associated 177 Channel. 179 o MPLS Multi-Topology Identifiers 180 Listing all code points that relates to MPLS Multi-Topology. 182 o Multiprotocol Label Switching Architecture (MPLS) Identifier Types 183 Listing all code points that relates to ITU-T Q.Recommendations. 185 o Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) 186 Ping Parameters 187 Listing all code points that relates to the LSP Ping protocol. 189 o Special-Purpose Multiprotocol Label Switching (MPLS) Label Values 190 Listing all code points that relates to the Special Purpose 191 Labels. 193 2.3. Structure made Explicit 195 What is needed to meet the criteria in RFC 8126 [RFC8126] section 196 2.1. "... related registries (should) be grouped together to make 197 related registries easier to find", is to make the existing structure 198 visible from the main IANA webpage. 200 Section 3 "Multiprotocol Label Switching Architecture (MPLS)" in this 201 document outlines this explicit or "made visible" structure. 202 Section 3 is "clean", i.e. there is nothing but the text that should 203 show up on the main IANA web page. All comments has been deferred to 204 Section 4 206 3. Multiprotocol Label Switching Architecture (MPLS) 208 o Generic Associated Channel (G-ACh) Parameters 210 * MPLS Generalized Associated Channel (G-ACh) Types (including 211 Pseudowire Associated Channel Types) 213 * G-ACh Advertisement Protocol Application Registry 215 * G-ACh Advertisement Protocol: GAP TLV Objects (Application ID 216 0) 218 * G-ACh Advertisement Protocol: Ethernet Interface Parameters 220 * CC/CV MEP-ID TLV Registry 222 * Measurement Timestamp Type 224 * Loss/Delay Measurement Control Code: Query Codes 226 * Loss/Delay Measurement Control Code: Response Codes 228 * MPLS Loss/Delay Measurement TLV Object 230 * MPLS Fault OAM Message Type Registry 232 * MPLS Fault OAM Flag Registry 234 * MPLS Fault OAM TLV Registry 236 * MPLS PSC Request Registry 238 * MPLS PSC TLV Registry 240 * MPLS PSC Capability Flag Registry 241 * MPLS RTM TLV Registry 243 + MPLS RTM Sub-TLV Registry 245 * MPLS-TP DHC TLVs 247 * MPLS RPS Request Code Registry 249 o MPLS Multi-Topology Identifiers 251 * MPLS Multi-Topology Identifiers 253 o Multiprotocol Label Switching Architecture (MPLS) Identifier Types 255 * Information Field and Protocol Identifier in the Q.2941 Generic 256 Identifier 258 * Q.2957 User-to-user Signaling for the Internet Protocol 260 o Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) 261 Ping Parameters 263 * Message Types 265 * Reply Modes 267 * Return Codes 269 * TLVs 271 + Sub-TLVs for TLV Types 1, 16, and 21 273 + Sub-TLVs for TLV Type 6 275 + Sub-TLVs for TLV Type 9 277 + Sub-TLVs for TLV Type 11 279 + Sub-TLVs for TLV Type 20 281 + Sub-TLVs for TLV Type 23 283 + Sub-TLVs for TLV Type 27 285 * Measurement Timestamp Type 287 * Loss/Delay Measurement Control Code: Query Codes 288 * Loss/Delay Measurement Control Code: Response Codes 290 * MPLS Loss/Delay Measurement TLV Object 292 * Global Flags 294 * Downstream Detailed Mapping Address Type Registry 296 * Next Hop Address Type Registry 298 * Reply Path Return Codes 300 * DS Flags 302 * Multipath Types 304 * Pad Types 306 * Interface and Label Stack and Detailed Interface and Label 307 Stack Address Types 309 * Proxy Flags 311 * MPLS OAM Function Flags 313 * Protocol in the Segment ID sub-TLV 315 * Adjacency Type in the IGP-Adjacency Segment ID 317 * Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping 318 TLV 320 * LSR Capability Flags 322 * Interface Index Flags 324 o Special-Purpose Multiprotocol Label Switching (MPLS) Label Values 326 * Special-Purpose MPLS Label Values 328 * Extended Special-Purpose MPLS Label Values 330 4. Comments on Section 3 332 In Section 3 the section header matches the top level entry for MPLS 333 code points "Multiprotocol Label Switching Architecture (MPLS)" 334 [MPLS-arch] on the main IANA web page "Protocol Registries" 335 [IANA-prot-reg]. 337 The five namespace entries (G-ACh, Architecture, LSP Ping, Multi- 338 topology, and SPL are new entries to the main IANA page. The 339 registries and sub-registries should be sorted under these new 340 headers as shown in Section 3. 342 Registries for sub-TLVs (sub-registries) has not normally listed on 343 the main IANA web page for MPLS, while we see a value of having all 344 registreis listed, we believe that listing of sub-TLV registries 345 should be discussed carefully before it is done. see 347 Tentatively the following structure is proposed: 349 o Top Level Registry 350 I.e. "Multiprotocol Label Switching Architecture (MPLS)" 352 * Namespace 353 E.g. "Multiprotocol Label Switching (MPLS) Label Switched 354 Paths (LSPs) Ping Parameters" 356 + Registry 357 E.g. "TLVs" 359 - Sub-registry 360 E.g. "Sub-TLVs for TLV Types 1, 16, and 21" 362 5. Security Considerations 364 This document updates IANA registries. It also updates terminology 365 used to define, and clarifies the terminology related to, the code 366 points in the registries. The document does not change how the code- 367 points in the registries are used. This should not create any new 368 threats. 370 However, the updated terminology and the clarifications improve 371 security because it makes it more likely that implementations will be 372 consistent and harder to attack. 374 6. IANA Considerations 376 IANA is requested to update the according to this document. 378 The IANA consideration section to be detailed. 380 7. Acknowledgements 382 TBA. 384 8. References 386 8.1. Normative References 388 [G-ACh-generic] 389 "Generic Associated Channel (G-ACh) Parameters", 390 . 393 [G-ACh-prot-adv] 394 "G-ACh Advertisement Protocol Application Registry", 395 . 398 [IANA-LSP-PING] 399 "Multiprotocol Label Switching (MPLS) Label Switched Paths 400 (LSPs) Ping Parameters", 401 . 404 [IANA-prot-reg] 405 "Protocol Registries", . 407 [IANA-Sub-1-16-21] 408 "Sub-TLVs for TLV Types 1, 16, and 21", 409 . 413 [IANA-TLV-reg] 414 "TLVs", . 417 [LSP-Ping] 418 "Multiprotocol Label Switching (MPLS) Label Switched Paths 419 (LSPs) Ping Parameters", 420 . 423 [MPLS-arch] 424 "Multiprotocol Label Switching Architecture (MPLS)", 425 . 427 [MPLS-code-points] 428 "Multiprotocol Label Switching Architecture (MPLS)", 429 . 431 [Multi-Topology] 432 "MPLS Multi-Topology Identifiers", 433 . 436 [Prot-ID] "Multiprotocol Label Switching Architecture (MPLS) 437 Identifier Types", . 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, 442 DOI 10.17487/RFC2119, March 1997, 443 . 445 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 446 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 447 May 2017, . 449 [SPL-Labels] 450 "Special-Purpose Multiprotocol Label Switching (MPLS) 451 Label Values", . 454 [TLVs] "TLVs", . 457 8.2. Informative References 459 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 460 Writing an IANA Considerations Section in RFCs", BCP 26, 461 RFC 8126, DOI 10.17487/RFC8126, June 2017, 462 . 464 Author's Address 466 Loa Andersson 467 Bronze Dragon Consulting 469 Email: loa@pi.nu