idnits 2.17.1 draft-thaler-iftype-reg-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 draft header indicates that this document updates RFC2863, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2863, updated by this document, for RFC5378 checks: 1998-08-14) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 05, 2019) is 1850 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) -- Obsolete informational reference (is this intentional?): RFC 1573 (Obsoleted by RFC 2233) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft Microsoft 4 Updates: 2863 (if approved) D. Romascanu 5 Intended status: Standards Track Independent 6 Expires: September 6, 2019 March 05, 2019 8 Guidelines and Registration Procedures for Interface Types 9 draft-thaler-iftype-reg-01 11 Abstract 13 The registration and use of interface types ("ifType" values) 14 predated the use of IANA Considerations sections and YANG modules, 15 and so confusion has arisen about the interface type allocation 16 process. This document provides updated guidelines for the 17 definition of new interface types, for consideration by those who are 18 defining, registering, or evaluating those definitions. 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 http://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 September 6, 2019. 37 Copyright Notice 39 Copyright (c) 2019 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 (http://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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Interface Sub-Layers and Sub-Types . . . . . . . . . . . . . 3 58 5. Registration . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 60 5.2. Media-specific OID-subtree assignments . . . . . . . . . 6 61 5.3. Registration Template . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 8.2. Informative References . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 The IANA IfType-MIB was originally defined in [RFC1573] as a separate 72 MIB module together with the Interfaces Group MIB (IF-MIB) module. 73 The IF-MIB module has since been updated and is currently specified 74 in [RFC2863], but this latest IF-MIB RFC no longer contains the IANA 75 IfType-MIB. Instead, the IANA IfType-MIB is now maintained as a 76 separate module. Similarly, [RFC7224] created an initial INANA 77 Interface Type YANG Module, and the current version is maintained by 78 IANA. 80 The current IANA IfType registries are in [iana-if-type], 81 [IANAifType-MIB], and [ifType]. 83 Although the ifType registry was originally defined in a MIB module, 84 the assignment and use of interface type values are not tied to MIB 85 modules or any other management mechanism. Interface type values can 86 be used as values of data model objects (MIB objects, YANG objects, 87 etc.), as parts of a unique identifier of a data model for a given 88 interface type (e.g., in an OID), or simply as values exposed by 89 local APIs or UI on a device. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in BCP 96 14 [RFC2119] [RFC8174] when, and only when, they appear in all 97 capitals, as shown here. 99 3. Problems 101 This document addresses the following issues: 103 1. As noted in Section 1, the former guidance was written with 104 wording specific to MIB modules, and accordingly some confusion 105 has resulted when using YANG modules. This document clarifies 106 that ifTypes are independent from the type of, or even existence 107 of, a data model. 109 2. The use of, and requirements around, sub-layers and sub-types are 110 not well understood even though good examples of both exist. 111 This is discussed in Section 4. 113 3. The registry is kept in the format of MIB and YANG modules, but 114 there was no process guidance written to check that updates were 115 syntactically correct, which led to the registry having syntax 116 errors that broke tools. Section 5.1 adds a validation step to 117 the documented assignment procedure. 119 4. Transmission values [ifType] have often been allocated as part of 120 ifType allocation, but no guidance exists about whether a 121 requester must ask for it or not, and the request form has no 122 such required field. As a result, IANA has asked the Designated 123 Expert to decide for each allocation, but no relevant guidance 124 for the Designated Expert has been documented. This is discussed 125 in Section 5.2. 127 5. Various documents and registries say to submit requests via 128 email, but a web form exists for submitting requests, which has 129 caused some confusion around which is to be used. This is 130 discussed in Section 6. 132 4. Interface Sub-Layers and Sub-Types 134 When multiple sub-layers exist below the network layer, each sub- 135 layer can be represented by its own row in the ifTable with its own 136 ifType, with the ifStackTable being used to identify the upward and 137 downward multiplexing relationships between rows. Section 3.1.1 of 138 [RFC2863] provides more discussion, and Section 3.1.2 of that RFC 139 provides guidance for defining interface sub-layers. More recent 140 experience shows that these guidelines are phrased in a way that is 141 now too restrictive, since at the time [RFC2863] was written, MIB 142 modules were the dominant data model. 144 This document clarifies that such guidance also applies to YANG 145 modules. 147 Some ifTypes may define sub-types. For example, the tunnel(131) 148 ifType defines sub-types, where each IANAtunnelType can have its own 149 MIB and/or YANG module with protocol-specific information, but there 150 is enough in common that some information is exposed in a generic IP 151 Tunnel MIB corresponding to the tunnel(131) ifType. 153 For requests that involve multiple sub-layers below the network 154 layer, requests MUST include (or reference) a discussion of the 155 multiplexing relationships between sub-layers, ideally with a 156 diagram. Various well-written examples exist of such definitions, 157 including [RFC3637] section 3.4.1, [RFC4087] section 3.1.1, and 158 [RFC5066] section 3.1.1. 160 Definers of sub-layers and sub-types should consider which model is 161 more appropriate for their needs. A sub-layer is generally used 162 whenever either a dynamic relationship exists (i.e., which instances 163 layer over which other instances can change over time) or a 164 multiplexing relationship exists with another sub-layer. A sub-type 165 can be used when neither of these are true, but where one interface 166 type is conceptually a subclass of another interface type, as far as 167 a management data model is concerned. 169 PROPOSED CLARIFICATION/ELABORATION: The intent of an interface type 170 or sub-type is that its definition should be sufficient to identify 171 an interoperable protocol. In some cases, a protocol might be 172 defined in a way that is not sufficient to provide interoperability 173 with other compliant implementations of that protocol. In such a 174 case, an ifType definition should discuss whether specific 175 instantiations (or profiles) of behavior should use a sub-layer model 176 (e.g., each vendor might layer the protocol over its own sub-layer 177 that provides the missing details), or a sub-type model (i.e., each 178 vendor might subclass the protocol without any layering 179 relationship). If a sub-type model is more appropriate, then the 180 data model for the protocol might include a sub-type identifier so 181 that management software can discover objects specific to the 182 subtype. In either case, such discussion is important to guide 183 definers of a data model for the more specific information (i.e., a 184 lower sub-layer or a subtype), as well as the Designated Expert that 185 must review requests for any such ifTypes or sub-types. 187 5. Registration 189 The IANA policy (using terms defined in [RFC5226]) for registration 190 is Expert Review. The role of the Designated Expert in the procedure 191 is to raise possible concerns about wider implications of proposals 192 for use and deployment of interface types. While it is recommended 193 that the responsible Area Director and the IESG take into 194 consideration the Designated Expert opinions, nothing in the 195 procedure empowers the Designated Expert to override properly 196 arrived-at IETF or working group consensus. 198 5.1. Procedures 200 Someone wishing to register a new ifType value MUST: 202 1. Check the IANA registry to see whether there is already an entry 203 that could easily satisfy the modeling and functional 204 requirements for the requested entry. If there is already such 205 an entry, use it or update the existing specification. Text in 206 an Internet-Draft, or part of some other permanently available, 207 stable specification may be written to clarify the usage of an 208 existing entry or entries for the desired purpose. 210 2. Check the IANA registry to see whether there is already some 211 other entry with the desired name. If there is already an 212 unrelated entry under the name, choose a different name. 214 3. Prepare a registration request using the template specified in 215 Section 5.3. The registration request can be contained in an 216 Internet-Draft, submitted alone, or as part of some other 217 permanently available, stable, specification. The registration 218 request can also be submitted in some other form (as part of 219 another document or as a stand-alone document), but the 220 registration request will be treated as an "IETF Contribution" 221 under the guidelines of [RFC5378]. 223 4. Submit the registration request (or pointer to document 224 containing it) to IANA at iana@iana.org or via the web form at 225 https://www.iana.org/form/iftype . 227 Upon receipt of a registration request, the following steps MUST be 228 followed: 230 1. IANA checks the submission for completeness; if required 231 information is missing or any citations are not correct, IANA 232 will reject the registration request. A registrant can resubmit 233 a corrected request if desired. 235 2. IANA requests Expert Review of the registration request against 236 the corresponding guidelines from this document. 238 3. The Designated Expert will evaluate the request against the 239 criteria. 241 4. Once the Designated Expert approves registration, IANA updates 242 [ifType], [IANAifType-MIB], and [iana-if-type] to show the 243 registration. When adding values to the IANAifType-MIB, IANA 244 should verify that the updated MIB module is syntactically 245 correct before publishing the update. There are various existing 246 tools or web sites that can be used to do this verification. 248 5. If instead the Designated Expert does not approve registration 249 (e.g., for any of the reasons in [RFC5226] section 3), a 250 registrant can resubmit a corrected request if desired, or the 251 IESG can override the Designated Expert and approve it per the 252 process in Section 5.3 of [RFC5226]. 254 5.2. Media-specific OID-subtree assignments 256 The current IANAifType-MIB notes: 258 The relationship between the assignment of ifType values and of 259 OIDs to particular media-specific MIBs is solely the purview of 260 IANA and is subject to change without notice. Quite often, a 261 media-specific MIB's OID-subtree assignment within MIB-II's 262 'transmission' subtree will be the same as its ifType value. 263 However, in some circumstances this will not be the case, and 264 implementors must not pre-assume any specific relationship between 265 ifType values and transmission subtree OIDs. 267 The following change is proposed: 269 CURRENT: For every ifType registration, the corresponding 270 transmission number value should be registered or marked "Reserved." 272 PROPOSED: For future ifType assignments, an OID-subtree assignment 273 MIB-II's 'transmission' subtree will be made with the same value. 275 RATIONALE: (1) This saves effort in the future since if a 276 transmission number is later needed, no IANA request is needed that 277 would then require another Expert Review. (2) The transmision 278 numbering space is not scarce, so there seems little need to reserve 279 the number for a different purpose than what the ifType is for. (3) 280 The Designated Expert need not review whether a transmission number 281 value should be registered when processing each ifType request, thus 282 reducing the possibility of delaying assignment of ifType values. 284 5.3. Registration Template 286 This template describes the fields that MUST be supplied in a 287 registration request suitable for adding to the registry: 289 Label for IANA ifType requested: As explained in Section 7.1.1 of 290 [RFC2578], a label for a named-number enumeration must consist of 291 one or more letters or digits, up to a maximum of 64 characters, 292 and the initial character must be a lower-case letter. (However, 293 labels longer than 32 characters are not recommended.) Note that 294 hyphens are not allowed. 296 Name of IANA ifType requested: A short description (e.g., a protocol 297 name), suitable to appear in a comment in the registry. 299 Description of the proposed use of the IANA ifType: Requesters MUST 300 include answers, either directly or via a link to some document 301 with the answers, to the following questions in the explanation of 302 the proposed use of the IANA IfType: 304 o How would IP run over your ifType? 306 o Would there be another interface sublayer between your ifType 307 and IP? 309 o Would your ifType be vendor-specific or proprietary? (If so, 310 the label MUST start with a string that shows that. For 311 example, if your company's name or acronym is xxx, then the 312 ifType label would be something like xxxSomeIfTypeLabel.) 314 o (ADDED) Would your ifType require or allow vendor-specific 315 extensions? If so, would the vendor use their own ifType in 316 sub-layer below the requested ifType, or a sub-type of the 317 ifType, or some other mechanism? 319 Reference, Internet-Draft, or Specification: A link to some document 320 is required. 322 Additional information or comments: Optionally any additional 323 comments for IANA or the Designated Expert. 325 6. IANA Considerations 327 This entire document is about IANA considerations. 329 CURRENT: The registries say to use email, but a web form exists 330 (https://www.iana.org/form/iftype), which is an apparent 331 contradiction. Should IANA require using the form? 332 Or require using email? Or accept submisions either way? 334 PROPOSED: In addition, IANA is requested to make the following 335 changes: 337 1. [IANAifType-MIB] currently says: "Requests for new values should 338 be made to IANA via email (iana&iana.org)." This should be 339 updated to instead say: "Requests for new values should be made 340 at https://www.iana.org/form/iftype or by email (iana&iana.org)." 342 2. [iana-if-type] currently says: "Requests for new values should be 343 made to IANA via email (iana&iana.org)." This should be updated 344 to instead say: "Requests for new values should be made at 345 https://www.iana.org/form/iftype or by email (iana&iana.org)." 347 7. Security Considerations 349 Since this document does not introduce any technology or protocol, 350 there are no security issues to be considered for this document 351 itself. 353 8. References 355 8.1. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, 359 DOI 10.17487/RFC2119, March 1997, . 362 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 363 Schoenwaelder, Ed., "Structure of Management Information 364 Version 2 (SMIv2)", STD 58, RFC 2578, 365 DOI 10.17487/RFC2578, April 1999, . 368 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 369 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 370 . 372 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 373 IANA Considerations Section in RFCs", RFC 5226, 374 DOI 10.17487/RFC5226, May 2008, . 377 [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights 378 Contributors Provide to the IETF Trust", BCP 78, RFC 5378, 379 DOI 10.17487/RFC5378, November 2008, . 382 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 383 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 384 May 2017, . 386 8.2. Informative References 388 [iana-if-type] 389 IANA, "iana-if-type YANG Module", February 2019, 390 . 392 [IANAifType-MIB] 393 IANA, "IANAifType-MIB", February 2019, 394 . 396 [ifType] IANA, "ifType definitions", February 2019, 397 . 400 [RFC1573] McCloghrie, K. and F. Kastenholz, "Evolution of the 401 Interfaces Group of MIB-II", RFC 1573, 402 DOI 10.17487/RFC1573, January 1994, . 405 [RFC3637] Heard, C., Ed., "Definitions of Managed Objects for the 406 Ethernet WAN Interface Sublayer", RFC 3637, 407 DOI 10.17487/RFC3637, September 2003, . 410 [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, 411 DOI 10.17487/RFC4087, June 2005, . 414 [RFC5066] Beili, E., "Ethernet in the First Mile Copper (EFMCu) 415 Interfaces MIB", RFC 5066, DOI 10.17487/RFC5066, November 416 2007, . 418 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 419 RFC 7224, DOI 10.17487/RFC7224, May 2014, 420 . 422 Authors' Addresses 424 David Thaler 425 Microsoft 427 EMail: dthaler@microsoft.com 429 Dan Romascanu 430 Independent 432 EMail: dromasca@gmail.com