draft-ietf-i2rs-architecture-07.txt		draft-ietf-i2rs-architecture-08.txt
	Network Working Group A. Atlas		Network Working Group A. Atlas
	Internet-Draft Juniper Networks		Internet-Draft Juniper Networks
	Intended status: Informational J. Halpern		Intended status: Informational J. Halpern
	Expires: June 14, 2015 Ericsson		Expires: July 11, 2015 Ericsson
	S. Hares		S. Hares
	Huawei		Huawei
	D. Ward		D. Ward
	Cisco Systems		Cisco Systems
	T. Nadeau		T. Nadeau
	Brocade		Brocade
	December 11, 2014		January 7, 2015
	An Architecture for the Interface to the Routing System		An Architecture for the Interface to the Routing System
	draft-ietf-i2rs-architecture-07		draft-ietf-i2rs-architecture-08
	Abstract		Abstract
	This document describes an architecture for a standard, programmatic		This document describes an architecture for a standard, programmatic
	interface for state transfer in and out of the internet routing		interface for state transfer in and out of the Internet routing
	system. It describes the basic architecture, the components, and		system. It describes the basic architecture, the components, and
	their interfaces with particular focus on those to be standardized as		their interfaces with particular focus on those to be standardized as
	part of I2RS.		part of the Interface to Routing System (I2RS).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 14, 2015.		This Internet-Draft will expire on July 11, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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 24		skipping to change at page 2, line 24
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4		1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4
	1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5		1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3. Key Architectural Properties . . . . . . . . . . . . . . . . 10		3. Key Architectural Properties . . . . . . . . . . . . . . . . 10
	3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10		3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10
	3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11		3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11
	3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11		3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 12		4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	4.1. Identity and Authentication . . . . . . . . . . . . . . . 13		4.1. Identity and Authentication . . . . . . . . . . . . . . . 13
	4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 13		4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 14
	5. Network Applications and I2RS Client . . . . . . . . . . . . 14		4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 14
			5. Network Applications and I2RS Client . . . . . . . . . . . . 15
	5.1. Example Network Application: Topology Manager . . . . . . 15		5.1. Example Network Application: Topology Manager . . . . . . 15
	6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 15		6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 16
	6.1. Relationship to its Routing Element . . . . . . . . . . . 15		6.1. Relationship to its Routing Element . . . . . . . . . . . 16
	6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 16		6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 16
	6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 16		6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 17
	6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 17		6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 18
	6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 17		6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 18
	6.3. Interactions with Local Config . . . . . . . . . . . . . 18		6.3. Interactions with Local Config . . . . . . . . . . . . . 18
	6.4. Routing Components and Associated I2RS Services . . . . . 18		6.4. Routing Components and Associated I2RS Services . . . . . 19
	6.4.1. Routing and Label Information Bases . . . . . . . . . 19		6.4.1. Routing and Label Information Bases . . . . . . . . . 20
	6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 20		6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 21
	6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 20		6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 21
	6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 21		6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 22
	6.4.5. Information Modeling, Device Variation, and		6.4.5. Information Modeling, Device Variation, and
	Information Relationships . . . . . . . . . . . . . . 21		Information Relationships . . . . . . . . . . . . . . 22
	6.4.5.1. Managing Variation: Object Classes/Types and		6.4.5.1. Managing Variation: Object Classes/Types and
	Inheritance . . . . . . . . . . . . . . . . . . . 21		Inheritance . . . . . . . . . . . . . . . . . . . 22
	6.4.5.2. Managing Variation: Optionality . . . . . . . . . 22		6.4.5.2. Managing Variation: Optionality . . . . . . . . . 23
	6.4.5.3. Managing Variation: Templating . . . . . . . . . 22		6.4.5.3. Managing Variation: Templating . . . . . . . . . 23
	6.4.5.4. Object Relationships . . . . . . . . . . . . . . 23		6.4.5.4. Object Relationships . . . . . . . . . . . . . . 24
	6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 23		6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 24
	6.4.5.4.2. Correlation Identification . . . . . . . . . 23		6.4.5.4.2. Correlation Identification . . . . . . . . . 24
	6.4.5.4.3. Object References . . . . . . . . . . . . . . 24		6.4.5.4.3. Object References . . . . . . . . . . . . . . 25
	6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 24		6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 25
	7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 24		7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 25
	7.1. One Control and Data Exchange Protocol . . . . . . . . . 24		7.1. One Control and Data Exchange Protocol . . . . . . . . . 25
	7.2. Communication Channels . . . . . . . . . . . . . . . . . 24		7.2. Communication Channels . . . . . . . . . . . . . . . . . 25
	7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 25		7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 26
	7.4. Identity and Security Role . . . . . . . . . . . . . . . 25		7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 26
	7.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 26		7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 27
	7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 26
	7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 27		7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 27
	7.7. Information collection . . . . . . . . . . . . . . . . . 27		7.7. Information collection . . . . . . . . . . . . . . . . . 28
	7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 28		7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 28
	7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 28		7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 29
	8. Operational and Manageability Considerations . . . . . . . . 29		8. Operational and Manageability Considerations . . . . . . . . 29
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
	11. Informative References . . . . . . . . . . . . . . . . . . . 30		11. Informative References . . . . . . . . . . . . . . . . . . . 30
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	Routers that form the internet routing infrastructure maintain state		Routers that form the internet routing infrastructure maintain state
	at various layers of detail and function. For example, a typical		at various layers of detail and function. For example, a typical
	router maintains a Routing Information Base (RIB), and implements		router maintains a Routing Information Base (RIB), and implements
	routing protocols such as OSPF, ISIS, and BGP to exchange protocol		routing protocols such as OSPF, ISIS, and BGP to exchange
	state and other information about the state of the network with other		reachability information, topology information, protocol state, and
	routers.		other information about the state of the network with other routers.
	Routers convert all of this information into forwarding entries which		Routers convert all of this information into forwarding entries which
	are then used to forward packets and flows between network elements.		are then used to forward packets and flows between network elements.
	The forwarding plane and the specified forwarding entries then		The forwarding plane and the specified forwarding entries then
	contain active state information that describes the expected and		contain active state information that describes the expected and
	observed operational behavior of the router and which is also needed		observed operational behavior of the router and which is also needed
	by the network applications. Network-oriented applications require		by the network applications. Network-oriented applications require
	easy access to this information to learn the network topology, to		easy access to this information to learn the network topology, to
	verify that programmed state is installed in the forwarding plane, to		verify that programmed state is installed in the forwarding plane, to
	measure the behavior of various flows, routes or forwarding entries,		measure the behavior of various flows, routes or forwarding entries,
	skipping to change at page 4, line 7		skipping to change at page 4, line 7
	state (for example, a Routing Element RIB manager's state), as well		state (for example, a Routing Element RIB manager's state), as well
	as enabling network-oriented applications to be built on top of		as enabling network-oriented applications to be built on top of
	today's routed networks. The I2RS is a programmatic asynchronous		today's routed networks. The I2RS is a programmatic asynchronous
	interface for transferring state into and out of the internet routing		interface for transferring state into and out of the internet routing
	system. This I2RS architecture recognizes that the routing system		system. This I2RS architecture recognizes that the routing system
	and a router's OS provide useful mechanisms that applications could		and a router's OS provide useful mechanisms that applications could
	harness to accomplish application-level goals.		harness to accomplish application-level goals.
	Fundamental to the I2RS are clear data models that define the		Fundamental to the I2RS are clear data models that define the
	semantics of the information that can be written and read. The I2RS		semantics of the information that can be written and read. The I2RS
	provides a framework for registering for and requesting the		provides a framework for registering and for requesting the
	appropriate information for each particular application. The I2RS		appropriate information for each particular application. The I2RS
	provides a way for applications to customize network behavior while		provides a way for applications to customize network behavior while
	leveraging the existing routing system as desired.		leveraging the existing routing system as desired.
	Although the I2RS architecture is general enough to support		Although the I2RS architecture is general enough to support
	information and data models for a variety of data, and aspects of the		information and data models for a variety of data, and aspects of the
	I2RS solution may be useful in domain other than routing, I2RS and		I2RS solution may be useful in domains other than routing, I2RS and
	this document are specifically focused on an interface for routing		this document are specifically focused on an interface for routing
	data.		data.
	1.1. Drivers for the I2RS Architecture		1.1. Drivers for the I2RS Architecture
	There are four key drivers that shape the I2RS architecture. First		There are four key drivers that shape the I2RS architecture. First
	is the need for an interface that is programmatic, asynchronous, and		is the need for an interface that is programmatic, asynchronous, and
	offers fast, interactive access for atomic operations. Second is the		offers fast, interactive access for atomic operations. Second is the
	access to structured information and state that is frequently not		access to structured information and state that is frequently not
	directly configurable or modeled in existing implementations or		directly configurable or modeled in existing implementations or
	skipping to change at page 10, line 14		skipping to change at page 10, line 14
	resources: A resource is an I2RS-specific use of memory, storage,		resources: A resource is an I2RS-specific use of memory, storage,
	or execution that a client may consume due to its I2RS operations.		or execution that a client may consume due to its I2RS operations.
	The amount of each such resource that a client may consume in the		The amount of each such resource that a client may consume in the
	context of a particular agent may be constrained based upon the		context of a particular agent may be constrained based upon the
	client's security role. An example of such a resource could		client's security role. An example of such a resource could
	include the number of notifications registered for. These are not		include the number of notifications registered for. These are not
	protocol-specific resources or network-specific resources.		protocol-specific resources or network-specific resources.
	role or security role: A security role specifies the scope,		role or security role: A security role specifies the scope,
	resources, priorities, etc. that a client or agent has.		resources, priorities, etc. that a client or agent has. Multiple
			identities may use the same security role.
	identity: A client is associated with exactly one specific		identity: A client is associated with exactly one specific
	identity. State can be attributed to a particular identity. It		identity. State can be attributed to a particular identity. It
	is possible for multiple communication channels to use the same		is possible for multiple communication channels to use the same
	identity; in that case, the assumption is that the associated		identity; in that case, the assumption is that the associated
	client is coordinating such communication.		client is coordinating such communication.
	secondary identity: An I2RS Client may supply a secondary opaque		secondary identity: An I2RS Client may supply a secondary opaque
	identity that is not interpreted by the I2RS Agent. An example		identity that is not interpreted by the I2RS Agent. An example
	use is when the I2RS Client is a go-between for multiple		use is when the I2RS Client is a go-between for multiple
	applications and it is necessary to track which application has		applications and it is necessary to track which application has
	requested a particular operation.		requested a particular operation.
			Groups: NETCONF Network Access [RFC6536] refers uses the term group
			in terms of an Administrative group which supports support the
			well-established distinction between a root account and other
			types of less-privileged conceptual user accounts. Group still
			refers to a single identity (e.g. root) which is shared by a group
			of users.
	3. Key Architectural Properties		3. Key Architectural Properties
	Several key architectural properties for the I2RS protocol are		Several key architectural properties for the I2RS protocol are
	elucidated below (simplicity, extensibility, and model-driven		elucidated below (simplicity, extensibility, and model-driven
	programmatic interfaces). However, some architecture principles such		programmatic interfaces). However, some architecture principles such
	as performance and scaling are not described below because they are		as performance and scaling are not described below because they are
	discussed in [I-D.ietf-i2rs-problem-statement] and because the		discussed in [I-D.ietf-i2rs-problem-statement] and because the
	performance and scaling requires varies based on the particular use-		performance and scaling requires varies based on the particular use-
	cases.		cases.
	skipping to change at page 13, line 4		skipping to change at page 13, line 12
	authentication and authorization for that communication is out of		authentication and authorization for that communication is out of
	scope; nothing prevents I2RS and a separate authentication and		scope; nothing prevents I2RS and a separate authentication and
	authorization channel from being used. Regardless of mechanism, an		authorization channel from being used. Regardless of mechanism, an
	I2RS Client that is acting as a broker is responsible for determining		I2RS Client that is acting as a broker is responsible for determining
	that applications using it are trusted and permitted to make the		that applications using it are trusted and permitted to make the
	particular requests.		particular requests.
	Different levels of integrity, confidentiality, and replay protection		Different levels of integrity, confidentiality, and replay protection
	are relevant for different aspects of I2RS. The primary		are relevant for different aspects of I2RS. The primary
	communication channel that is used for client authentication and then		communication channel that is used for client authentication and then
	used by the client to write data requires integrity, privacy and		used by the client to write data requires integrity, confidentiality
	replay protection. Appropriate selection of a default required		and replay protection. Appropriate selection of a default required
	transport protocol is the preferred way of meeting these		transport protocol is the preferred way of meeting these
	requirements.		requirements.
	Other communications via I2RS may not require integrity,		Other communications via I2RS may not require integrity,
	confidentiality, and replay protection. For instance, if an I2RS		confidentiality, and replay protection. For instance, if an I2RS
	Client subscribes to an information stream of prefix announcements		Client subscribes to an information stream of prefix announcements
	from OSPF, those may require integrity but probably not		from OSPF, those may require integrity but probably not
	confidentiality or replay protection. Similarly, an information		confidentiality or replay protection. Similarly, an information
	stream of interface statistics may not even require guaranteed		stream of interface statistics may not even require guaranteed
	delivery. In Section 7.2, more reasoning for multiple communication		delivery. In Section 7.2, more reasoning for multiple communication
	skipping to change at page 13, line 40		skipping to change at page 13, line 48
	of the system must be accurately attributable. In an ideal		of the system must be accurately attributable. In an ideal
	architecture, even information collection and notification should be		architecture, even information collection and notification should be
	protected; this may be subject to engineering tradeoffs during the		protected; this may be subject to engineering tradeoffs during the
	design.		design.
	I2RS clients may be operating on behalf of other applications. While		I2RS clients may be operating on behalf of other applications. While
	those applications' identities are not needed for authentication or		those applications' identities are not needed for authentication or
	authorization, each application should have a unique opaque		authorization, each application should have a unique opaque
	identifier that can be provided by the I2RS client to the I2RS agent		identifier that can be provided by the I2RS client to the I2RS agent
	for purposes of tracking attribution of operations to support		for purposes of tracking attribution of operations to support
	functionality such as accounting and troubleshooting.		functionality such as troubleshooting and logging of network changes.
	4.2. Authorization		4.2. Authorization
	All operations using I2RS, both observation and manipulation, should		All operations using I2RS, both observation and manipulation, should
	be subject to appropriate authorization controls. Such authorization		be subject to appropriate authorization controls. Such authorization
	is based on the identity and assigned role of the I2RS client		is based on the identity and assigned role of the I2RS client
	performing the operations and the I2RS agent in the network element.		performing the operations and the I2RS agent in the network element.
			(Multiple Identities may use the same role).
	I2RS Agents, in performing information collection and manipulation,		I2RS Agents, in performing information collection and manipulation,
	will be acting on behalf of the I2RS clients. As such, each		will be acting on behalf of the I2RS clients. As such, each
	operation authorization will be based on the lower of the two		operation authorization will be based on the lower of the two
	permissions of the agent itself and of the authenticated client. The		permissions of the agent itself and of the authenticated client. The
	mechanism by which this authorization is applied within the device is		mechanism by which this authorization is applied within the device is
	outside of the scope of I2RS.		outside of the scope of I2RS.
	The appropriate or necessary level of granularity for scope can		The appropriate or necessary level of granularity for scope can
	depend upon the particular I2RS Service and the implementation's		depend upon the particular I2RS Service and the implementation's
	granularity. An approach to a similar access control problem is		granularity. An approach to a similar access control problem is
	defined in the NetConf Access Control Model[RFC6536]; it allows		defined in the NetConf Access Control Model (NACM) [RFC6536]; it
	arbitrary access to be specified for a data node instance identifier		allows arbitrary access to be specified for a data node instance
	while defining meaningful manipulable defaults. The ability to		identifier while defining meaningful manipulable defaults. The
	specify one or more groups or roles that a particular I2RS Client		identity within NACM [RFC6536] can be specify as either a user name
	belongs and then define access controls in terms of those groups or		or a group user name (e.g. Root), and this name is linked a scope
	roles is expected. When a client is authenticated, its group or role		policy that contained in a a set of access control rules. Similarly,
	membership should be provided to the I2RS Agent. The set of access		it is expected the I2RS identity links to one role which has a scope
	control rules that an I2RS Agent uses would need to be either		policy specified by a set of access control rules. This scope policy
	provided via Local Config, exposed as an I2RS Service for		is can be provided via Local Config, exposed as an I2RS Service for
	manipulation by authorized clients, or via some other method.		manipulation by authorized clients, or via some other method (e.g.
			AAA service)
			When an I2RS client is authenticated, its identity is provided to the
			I2RS Agent, and this identity links to a role which links to the
			scope policy. Multiple identities may link to the same role (e.g
			ability to read I2RS RIB).
			4.3. Client Redundancy
			I2RS must support client redundancy. At the simplest, this can be
			handled by having a primary and a backup network application that
			both use the same client identity and can successfully authenticate
			as such. Since I2RS does not require a continuous transport
			connection and supports multiple transport sessions, this can provide
			some basic redundancy. However, it does not address the need for
			troubleshooting and logging of network changes to be informed about
			which network application is actually active. At a minimum, basic
			transport information about each connection and time can be logged
			with the identity.
	5. Network Applications and I2RS Client		5. Network Applications and I2RS Client
	I2RS is expected to be used by network-oriented applications in		I2RS is expected to be used by network-oriented applications in
	different architectures. While the interface between a network-		different architectures. While the interface between a network-
	oriented application and the I2RS client is outside the scope of		oriented application and the I2RS client is outside the scope of
	I2RS, considering the different architectures is important to		I2RS, considering the different architectures is important to
	sufficiently specify I2RS.		sufficiently specify I2RS.
	In the simplest architecture, a network-oriented application has an		In the simplest architecture of direct access, a network-oriented
	I2RS client as a library or driver for communication with routing		application has an I2RS client as a library or driver for
	elements.		communication with routing elements.
	In the broker architecture, multiple network-oriented applications		In the broker architecture, multiple network-oriented applications
	communicate in an unspecified fashion to a broker application that		communicate in an unspecified fashion to a broker application that
	contains an I2RS Client. That broker application requires additional		contains an I2RS Client. That broker application requires additional
	functionality for authentication and authorization of the network-		functionality for authentication and authorization of the network-
	oriented applications; such functionality is out of scope for I2RS		oriented applications; such functionality is out of scope for I2RS
	but similar considerations to those described in Section 4.2 do		but similar considerations to those described in Section 4.2 do
	apply. As discussed in Section 4.1, the broker I2RS Client should		apply. As discussed in Section 4.1, the broker I2RS Client should
	determine distinct opaque identifiers for each network-oriented		determine distinct opaque identifiers for each network-oriented
	application that is using it. The broker I2RS Client can pass along		application that is using it. The broker I2RS Client can pass along
	skipping to change at page 18, line 38		skipping to change at page 19, line 16
	resolution cannot be time-based. Simply allowing the most recent		resolution cannot be time-based. Simply allowing the most recent
	state to prevail could cause race conditions where the final state is		state to prevail could cause race conditions where the final state is
	not repeatably deterministic.		not repeatably deterministic.
	6.4. Routing Components and Associated I2RS Services		6.4. Routing Components and Associated I2RS Services
	For simplicity, each logical protocol or set of functionality that		For simplicity, each logical protocol or set of functionality that
	can be compactly described in a separable information and data model		can be compactly described in a separable information and data model
	is considered as a separate I2RS Service. A routing element need not		is considered as a separate I2RS Service. A routing element need not
	implement all routing components described nor provide the associated		implement all routing components described nor provide the associated
	I2RS services. When a full implementation is not mandatory, an I2RS		I2RS services. I2RS Services should include a capability model so
	Service should include a capability model so that implementations can		that peers can determine which parts of the service are supported.
	indicate which parts of the service are supported. Each I2RS Service		Each I2RS Service requires an information model that describes at
	requires an information model that describes at least the following:		least the following: data that can be read, data that can be written,
	data that can be read, data that can be written, notifications that		notifications that can be subscribed to, and the capability model
	can be subscribed to, and the capability model mentioned above.		mentioned above.
	The initial services included in the I2RS architecture are as		The initial services included in the I2RS architecture are as
	follows.		follows.
	*************************** ************** *****************		*************************** ************** *****************
	* I2RS Protocol * * * * Dynamic *		* I2RS Protocol * * * * Dynamic *
	* * * Interfaces * * Data & *		* * * Interfaces * * Data & *
	* +--------+ +-------+ * * * * Statistics *		* +--------+ +-------+ * * * * Statistics *
	* | Client | | Agent | * ************** *****************		* | Client | | Agent | * ************** *****************
	* +--------+ +-------+ *		* +--------+ +-------+ *
	skipping to change at page 22, line 30		skipping to change at page 23, line 30
	Information model should provide information that:		Information model should provide information that:
	o Is X required for the data field to be accepted and applied?		o Is X required for the data field to be accepted and applied?
	o If X is optional, then how does "X" as an optional portion of data		o If X is optional, then how does "X" as an optional portion of data
	field interact with the required aspects of the data field?		field interact with the required aspects of the data field?
	o Does the data field have defaults for the mandatory portion of the		o Does the data field have defaults for the mandatory portion of the
	field and the optional portions of the field		field and the optional portions of the field
	o Is X required to be within a particular set of values (E.g. range,		o Is X required to be within a particular set of values (e.g. range,
	length of strings)?		length of strings)?
	The information model needs to be clear about what read or write		The information model needs to be clear about what read or write
	values are set by client and what responses or actions are required		values are set by client and what responses or actions are required
	by the agent. It is important to indicate what is required or		by the agent. It is important to indicate what is required or
	optional in client values and agent responses/actions.		optional in client values and agent responses/actions.
	6.4.5.3. Managing Variation: Templating		6.4.5.3. Managing Variation: Templating
	A template is a collection of information to address a problem; it		A template is a collection of information to address a problem; it
	skipping to change at page 25, line 38		skipping to change at page 26, line 38
	The protocol capability negotiation can be segmented into the basic		The protocol capability negotiation can be segmented into the basic
	version negotiation (required to ensure basic communication), and the		version negotiation (required to ensure basic communication), and the
	more complex capability exchange which can take place within the base		more complex capability exchange which can take place within the base
	protocol mechanisms. In particular, the more complex protocol and		protocol mechanisms. In particular, the more complex protocol and
	mechanism negotiation can be addressed by defining information models		mechanism negotiation can be addressed by defining information models
	for both the I2RS Agent and the I2RS Client. These information		for both the I2RS Agent and the I2RS Client. These information
	models can describe the various capability options. This can then		models can describe the various capability options. This can then
	represent and be used to communicate important information about the		represent and be used to communicate important information about the
	agent, and the capabilities thereof.		agent, and the capabilities thereof.
	7.4. Identity and Security Role		7.4. Scope Policy Specifications
	Each I2RS Client will have a unique identity; it can also have
	secondary identities to be used for troubleshooting. A secondary
	identity is merely a unique, opaque identifier that may be helpful in
	troubleshooting. Via authentication and authorization mechanisms
	based on the primary unique identity, the I2RS Client will have a
	specific scope for reading data, for writing data, and limitations on
	the resources that can be consumed. The scopes need to specify both
	the data and the value ranges.
	7.4.1. Client Redundancy
	I2RS must support client redundancy. At the simplest, this can be		As section 4.1 and 4.2 describe, each I2RS Client will have a unique
	handled by having a primary and a backup network application that		identity and it may have a secondary identity (see section 2) to aid
	both use the same client identity and can successfully authenticate		in troubleshooting. As section 4 indicates, all authentication and
	as such. Since I2RS does not require a continuous transport		authorization mechanisms are based on the primary Identity which
	connection and supports multiple transport sessions, this can provide		links to a role with scope policy for for reading data, for writing
	some basic redundancy. However, it does not address concerns for		data, and limitations on the resources that can be consumed.
	troubleshooting and accountability about knowing which network		Specifications for scope policy need to specify the data and value
	application is actually active. At a minimum, basic transport		ranges for portion of scope policy.
	information about each connection and time can be logged with the
	identity.
	7.5. Connectivity		7.5. Connectivity
	A client may or may not maintain an active communication channel with		A client may or may not maintain an active communication channel with
	an agent. Therefore, an agent may need to open a communication		an agent. Therefore, an agent may need to open a communication
	channel to the client to communicate previously requested		channel to the client to communicate previously requested
	information. The lack of an active communication channel does not		information. The lack of an active communication channel does not
	imply that the associated client is non-functional. When		imply that the associated client is non-functional. When
	communication is required, the agent or client can open a new		communication is required, the agent or client can open a new
	communication channel.		communication channel.
	skipping to change at page 27, line 32		skipping to change at page 28, line 16
	specific types of events and filtering operations can vary by		specific types of events and filtering operations can vary by
	information model and need to be specified as part of the information		information model and need to be specified as part of the information
	model.		model.
	The I2RS information model needs to include representation of these		The I2RS information model needs to include representation of these
	events. As discussed earlier, the capability information in the		events. As discussed earlier, the capability information in the
	model will allow I2RS clients to understand which events a given I2RS		model will allow I2RS clients to understand which events a given I2RS
	Agent is capable of generating.		Agent is capable of generating.
	For performance and scaling by the I2RS client and general		For performance and scaling by the I2RS client and general
	information privacy, an I2RS Client needs to be able to register for		information confidentiality, an I2RS Client needs to be able to
	just the events it is interested in. It is also possible that I2RS		register for just the events it is interested in. It is also
	might might provide a stream of notifications via a publish/subscribe		possible that I2RS might provide a stream of notifications via a
	mechanism that is not amenable to having the I2RS agent do the		publish/subscribe mechanism that is not amenable to having the I2RS
	filtering.		agent do the filtering.
	7.7. Information collection		7.7. Information collection
	One of the other important aspects of the I2RS is that it is intended		One of the other important aspects of the I2RS is that it is intended
	to simplify collecting information about the state of network		to simplify collecting information about the state of network
	elements. This includes both getting a snapshot of a large amount of		elements. This includes both getting a snapshot of a large amount of
	data about the current state of the network element, and subscribing		data about the current state of the network element, and subscribing
	to a feed of the ongoing changes to the set of data or a subset		to a feed of the ongoing changes to the set of data or a subset
	thereof. This is considered architecturally separate from		thereof. This is considered architecturally separate from
	notifications due to the differences in information rate and total		notifications due to the differences in information rate and total
End of changes. 32 change blocks.
	95 lines changed or deleted		110 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/