Guidelines and Registration Procedures for Interface Types and Tunnel Types
RFC 8892
Document | Type |
RFC - Proposed Standard
(August 2020; No errata)
Updates RFC 2863
Was draft-thaler-iftype-reg (individual in int area)
|
|
---|---|---|---|
Authors | Dave Thaler , Dan Romascanu | ||
Last updated | 2020-08-28 | ||
Stream | IETF | ||
Formats | plain text html xml pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | Ian Farrer | ||
Shepherd write-up | Show (last changed 2019-09-30) | ||
IESG | IESG state | RFC 8892 (Proposed Standard) | |
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Suresh Krishnan | ||
Send notices to | (None) | ||
IANA | IANA review state | IANA - Not OK | |
IANA action state | RFC-Ed-Ack |
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 hasShow full document text