idnits 2.17.1 draft-thaler-iftype-reg-05.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 (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 (October 03, 2019) is 1664 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 informational reference (is this intentional?): RFC 1573 (Obsoleted by RFC 2233) -- Obsolete informational reference (is this intentional?): RFC 2667 (Obsoleted by RFC 4087) Summary: 0 errors (**), 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: April 5, 2020 October 03, 2019 8 Guidelines and Registration Procedures for Interface Types and Tunnel 9 Types 10 draft-thaler-iftype-reg-05 12 Abstract 14 The registration and use of interface types ("ifType" values) 15 predated the use of IANA Considerations sections and YANG modules, 16 and so confusion has arisen about the interface type allocation 17 process. Tunnel types were then added later, with the same 18 requirements and allocation policy as interface types. This document 19 updates RFC 2863, and provides updated guidelines for the definition 20 of new interface types and tunnel types, for consideration by those 21 who are defining, registering, or evaluating those definitions. 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 April 5, 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 (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 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Interface Sub-Layers and Sub-Types . . . . . . . . . . . . . 4 61 4.1. Alternate Values . . . . . . . . . . . . . . . . . . . . 5 62 5. Available Formats . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Registration . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 7 65 6.2. Media-specific OID-subtree assignments . . . . . . . . . 8 66 6.3. Registration Template . . . . . . . . . . . . . . . . . . 9 67 6.3.1. ifType . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.3.2. tunnelType . . . . . . . . . . . . . . . . . . . . . 10 69 7. Submitting Requests . . . . . . . . . . . . . . . . . . . . . 11 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 10.2. Informative References . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 The IANA IfType-MIB was originally defined in [RFC1573] as a separate 80 MIB module together with the Interfaces Group MIB (IF-MIB) module. 81 The IF-MIB module has since been updated and is currently specified 82 in [RFC2863], but this latest IF-MIB RFC no longer contains the IANA 83 IfType-MIB. Instead, the IANA IfType-MIB is now maintained as a 84 separate module. Similarly, [RFC7224] created an initial IANA 85 Interface Type YANG Module, and the current version is maintained by 86 IANA. 88 The current IANA IfType registry is at [ifType-registry], with the 89 same values also appearing in [yang-if-type], and the IANAifType 90 textual convention at [IANAifType-MIB]. 92 Although the ifType registry was originally defined in a MIB module, 93 the assignment and use of interface type values are not tied to MIB 94 modules or any other management mechanism. Interface type values can 95 be used as values of data model objects (MIB objects, YANG objects, 96 etc.), as parts of a unique identifier of a data model for a given 97 interface type (e.g., in an OID), or simply as values exposed by 98 local APIs or UI on a device. 100 The TUNNEL-MIB was then defined in [RFC2667] (now obsoleted by 101 [RFC4087]) which created a tunnelType registry ([tunnelType-registry] 102 and the IANAtunnelType textual convention at [IANAifType-MIB]) and 103 defined the assignment policy for tunnelType values to always be 104 identical to the policy for assigning ifType values. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. Problems 116 This document addresses the following issues: 118 1. As noted in Section 1, the former guidance was written with 119 wording specific to MIB modules, and accordingly some confusion 120 has resulted when using YANG modules. This document clarifies 121 that ifTypes and tunnelTypes are independent from the type of, or 122 even existence of, a data model. 124 2. The use of, and requirements around, sub-layers and sub-types are 125 not well understood even though good examples of both exist. 126 This is discussed in Section 4. 128 3. Since the ifType and tunnelType registries were originally 129 defined, and are still retrievable, in the format of MIB modules 130 (in addition to other formats), confusion arose when adding YANG 131 modules as another format, as to whether each format is a 132 separate registry. This is discussed in Section 5. 134 4. The registries are retrievable in the format of MIB and YANG 135 modules, but there was no process guidance written to check that 136 those formats were syntactically correct as updates were made, 137 which led to the registry having syntax errors that broke tools. 138 Section 6.1 adds a validation step to the documented assignment 139 procedure. 141 5. Transmission values [transmission-registry] have often been 142 allocated as part of ifType allocation, but no guidance exists 143 about whether a requester must ask for it or not, and the request 144 form has no such required field. As a result, IANA has asked the 145 Designated Expert to decide for each allocation, but no relevant 146 guidance for the Designated Expert has been documented. This is 147 remedied in Section 6.2. 149 6. Various documents and registries said to submit requests via 150 email, but a web form exists for submitting requests, which 151 caused some confusion around which is to be used. This is 152 discussed in Section 7. 154 4. Interface Sub-Layers and Sub-Types 156 When multiple sub-layers exist below the network layer, each sub- 157 layer can be represented by its own row in the ifTable with its own 158 ifType, with the ifStackTable being used to identify the upward and 159 downward multiplexing relationships between rows. Section 3.1.1 of 160 [RFC2863] provides more discussion, and Section 3.1.2 of that RFC 161 provides guidance for defining interface sub-layers. More recent 162 experience shows that these guidelines are phrased in a way that is 163 now too restrictive, since at the time [RFC2863] was written, MIB 164 modules were the dominant data model. 166 This document clarifies that such guidance also applies to YANG 167 modules. 169 Some ifTypes may define sub-types. For example, the tunnel(131) 170 ifType defines sub-types, where each tunnelType can have its own MIB 171 and/or YANG module with protocol-specific information, but there is 172 enough in common that some information is exposed in a generic IP 173 Tunnel MIB corresponding to the tunnel(131) ifType. 175 For requests that involve multiple sub-layers below the network 176 layer, requests MUST include (or reference) a discussion of the 177 multiplexing relationships between sub-layers, ideally with a 178 diagram. Various well-written examples exist of such definitions, 179 including [RFC3637] section 3.4.1, [RFC4087] section 3.1.1, and 180 [RFC5066] section 3.1.1. 182 Definers of sub-layers and sub-types should consider which model is 183 more appropriate for their needs. A sub-layer is generally used 184 whenever either a dynamic relationship exists (i.e., which instances 185 layer over which other instances can change over time) or a 186 multiplexing relationship exists with another sub-layer. A sub-type 187 can be used when neither of these are true, but where one interface 188 type is conceptually a subclass of another interface type, as far as 189 a management data model is concerned. 191 In general, the intent of an interface type or sub-type is that its 192 definition should be sufficient to identify an interoperable 193 protocol. In some cases, however, a protocol might be defined in a 194 way that is not sufficient to provide interoperability with other 195 compliant implementations of that protocol. In such a case, an 196 ifType definition should discuss whether specific instantiations (or 197 profiles) of behavior should use a sub-layer model (e.g., each vendor 198 might layer the protocol over its own sub-layer that provides the 199 missing details), or a sub-type model (i.e., each vendor might 200 subclass the protocol without any layering relationship). If a sub- 201 type model is more appropriate, then the data model for the protocol 202 might include a sub-type identifier so that management software can 203 discover objects specific to the subtype. In either case, such 204 discussion is important to guide definers of a data model for the 205 more specific information (i.e., a lower sub-layer or a subtype), as 206 well as the Designated Expert that must review requests for any such 207 ifTypes or sub-types. 209 4.1. Alternate Values 211 Another design decision is whether to reuse an existing ifType or 212 tunnelType value, possibly using a sub-type or sub-layer model for 213 refinements, or to use a different value for a new mechanism. 215 If there is already an entry that could easily satisfy the modeling 216 and functional requirements for the requested entry, it should be 217 reused so that applications and tools that use the existing value can 218 be used without changes. If however, the modeling and functional 219 requirements are significantly different enough such that having 220 existing applications and tools use the existing value would be seen 221 as a problem, a new value should be used. 223 For example, originally multiple ifType values were used for 224 different flavors of Ethernet (ethernetCsmacd(6), iso88023Csmacd(7), 225 fastEther(62), etc.), typically because they were registered by 226 multiple vendors. [RFC3635] then deprecated all but 227 ethernetCsmacd(6), since using different values was seen as 228 problematic since all were functionally similar. 230 As another example, the Teredo tunnel protocol [RFC4380] encapsulates 231 packets over UDP, and a udp(8) tunnelType value was defined in 232 [RFC2667], with the description "The value UDP indicates that the 233 payload packet is encapsulated within a normal UDP packet (e.g., RFC 234 1234)." However, the protocol model is quite different between 235 [RFC1234] and Teredo. For example, [RFC1234] supports encapsulation 236 of multicast/broadcast traffic whereas Teredo does not. As such, it 237 would be more confusing to applications and tools to represent them 238 using the same tunnel type, and so [RFC4087] defined a new value for 239 Teredo. 241 In summary, definers of new interface or tunnel mechanisms should use 242 a new ifType or tunnelType value rather than reusing an existing 243 value when key aspects such as the header format or the link model 244 (point-to-point, non-broadcast multi-access, broadcast capable multi- 245 access, unidirectional broadcast, etc.) are significantly different 246 from existing values, but reuse the same value when the differences 247 can be expressed in terms of differing values of existing objects, 248 other than ifType/tunnelType, in the standard YANG or MIB module. 250 5. Available Formats 252 Many registries are available in multiple formats. For example, XML, 253 HTML, CSV, and Plain text are common formats in which many registries 254 are available. This document clarifies that the [IANAifType-MIB], 255 [yang-if-type], and [yang-tunnel-type] MIB and YANG modules are 256 merely additional formats in which the ifType and tunnelType 257 registries are available. The MIB and YANG modules are not separate 258 registries, and the same values are always present in all formats of 259 the same registry. 261 The confusion stemmed in part from the fact that the IANA "Protocol 262 Registries" [protocol-registries] listed the YANG and MIB module 263 formats separately, as if they were separate registries. However, 264 the entries for the yang-if-type and iana-tunnel-type YANG modules 265 said "See ifType definitions registry." and "See tunnelType registry 266 (mib-2.interface.ifTable.ifEntry.ifType.tunnelType)." respectively, 267 although the entry for the IANAifType-MIB had no such note. 269 This document clarifies the relationship for the ifType and 270 tunnelType registries with the following actions: 272 1. Add the following note to the entry for the IANAifType-MIB at 273 [protocol-registries]: "This is one of the available formats of 274 the ifType and tunnelType registries." 276 2. Change the note on the entry for the iana-if-type YANG module at 277 [protocol-registries] to read: "This is one of the available 278 formats of the ifType registry." 280 3. Change the note on the entry for the iana-tunnel-type YANG module 281 at [protocol-registries] to read: "This is one of the available 282 formats of the tunnelType registry." 284 4. Create a section for "Interface Parameters" at 285 [protocol-registries], with entries for "Interface Types 286 (ifType)" [ifType-registry], "Tunnel Types (tunnelType)" 287 [tunnelType-registry], and "Transmission Values" 288 [transmission-registry]. 290 5. Update the ifType definitions registry [ifType-registry] to list 291 MIB [IANAifType-MIB] and YANG [yang-if-type] as Available 292 Formats. 294 6. Update the tunnelType definitions registry [tunnelType-registry] 295 to list MIB [IANAifType-MIB] and YANG [yang-tunnel-type] as 296 Available Formats, and change the title to "tunnelType 297 Definitions" for consistency with the [ifType-registry] title. 299 7. Replace the [yang-if-type] page with the YANG module content, 300 rather than having a page that itself claims to have multiple 301 Available Formats. 303 8. Replace the [yang-tunnel-type] page with the YANG module content, 304 rather than having a page that itself claims to have multiple 305 Available Formats. 307 6. Registration 309 The IANA policy (using terms defined in [RFC8126]) for registration 310 is Expert Review, for both Interface Types and Tunnel Types. The 311 role of the Designated Expert in the procedure is to raise possible 312 concerns about wider implications of proposals for use and deployment 313 of interface types. While it is recommended that the responsible 314 Area Director and the IESG take into consideration the Designated 315 Expert opinions, nothing in the procedure empowers the Designated 316 Expert to override properly arrived-at IETF or working group 317 consensus. 319 6.1. Procedures 321 Someone wishing to register a new ifType or tunnelType value MUST: 323 1. Check the IANA registry to see whether there is already an entry 324 that could easily satisfy the modeling and functional 325 requirements for the requested entry. If there is already such 326 an entry, use it or update the existing specification. Text in 327 an Internet-Draft, or part of some other permanently available, 328 stable specification may be written to clarify the usage of an 329 existing entry or entries for the desired purpose. 331 2. Check the IANA registry to see whether there is already some 332 other entry with the desired name. If there is already an 333 unrelated entry under the name, choose a different name. 335 3. Prepare a registration request using the template specified in 336 Section 6.3. The registration request can be contained in an 337 Internet-Draft, submitted alone, or as part of some other 338 permanently available, stable, specification. The registration 339 request can also be submitted in some other form (as part of 340 another document or as a stand-alone document), but the 341 registration request will be treated as an "IETF Contribution" 342 under the guidelines of [RFC5378]. 344 4. Submit the registration request (or pointer to document 345 containing it) to IANA at iana@iana.org or (if requesting an 346 ifType) via the web form at https://www.iana.org/form/iftype . 348 Upon receipt of a registration request, the following steps MUST be 349 followed: 351 1. IANA checks the submission for completeness; if required 352 information is missing or any citations are not correct, IANA 353 will reject the registration request. A registrant can resubmit 354 a corrected request if desired. 356 2. IANA requests Expert Review of the registration request against 357 the corresponding guidelines from this document. 359 3. The Designated Expert will evaluate the request against the 360 criteria. 362 4. Once the Designated Expert approves registration, IANA updates 363 [ifType-registry], [IANAifType-MIB], and [yang-if-type] to show 364 the registration for an Interface Type, or [tunnelType-registry], 365 [IANAifType-MIB], and [yang-tunnel-type] to show the registration 366 for a Tunnel Type. When adding values, IANA should verify that 367 the updated MIB module and YANG module formats are syntactically 368 correct before publishing the update. There are various existing 369 tools or web sites that can be used to do this verification. 371 5. If instead the Designated Expert does not approve registration 372 (e.g., for any of the reasons in [RFC8126] section 3), a 373 registrant can resubmit a corrected request if desired, or the 374 IESG can override the Designated Expert and approve it per the 375 process in Section 5.3 of [RFC8126]. 377 6.2. Media-specific OID-subtree assignments 379 The current IANAifType-MIB notes: 381 The relationship between the assignment of ifType values and of 382 OIDs to particular media-specific MIBs is solely the purview of 383 IANA and is subject to change without notice. Quite often, a 384 media-specific MIB's OID-subtree assignment within MIB-II's 385 'transmission' subtree will be the same as its ifType value. 387 However, in some circumstances this will not be the case, and 388 implementors must not pre-assume any specific relationship between 389 ifType values and transmission subtree OIDs. 391 The following change is to be made: 393 OLD: For every ifType registration, the corresponding transmission 394 number value should be registered or marked "Reserved." 396 NEW: For future ifType assignments, an OID-subtree assignment MIB- 397 II's 'transmission' subtree will be made with the same value. 399 Rationale: (1) This saves effort in the future since if a 400 transmission number is later needed, no IANA request is needed that 401 would then require another Expert Review. (2) The transmision 402 numbering space is not scarce, so there seems little need to reserve 403 the number for a different purpose than what the ifType is for. (3) 404 The Designated Expert need not review whether a transmission number 405 value should be registered when processing each ifType request, thus 406 reducing the possibility of delaying assignment of ifType values. (4) 407 There is no case on record where allocating the same value could have 408 caused any problem. 410 6.3. Registration Template 412 6.3.1. ifType 414 The following template describes the fields that MUST be supplied in 415 a registration request suitable for adding to the ifType registry: 417 Label for IANA ifType requested: As explained in Section 7.1.1 of 418 [RFC2578], a label for a named-number enumeration must consist of 419 one or more letters or digits, up to a maximum of 64 characters, 420 and the initial character must be a lower-case letter. (However, 421 labels longer than 32 characters are not recommended.) Note that 422 hyphens are not allowed. 424 Name of IANA ifType requested: A short description (e.g., a protocol 425 name), suitable to appear in a comment in the registry. 427 Description of the proposed use of the IANA ifType: Requesters MUST 428 include answers, either directly or via a link to some document 429 with the answers, to the following questions in the explanation of 430 the proposed use of the IANA IfType: 432 o How would IP run over your ifType? 433 o Would there be another interface sublayer between your ifType 434 and IP? 436 o Would your ifType be vendor-specific or proprietary? (If so, 437 the label MUST start with a string that shows that. For 438 example, if your company's name or acronym is xxx, then the 439 ifType label would be something like xxxSomeIfTypeLabel.) 441 o Would your ifType require or allow vendor-specific extensions? 442 If so, would the vendor use their own ifType in a sub-layer 443 below the requested ifType, or a sub-type of the ifType, or 444 some other mechanism? 446 Reference, Internet-Draft, or Specification: A link to some document 447 is required. 449 Additional information or comments: Optionally any additional 450 comments for IANA or the Designated Expert. 452 6.3.2. tunnelType 454 Prior to this document, no form existed for tunnelType (and new 455 tunnelType requests did not need to use the ifType form that did 456 exist). This document therefore specifies a tunnelType form. 458 The following template describes the fields that MUST be supplied in 459 a registration request suitable for adding to the tunnelType 460 registry: 462 Label for IANA tunnelType requested: As explained in Section 7.1.1 463 of [RFC2578], a label for a named-number enumeration must consist 464 of one or more letters or digits, up to a maximum of 64 465 characters, and the initial character must be a lower-case letter. 466 (However, labels longer than 32 characters are not recommended.) 467 Note that hyphens are not allowed. 469 Name of IANA tunnelType requested: A short description (e.g., a 470 protocol name), suitable to appear in a comment in the registry. 472 Description of the proposed use of the IANA tunnelType: Requesters 473 MUST include answers, either directly or via a link to some 474 document with the answers, to the following questions in the 475 explanation of the proposed use of the IANA tunnelType: 477 o How would IP run over your tunnelType? 479 o Would there be another interface sublayer between your 480 tunnelType and IP? 482 o Would your tunnelType be vendor-specific or proprietary? (If 483 so, the label MUST start with a string that shows that. For 484 example, if your company's name or acronym is xxx, then the 485 tunnelType label would be something like xxxSomeIfTypeLabel.) 487 o Would your tunnelType require or allow vendor-specific 488 extensions? If so, would the vendor use their own tunnelType 489 in a sub-layer below the requested tunnelType, or some sort of 490 sub-type of the tunnelType, or some other mechanism? 492 Reference, Internet-Draft, or Specification: A link to some document 493 is required. 495 Additional information or comments: Optionally any additional 496 comments for IANA or the Designated Expert. 498 7. Submitting Requests 500 At the time of this writing, [IANAifType-MIB] said: "Requests for new 501 values should be made to IANA via email (iana&iana.org)." However, a 502 web form exists (https://www.iana.org/form/iftype), which is an 503 apparent contradiction, but submissions either way are accepted. 505 IANA is requested to update the MIB module to instead say: "Interface 506 types must not be directly added to the IANAifType-MIB MIB module. 507 They must instead be added to the "ifType definitions" registry at 508 [ifType-registry]." 510 (Note that [yang-if-type] was previously updated with this language.) 512 8. IANA Considerations 514 This entire document is about IANA considerations. 516 9. Security Considerations 518 Since this document does not introduce any technology or protocol, 519 there are no security issues to be considered for this document 520 itself. 522 10. References 524 10.1. Normative References 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, 528 DOI 10.17487/RFC2119, March 1997, . 531 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 532 Schoenwaelder, Ed., "Structure of Management Information 533 Version 2 (SMIv2)", STD 58, RFC 2578, 534 DOI 10.17487/RFC2578, April 1999, . 537 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 538 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 539 . 541 [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights 542 Contributors Provide to the IETF Trust", BCP 78, RFC 5378, 543 DOI 10.17487/RFC5378, November 2008, . 546 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 547 Writing an IANA Considerations Section in RFCs", BCP 26, 548 RFC 8126, DOI 10.17487/RFC8126, June 2017, 549 . 551 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 552 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 553 May 2017, . 555 10.2. Informative References 557 [IANAifType-MIB] 558 IANA, "IANAifType-MIB", February 2019, 559 . 561 [ifType-registry] 562 IANA, "ifType definitions", June 2019, 563 . 566 [protocol-registries] 567 IANA, "Protocol Registries", June 2019, 568 . 570 [RFC1234] Provan, D., "Tunneling IPX traffic through IP networks", 571 RFC 1234, DOI 10.17487/RFC1234, June 1991, 572 . 574 [RFC1573] McCloghrie, K. and F. Kastenholz, "Evolution of the 575 Interfaces Group of MIB-II", RFC 1573, 576 DOI 10.17487/RFC1573, January 1994, . 579 [RFC2667] Thaler, D., "IP Tunnel MIB", RFC 2667, 580 DOI 10.17487/RFC2667, August 1999, . 583 [RFC3635] Flick, J., "Definitions of Managed Objects for the 584 Ethernet-like Interface Types", RFC 3635, 585 DOI 10.17487/RFC3635, September 2003, . 588 [RFC3637] Heard, C., Ed., "Definitions of Managed Objects for the 589 Ethernet WAN Interface Sublayer", RFC 3637, 590 DOI 10.17487/RFC3637, September 2003, . 593 [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, 594 DOI 10.17487/RFC4087, June 2005, . 597 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 598 Network Address Translations (NATs)", RFC 4380, 599 DOI 10.17487/RFC4380, February 2006, . 602 [RFC5066] Beili, E., "Ethernet in the First Mile Copper (EFMCu) 603 Interfaces MIB", RFC 5066, DOI 10.17487/RFC5066, November 604 2007, . 606 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 607 RFC 7224, DOI 10.17487/RFC7224, May 2014, 608 . 610 [transmission-registry] 611 IANA, "transmission definitions", June 2019, 612 . 615 [tunnelType-registry] 616 IANA, "Internet-standard MIB - mib- 617 2.interface.ifTable.ifEntry.ifType.tunnelType", June 2019, 618 . 621 [yang-if-type] 622 IANA, "iana-if-type YANG Module", February 2019, 623 . 625 [yang-tunnel-type] 626 IANA, "iana-tunnel-type YANG Module", June 2019, 627 . 629 Authors' Addresses 631 Dave Thaler 632 Microsoft 634 EMail: dthaler@microsoft.com 636 Dan Romascanu 637 Independent 639 EMail: dromasca@gmail.com