Diff: draft-ietf-netmod-intf-ext-yang-08.txt - draft-ietf-netmod-intf-ext-yang-09.txt

	draft-ietf-netmod-intf-ext-yang-08.txt	draft-ietf-netmod-intf-ext-yang-09.txt

	Internet Engineering Task Force R. Wilton, Ed.	Internet Engineering Task Force R. Wilton, Ed.
	Internet-Draft D. Ball	Internet-Draft D. Ball
	Intended status: Standards Track T. Singh	Intended status: Standards Track T. Singh

	Expires: May 7, 2020 Cisco Systems	Expires: January 14, 2021 Cisco Systems
	S. Sivaraj	S. Sivaraj
	Juniper Networks	Juniper Networks

	November 4, 2019	July 13, 2020

	Common Interface Extension YANG Data Models	Common Interface Extension YANG Data Models

	draft-ietf-netmod-intf-ext-yang-08	draft-ietf-netmod-intf-ext-yang-09

	Abstract	Abstract

	This document defines two YANG modules that augment the Interfaces	This document defines two YANG modules that augment the Interfaces
	data model defined in the "YANG Data Model for Interface Management"	data model defined in the "YANG Data Model for Interface Management"
	with additional configuration and operational data nodes to support	with additional configuration and operational data nodes to support
	common lower layer interface properties, such as interface MTU.	common lower layer interface properties, such as interface MTU.

	The YANG modules in this document conform to the Network Management	The YANG modules in this document conform to the Network Management
	Datastore Architecture (NMDA) defined in RFC 8342.	Datastore Architecture (NMDA) defined in RFC 8342.

	skipping to change at page 1, line 39 ¶	skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.	Drafts is at https://datatracker.ietf.org/drafts/current/.

	Internet-Drafts are draft documents valid for a maximum of six months	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."	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 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.	document authors. All rights reserved.

	This document is subject to BCP 78 and the IETF Trust's Legal	This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents	Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of	(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents	publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect	carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must	to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of	include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as	the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.	described in the Simplified BSD License.

	Table of Contents	Table of Contents

	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3

	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4	1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
	2. Interface Extensions Module . . . . . . . . . . . . . . . . . 4	2. Interface Extensions Module . . . . . . . . . . . . . . . . . 4
	2.1. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 5	2.1. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 6	2.2. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.2.1. Suppress Threshold . . . . . . . . . . . . . . . . . 7	2.2.1. Suppress Threshold . . . . . . . . . . . . . . . . . 7
	2.2.2. Half-Life Period . . . . . . . . . . . . . . . . . . 7	2.2.2. Half-Life Period . . . . . . . . . . . . . . . . . . 7
	2.2.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 7	2.2.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 7
	2.2.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 7	2.2.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 7
	2.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7	2.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7
	2.4. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 8	2.4. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.5. Maximum frame size . . . . . . . . . . . . . . . . . . . 8	2.5. Maximum frame size . . . . . . . . . . . . . . . . . . . 8
	2.6. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 8	2.6. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 8
	2.7. Forwarding Mode . . . . . . . . . . . . . . . . . . . . . 9	2.7. Forwarding Mode . . . . . . . . . . . . . . . . . . . . . 9
	3. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 9	3. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 9
	4. Interface Extensions YANG Module . . . . . . . . . . . . . . 10	4. Interface Extensions YANG Module . . . . . . . . . . . . . . 10

	5. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 20	5. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 21
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	6.1. Carrier delay configuration . . . . . . . . . . . . . . . 24	6.1. Carrier delay configuration . . . . . . . . . . . . . . . 25
	6.2. Dampening configuration . . . . . . . . . . . . . . . . . 25	6.2. Dampening configuration . . . . . . . . . . . . . . . . . 26
	6.3. MAC address configuration . . . . . . . . . . . . . . . . 26	6.3. MAC address configuration . . . . . . . . . . . . . . . . 27
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
	8. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 28	8. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	8.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 28	8.1. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 29
	8.2. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 28	8.2. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 29
	8.3. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 28	8.3. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 29
	8.4. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 28	8.4. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 29
	8.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 28	8.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 29
	8.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 28	8.6. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 29
	8.7. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 28	8.7. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 29
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29	8.8. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 30
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 29	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	10.1. ietf-if-extensions.yang . . . . . . . . . . . . . . . . 29	9.1. YANG Module Registrations . . . . . . . . . . . . . . . . 30
	10.2. ietf-if-ethernet-like.yang . . . . . . . . . . . . . . . 30	10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30	10.1. ietf-if-extensions.yang . . . . . . . . . . . . . . . . 31
	11.1. Normative References . . . . . . . . . . . . . . . . . . 30	10.2. ietf-if-ethernet-like.yang . . . . . . . . . . . . . . . 32
	11.2. Informative References . . . . . . . . . . . . . . . . . 31	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32	11.1. Normative References . . . . . . . . . . . . . . . . . . 32
		11.2. Informative References . . . . . . . . . . . . . . . . . 33

		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34

	1. Introduction	1. Introduction

	This document defines two NMDA compatible [RFC8342] YANG 1.1	This document defines two NMDA compatible [RFC8342] YANG 1.1
	[RFC7950] modules for the management of network interfaces. It	[RFC7950] modules for the management of network interfaces. It
	defines various augmentations to the generic interfaces data model	defines various augmentations to the generic interfaces data model
	[RFC8343] to support configuration of lower layer interface	[RFC8343] to support configuration of lower layer interface
	properties that are common across many types of network interface.	properties that are common across many types of network interface.

	One of the aims of this document is to provide a standard definition	One of the aims of this document is to provide a standard definition

	skipping to change at page 10, line 18 ¶	skipping to change at page 10, line 18 ¶
	augment /if:interfaces/if:interface:	augment /if:interfaces/if:interface:
	+--rw ethernet-like	+--rw ethernet-like
	+--rw mac-address? yang:mac-address	+--rw mac-address? yang:mac-address
	\| {configurable-mac-address}?	\| {configurable-mac-address}?
	+--ro bia-mac-address? yang:mac-address	+--ro bia-mac-address? yang:mac-address
	augment /if:interfaces/if:interface/if:statistics:	augment /if:interfaces/if:interface/if:statistics:
	+--ro in-drop-unknown-dest-mac-pkts? yang:counter64	+--ro in-drop-unknown-dest-mac-pkts? yang:counter64

	4. Interface Extensions YANG Module	4. Interface Extensions YANG Module


	This YANG module augments the interface container defined in RFC 8343	This YANG module augments the interface container defined in
	[RFC8343].	[RFC8343]. It also contains references to [RFC6991] and [RFC7224].

	<CODE BEGINS> file "ietf-if-extensions@2019-11-04.yang"	<CODE BEGINS> file "ietf-if-extensions@2019-11-04.yang"
	module ietf-if-extensions {	module ietf-if-extensions {
	yang-version 1.1;	yang-version 1.1;

	namespace "urn:ietf:params:xml:ns:yang:ietf-if-extensions";	namespace "urn:ietf:params:xml:ns:yang:ietf-if-extensions";

	prefix if-ext;	prefix if-ext;

	import ietf-yang-types {	import ietf-yang-types {

	skipping to change at page 11, line 39 ¶	skipping to change at page 11, line 39 ¶
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
	'MAY', and 'OPTIONAL' in this document are to be interpreted as	'MAY', and 'OPTIONAL' in this document are to be interpreted as
	described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,	described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
	they appear in all capitals, as shown here.";	they appear in all capitals, as shown here.";

	revision 2019-11-04 {	revision 2019-11-04 {
	description	description
	"Initial revision.";	"Initial revision.";

	reference	reference

	"RFC XXX, Common Interface Extension YANG Data Models";	"RFC XXXX, Common Interface Extension YANG Data Models";
	}	}

	feature carrier-delay {	feature carrier-delay {
	description	description

	"This feature indicates that configurable interface	"This feature indicates that configurable interface carrier
	carrier delay is supported, which is a feature is used to	delay is supported, which is a feature is used to limit the
	limit the propagation of very short interface link state	propagation of very short interface link state flaps.";
	flaps.";	reference "RFC XXXX, Section 2.1 Carrier Delay";
	reference "RFC XXX, Section 2.1 Carrier Delay";
	}	}

	feature dampening {	feature dampening {
	description	description
	"This feature indicates that the device supports interface	"This feature indicates that the device supports interface
	dampening, which is a feature that is used to limit the	dampening, which is a feature that is used to limit the
	propagation of interface link state flaps over longer	propagation of interface link state flaps over longer
	periods.";	periods.";

	reference "RFC XXX, Section 2.2 Dampening";	reference "RFC XXXX, Section 2.2 Dampening";
	}	}

	feature loopback {	feature loopback {
	description	description

	"This feature indicates that configurable interface loopback	"This feature indicates that configurable interface loopback is
	is supported.";	supported.";
	reference "RFC XXX, Section 2.4 Loopback";	reference "RFC XXXX, Section 2.4 Loopback";
	}	}

	feature max-frame-size {	feature max-frame-size {
	description	description

	"This feature indicates that the device supports configuring	"This feature indicates that the device supports configuring or
	or reporting the maximum frame size on interfaces.";	reporting the maximum frame size on interfaces.";
	reference "RFC XXX, Section 2.5 Maximum Frame Size";	reference "RFC XXXX, Section 2.5 Maximum Frame Size";
	}	}

	feature sub-interfaces {	feature sub-interfaces {
	description	description
	"This feature indicates that the device supports the	"This feature indicates that the device supports the
	instantiation of sub-interfaces. Sub-interfaces are defined	instantiation of sub-interfaces. Sub-interfaces are defined
	as logical child interfaces that allow features and forwarding	as logical child interfaces that allow features and forwarding
	decisions to be applied to a subset of the traffic processed	decisions to be applied to a subset of the traffic processed
	on the specified parent interface.";	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	* Define common identities to help allow interface types to be
	* assigned properties.	* assigned properties.
	*/	*/
	identity sub-interface {	identity sub-interface {
	description	description
	"Base type for generic sub-interfaces.	"Base type for generic sub-interfaces.

	New or custom interface types can derive from this type to	New or custom interface types can derive from this type to
	inherit generic sub-interface configuration.";	inherit generic sub-interface configuration.";

	reference "RFC XXX, Section 2.6 Sub-interface";	reference "RFC XXXX, Section 2.6 Sub-interface";
	}	}

	identity ethSubInterface{	identity ethSubInterface{
	base ianaift:l2vlan;	base ianaift:l2vlan;
	base sub-interface;	base sub-interface;
	description	description
	"This identity represents the child sub-interface of any	"This identity represents the child sub-interface of any
	interface types that uses Ethernet framing (with or without	interface types that uses Ethernet framing (with or without
	802.1Q tagging).";	802.1Q tagging).";
	}	}

	identity loopback {	identity loopback {
	description "Base identity for interface loopback options";	description "Base identity for interface loopback options";

	reference "RFC XXX, Section 2.4";	reference "RFC XXXX, Section 2.4";
	}	}
	identity internal {	identity internal {
	base loopback;	base loopback;
	description	description
	"All egress traffic on the interface is internally looped back	"All egress traffic on the interface is internally looped back
	within the interface to be received on the ingress path.";	within the interface to be received on the ingress path.";

	reference "RFC XXX, Section 2.4";	reference "RFC XXXX, Section 2.4";
	}	}
	identity line {	identity line {
	base loopback;	base loopback;
	description	description
	"All ingress traffic received on the interface is internally	"All ingress traffic received on the interface is internally
	looped back within the interface to the egress path.";	looped back within the interface to the egress path.";

	reference "RFC XXX, Section 2.4";	reference "RFC XXXX, Section 2.4";
	}	}
	identity connector {	identity connector {
	base loopback;	base loopback;
	description	description
	"The interface has a physical loopback connector attached that	"The interface has a physical loopback connector attached that
	loops all egress traffic back into the interface's ingress	loops all egress traffic back into the interface's ingress
	path, with equivalent semantics to loopback internal.";	path, with equivalent semantics to loopback internal.";

	reference "RFC XXX, Section 2.4";	reference "RFC XXXX, Section 2.4";
	}	}

	identity forwarding-mode {	identity forwarding-mode {
	description "Base identity for forwarding-mode options.";	description "Base identity for forwarding-mode options.";

	reference "RFC XXX, Section 2.7";	reference "RFC XXXX, Section 2.7";
	}	}
	identity physical {	identity physical {
	base forwarding-mode;	base forwarding-mode;
	description	description
	"Physical layer forwarding. This includes DWDM or OTN based	"Physical layer forwarding. This includes DWDM or OTN based
	optical switching.";	optical switching.";

	reference "RFC XXX, Section 2.7";	reference "RFC XXXX, Section 2.7";
	}	}
	identity data-link {	identity data-link {
	base forwarding-mode;	base forwarding-mode;
	description	description
	"Layer 2 based forwarding, such as Ethernet/VLAN based	"Layer 2 based forwarding, such as Ethernet/VLAN based
	switching, or L2VPN services.";	switching, or L2VPN services.";

	reference "RFC XXX, Section 2.7";	reference "RFC XXXX, Section 2.7";
	}	}
	identity network {	identity network {
	base forwarding-mode;	base forwarding-mode;
	description	description
	"Network layer based forwarding, such as IP, MPLS, or L3VPNs.";	"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	* Augments the IETF interfaces model with leaves to configure
	* and monitor carrier-delay on an interface.	* and monitor carrier-delay on an interface.
	*/	*/
	augment "/if:interfaces/if:interface" {	augment "/if:interfaces/if:interface" {
	description	description
	"Augments the IETF interface model with optional common	"Augments the IETF interface model with optional common
	interface level commands that are not formally covered by any	interface level commands that are not formally covered by any

	skipping to change at page 15, line 49 ¶	skipping to change at page 15, line 49 ¶
	actually down.";	actually down.";
	}	}
	}	}
	config false;	config false;
	description	description
	"Reports whether a carrier delay timer is actively running,	"Reports whether a carrier delay timer is actively running,
	in which case the interface state does not match the	in which case the interface state does not match the
	underlying carrier state.";	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	* Augments the IETF interfaces model with a container to hold
	* generic interface dampening	* generic interface dampening
	*/	*/
	container dampening {	container dampening {
	if-feature "dampening";	if-feature "dampening";
	presence	presence
	"Enable interface link flap dampening with default settings	"Enable interface link flap dampening with default settings
	(that are vendor/device specific).";	(that are vendor/device specific).";
	description	description
	"Interface dampening limits the propagation of interface link	"Interface dampening limits the propagation of interface link
	state flaps over longer periods.";	state flaps over longer periods.";

	reference "RFC XXX, Section 2.2 Dampening";	reference "RFC XXXX, Section 2.2 Dampening";

	leaf half-life {	leaf half-life {
	type uint32;	type uint32;
	units seconds;	units seconds;
	description	description
	"The time (in seconds) after which a penalty would be half	"The time (in seconds) after which a penalty would be half
	its original value. Once the interface has been assigned	its original value. Once the interface has been assigned
	a penalty, the penalty is decreased at a decay rate	a penalty, the penalty is decreased at a decay rate
	equivalent to the half-life. For some devices, the	equivalent to the half-life. For some devices, the
	allowed values may be restricted to particular multiples	allowed values may be restricted to particular multiples
	of seconds. The default value is vendor/device	of seconds. The default value is vendor/device
	specific.";	specific.";

	reference "RFC XXX, Section 2.3.2 Half-Life Period";	reference "RFC XXXX, Section 2.3.2 Half-Life Period";
	}	}

	leaf reuse {	leaf reuse {
	type uint32;	type uint32;
	description	description
	"Penalty value below which a stable interface is	"Penalty value below which a stable interface is
	unsuppressed (i.e. brought up) (no units). The default	unsuppressed (i.e. brought up) (no units). The default
	value is vendor/device specific. The penalty value for a	value is vendor/device specific. The penalty value for a
	link up->down state change is 1000 units.";	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 {	leaf suppress {
	type uint32;	type uint32;
	description	description
	"Limit at which an interface is suppressed (i.e. held down)	"Limit at which an interface is suppressed (i.e. held down)
	when its penalty exceeds that limit (no units). The value	when its penalty exceeds that limit (no units). The value
	must be greater than the reuse threshold. The default	must be greater than the reuse threshold. The default
	value is vendor/device specific. The penalty value for a	value is vendor/device specific. The penalty value for a
	link up->down state change is 1000 units.";	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 {	leaf max-suppress-time {
	type uint32;	type uint32;
	units seconds;	units seconds;
	description	description
	"Maximum time (in seconds) that an interface can be	"Maximum time (in seconds) that an interface can be
	suppressed before being unsuppressed if no further link	suppressed before being unsuppressed if no further link
	up->down state change penalties have been applied. This	up->down state change penalties have been applied. This
	value effectively acts as a ceiling that the penalty value	value effectively acts as a ceiling that the penalty value
	cannot exceed. The default value is vendor/device	cannot exceed. The default value is vendor/device
	specific.";	specific.";

	reference "RFC XXX, Section 2.2.4 Maximum Suppress Time";	reference "RFC XXXX, Section 2.2.4 Maximum Suppress Time";
	}	}

	leaf penalty {	leaf penalty {
	type uint32;	type uint32;
	config false;	config false;
	description	description
	"The current penalty value for this interface. When the	"The current penalty value for this interface. When the
	penalty value exceeds the 'suppress' leaf then the	penalty value exceeds the 'suppress' leaf then the
	interface is suppressed (i.e. held down).";	interface is suppressed (i.e. held down).";

	reference "RFC XXX, Section 2.2 Dampening";	reference "RFC XXXX, Section 2.2 Dampening";
	}	}

	leaf suppressed {	leaf suppressed {
	type boolean;	type boolean;
	config false;	config false;
	description	description
	"Represents whether the interface is suppressed (i.e. held	"Represents whether the interface is suppressed (i.e. held
	down) because the 'penalty' leaf value exceeds the	down) because the 'penalty' leaf value exceeds the
	'suppress' leaf.";	'suppress' leaf.";

	reference "RFC XXX, Section 2.2 Dampening";	reference "RFC XXXX, Section 2.2 Dampening";
	}	}

	leaf time-remaining {	leaf time-remaining {
	when '../suppressed = "true"' {	when '../suppressed = "true"' {
	description	description
	"Only suppressed interfaces have a time remaining.";	"Only suppressed interfaces have a time remaining.";
	}	}
	type uint32;	type uint32;
	units seconds;	units seconds;
	config false;	config false;
	description	description
	"For a suppressed interface, this leaf represents how long	"For a suppressed interface, this leaf represents how long
	(in seconds) that the interface will remain suppressed	(in seconds) that the interface will remain suppressed
	before it is allowed to go back up again.";	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	* Various types of interfaces support a configurable layer 2
	* encapsulation, any that are supported by YANG should be	* encapsulation, any that are supported by YANG should be
	* listed here.	* listed here.
	*	*
	* Different encapsulations can hook into the common encaps-type	* Different encapsulations can hook into the common encaps-type
	* choice statement.	* choice statement.
	*/	*/

	skipping to change at page 18, line 34 ¶	skipping to change at page 18, line 34 ¶
	"All interface types that can have a configurable L2	"All interface types that can have a configurable L2
	encapsulation.";	encapsulation.";
	}	}

	description	description
	"Holds the OSI layer 2 encapsulation associated with an	"Holds the OSI layer 2 encapsulation associated with an
	interface.";	interface.";
	choice encaps-type {	choice encaps-type {
	description	description
	"Extensible choice of layer 2 encapsulations";	"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,	* Various types of interfaces support loopback configuration,
	* any that are supported by YANG should be listed here.	* any that are supported by YANG should be listed here.
	*/	*/
	leaf loopback {	leaf loopback {
	when "derived-from-or-self(../if:type,	when "derived-from-or-self(../if:type,
	'ianaift:ethernetCsmacd') or	'ianaift:ethernetCsmacd') or

	skipping to change at page 19, line 8 ¶	skipping to change at page 19, line 8 ¶
	derived-from-or-self(../if:type, 'ianaift:atm') or	derived-from-or-self(../if:type, 'ianaift:atm') or
	derived-from-or-self(../if:type, 'ianaift:otnOtu')" {	derived-from-or-self(../if:type, 'ianaift:otnOtu')" {
	description	description
	"All interface types that support loopback configuration.";	"All interface types that support loopback configuration.";
	}	}
	if-feature "loopback";	if-feature "loopback";
	type identityref {	type identityref {
	base loopback;	base loopback;
	}	}
	description "Enables traffic 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.	* Allows the maximum frame size to be configured or reported.
	*/	*/
	leaf max-frame-size {	leaf max-frame-size {
	if-feature "max-frame-size";	if-feature "max-frame-size";
	type uint32 {	type uint32 {
	range "64 .. max";	range "64 .. max";
	}	}

	skipping to change at page 19, line 30 ¶	skipping to change at page 19, line 30 ¶
	"The maximum size of layer 2 frames that may be transmitted	"The maximum size of layer 2 frames that may be transmitted
	or received on the interface (including any frame header,	or received on the interface (including any frame header,
	maximum frame payload size, and frame checksum sequence).	maximum frame payload size, and frame checksum sequence).

	If configured, the max-frame-size also limits the maximum	If configured, the max-frame-size also limits the maximum
	frame size of any child sub-interfaces. The MTU available	frame size of any child sub-interfaces. The MTU available
	to higher layer protocols is restricted to the maximum frame	to higher layer protocols is restricted to the maximum frame
	payload size, and MAY be further restricted by explicit	payload size, and MAY be further restricted by explicit
	layer 3 or protocol specific MTU configuration.";	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	* Augments the IETF interfaces model with a leaf that indicates
	* which mode, or layer, is being used to forward the traffic.	* which mode, or layer, is being used to forward the traffic.
	*/	*/
	leaf forwarding-mode {	leaf forwarding-mode {
	type identityref {	type identityref {
	base forwarding-mode;	base forwarding-mode;
	}	}
	config false;	config false;

	description	description
	"The forwarding mode that the interface is operating in.";	"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.	* Add generic support for sub-interfaces.
	*	*
	* This should be extended to cover all interface types that are	* This should be extended to cover all interface types that are
	* child interfaces of other interfaces.	* child interfaces of other interfaces.
	*/	*/
	augment "/if:interfaces/if:interface" {	augment "/if:interfaces/if:interface" {

	skipping to change at page 20, line 28 ¶	skipping to change at page 20, line 28 ¶
	"Adds a parent interface field to interfaces that model	"Adds a parent interface field to interfaces that model
	sub-interfaces.";	sub-interfaces.";
	leaf parent-interface {	leaf parent-interface {

	type if:interface-ref;	type if:interface-ref;

	mandatory true;	mandatory true;
	description	description
	"This is the reference to the parent interface of this	"This is the reference to the parent interface of this
	sub-interface.";	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).";
	}	}
	}	}
	}	}
	<CODE ENDS>	<CODE ENDS>

	5. Interfaces Ethernet-Like YANG Module	5. Interfaces Ethernet-Like YANG Module

	This YANG module augments the interface container defined in RFC 8343	This YANG module augments the interface container defined in RFC 8343
	[RFC8343] for Ethernet-like interfaces. This includes Ethernet	[RFC8343] for Ethernet-like interfaces. This includes Ethernet

	interfaces, 802.3 LAG (802.1AX) interfaces, VLAN sub-interfaces,	interfaces, 802.3 LAG (802.1AX) interfaces, Switch Virtual
	Switch Virtual interfaces, and Pseudo-Wire Head-End interfaces.	interfaces, and Pseudo-Wire Head-End interfaces. It also contains
		references to [RFC6991], [RFC7224], and [IEEE802.3.2-2019].


	<CODE BEGINS> file "ietf-if-ethernet-like@2019-11-04.yang"	<CODE BEGINS> file "ietf-if-ethernet-like@2019-11-04.yang"
	module ietf-if-ethernet-like {	module ietf-if-ethernet-like {
	yang-version 1.1;	yang-version 1.1;


	namespace	namespace
	"urn:ietf:params:xml:ns:yang:ietf-if-ethernet-like";	"urn:ietf:params:xml:ns:yang:ietf-if-ethernet-like";


	prefix ethlike;	prefix ethlike;
	import ietf-interfaces {
	prefix if;
	reference
	"RFC 8343: A YANG Data Model For Interface Management";
	}


	import ietf-yang-types {	import ietf-interfaces {
	prefix yang;	prefix if;
	reference "RFC 6991: Common YANG Data Types";	reference
	}	"RFC 8343: A YANG Data Model For Interface Management";


	import iana-if-type {	}
	prefix ianaift;
	reference "RFC 7224: IANA Interface Type YANG Module";
	}


	organization	import ietf-yang-types {
	"IETF NETMOD (NETCONF Data Modeling Language) Working Group";	prefix yang;
		reference "RFC 6991: Common YANG Data Types";
		}


	contact	import iana-if-type {
	"WG Web: <http://tools.ietf.org/wg/netmod/>	prefix ianaift;
	WG List: <mailto:netmod@ietf.org>	reference "RFC 7224: IANA Interface Type YANG Module";
		}


	Editor: Robert Wilton	organization
	<mailto:rwilton@cisco.com>";	"IETF NETMOD (NETCONF Data Modeling Language) Working Group";


	description	contact
	"This module contains YANG definitions for configuration for	"WG Web: <http://tools.ietf.org/wg/netmod/>
	'Ethernet-like' interfaces. It is applicable to all interface	WG List: <mailto:netmod@ietf.org>
	types that use Ethernet framing and expose an Ethernet MAC
	layer, and includes such interfaces as physical Ethernet
	interfaces, Ethernet LAG interfaces and VLAN sub-interfaces.


	Additional interface configuration and counters for physical	Editor: Robert Wilton
	Ethernet interfaces are defined in	<mailto:rwilton@cisco.com>";
	ieee802-ethernet-interface.yang, as part of IEEE Std
	802.3.2-2019.


	Copyright (c) 2019 IETF Trust and the persons identified as	description
	authors of the code. All rights reserved.	"This module contains YANG definitions for configuration for
		'Ethernet-like' interfaces. It is applicable to all interface
		types that use Ethernet framing and expose an Ethernet MAC
		layer, and includes such interfaces as physical Ethernet
		interfaces, Ethernet LAG interfaces and VLAN sub-interfaces.


	Redistribution and use in source and binary forms, with or	Additional interface configuration and counters for physical
	without modification, is permitted pursuant to, and subject to	Ethernet interfaces are defined in
	the license terms contained in, the Simplified BSD License set	ieee802-ethernet-interface.yang, as part of IEEE Std
	forth in Section 4.c of the IETF Trust's Legal Provisions	802.3.2-2019.
	Relating to IETF Documents
	(https://trustee.ietf.org/license-info).


	This version of this YANG module is part of RFC XXXX	Copyright (c) 2019 IETF Trust and the persons identified as
	(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself	authors of the code. All rights reserved.
	for full legal notices.";


	revision 2019-11-04 {	Redistribution and use in source and binary forms, with or
	description "Initial revision.";	without modification, is permitted pursuant to, and subject to
		the license terms contained in, the Simplified BSD License set
		forth in Section 4.c of the IETF Trust's Legal Provisions
		Relating to IETF Documents
		(https://trustee.ietf.org/license-info).


	reference	This version of this YANG module is part of RFC XXXX
	"RFC XXX, Common Interface Extension YANG Data Models";	(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
	}	for full legal notices.";


	feature configurable-mac-address {	revision 2019-11-04 {
	description	description "Initial revision.";
	"This feature indicates that MAC addresses on Ethernet-like
	interfaces can be configured.";
	reference "RFC XXX, Section 3 Interfaces Ethernet-Like Module";
	}


	/*	reference
	* Configuration parameters for Ethernet-like interfaces.	"RFC XXXX, Common Interface Extension YANG Data Models";
	*/	}
	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";
	}
	description
	"Augment the interface model with parameters for all
	Ethernet-like interfaces.";


	container ethernet-like {	feature configurable-mac-address {
	description	description
	"Contains parameters for interfaces that use Ethernet framing	"This feature indicates that MAC addresses on Ethernet-like
	and expose an Ethernet MAC layer.";	interfaces can be configured.";
		reference
		"RFC XXXX, Section 3, Interfaces Ethernet-Like Module";
		}


	leaf mac-address {	/*
	if-feature "configurable-mac-address";	* Configuration parameters for Ethernet-like interfaces.
	type yang:mac-address;	*/
	description	augment "/if:interfaces/if:interface" {
	"The MAC address of the interface. The operational value	when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or
	matches the /if:interfaces/if:interface/if:phys-address	derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or
	leaf defined in ietf-interface.yang.";	derived-from-or-self(if:type, 'ianaift:ifPwType')" {
	}	description "Applies to all Ethernet-like interfaces";
		}
		description
		"Augment the interface model with parameters for all
		Ethernet-like interfaces.";


	leaf bia-mac-address {	container ethernet-like {
	type yang:mac-address;	description
	config false;	"Contains parameters for interfaces that use Ethernet framing
	description	and expose an Ethernet MAC layer.";
	"The 'burnt-in' MAC address. I.e the default MAC address
	assigned to the interface if no MAC address has been
	explicitly configured on it.";
	}
	}
	}


	/*	leaf mac-address {
	* Configuration parameters for Ethernet-like interfaces.	if-feature "configurable-mac-address";
	*/	type yang:mac-address;
	augment "/if:interfaces/if:interface/if:statistics" {	description
	when "derived-from-or-self(../if:type,	"The MAC address of the interface. The operational value
	'ianaift:ethernetCsmacd') or	matches the /if:interfaces/if:interface/if:phys-address
	derived-from-or-self(../if:type,	leaf defined in ietf-interface.yang.";
	'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 bia-mac-address {
	type yang:counter64;	type yang:mac-address;
	units frames;	config false;
	description	description
	"A count of the number of frames that were well formed, but	"The 'burnt-in' MAC address. I.e the default MAC address
	otherwise dropped because the destination MAC address did	assigned to the interface if no MAC address has been
	not pass any ingress destination MAC address filter.	explicitly configured on it.";
		}
		}
		}


	For consistency, frames counted against this drop counters	/*
	are also counted against the IETF interfaces statistics. In	* Configuration parameters for Ethernet-like interfaces.
	particular, they are included in in-octets and in-discards,	*/
	but are not included in in-unicast-pkts, in-multicast-pkts	augment "/if:interfaces/if:interface/if:statistics" {
	or in-broadcast-pkts, because they are not delivered to a	when "derived-from-or-self(../if:type,
	higher layer.	'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.";


	Discontinuities in the values of this counter can occur at	leaf in-discard-unknown-dest-mac-pkts {
	re-initialization of the management system, and at other	type yang:counter64;
	times as indicated by the value of the 'discontinuity-time'	units frames;
	leaf defined in the ietf-interfaces YANG module (RFC 8343).";	description
	}	"A count of the number of frames that were well formed, but
	}	otherwise discarded because the destination MAC address did
	}	not pass any ingress destination MAC address filter.
	<CODE ENDS>
		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).";
		}
		}
		}
		<CODE ENDS>

	6. Examples	6. Examples

	The following sections give some examples of how different parts of	The following sections give some examples of how different parts of
	the YANG modules could be used. Examples are not given for the more	the YANG modules could be used. Examples are not given for the more
	trivial configuration, or for sub-interfaces, for which examples are	trivial configuration, or for sub-interfaces, for which examples are
	contained in [I-D.ietf-netmod-sub-intf-vlan-model].	contained in [I-D.ietf-netmod-sub-intf-vlan-model].

	6.1. Carrier delay configuration	6.1. Carrier delay configuration


	skipping to change at page 28, line 17 ¶	skipping to change at page 29, line 17 ¶
	The authors wish to thank Eric Gray, Ing-Wher Chen, Jon Culver,	The authors wish to thank Eric Gray, Ing-Wher Chen, Jon Culver,
	Juergen Schoenwaelder, Ladislav Lhotka, Lou Berger, Mahesh	Juergen Schoenwaelder, Ladislav Lhotka, Lou Berger, Mahesh
	Jethanandani, Martin Bjorklund, Michael Zitao, Neil Ketley, Qin Wu,	Jethanandani, Martin Bjorklund, Michael Zitao, Neil Ketley, Qin Wu,
	William Lupton, Xufeng Liu, Andy Bierman, and Vladimir Vassilev for	William Lupton, Xufeng Liu, Andy Bierman, and Vladimir Vassilev for
	their helpful comments contributing to this document.	their helpful comments contributing to this document.

	8. ChangeLog	8. ChangeLog

	XXX, RFC Editor, please delete this change log before publication.	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.	o Initial updates after WG LC comments.


	8.2. Version -07	8.3. Version -07

	o Minor editorial updates	o Minor editorial updates


	8.3. Version -06	8.4. Version -06

	o Remove reservable-bandwidth, based on Acee's suggestion	o Remove reservable-bandwidth, based on Acee's suggestion

	o Add examples	o Add examples

	o Add additional state parameters for carrier-delay and dampening	o Add additional state parameters for carrier-delay and dampening


	8.4. Version -05	8.5. Version -05

	o Incorporate feedback from Andy Bierman	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.	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	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-	o Minor changes only: Fix errors in when statements, use derived-
	from-or-self() for future proofing.	from-or-self() for future proofing.

	9. IANA Considerations	9. IANA Considerations


	This document defines several new YANG module and the authors	9.1. YANG Module Registrations
	politely request that IANA assigns unique names to the two YANG
	module files contained within this document, and also appropriate	The following YANG modules are requested to be registred in the IANA
	URIs in the "IETF XML Registry".	"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	10. Security Considerations

	The YANG module defined in this memo is designed to be accessed via	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 NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is
	the secure transport layer and the mandatory to implement secure	the secure transport layer and the mandatory to implement secure
	transport is SSH RFC 6242 [RFC6242]. The NETCONF access control	transport is SSH RFC 6242 [RFC6242]. The NETCONF access control
	model RFC 6536 [RFC6536] provides the means to restrict access for	model RFC 6536 [RFC6536] provides the means to restrict access for
	particular NETCONF users to a pre-configured subset of all available	particular NETCONF users to a pre-configured subset of all available
	NETCONF protocol operations and content.	NETCONF protocol operations and content.

	skipping to change at page 31, line 5 ¶	skipping to change at page 32, line 42 ¶

	11. References	11. References

	11.1. Normative References	11.1. Normative References

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.	<https://www.rfc-editor.org/info/rfc2119>.


		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
		DOI 10.17487/RFC3688, January 2004,
		<https://www.rfc-editor.org/info/rfc3688>.

		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
		the Network Configuration Protocol (NETCONF)", RFC 6020,
		DOI 10.17487/RFC6020, October 2010,
		<https://www.rfc-editor.org/info/rfc6020>.

	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,	RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.	<https://www.rfc-editor.org/info/rfc7950>.

	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.	May 2017, <https://www.rfc-editor.org/info/rfc8174>.

	[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,	[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
	and R. Wilton, "Network Management Datastore Architecture	and R. Wilton, "Network Management Datastore Architecture

	skipping to change at page 31, line 27 ¶	skipping to change at page 33, line 27 ¶

	[RFC8343] Bjorklund, M., "A YANG Data Model for Interface	[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
	Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,	Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
	<https://www.rfc-editor.org/info/rfc8343>.	<https://www.rfc-editor.org/info/rfc8343>.

	11.2. Informative References	11.2. Informative References

	[I-D.ietf-netmod-sub-intf-vlan-model]	[I-D.ietf-netmod-sub-intf-vlan-model]
	Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.	Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.
	Sivaraj, "Sub-interface VLAN YANG Data Models", draft-	Sivaraj, "Sub-interface VLAN YANG Data Models", draft-

	ietf-netmod-sub-intf-vlan-model-05 (work in progress),	ietf-netmod-sub-intf-vlan-model-06 (work in progress),
	March 2019.	November 2019.


	[IEEE802.3.2]	[IEEE802.3.2-2019]
	IEEE WG802.3 - Ethernet Working Group, "IEEE	IEEE WG802.3 - Ethernet Working Group, "IEEE
	802.3.2-2019", 2019.	802.3.2-2019", 2019.

	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol	and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.	<https://www.rfc-editor.org/info/rfc6241>.

	[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure	[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
	Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,	Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,

End of changes. 73 change blocks.
	210 lines changed or deleted	309 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/