--- 1/draft-ietf-netmod-intf-ext-yang-08.txt 2020-07-13 14:17:15.174078315 -0700 +++ 2/draft-ietf-netmod-intf-ext-yang-09.txt 2020-07-13 14:17:15.222078985 -0700 @@ -1,21 +1,21 @@ Internet Engineering Task Force R. Wilton, Ed. Internet-Draft D. Ball Intended status: Standards Track T. Singh -Expires: May 7, 2020 Cisco Systems +Expires: January 14, 2021 Cisco Systems S. Sivaraj Juniper Networks - November 4, 2019 + July 13, 2020 Common Interface Extension YANG Data Models - draft-ietf-netmod-intf-ext-yang-08 + draft-ietf-netmod-intf-ext-yang-09 Abstract This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. @@ -28,78 +28,81 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 7, 2020. + This Internet-Draft will expire on January 14, 2021. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 2. Interface Extensions Module . . . . . . . . . . . . . . . . . 4 2.1. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Suppress Threshold . . . . . . . . . . . . . . . . . 7 2.2.2. Half-Life Period . . . . . . . . . . . . . . . . . . 7 2.2.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 7 2.2.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 7 2.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5. Maximum frame size . . . . . . . . . . . . . . . . . . . 8 2.6. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 8 2.7. Forwarding Mode . . . . . . . . . . . . . . . . . . . . . 9 3. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 9 4. Interface Extensions YANG Module . . . . . . . . . . . . . . 10 - 5. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 20 - 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 6.1. Carrier delay configuration . . . . . . . . . . . . . . . 24 - 6.2. Dampening configuration . . . . . . . . . . . . . . . . . 25 - 6.3. MAC address configuration . . . . . . . . . . . . . . . . 26 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 - 8. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 8.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 28 - 8.2. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 28 - 8.3. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 28 - 8.4. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 28 - 8.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 28 - 8.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 28 - 8.7. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 28 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 10.1. ietf-if-extensions.yang . . . . . . . . . . . . . . . . 29 - 10.2. ietf-if-ethernet-like.yang . . . . . . . . . . . . . . . 30 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 - 11.2. Informative References . . . . . . . . . . . . . . . . . 31 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 + 5. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 21 + 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 6.1. Carrier delay configuration . . . . . . . . . . . . . . . 25 + 6.2. Dampening configuration . . . . . . . . . . . . . . . . . 26 + 6.3. MAC address configuration . . . . . . . . . . . . . . . . 27 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 + 8. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 8.1. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 29 + 8.2. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 29 + 8.3. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 29 + 8.4. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 29 + 8.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 29 + 8.6. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 29 + 8.7. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 29 + 8.8. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 30 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 + 9.1. YANG Module Registrations . . . . . . . . . . . . . . . . 30 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 + 10.1. ietf-if-extensions.yang . . . . . . . . . . . . . . . . 31 + 10.2. ietf-if-ethernet-like.yang . . . . . . . . . . . . . . . 32 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 + 11.2. Informative References . . . . . . . . . . . . . . . . . 33 + + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction This document defines two NMDA compatible [RFC8342] YANG 1.1 [RFC7950] modules for the management of network interfaces. It defines various augmentations to the generic interfaces data model [RFC8343] to support configuration of lower layer interface properties that are common across many types of network interface. One of the aims of this document is to provide a standard definition @@ -421,22 +424,22 @@ augment /if:interfaces/if:interface: +--rw ethernet-like +--rw mac-address? yang:mac-address | {configurable-mac-address}? +--ro bia-mac-address? yang:mac-address augment /if:interfaces/if:interface/if:statistics: +--ro in-drop-unknown-dest-mac-pkts? yang:counter64 4. Interface Extensions YANG Module - This YANG module augments the interface container defined in RFC 8343 - [RFC8343]. + This YANG module augments the interface container defined in + [RFC8343]. It also contains references to [RFC6991] and [RFC7224]. file "ietf-if-extensions@2019-11-04.yang" module ietf-if-extensions { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-if-extensions"; prefix if-ext; import ietf-yang-types { @@ -488,137 +491,136 @@ NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2019-11-04 { description "Initial revision."; reference - "RFC XXX, Common Interface Extension YANG Data Models"; + "RFC XXXX, Common Interface Extension YANG Data Models"; } feature carrier-delay { description - "This feature indicates that configurable interface - carrier delay is supported, which is a feature is used to - limit the propagation of very short interface link state - flaps."; - reference "RFC XXX, Section 2.1 Carrier Delay"; + "This feature indicates that configurable interface carrier + delay is supported, which is a feature is used to limit the + propagation of very short interface link state flaps."; + reference "RFC XXXX, Section 2.1 Carrier Delay"; } feature dampening { description "This feature indicates that the device supports interface dampening, which is a feature that is used to limit the propagation of interface link state flaps over longer periods."; - reference "RFC XXX, Section 2.2 Dampening"; + reference "RFC XXXX, Section 2.2 Dampening"; } feature loopback { description - "This feature indicates that configurable interface loopback - is supported."; - reference "RFC XXX, Section 2.4 Loopback"; + "This feature indicates that configurable interface loopback is + supported."; + reference "RFC XXXX, Section 2.4 Loopback"; } feature max-frame-size { description - "This feature indicates that the device supports configuring - or reporting the maximum frame size on interfaces."; - reference "RFC XXX, Section 2.5 Maximum Frame Size"; + "This feature indicates that the device supports configuring or + reporting the maximum frame size on interfaces."; + reference "RFC XXXX, Section 2.5 Maximum Frame Size"; } feature sub-interfaces { description "This feature indicates that the device supports the instantiation of sub-interfaces. Sub-interfaces are defined as logical child interfaces that allow features and forwarding decisions to be applied to a subset of the traffic processed on the specified parent interface."; - reference "RFC XXX, Section 2.6 Sub-interface"; + reference "RFC XXXX, Section 2.6 Sub-interface"; } /* * Define common identities to help allow interface types to be * assigned properties. */ identity sub-interface { description "Base type for generic sub-interfaces. New or custom interface types can derive from this type to inherit generic sub-interface configuration."; - reference "RFC XXX, Section 2.6 Sub-interface"; + reference "RFC XXXX, Section 2.6 Sub-interface"; } identity ethSubInterface{ base ianaift:l2vlan; base sub-interface; description "This identity represents the child sub-interface of any interface types that uses Ethernet framing (with or without 802.1Q tagging)."; } identity loopback { description "Base identity for interface loopback options"; - reference "RFC XXX, Section 2.4"; + reference "RFC XXXX, Section 2.4"; } identity internal { base loopback; description "All egress traffic on the interface is internally looped back within the interface to be received on the ingress path."; - reference "RFC XXX, Section 2.4"; + reference "RFC XXXX, Section 2.4"; } identity line { base loopback; description "All ingress traffic received on the interface is internally looped back within the interface to the egress path."; - reference "RFC XXX, Section 2.4"; + reference "RFC XXXX, Section 2.4"; } identity connector { base loopback; description "The interface has a physical loopback connector attached that loops all egress traffic back into the interface's ingress path, with equivalent semantics to loopback internal."; - reference "RFC XXX, Section 2.4"; + reference "RFC XXXX, Section 2.4"; } identity forwarding-mode { description "Base identity for forwarding-mode options."; - reference "RFC XXX, Section 2.7"; + reference "RFC XXXX, Section 2.7"; } identity physical { base forwarding-mode; description "Physical layer forwarding. This includes DWDM or OTN based optical switching."; - reference "RFC XXX, Section 2.7"; + reference "RFC XXXX, Section 2.7"; } identity data-link { base forwarding-mode; description "Layer 2 based forwarding, such as Ethernet/VLAN based switching, or L2VPN services."; - reference "RFC XXX, Section 2.7"; + reference "RFC XXXX, Section 2.7"; } identity network { base forwarding-mode; description "Network layer based forwarding, such as IP, MPLS, or L3VPNs."; - reference "RFC XXX, Section 2.7"; + reference "RFC XXXX, Section 2.7"; } /* * Augments the IETF interfaces model with leaves to configure * and monitor carrier-delay on an interface. */ augment "/if:interfaces/if:interface" { description "Augments the IETF interface model with optional common interface level commands that are not formally covered by any @@ -688,116 +690,116 @@ actually down."; } } config false; description "Reports whether a carrier delay timer is actively running, in which case the interface state does not match the underlying carrier state."; } - reference "RFC XXX, Section 2.1 Carrier Delay"; + reference "RFC XXXX, Section 2.1 Carrier Delay"; } /* * Augments the IETF interfaces model with a container to hold * generic interface dampening */ container dampening { if-feature "dampening"; presence "Enable interface link flap dampening with default settings (that are vendor/device specific)."; description "Interface dampening limits the propagation of interface link state flaps over longer periods."; - reference "RFC XXX, Section 2.2 Dampening"; + reference "RFC XXXX, Section 2.2 Dampening"; leaf half-life { type uint32; units seconds; description "The time (in seconds) after which a penalty would be half its original value. Once the interface has been assigned a penalty, the penalty is decreased at a decay rate equivalent to the half-life. For some devices, the allowed values may be restricted to particular multiples of seconds. The default value is vendor/device specific."; - reference "RFC XXX, Section 2.3.2 Half-Life Period"; + reference "RFC XXXX, Section 2.3.2 Half-Life Period"; } leaf reuse { type uint32; description "Penalty value below which a stable interface is unsuppressed (i.e. brought up) (no units). The default value is vendor/device specific. The penalty value for a link up->down state change is 1000 units."; - reference "RFC XXX, Section 2.2.3 Reuse Threshold"; + reference "RFC XXXX, Section 2.2.3 Reuse Threshold"; } leaf suppress { type uint32; description "Limit at which an interface is suppressed (i.e. held down) when its penalty exceeds that limit (no units). The value must be greater than the reuse threshold. The default value is vendor/device specific. The penalty value for a link up->down state change is 1000 units."; - reference "RFC XXX, Section 2.2.1 Suppress Threshold"; + reference "RFC XXXX, Section 2.2.1 Suppress Threshold"; } leaf max-suppress-time { type uint32; units seconds; description "Maximum time (in seconds) that an interface can be suppressed before being unsuppressed if no further link up->down state change penalties have been applied. This value effectively acts as a ceiling that the penalty value cannot exceed. The default value is vendor/device specific."; - reference "RFC XXX, Section 2.2.4 Maximum Suppress Time"; + reference "RFC XXXX, Section 2.2.4 Maximum Suppress Time"; } leaf penalty { type uint32; config false; description "The current penalty value for this interface. When the penalty value exceeds the 'suppress' leaf then the interface is suppressed (i.e. held down)."; - reference "RFC XXX, Section 2.2 Dampening"; + reference "RFC XXXX, Section 2.2 Dampening"; } leaf suppressed { type boolean; config false; description "Represents whether the interface is suppressed (i.e. held down) because the 'penalty' leaf value exceeds the 'suppress' leaf."; - reference "RFC XXX, Section 2.2 Dampening"; + reference "RFC XXXX, Section 2.2 Dampening"; } leaf time-remaining { when '../suppressed = "true"' { description "Only suppressed interfaces have a time remaining."; } type uint32; units seconds; config false; description "For a suppressed interface, this leaf represents how long (in seconds) that the interface will remain suppressed before it is allowed to go back up again."; - reference "RFC XXX, Section 2.2 Dampening"; + reference "RFC XXXX, Section 2.2 Dampening"; } } /* * Various types of interfaces support a configurable layer 2 * encapsulation, any that are supported by YANG should be * listed here. * * Different encapsulations can hook into the common encaps-type * choice statement. */ @@ -816,21 +818,21 @@ "All interface types that can have a configurable L2 encapsulation."; } description "Holds the OSI layer 2 encapsulation associated with an interface."; choice encaps-type { description "Extensible choice of layer 2 encapsulations"; - reference "RFC XXX, Section 2.3 Encapsulation"; + reference "RFC XXXX, Section 2.3 Encapsulation"; } } /* * Various types of interfaces support loopback configuration, * any that are supported by YANG should be listed here. */ leaf loopback { when "derived-from-or-self(../if:type, 'ianaift:ethernetCsmacd') or @@ -838,21 +840,21 @@ derived-from-or-self(../if:type, 'ianaift:atm') or derived-from-or-self(../if:type, 'ianaift:otnOtu')" { description "All interface types that support loopback configuration."; } if-feature "loopback"; type identityref { base loopback; } description "Enables traffic loopback."; - reference "RFC XXX, Section 2.4 Loopback"; + reference "RFC XXXX, Section 2.4 Loopback"; } /* * Allows the maximum frame size to be configured or reported. */ leaf max-frame-size { if-feature "max-frame-size"; type uint32 { range "64 .. max"; } @@ -860,36 +862,36 @@ "The maximum size of layer 2 frames that may be transmitted or received on the interface (including any frame header, maximum frame payload size, and frame checksum sequence). If configured, the max-frame-size also limits the maximum frame size of any child sub-interfaces. The MTU available to higher layer protocols is restricted to the maximum frame payload size, and MAY be further restricted by explicit layer 3 or protocol specific MTU configuration."; - reference "RFC XXX, Section 2.5 Maximum Frame Size"; + reference "RFC XXXX, Section 2.5 Maximum Frame Size"; } /* * Augments the IETF interfaces model with a leaf that indicates * which mode, or layer, is being used to forward the traffic. */ leaf forwarding-mode { type identityref { base forwarding-mode; } config false; description "The forwarding mode that the interface is operating in."; - reference "RFC XXX, Section 2.7 Forwarding Mode"; + reference "RFC XXXX, Section 2.7 Forwarding Mode"; } } /* * Add generic support for sub-interfaces. * * This should be extended to cover all interface types that are * child interfaces of other interfaces. */ augment "/if:interfaces/if:interface" { @@ -906,45 +908,91 @@ "Adds a parent interface field to interfaces that model sub-interfaces."; leaf parent-interface { type if:interface-ref; mandatory true; description "This is the reference to the parent interface of this sub-interface."; - reference "RFC XXX, Section 2.6 Sub-interface"; + reference "RFC XXXX, Section 2.6 Sub-interface"; + } + } + + /* + * Add discard counter for unknown sub-interface encapsulation + */ + augment "/if:interfaces/if:interface/if:statistics" { + when "derived-from-or-self(../if:type, + 'ianaift:ethernetCsmacd') or + derived-from-or-self(../if:type, + 'ianaift:ieee8023adLag') or + derived-from-or-self(../if:type, 'ianaift:ifPwType')" { + description + "Applies to interfaces that can demux to sub-interfaces"; + } + if-feature "sub-interfaces"; + + description + "Augment the interface model statistics with a sub-interface + demux discard counter."; + + leaf in-discard-unknown-encaps { + type yang:counter64; + units frames; + description + "A count of the number of frames that were well formed, but + otherwise discarded because their encapsulation does not + classify to the interface or any child sub-interface. E.g., + a packet might be discarded because the it has an unknown + VLAN Id, or does not have a VLAN Id when one is expected. + + For consistency, frames counted against this counter are + also counted against the IETF interfaces statistics. In + particular, they are included in in-octets and in-discards, + but are not included in in-unicast-pkts, in-multicast-pkts + or in-broadcast-pkts, because they are not delivered to a + higher layer. + + Discontinuities in the values of this counter can occur at + re-initialization of the management system, and at other + times as indicated by the value of the 'discontinuity-time' + leaf defined in the ietf-interfaces YANG module + (RFC 8343)."; } } } 5. Interfaces Ethernet-Like YANG Module This YANG module augments the interface container defined in RFC 8343 [RFC8343] for Ethernet-like interfaces. This includes Ethernet - interfaces, 802.3 LAG (802.1AX) interfaces, VLAN sub-interfaces, - Switch Virtual interfaces, and Pseudo-Wire Head-End interfaces. + interfaces, 802.3 LAG (802.1AX) interfaces, Switch Virtual + interfaces, and Pseudo-Wire Head-End interfaces. It also contains + references to [RFC6991], [RFC7224], and [IEEE802.3.2-2019]. file "ietf-if-ethernet-like@2019-11-04.yang" module ietf-if-ethernet-like { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-if-ethernet-like"; prefix ethlike; + import ietf-interfaces { prefix if; reference "RFC 8343: A YANG Data Model For Interface Management"; + } import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types"; } import iana-if-type { prefix ianaift; reference "RFC 7224: IANA Interface Type YANG Module"; @@ -983,28 +1031,29 @@ (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; revision 2019-11-04 { description "Initial revision."; reference - "RFC XXX, Common Interface Extension YANG Data Models"; + "RFC XXXX, Common Interface Extension YANG Data Models"; } feature configurable-mac-address { description "This feature indicates that MAC addresses on Ethernet-like interfaces can be configured."; - reference "RFC XXX, Section 3 Interfaces Ethernet-Like Module"; + reference + "RFC XXXX, Section 3, Interfaces Ethernet-Like Module"; } /* * Configuration parameters for Ethernet-like interfaces. */ augment "/if:interfaces/if:interface" { when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or derived-from-or-self(if:type, 'ianaift:ifPwType')" { description "Applies to all Ethernet-like interfaces"; @@ -1046,39 +1095,40 @@ 'ianaift:ethernetCsmacd') or derived-from-or-self(../if:type, 'ianaift:ieee8023adLag') or derived-from-or-self(../if:type, 'ianaift:ifPwType')" { description "Applies to all Ethernet-like interfaces"; } description "Augment the interface model statistics with additional counters related to Ethernet-like interfaces."; - leaf in-drop-unknown-dest-mac-pkts { + leaf in-discard-unknown-dest-mac-pkts { type yang:counter64; units frames; description "A count of the number of frames that were well formed, but - otherwise dropped because the destination MAC address did + otherwise discarded because the destination MAC address did not pass any ingress destination MAC address filter. - For consistency, frames counted against this drop counters - are also counted against the IETF interfaces statistics. In + For consistency, frames counted against this counter are + also counted against the IETF interfaces statistics. In particular, they are included in in-octets and in-discards, but are not included in in-unicast-pkts, in-multicast-pkts or in-broadcast-pkts, because they are not delivered to a higher layer. Discontinuities in the values of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the 'discontinuity-time' - leaf defined in the ietf-interfaces YANG module (RFC 8343)."; + leaf defined in the ietf-interfaces YANG module + (RFC 8343)."; } } } 6. Examples The following sections give some examples of how different parts of the YANG modules could be used. Examples are not given for the more trivial configuration, or for sub-interfaces, for which examples are @@ -1237,59 +1287,99 @@ The authors wish to thank Eric Gray, Ing-Wher Chen, Jon Culver, Juergen Schoenwaelder, Ladislav Lhotka, Lou Berger, Mahesh Jethanandani, Martin Bjorklund, Michael Zitao, Neil Ketley, Qin Wu, William Lupton, Xufeng Liu, Andy Bierman, and Vladimir Vassilev for their helpful comments contributing to this document. 8. ChangeLog XXX, RFC Editor, please delete this change log before publication. -8.1. Version -08 +8.1. Version -09 + + o Fixed IANA section. + +8.2. Version -08 o Initial updates after WG LC comments. -8.2. Version -07 +8.3. Version -07 o Minor editorial updates -8.3. Version -06 +8.4. Version -06 o Remove reservable-bandwidth, based on Acee's suggestion o Add examples o Add additional state parameters for carrier-delay and dampening -8.4. Version -05 +8.5. Version -05 o Incorporate feedback from Andy Bierman -8.5. Version -04 +8.6. Version -04 o Incorporate feedback from Lada, some comments left as open issues. -8.6. Version -03 +8.7. Version -03 o Fixed incorrect module name references, and updated tree output -8.7. Version -02 +8.8. Version -02 o Minor changes only: Fix errors in when statements, use derived- from-or-self() for future proofing. 9. IANA Considerations - This document defines several new YANG module and the authors - politely request that IANA assigns unique names to the two YANG - module files contained within this document, and also appropriate - URIs in the "IETF XML Registry". +9.1. YANG Module Registrations + + The following YANG modules are requested to be registred in the IANA + "YANG Module Names" [RFC6020] registry: + + The ietf-if-extensions module: + + Name: ietf-if-extensions + + XML Namespace: urn:ietf:params:xml:ns:yang:ietf-if-extensions + + Prefix: if-ext + + Reference: [RFCXXXX] + + The ietf-if-ethernet-like module: + + Name: ietf-if-ethernet-like + + XML Namespace: urn:ietf:params:xml:ns:yang:ietf-if-ethernet-like + + Prefix: ethlike + + Reference: [RFCXXXX] + + This document registers two URIs in the "IETF XML Registry" + [RFC3688]. Following the format in RFC 3688, the following + registrations have been made. + + URI: urn:ietf:params:xml:ns:yang:ietf-if-extensions + + Registrant Contact: The IESG. + + XML: N/A, the requested URI is an XML namespace. + + URI: urn:ietf:params:xml:ns:yang:ietf-if-ethernet-like + + Registrant Contact: The IESG. + + XML: N/A, the requested URI is an XML namespace. 10. Security Considerations The YANG module defined in this memo is designed to be accessed via the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is the secure transport layer and the mandatory to implement secure transport is SSH RFC 6242 [RFC6242]. The NETCONF access control model RFC 6536 [RFC6536] provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content. @@ -1363,20 +1453,29 @@ 11. References 11.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, . + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . + + [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for + the Network Configuration Protocol (NETCONF)", RFC 6020, + DOI 10.17487/RFC6020, October 2010, + . + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture @@ -1385,24 +1484,24 @@ [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . 11.2. Informative References [I-D.ietf-netmod-sub-intf-vlan-model] Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. Sivaraj, "Sub-interface VLAN YANG Data Models", draft- - ietf-netmod-sub-intf-vlan-model-05 (work in progress), - March 2019. + ietf-netmod-sub-intf-vlan-model-06 (work in progress), + November 2019. - [IEEE802.3.2] + [IEEE802.3.2-2019] IEEE WG802.3 - Ethernet Working Group, "IEEE 802.3.2-2019", 2019. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,