IANA Interface Type YANG Module
Extracted elements (17)
The iana-if-type YANG module is designed to mirror the IANA 'ifType definitions' registry in exactly the same way that the IANAifType-MIB reflects the same registry. This provides a YANG-native equivalent to the existing MIB for use with NETCONF-based management.
The module is IANA-maintained rather than author-maintained. The latest revision can always be obtained from the IANA web site, and whenever a new interface type is added to the 'ifType definitions' registry, both the IANAifType-MIB and the iana-if-type YANG module are updated by IANA.
The iana-if-type module imports from 'ietf-interfaces' (RFC 7223), specifically the 'interface-type' identity. Implementations must have RFC 7223 available to use this module.
The identity 'ethernetCsmacd' covers all Ethernet-like interfaces regardless of speed as per RFC 3635. Identities 'iso88023Csmacd', 'starLan', 'fastEther', 'fastEtherFX', and 'gigabitEthernet' are all deprecated in favor of 'ethernetCsmacd'.
The identity 'propBWAp2Mp' notes that its use for IEEE 802.16 WMAN interfaces (as per IEEE Std 802.16f) is deprecated, and 'ieee80216WMAN' should be used instead. Similarly, 'adsl2' is deprecated in favor of 'adsl2plus'.
Each new identity statement added to the module should define 'base' (value 'iana-interface-type'), 'status' (only if deprecated or obsolete), 'description' (replicated from registry, line-wrapped at 72 characters), and 'reference' (replicated from registry with document title).
Interface types MUST NOT be directly added to the iana-if-type YANG module. They must instead be added to the 'ifType definitions' registry, which then drives an update to the YANG module.
Unassigned or reserved values from the 'ifType definitions' registry are not present in the iana-if-type YANG module.
When an interface type is added to the 'ifType definitions' registry, a new 'identity' statement must be added to the iana-if-type YANG module with the same name as the corresponding enumeration in the IANAifType-MIB.
When the iana-if-type YANG module is updated, a new 'revision' statement must be added in front of the existing revision statements.
The iana-if-type YANG module defines YANG identities for all IANA-registered interface types. It uses namespace 'urn:ietf:params:xml:ns:yang:iana-if-type' and prefix 'ianaift', and imports the 'interface-type' identity from the ietf-interfaces module (RFC 7223).
The 'iana-interface-type' identity serves as the base for all interface type identities in the module. Every specific interface type identity (e.g., ethernetCsmacd, ppp, atm) derives from this base identity.
The module defines identities for over 230 interface types spanning legacy (regular1822, hdh1822), LAN (ethernetCsmacd, ieee80211, ieee802154), WAN (ds1, ds3, sonet), ATM, DSL (adsl, vdsl, sdsl), voice (voiceEM, voiceFXO, voiceFXS), optical (otnOdu, otnOtu), and virtual/tunnel (tunnel, l2vlan, mpls) technologies.
A URI is registered in the IETF XML registry (RFC 3688): 'urn:ietf:params:xml:ns:yang:iana-if-type', with IANA as registrant contact, representing an XML namespace.
A YANG module is registered in the 'YANG Module Names' registry (RFC 6020) with name 'iana-if-type', namespace 'urn:ietf:params:xml:ns:yang:iana-if-type', prefix 'ianaift', and reference RFC 7224.
The 'ifType definitions' registry (IANA SMI numbers registry) is the authoritative source for interface type assignments. This document adds RFC 7224 as a reference to that registry and adds a note requiring the iana-if-type YANG module to be updated whenever the registry is modified.
Since this document defines only a YANG module containing identity definitions that mirror an existing IANA registry and does not introduce any technology or protocol, there are no security issues to be considered for this document itself.