draft-ietf-i2rs-yang-network-topo-02.txt		draft-ietf-i2rs-yang-network-topo-03.txt
	Network Working Group A. Clemm		Network Working Group A. Clemm
	Internet-Draft J. Medved		Internet-Draft J. Medved
	Intended status: Standards Track R. Varga		Intended status: Standards Track R. Varga
	Expires: June 10, 2016 T. Tkacik		Expires: December 11, 2016 T. Tkacik
	Cisco		Cisco
	N. Bahadur		N. Bahadur
	Bracket Computing		Bracket Computing
	H. Ananthakrishnan		H. Ananthakrishnan
	Packet Design		Packet Design
	December 8, 2015		X. Liu
			Kuatro Technologies
			June 9, 2016
	A Data Model for Network Topologies		A Data Model for Network Topologies
	draft-ietf-i2rs-yang-network-topo-02.txt		draft-ietf-i2rs-yang-network-topo-03.txt
	Abstract		Abstract
	This document defines an abstract (generic) YANG data model for		This document defines an abstract (generic) YANG data model for
	network/service topologies and inventories. The model serves as a		network/service topologies and inventories. The model serves as a
	base model which is augmented with technology-specific details in		base model which is augmented with technology-specific details in
	other, more specific topology and inventory models.		other, more specific topology and inventory models.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 41 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 June 10, 2016.		This Internet-Draft will expire on December 11, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 45 ¶
	3.4.3. Dealing with changes in underlay networks . . . . . . 13		3.4.3. Dealing with changes in underlay networks . . . . . . 13
	3.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 13		3.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 13
	3.4.5. Cardinality and directionality of links . . . . . . . 13		3.4.5. Cardinality and directionality of links . . . . . . . 13
	3.4.6. Multihoming and link aggregation . . . . . . . . . . 14		3.4.6. Multihoming and link aggregation . . . . . . . . . . 14
	3.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 14		3.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 14
	3.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 14		3.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 14
	3.4.9. Representing the same device in multiple networks . . 14		3.4.9. Representing the same device in multiple networks . . 14
	3.5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 15		3.5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 15
	3.5.1. Supporting client as well as server provided network		3.5.1. Supporting client as well as server provided network
	topology . . . . . . . . . . . . . . . . . . . . . . 16		topology . . . . . . . . . . . . . . . . . . . . . . 16
	3.5.2. Identifiers of string or URI type . . . . . . . . . . 16		3.5.2. Identifiers of string or URI type . . . . . . . . . . 17
	4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17		4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17
	4.1. Defining the Abstract Network: network.yang . . . . . . . 17		4.1. Defining the Abstract Network: network.yang . . . . . . . 17
	4.2. Creating Abstract Network Topology: network-topology.yang 21		4.2. Creating Abstract Network Topology: network-topology.yang 22
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 28		5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
	8.1. Normative References . . . . . . . . . . . . . . . . . . 28		8.1. Normative References . . . . . . . . . . . . . . . . . . 29
	8.2. Informative References . . . . . . . . . . . . . . . . . 29		8.2. Informative References . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
	1. Introduction		1. Introduction
	This document introduces an abstract (base) YANG [RFC6020] [RFC6021]		This document introduces an abstract (base) YANG [RFC6020] [RFC6021]
	data model to represent networks and topologies. The data model is		data model to represent networks and topologies. The data model is
	divided into two parts. The first part of the model defines a		divided into two parts. The first part of the model defines a
	network model that allows to define network hierarchies (i.e. network		network model that allows to define network hierarchies (i.e. network
	stacks) and to maintain an inventory of nodes contained in a network.		stacks) and to maintain an inventory of nodes contained in a network.
	The second part of the model augments the basic network model with		The second part of the model augments the basic network model with
	information to describe topology information. Specifically, it adds		information to describe topology information. Specifically, it adds
	skipping to change at page 8, line 16 ¶		skipping to change at page 8, line 16 ¶
	+--rw networks		+--rw networks
	| +--rw network* [network-id]		| +--rw network* [network-id]
	| +--rw network-types		| +--rw network-types
	| +--rw network-id network-id		| +--rw network-id network-id
	| +--rw supporting-network* [network-ref]		| +--rw supporting-network* [network-ref]
	| | +--rw network-ref -> /networks/network/network-id		| | +--rw network-ref -> /networks/network/network-id
	| +--rw node* [node-id]		| +--rw node* [node-id]
	| +--rw node-id node-id		| +--rw node-id node-id
	| +--rw supporting-node* [network-ref node-ref]		| +--rw supporting-node* [network-ref node-ref]
	| +--rw network-ref -> ../../../supporting-network/+		| +--rw network-ref -> ../../../supporting-network/+
	| | network-ref		| | network-ref
	| +--rw node-ref -> /networks/network/node/node-id		| +--rw node-ref -> /networks/network/node/node-id
	+--ro networks-state		+--ro networks-state
	+--ro network* [network-ref]		+--ro network* [network-ref]
	+--ro network-ref -> /networks/network/network-id		+--ro network-ref -> /networks/network/network-id
	+--ro server-provided? boolean		+--ro server-provided? boolean
	Figure 4: The structure of the abstract (base) network model		Figure 4: The structure of the abstract (base) network model
	The model contains a container with a list of networks, and a		The model contains a container with a list of networks, and a
	container with a list of network state.		container with a list of network state.
	skipping to change at page 10, line 33 ¶		skipping to change at page 10, line 33 ¶
	+--rw source		+--rw source
	| +--rw source-node -> ../../../nd:node/node-id		| +--rw source-node -> ../../../nd:node/node-id
	| +--rw source-tp? -> ../../../nd:node[nd:node-id=current()/+		| +--rw source-tp? -> ../../../nd:node[nd:node-id=current()/+
	| ../source-node]/termination-point/tp-id		| ../source-node]/termination-point/tp-id
	+--rw destination		+--rw destination
	| +--rw dest-node -> ../../../nd:node/node-id		| +--rw dest-node -> ../../../nd:node/node-id
	| +--rw dest-tp? -> ../../../nd:node[nd:node-id=current()/+		| +--rw dest-tp? -> ../../../nd:node[nd:node-id=current()/+
	| ../dest-node]/termination-point/tp-id		| ../dest-node]/termination-point/tp-id
	+--rw link-id link-id		+--rw link-id link-id
	+--rw supporting-link* [network-ref link-ref]		+--rw supporting-link* [network-ref link-ref]
	+--rw network-ref -> ../../../nd:supporting-network/		+--rw network-ref -> ../../../nd:supporting-network/+
	| network-ref		| network-ref
	+--rw link-ref -> /nd:networks/network[nd:network-id=+		+--rw link-ref -> /nd:networks/network[nd:network-id=+
	current()/../network-ref]/link/link-id		current()/../network-ref]/link/link-id
	augment /nd:networks/nd:network/nd:node:		augment /nd:networks/nd:network/nd:node:
	+--rw termination-point* [tp-id]		+--rw termination-point* [tp-id]
	+--rw tp-id tp-id		+--rw tp-id tp-id
	+--rw supporting-termination-point* [network-ref node-ref tp-ref]		+--rw supporting-termination-point* [network-ref node-ref tp-ref]
	+--rw network-ref -> ../../../nd:supporting-node/network-ref		+--rw network-ref -> ../../../nd:supporting-node/network-ref
	+--rw node-ref -> ../../../nd:supporting-node/node-ref		+--rw node-ref -> ../../../nd:supporting-node/node-ref
	+--rw tp-ref -> /nd:networks/network[nd:network-id=+		+--rw tp-ref -> /nd:networks/network[nd:network-id=+
	current()/../network-ref]/node+		current()/../network-ref]/node+
	[nd:node-id=current()/../node-ref]/+		[nd:node-id=current()/../node-ref]/+
	termination-point/tp-id		termination-point/tp-id
	Figure 5: The structure of the abstract (base) network topology model		Figure 5: The structure of the abstract (base) network topology model
	A node has a list of termination points that are used to terminate		A node has a list of termination points that are used to terminate
	links. An example of a termination point might be a physical or		links. An example of a termination point might be a physical or
	logical port or, more generally, an interface.		logical port or, more generally, an interface.
	Like a node, a termination point can in turn be supported by an		Like a node, a termination point can in turn be supported by an
	underlying termination point, contained in the supporting node of the		underlying termination point, contained in the supporting node of the
	underlay network.		underlay network.
	skipping to change at page 16, line 19 ¶		skipping to change at page 16, line 19 ¶
	captured in one coherent model. In most cases network topology		captured in one coherent model. In most cases network topology
	information is discovered about a network; the topology is considered		information is discovered about a network; the topology is considered
	a property of the network that is reflected in the model. That said,		a property of the network that is reflected in the model. That said,
	it is conceivable that certain types of topology need to also be		it is conceivable that certain types of topology need to also be
	configurable by an application.		configurable by an application.
	There are several alternatives in which this can be addressed. The		There are several alternatives in which this can be addressed. The
	alternative chosen in this draft does not restrict network topology		alternative chosen in this draft does not restrict network topology
	information as read-only, but includes a state that indicates for		information as read-only, but includes a state that indicates for
	each network whether it is populated by the server or by a client		each network whether it is populated by the server or by a client
	application. (The drawback of this solution is that it stretches its		application. The drawback of this solution is that it stretches its
	use of the configuration concept. Configuration information is		use of the configuration concept. Configuration information in
	subject to backup and restore, which is not applicable to server-		general is subject to backup and restore, which is not applicable to
	provided information. Perhaps more serious is the ability of a		server-provided information. Perhaps more serious is the ability of
	client to lock a configuration and thus prevent changes to server-		a client to lock a configuration and thus prevent changes to server-
	provided network topology while the lock is in effect. Preventing		provided network topology while the lock is in effect. Preventing
	this requires special treatment of network topology related		this requires special treatment of network topology related
	configuration information.)		configuration information.
	In another alternative, all information about network topology that		In another alternative, all information about network topology that
	is in effect is represented as network state, i.e. as read-only		is in effect is represented as network state, i.e. as read-only
	information, regardless of how it came into being. For cases where		information, regardless of how it came into being. For cases where
	network topology needs to be configured, a second branch for		network topology needs to be configured, a second branch for
	configurable topology information is introduced. Any network		configurable topology information is introduced. Any network
	topology configuration is mirrored by network state information. A		topology configuration is mirrored by network state information. A
	configurable network will thus be represented twice: once in the		configurable network will thus be represented twice: once in the
	read-only list of all networks, a second time in a configuration		read-only list of all networks, a second time in a configuration
	sandbox. (The drawback of this solution is slightly increased		sandbox. The drawback of this solution is increased complexity of
	complexity of augmentations due to two target branches.		augmentations due to two target branches.
			A third alternative would make use of YANG metadata
			[I-D.draft-ietf-netmod-yang-metadata]. Topology information
			represents configuration data. In addition, a new metadata tag is
			introduced to be able to tag data populated by the server as server-
			provided. This could be a boolean, or even a type "empty". The
			semantics of the tag is that it is applied to any topology data that
			comes into being (respectively is configured) by an embedded
			application on the network, as opposed to e.g. a controller
			application. The metadata will be set automatically by the server as
			applicable.
	3.5.2. Identifiers of string or URI type		3.5.2. Identifiers of string or URI type
	The current model defines identifiers of nodes, networks, links, and		The current model defines identifiers of nodes, networks, links, and
	termination points as URIs. An alternative would define them as		termination points as URIs. An alternative would define them as
	string.		string.
	The case for strings is that they will be easier to implement. The		The case for strings is that they will be easier to implement. The
	reason for choosing URIs is that the topology/node/tp exists in a		reason for choosing URIs is that the topology/node/tp exists in a
	larger context, hence it is useful to be able to correlate		larger context, hence it is useful to be able to correlate
	skipping to change at page 17, line 15 ¶		skipping to change at page 17, line 29 ¶
	data. A URI makes the structure explicit and also attaches		data. A URI makes the structure explicit and also attaches
	additional semantics: the URI, unlike a free-form string, can be fed		additional semantics: the URI, unlike a free-form string, can be fed
	into a URI resolver, which can point to additional resources		into a URI resolver, which can point to additional resources
	associated with the URI. This property is important when the		associated with the URI. This property is important when the
	topology data is integrated into a larger, more complex system.		topology data is integrated into a larger, more complex system.
	4. YANG Modules		4. YANG Modules
	4.1. Defining the Abstract Network: network.yang		4.1. Defining the Abstract Network: network.yang
	<CODE BEGINS> file "ietf-network@2015-12-08.yang"		<CODE BEGINS> file "ietf-network@2016-06-09.yang"
	module ietf-network {		module ietf-network {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-network";		namespace "urn:ietf:params:xml:ns:yang:ietf-network";
	prefix nd;		prefix nd;
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	}		}
	organization		organization
	"IETF I2RS (Interface to the Routing System) Working Group";		"IETF I2RS (Interface to the Routing System) Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/i2rs/>		"WG Web: <http://tools.ietf.org/wg/i2rs/>
	WG List: <mailto:i2rs@ietf.org>		WG List: <mailto:i2rs@ietf.org>
	WG Chair: Susan Hares		WG Chair: Susan Hares
	<mailto:shares@ndzh.com>		<mailto:shares@ndzh.com>
	WG Chair: Jeffrey Haas		WG Chair: Russ White
	<mailto:jhaas@pfrc.org>		<mailto:russ@riw.us>
	Editor: Alexander Clemm		Editor: Alexander Clemm
	<mailto:alex@cisco.com>		<mailto:alex@cisco.com>
	Editor: Jan Medved		Editor: Jan Medved
	<mailto:jmedved@cisco.com>		<mailto:jmedved@cisco.com>
	Editor: Robert Varga		Editor: Robert Varga
	<mailto:rovarga@cisco.com>		<mailto:rovarga@cisco.com>
	Editor: Tony Tkacik		Editor: Tony Tkacik
	<mailto:ttkacik@cisco.com>		<mailto:ttkacik@cisco.com>
	Editor: Nitin Bahadur		Editor: Nitin Bahadur
	<mailto:nitin_bahadur@yahoo.com>		<mailto:nitin_bahadur@yahoo.com>
	Editor: Hariharan Ananthakrishnan		Editor: Hariharan Ananthakrishnan
	<mailto:hari@packetdesign.com>";		<mailto:hari@packetdesign.com>
			Editor: Xufeng Liu
			<mailto:xliu@kuatrotech.com>";
	description		description
	"This module defines a common base model for a collection		"This module defines a common base model for a collection
	of nodes in a network. Node definitions are further used		of nodes in a network. Node definitions are further used
	in network topologies and inventories.		in network topologies and inventories.
	Copyright (c) 2015 IETF Trust and the persons identified as		Copyright (c) 2016 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of		This version of this YANG module is part of
	draft-ietf-i2rs-yang-network-topo-02;		draft-ietf-i2rs-yang-network-topo-03;
	see the RFC itself for full legal notices.		see the RFC itself for full legal notices.
	NOTE TO RFC EDITOR: Please replace above reference to		NOTE TO RFC EDITOR: Please replace above reference to
	draft-ietf-i2rs-yang-network-topo-02 with RFC		draft-ietf-i2rs-yang-network-topo-03 with RFC
	number when published (i.e. RFC xxxx).";		number when published (i.e. RFC xxxx).";
	revision 2015-12-08 {		revision 2016-06-09 {
	description		description
	"Initial revision.		"Initial revision.
	NOTE TO RFC EDITOR: Please replace the following reference		NOTE TO RFC EDITOR: Please replace the following reference
	to draft-ietf-i2rs-yang-network-topo-02 with		to draft-ietf-i2rs-yang-network-topo-02 with
	RFC number when published (i.e. RFC xxxx).";		RFC number when published (i.e. RFC xxxx).";
	reference		reference
	"draft-ietf-i2rs-yang-network-topo-02";		"draft-ietf-i2rs-yang-network-topo-03";
	}		}
	typedef node-id {		typedef node-id {
	type inet:uri;		type inet:uri;
	description		description
	"Identifier for a node.";		"Identifier for a node.";
	}		}
	typedef network-id {		typedef network-id {
	type inet:uri;		type inet:uri;
	skipping to change at page 21, line 37 ¶		skipping to change at page 22, line 4 ¶
	leaf server-provided {		leaf server-provided {
	type boolean;		type boolean;
	description		description
	"Indicates whether the information concerning this		"Indicates whether the information concerning this
	particular network is populated by the server		particular network is populated by the server
	(server-provided true, the general case for network		(server-provided true, the general case for network
	information discovered from the server),		information discovered from the server),
	or whether it is configured by a client		or whether it is configured by a client
	(server-provided true, possible e.g. for		(server-provided true, possible e.g. for
	service overlays managed through a controller).";		service overlays managed through a controller).";
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	4.2. Creating Abstract Network Topology: network-topology.yang		4.2. Creating Abstract Network Topology: network-topology.yang
	<CODE BEGINS> file "ietf-network-topology@2015-12-08.yang"		<CODE BEGINS> file "ietf-network-topology@2016-06-09.yang"
	module ietf-network-topology {		module ietf-network-topology {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology";		namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology";
	prefix lnk;		prefix lnk;
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	}		}
	import ietf-network {		import ietf-network {
	prefix nd;		prefix nd;
	skipping to change at page 22, line 20 ¶		skipping to change at page 22, line 37 ¶
	organization		organization
	"IETF I2RS (Interface to the Routing System) Working Group";		"IETF I2RS (Interface to the Routing System) Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/i2rs/>		"WG Web: <http://tools.ietf.org/wg/i2rs/>
	WG List: <mailto:i2rs@ietf.org>		WG List: <mailto:i2rs@ietf.org>
	WG Chair: Susan Hares		WG Chair: Susan Hares
	<mailto:shares@ndzh.com>		<mailto:shares@ndzh.com>
	WG Chair: Jeffrey Haas		WG Chair: Russ White
	<mailto:jhaas@pfrc.org>		<mailto:russ@riw.us>
	Editor: Alexander Clemm		Editor: Alexander Clemm
	<mailto:alex@cisco.com>		<mailto:alex@cisco.com>
	Editor: Jan Medved		Editor: Jan Medved
	<mailto:jmedved@cisco.com>		<mailto:jmedved@cisco.com>
	Editor: Robert Varga		Editor: Robert Varga
	<mailto:rovarga@cisco.com>		<mailto:rovarga@cisco.com>
	Editor: Tony Tkacik		Editor: Tony Tkacik
	<mailto:ttkacik@cisco.com>		<mailto:ttkacik@cisco.com>
	Editor: Nitin Bahadur		Editor: Nitin Bahadur
	<mailto:nitin_bahadur@yahoo.com>		<mailto:nitin_bahadur@yahoo.com>
	Editor: Hariharan Ananthakrishnan		Editor: Hariharan Ananthakrishnan
	<mailto:hari@packetdesign.com>";		<mailto:hari@packetdesign.com>
			Editor: Xufeng Liu
			<mailto:xliu@kuatrotech.com>";
	description		description
	"This module defines a common base model for network topology,		"This module defines a common base model for network topology,
	augmenting the base network model with links to connect nodes,		augmenting the base network model with links to connect nodes,
	as well as termination points to terminate links on nodes.		as well as termination points to terminate links on nodes.
	Copyright (c) 2015 IETF Trust and the persons identified as		Copyright (c) 2016 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of		This version of this YANG module is part of
	draft-ietf-i2rs-yang-network-topo-02;		draft-ietf-i2rs-yang-network-topo-03;
	see the RFC itself for full legal notices.		see the RFC itself for full legal notices.
	NOTE TO RFC EDITOR: Please replace above reference to		NOTE TO RFC EDITOR: Please replace above reference to
	draft-ietf-i2rs-yang-network-topo-02 with RFC		draft-ietf-i2rs-yang-network-topo-03 with RFC
	number when published (i.e. RFC xxxx).";		number when published (i.e. RFC xxxx).";
	revision 2015-12-08 {		revision 2016-06-09 {
	description		description
	"Initial revision.		"Initial revision.
	NOTE TO RFC EDITOR: Please replace the following reference		NOTE TO RFC EDITOR: Please replace the following reference
	to draft-ietf-i2rs-yang-network-topo-02 with		to draft-ietf-i2rs-yang-network-topo-02 with
	RFC number when published (i.e. RFC xxxx).";		RFC number when published (i.e. RFC xxxx).";
	reference		reference
	"draft-ietf-i2rs-yang-network-topo-02.";		"draft-ietf-i2rs-yang-network-topo-02.";
	}		}
	typedef link-id {		typedef link-id {
	skipping to change at page 29, line 22 ¶		skipping to change at page 29, line 43 ¶
	[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.		[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
	Bierman, "Network Configuration Protocol (NETCONF)",		Bierman, "Network Configuration Protocol (NETCONF)",
	RFC 6241, June 2011.		RFC 6241, June 2011.
	[RFC7223] Bjorklund, M., "A YANG Data Model for Interface		[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
	Management", RFC 7223, May 2014.		Management", RFC 7223, May 2014.
	8.2. Informative References		8.2. Informative References
	[I-D.draft-ietf-netconf-yang-push]		[I-D.draft-ietf-netconf-yang-push]
	Clemm, A., Voit, E., and A. Gonzalez Prieto, "Subscribing		Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A.,
	to YANG datastore push updates", I-D draft-ietf-netconf-		and E. Nilsen-Nygaard, "Subscribing to YANG datastore push
	yang-push-00, October 2015.		updates", I-D draft-ietf-netconf-yang-push-02, March 2016.
			[I-D.draft-ietf-netmod-yang-metadata]
			Lhotka, L., "Defining and Using Metadata with YANG", I-D
			draft-ietf-netmod-yang-metadata-07, March 2016.
	[I.D.draft-ietf-netmod-rfc6020bis]		[I.D.draft-ietf-netmod-rfc6020bis]
	Bjorklund, M., "The YANG 1.1 Data Modeling Language", I-D		Bjorklund, M., "The YANG 1.1 Data Modeling Language", I-D
	draft-ietf-netmod-rfc6020bis-08, October 2015.		draft-ietf-netmod-rfc6020bis-12, April 2016.
	[topology-use-cases]		[topology-use-cases]
	Medved, J., Previdi, S., Lopez, V., and S. Amante,		Medved, J., Previdi, S., Lopez, V., and S. Amante,
	"Topology API Use Cases", I-D draft-amante-i2rs-topology-		"Topology API Use Cases", I-D draft-amante-i2rs-topology-
	use-cases-01, October 2013.		use-cases-01, October 2013.
	Authors' Addresses		Authors' Addresses
	Alexander Clemm		Alexander Clemm
	Cisco		Cisco
	skipping to change at line 1382 ¶		skipping to change at page 31, line 4 ¶
	Nitin Bahadur		Nitin Bahadur
	Bracket Computing		Bracket Computing
	EMail: nitin_bahadur@yahoo.com		EMail: nitin_bahadur@yahoo.com
	Hariharan Ananthakrishnan		Hariharan Ananthakrishnan
	Packet Design		Packet Design
	EMail: hari@packetdesign.com		EMail: hari@packetdesign.com
			Xufeng Liu
			Kuatro Technologies
			EMail: xliu@kuatrotech.com
End of changes. 34 change blocks.
	45 lines changed or deleted		69 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/