diff options
Diffstat (limited to 'doc/rfc/rfc8892.txt')
| -rw-r--r-- | doc/rfc/rfc8892.txt | 714 |
1 files changed, 714 insertions, 0 deletions
diff --git a/doc/rfc/rfc8892.txt b/doc/rfc/rfc8892.txt new file mode 100644 index 0000000..abee765 --- /dev/null +++ b/doc/rfc/rfc8892.txt @@ -0,0 +1,714 @@ + + + + +Internet Engineering Task Force (IETF) D. Thaler +Request for Comments: 8892 Microsoft +Updates: 2863 D. Romascanu +Category: Standards Track Independent +ISSN: 2070-1721 August 2020 + + + Guidelines and Registration Procedures for Interface Types and Tunnel + Types + +Abstract + + This document provides guidelines and procedures for those who are + defining, registering, or evaluating definitions of new interface + types ("ifType" values) and tunnel types. The original definition of + the IANA interface type registry predated the use of IANA + Considerations sections and YANG modules, so some confusion arose + over time. Tunnel types were added later, with the same requirements + and allocation policy as interface types. This document updates RFC + 2863 and provides updated guidance for these registries. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8892. + +Copyright Notice + + Copyright (c) 2020 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Problems + 4. Interface Sub-layers and Sub-types + 4.1. Alternate Values + 5. Available Formats + 6. Registration + 6.1. Procedures + 6.2. Media-Specific OID-Subtree Assignments + 6.3. Registration Template + 6.3.1. ifType + 6.3.2. tunnelType + 7. IANA Considerations + 7.1. MIB and YANG Modules + 7.2. Transmission Number Assignments + 8. Security Considerations + 9. References + 9.1. Normative References + 9.2. Informative References + Authors' Addresses + +1. Introduction + + The IANA IfType-MIB, which contains the list of interface type + (ifType) values, was originally defined in [RFC1573] as a separate + MIB module together with the Interfaces Group MIB (IF-MIB) module. + The IF-MIB module was subsequently updated and is currently specified + in [RFC2863], but the latest IF-MIB RFC no longer contains the IANA + IfType-MIB. Instead, the IANA IfType-MIB is maintained by IANA as a + separate module. Similarly, [RFC7224] created an initial IANA + Interface Type YANG Module, and the current version is maintained by + IANA. + + The current IANA IfType registry is at [ifType-registry], with the + same values also appearing in both [yang-if-type] and the IANAifType + textual convention at [IANAifType-MIB]. + + Although the ifType registry was originally defined in a MIB module, + the assignment and use of interface type values are not tied to MIB + modules or any other management mechanism. An interface type value + can be used as the value of a data model object (MIB object, YANG + object, etc.), as part of a unique identifier of a data model for a + given interface type (e.g., in an OID), or simply as a value exposed + by local APIs or UIs on a device. + + The TUNNEL-MIB was defined in [RFC2667] (now obsoleted by [RFC4087]), + which created a tunnelType registry ([tunnelType-registry] and the + IANAtunnelType textual convention at [IANAifType-MIB]), and it + defined the assignment policy for tunnelType values to always be + identical to the policy for assigning ifType values. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Problems + + This document addresses the following issues: + + 1. As noted in Section 1, the original guidance was written with + wording specific to MIB modules; accordingly, some confusion has + resulted when using YANG modules. This document clarifies that + ifTypes and tunnelTypes are independent from the type of, or even + existence of, a data model. + + 2. The use of and requirements around sub-layers and sub-types were + not well understood, but good examples of both now exist. This + is discussed in Section 4. + + 3. Since the "Interface Types (ifType)" and "Tunnel Types + (tunnelType)" registries were originally defined, and are still + retrievable, in the format of MIB modules (in addition to other + formats), confusion arose when adding YANG modules as another + format as to whether each is a separate registry. This is + discussed in Section 5. + + 4. The registries are retrievable in the format of MIB and YANG + modules, but there was previously no process guidance written to + check that those formats were syntactically correct as updates + were made, which led to the registry having syntax errors that + broke tools. Section 6.1 adds a validation step to the + documented assignment procedure. + + 5. Various documents and registries previously said to submit + requests via email, but a web form exists for submitting + requests, which caused some confusion around which was to be + used. This is addressed in Section 6.1. + + 6. Transmission values [transmission-registry] have generally been + allocated as part of ifType allocation, but no guidance existed + as to whether a requester must ask for it or not, and the request + form had no such required field. As a result, IANA has asked the + designated expert to decide for each allocation, but no relevant + guidance for the designated expert has been documented. This is + remedied in Section 6.2. + +4. Interface Sub-layers and Sub-types + + When multiple sub-layers exist below the network layer, each sub- + layer can be represented by its own row in the ifTable with its own + ifType, with the ifStackTable being used to identify the upward and + downward multiplexing relationships between rows. Section 3.1.1 of + [RFC2863] provides more discussion, and 3.1.2 provides guidance for + defining interface sub-layers. More recent experience shows that + those guidelines were phrased in a way that is now too restrictive, + since at the time [RFC2863] was written, MIB modules were the + dominant data model. + + This document clarifies that the same guidance also applies to YANG + modules. + + Some ifTypes may define sub-types. For example, the tunnel(131) + ifType defines sub-types known as "tunnelTypes", where each + tunnelType can have its own MIB and/or YANG module with protocol- + specific information, but there is enough in common that some + information is exposed in a generic IP Tunnel MIB corresponding to + the tunnel(131) ifType. + + For requests that involve multiple sub-layers below the network + layer, requests MUST include (or reference) a discussion of the + multiplexing relationships between sub-layers, ideally with a + diagram. Various well-written examples exist of such definitions, + including Section 3.4.1 of [RFC3637], Section 3.1.1 of [RFC4087], and + Section 3.1.1 of [RFC5066]. + + Definers of sub-layers and sub-types should consider which model is + more appropriate for their needs. A sub-layer is generally used + whenever either a dynamic relationship exists (i.e., when the set of + instances above or below a given instance can change over time) or a + multiplexing relationship exists with another sub-layer. A sub-type + can be used when neither of these is true but where one interface + type is conceptually a subclass of another interface type, as far as + a management data model is concerned. + + In general, the intent of an interface type or sub-type is that its + definition should be sufficient to identify an interoperable + protocol. In some cases, however, a protocol might be defined in a + way that is not sufficient to provide interoperability with other + compliant implementations of that protocol. In such a case, an + ifType definition should discuss whether specific instantiations (or + profiles) of behavior should use a sub-layer model (e.g., each vendor + might layer the protocol over its own sub-layer that provides the + missing details) or a sub-type model (i.e., each vendor might + subclass the protocol without any layering relationship). If a sub- + type model is more appropriate, then the data model for the protocol + might include a sub-type identifier so that management software can + discover objects specific to the sub-type. In either case, such + discussion is important to guide definers of a data model for the + more specific information (i.e., a lower sub-layer or a sub-type), as + well as the designated expert, who must review requests for any such + ifTypes or sub-types. + +4.1. Alternate Values + + Another design decision is whether to reuse an existing ifType or + tunnelType value, possibly using a sub-type or sub-layer model for + refinements, or to use a different value for a new mechanism. + + If there is already an entry that could easily satisfy the modeling + and functional requirements for the requested entry, it should be + reused so that applications and tools that use the existing value can + be used without changes. If, however, the modeling and functional + requirements are significantly different enough such that having + existing applications and tools use the existing value would be seen + as a problem, a new value should be used. + + For example, originally different ifType values were used for + different flavors of Ethernet (ethernetCsmacd(6), iso88023Csmacd(7), + fastEther(62), etc.), typically because they were registered by + different vendors. Using different values was, however, seen as + problematic because all were functionally similar, so [RFC3635] then + deprecated all but ethernetCsmacd(6). + + As another example, a udp(8) tunnelType value was defined in + [RFC2667] with the description "The value UDP indicates that the + payload packet is encapsulated within a normal UDP packet (e.g., RFC + 1234)." The Teredo tunnel protocol [RFC4380] was later defined and + encapsulates packets over UDP, but the protocol model is quite + different between [RFC1234] and Teredo. For example, [RFC1234] + supports encapsulation of multicast/broadcast traffic, whereas Teredo + does not. As such, it would be more confusing to applications and + tools to represent them using the same tunnel type, and so [RFC4087] + defined a new value for Teredo. + + In summary, definers of new interface or tunnel mechanisms should use + a new ifType or tunnelType value rather than reuse an existing value + when key aspects such as the header format or the link model (point- + to-point, non-broadcast multi-access, broadcast-capable multi-access, + unidirectional broadcast, etc.) are significantly different from + existing values, but they should reuse the same value when the + differences can be expressed in terms of differing values of existing + objects other than ifType/tunnelType in the standard YANG or MIB + module. + +5. Available Formats + + Many registries are available in multiple formats. For example, XML, + HTML, CSV, and plain text are common formats in which many registries + are available. This document clarifies that the [IANAifType-MIB], + [yang-if-type], and [yang-tunnel-type] MIB and YANG modules are + merely additional formats in which the "Interface Types (ifType)" and + "Tunnel Types (tunnelType)" registries are available. The MIB and + YANG modules are not separate registries, and the same values are + always present in all formats of the same registry. + + The confusion stemmed in part from the fact that the IANA "Protocol + Registries" [protocol-registries] listed the YANG and MIB module + formats separately, as if they were separate registries. However, + the entries for the yang-if-type and iana-tunnel-type YANG modules + said "See ifType definitions registry" and "See tunnelType registry + (mib-2.interface.ifTable.ifEntry.ifType.tunnelType)" respectively, + although the entry for the IANAifType-MIB had no such note. + Section 7.1 addresses this. + +6. Registration + + The IANA policy (using terms defined in [RFC8126]) for registration + is Expert Review for both interface types and tunnel types. The role + of the designated expert in the procedure is to raise possible + concerns about wider implications of proposals for use and deployment + of interface types. While it is recommended that the responsible + Area Director and the IESG take into consideration the designated + expert opinions, nothing in the procedure empowers the designated + expert to override properly arrived-at IETF or working group + consensus. + +6.1. Procedures + + Someone wishing to register a new ifType or tunnelType value MUST: + + 1. Check the IANA registry to see whether there is already an entry + that could easily satisfy the modeling and functional + requirements for the requested entry. If there is already such + an entry, use it or update the existing specification. Text in + an Internet-Draft or part of some permanently available, stable + specification may be written to clarify the usage of an existing + entry or entries for the desired purpose. + + 2. Check the IANA registry to see whether there is already some + other entry with the desired name. If there is already an + unrelated entry under the desired name, choose a different name. + + 3. Prepare a registration request using the template specified in + Section 6.3. The registration request can be contained in an + Internet-Draft, submitted alone, or submitted as part of some + permanently available, stable specification. The registration + request can also be submitted in some other form (as part of + another document or as a stand-alone document), but the + registration request will be treated as an "IETF Contribution" + under the guidelines of [RFC5378]. + + 4. Submit the registration request (or pointer to a document + containing it) to IANA at iana@iana.org or (if requesting an + ifType) via the web form at <https://www.iana.org/form/iftype>. + + Upon receipt of a registration request, the following steps MUST be + followed: + + 1. IANA checks the submission for completeness; if required + information is missing or any citations are not correct, IANA + will reject the registration request. A registrant can resubmit + a corrected request if desired. + + 2. IANA requests Expert Review of the registration request against + the corresponding guidelines from this document. + + 3. The designated expert will evaluate the request against the + criteria. + + 4. Once the designated expert approves a registration, IANA updates + [ifType-registry], [IANAifType-MIB], and [yang-if-type] to show + the registration for an interface type, or [tunnelType-registry], + [IANAifType-MIB], and [yang-tunnel-type] to show the registration + for a tunnel type. When adding values, IANA should verify that + the updated MIB module and YANG module formats are syntactically + correct before publishing the update. There are various existing + tools or websites that can be used to do this verification. + + 5. If instead the designated expert does not approve registration + (e.g., for any of the reasons in [RFC8126], Section 5), a + registrant can resubmit a corrected request if desired, or the + IESG can override the designated expert and approve it per the + process in Section 3.3 of [RFC8126]. + +6.2. Media-Specific OID-Subtree Assignments + + [IANAifType-MIB] notes: + + | The relationship between the assignment of ifType values and of + | OIDs to particular media-specific MIBs is solely the purview of + | IANA and is subject to change without notice. Quite often, a + | media-specific MIB's OID-subtree assignment within MIB-II's + | 'transmission' subtree will be the same as its ifType value. + | However, in some circumstances this will not be the case, and + | implementors must not pre-assume any specific relationship between + | ifType values and transmission subtree OIDs. + + The advice above remains unchanged, but this document changes the + allocation procedure to streamline the process, so that an ifType + value and a transmission number value with the same value will be + assigned at the same time. + + Rationale: + + (1) This saves future effort if a transmission number is later + deemed necessary, since no IANA request is needed that would + then require another Expert Review. + + (2) The transmission numbering space is not scarce, so there seems + to be little need to reserve the number for a different purpose + than what the ifType is for. + + (3) The designated expert need not review whether a transmission + number value should be registered when processing each ifType + request, thus reducing the possibility of delaying assignment of + ifType values. + + (4) There is no case on record where allocating the same value could + have caused any problems. + +6.3. Registration Template + +6.3.1. ifType + + The following template describes the fields that MUST be supplied in + a registration request suitable for adding to the "Interface Types + (ifType)" registry: + + Label for IANA ifType requested: As explained in Section 7.1.1 of + [RFC2578], a label for a named-number enumeration must consist of + one or more letters or digits, up to a maximum of 64 characters, + and the initial character must be a lowercase letter. (However, + labels longer than 32 characters are not recommended.) Note that + hyphens are not allowed. + + Name of IANA ifType requested: A short description (e.g., a protocol + name) suitable to appear in a comment in the registry. + + Description of the proposed use of the IANA ifType: Requesters MUST + include answers, either directly or via a link to a document with + the answers, to the following questions in the explanation of the + proposed use of the IANA IfType: + + * How would IP run over your ifType? + + * Would there be another interface sub-layer between your ifType + and IP? + + * Would your ifType be vendor specific / proprietary? (If so, + the label MUST start with a string that shows that. For + example, if your company's name or acronym is xxx, then the + ifType label would be something like xxxSomeIfTypeLabel.) + + * Would your ifType require or allow vendor-specific extensions? + If so, would the vendor use their own ifType in a sub-layer + below the requested ifType, a sub-type of the ifType, or some + other mechanism? + + Reference, Internet-Draft, or Specification: A link to a document is + required. + + Additional information or comments: Optional; any additional + comments for IANA or the designated expert. + +6.3.2. tunnelType + + Prior to this document, no form existed for tunnelType (and new + tunnelType requests did not need to use the ifType form that did + exist). This document therefore specifies a tunnelType form. + + The following template describes the fields that MUST be supplied in + a registration request suitable for adding to the "Tunnel Types + (tunnelType)" registry: + + Label for IANA tunnelType requested: As explained in Section 7.1.1 + of [RFC2578], a label for a named-number enumeration must consist + of one or more letters or digits, up to a maximum of 64 + characters, and the initial character must be a lowercase letter. + (However, labels longer than 32 characters are not recommended.) + Note that hyphens are not allowed. + + Name of IANA tunnelType requested: A short description (e.g., a + protocol name) suitable to appear in a comment in the registry. + + Description of the proposed use of the IANA tunnelType: Requesters + MUST include answers, either directly or via a link to a document + with the answers, to the following questions in the explanation of + the proposed use of the IANA tunnelType: + + * How would IP run over your tunnelType? + + * Would there be another interface sub-layer between your + tunnelType and IP? + + * Would your tunnelType be vendor-specific or proprietary? (If + so, the label MUST start with a string that shows that. For + example, if your company's name or acronym is xxx, then the + tunnelType label would be something like + xxxSomeTunnelTypeLabel.) + + * Would your tunnelType require or allow vendor-specific + extensions? If so, would the vendor use their own tunnelType + in a sub-layer below the requested tunnelType, or some sort of + sub-type of the tunnelType, or some other mechanism? + + Reference, Internet-Draft, or Specification: A link to a document is + required. + + Additional information or comments: Optionally any additional + comments for IANA or the designated expert. + +7. IANA Considerations + + This entire document is about IANA considerations, but this section + discusses actions taken by and to be taken by IANA. There are three + registries affected: + + 1. Interface Types (ifType) [ifType-registry]: The registration + process is updated in Section 6.1, and the template is updated in + Section 6.3.1. + + 2. Tunnel Types (tunnelType) [tunnelType-registry]: The registration + process is updated in Section 6.1, and the template is updated in + Section 6.3.2. + + 3. Transmission Number Values [transmission-registry]: The + assignment process is updated in Section 6.2. + + At the time of publication of this document, IANA is unable to + perform some of the actions requested below due to limitations of + their current platform and toolset. In such cases, IANA is requested + to perform these actions as and when the migration to a new platform + that would enable these actions is complete. + +7.1. MIB and YANG Modules + + IANA is to complete the following to clarify the relationship between + MIB modules, YANG modules, and the relevant registries. + + 1. The following note has been added to the IANAifType-MIB at + [protocol-registries]: "This is one of the available formats of + the Interface Types (ifType) and Tunnel Types (tunnelType) + registries." + + 2. The note for the iana-if-type YANG module at + [protocol-registries] has been updated to read: "This is one of + the available formats of the Interface Types (ifType) registry." + + 3. The note for the iana-tunnel-type YANG module at + [protocol-registries] has been updated to read: "This is one of + the available formats of the Tunnel Types (tunnelType) + registry." + + 4. The new "Interface Parameters" category at [protocol-registries] + includes entries for "Interface Types (ifType)" + [ifType-registry], "Tunnel Types (tunnelType)" + [tunnelType-registry], and "Transmission Number Values" + [transmission-registry]. + + 5. Update the "Interface Types (ifType)" registry [ifType-registry] + to list MIB [IANAifType-MIB] and YANG [yang-if-type] as + Available Formats. + + 6. Update the "Tunnel Types (tunnelType)" registry + [tunnelType-registry] to list MIB [IANAifType-MIB] and YANG + [yang-tunnel-type] as Available Formats. + + 7. Replace the [yang-if-type] page with the YANG module content + rather than having a page that claims to have multiple Available + Formats. + + 8. Replace the [yang-tunnel-type] page with the YANG module content + rather than having a page that claims to have multiple Available + Formats. + + 9. In addition, [IANAifType-MIB] is to be updated as follows: + + OLD: + + | Requests for new values should be made to IANA via email + | (iana@iana.org). + + NEW: + + | Interface types must not be directly added to the IANAifType- + | MIB MIB module. They must instead be added to the "Interface + | Types (ifType)" registry at [ifType-registry]. + + (Note that [yang-if-type] was previously updated with this + language.) + + 10. IANA has added this document as a reference in the "Interface + Types (ifType)", "Tunnel Types (tunnelType)", and "Transmission + Number Values" registries, as well as the iana-if-type YANG + Module, iana-tunnel-type YANG Module, and IANAifType-MIB. + +7.2. Transmission Number Assignments + + Per the discussion in Section 6.2, [ifType-registry] has been updated + as follows: + + OLD: + + | For every ifType registration, the corresponding transmission + | number value should be registered or marked "Reserved". + + NEW: + + | For future ifType assignments, an OID-subtree assignment MIB-II's + | 'transmission' subtree will be made with the same value. + + Similarly, the following change has been made to + [transmission-registry]: + + OLD: + + | For every transmission number registration, the corresponding + | ifType value should be registered or marked "Reserved". + + NEW: + + | For future transmission number assignments, an 'ifType' will be + | made with the same value. + +8. Security Considerations + + Since this document does not introduce any technology or protocol, + there are no security issues to be considered for this document + itself. + + For security considerations related to MIB and YANG modules that + expose these values, see Section 9 of [RFC2863], Section 6 of + [RFC4087], and Section 3 of [RFC8675]. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + <https://www.rfc-editor.org/info/rfc2578>. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, + <https://www.rfc-editor.org/info/rfc2863>. + + [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights + Contributors Provide to the IETF Trust", BCP 78, RFC 5378, + DOI 10.17487/RFC5378, November 2008, + <https://www.rfc-editor.org/info/rfc5378>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +9.2. Informative References + + [IANAifType-MIB] + IANA, "IANAifType-MIB Definitions", + <http://www.iana.org/assignments/ianaiftype-mib>. + + [ifType-registry] + IANA, "Interface Types (ifType)", + <https://www.iana.org/assignments/smi-numbers>. + + [protocol-registries] + IANA, "Protocol Registries", + <https://www.iana.org/protocols>. + + [RFC1234] Provan, D., "Tunneling IPX traffic through IP networks", + RFC 1234, DOI 10.17487/RFC1234, June 1991, + <https://www.rfc-editor.org/info/rfc1234>. + + [RFC1573] McCloghrie, K. and F. Kastenholz, "Evolution of the + Interfaces Group of MIB-II", RFC 1573, + DOI 10.17487/RFC1573, January 1994, + <https://www.rfc-editor.org/info/rfc1573>. + + [RFC2667] Thaler, D., "IP Tunnel MIB", RFC 2667, + DOI 10.17487/RFC2667, August 1999, + <https://www.rfc-editor.org/info/rfc2667>. + + [RFC3635] Flick, J., "Definitions of Managed Objects for the + Ethernet-like Interface Types", RFC 3635, + DOI 10.17487/RFC3635, September 2003, + <https://www.rfc-editor.org/info/rfc3635>. + + [RFC3637] Heard, C.M., Ed., "Definitions of Managed Objects for the + Ethernet WAN Interface Sublayer", RFC 3637, + DOI 10.17487/RFC3637, September 2003, + <https://www.rfc-editor.org/info/rfc3637>. + + [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, + DOI 10.17487/RFC4087, June 2005, + <https://www.rfc-editor.org/info/rfc4087>. + + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + Network Address Translations (NATs)", RFC 4380, + DOI 10.17487/RFC4380, February 2006, + <https://www.rfc-editor.org/info/rfc4380>. + + [RFC5066] Beili, E., "Ethernet in the First Mile Copper (EFMCu) + Interfaces MIB", RFC 5066, DOI 10.17487/RFC5066, November + 2007, <https://www.rfc-editor.org/info/rfc5066>. + + [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", + RFC 7224, DOI 10.17487/RFC7224, May 2014, + <https://www.rfc-editor.org/info/rfc7224>. + + [RFC8675] Boucadair, M., Farrer, I., and R. Asati, "A YANG Data + Model for Tunnel Interface Types", RFC 8675, + DOI 10.17487/RFC8675, November 2019, + <https://www.rfc-editor.org/info/rfc8675>. + + [transmission-registry] + IANA, "Transmission Number Values", + <https://www.iana.org/assignments/smi-numbers>. + + [tunnelType-registry] + IANA, "Tunnel Types (tunnelType)", + <https://www.iana.org/assignments/smi-numbers>. + + [yang-if-type] + IANA, "iana-if-type YANG Module", + <http://www.iana.org/assignments/iana-if-type>. + + [yang-tunnel-type] + IANA, "iana-tunnel-type YANG Module", + <https://www.iana.org/assignments/iana-tunnel-type>. + +Authors' Addresses + + Dave Thaler + Microsoft + + Email: dthaler@microsoft.com + + + Dan Romascanu + Independent + + Email: dromasca@gmail.com |