draft-ietf-i2rs-ephemeral-state-17.txt		draft-ietf-i2rs-ephemeral-state-17.txt
	I2RS working group J. Haas		I2RS working group J. Haas
	Internet-Draft Juniper		Internet-Draft Juniper
	Intended status: Standards Track S. Hares		Intended status: Informational S. Hares
	Expires: March 24, 2017 Huawei		Expires: March 24, 2017 Huawei
	September 20, 2016		September 20, 2016
	I2RS Ephemeral State Requirements		I2RS Ephemeral State Requirements
	draft-ietf-i2rs-ephemeral-state-17		draft-ietf-i2rs-ephemeral-state-17
	Abstract		Abstract
	The I2RS (interface to routing system) Architecture document		The I2RS (interface to routing system) Architecture document
	(RFC7920) abstractly describes a number of requirements for ephemeral		(RFC7920) abstractly describes a number of requirements for ephemeral
	skipping to change at page 3, line 30		skipping to change at page 3, line 30
	Support for ephemeral state is an I2RS protocol requirement that		Support for ephemeral state is an I2RS protocol requirement that
	requires datastore changes (see section 3), YANG additions (see		requires datastore changes (see section 3), YANG additions (see
	section 4), NETCONF additions (see section 5), and RESTCONF additions		section 4), NETCONF additions (see section 5), and RESTCONF additions
	(see section 6).		(see section 6).
	Sections 7-9 provide details that expand upon the changes in sections		Sections 7-9 provide details that expand upon the changes in sections
	3-6 to clarify requirements discussed by the I2RS and NETCONF working		3-6 to clarify requirements discussed by the I2RS and NETCONF working
	groups. Section 7 provided additional requirements that detail how		groups. Section 7 provided additional requirements that detail how
	write-conflicts should be resolved if two I2RS client write the same		write-conflicts should be resolved if two I2RS client write the same
	data. Section 8 details an additional requirement that details on		data. Section 8 details an additional requirement that describes
	I2RS support of multiple message transactions. Section 9 highlights		I2RS support of multiple message transactions. Section 9 highlights
	two requirements in the I2RS publication/subscription requirements		two requirements in the I2RS publication/subscription requirements
	[RFC7923] that must be expanded for ephemeral state.		[RFC7923] that must be expanded for ephemeral state.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	skipping to change at page 5, line 7		skipping to change at page 5, line 7
	agent.		agent.
	10. The I2RS protocol MUST support the use of a secure transport.		10. The I2RS protocol MUST support the use of a secure transport.
	However, certain functions such as notifications MAY use a non-		However, certain functions such as notifications MAY use a non-
	secure transport. Each model or service (notification, logging)		secure transport. Each model or service (notification, logging)
	must define within the model or service the valid uses of a non-		must define within the model or service the valid uses of a non-
	secure transport.		secure transport.
	3. Ephemeral State Requirements		3. Ephemeral State Requirements
	In requirements Ephemeral-REQ-01 to Ephemeral-15, Ephemeral state is		In requirements Ephemeral-REQ-01 to Ephemeral-REQ-15, Ephemeral state
	defined as potentially including in a data model ephemeral		is defined as potentially including in a data model ephemeral
	configuration and operational state which is flagged as ephemeral.		configuration and operational state which is flagged as ephemeral.
	3.1. Persistence		3.1. Persistence
	Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does		Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does
	not persist across reboots. If state must be restored, it should be		not persist across reboots. If state must be restored, it should be
	done solely by replay actions from the I2RS client via the I2RS		done solely by replay actions from the I2RS client via the I2RS
	agent.		agent.
	While at first glance this may seem equivalent to the writable-		While at first glance this may seem equivalent to the writable-
	skipping to change at page 5, line 34		skipping to change at page 5, line 34
	Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral		Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral
	state for constraint purposes; it SHALL be considered a validation		state for constraint purposes; it SHALL be considered a validation
	error if it does.		error if it does.
	Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints		Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints
	that refer to operational state, this includes potentially fast		that refer to operational state, this includes potentially fast
	changing or short lived operational state nodes, such as MPLS LSP-ID		changing or short lived operational state nodes, such as MPLS LSP-ID
	or a BGP IN-RIB. Ephemeral state constraints should be assessed when		or a BGP IN-RIB. Ephemeral state constraints should be assessed when
	the ephemeral state is written, and if any of the constraints change		the ephemeral state is written, and if any of the constraints change
	to make the constraints invalid after that time the I2RS agent should		to make the constraints invalid after that time the I2RS agent SHOULD
	notify the I2RS client.		notify the I2RS client.
	Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non-		Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non-
	ephemeral state as a constraint. Non-ephemeral state can be		ephemeral state as a constraint. Non-ephemeral state can be
	configuration state or operational state.		configuration state or operational state.
	Ephemeral-REQ-05: I2RS pub-sub [RFC7923], tracing ([RFC7922], RPC or		Ephemeral-REQ-05: I2RS pub-sub [RFC7923], tracing [RFC7922], RPC or
	other mechanisms may lead to undesirable or unsustainable resource		other mechanisms may lead to undesirable or unsustainable resource
	consumption on a system implementing an I2RS agent. It is		consumption on a system implementing an I2RS agent. It is
	RECOMMENDED that mechanisms be made available to permit		RECOMMENDED that mechanisms be made available to permit
	prioritization of I2RS operations, when appropriate, to permit		prioritization of I2RS operations, when appropriate, to permit
	implementations to shed work load when operating under constrained		implementations to shed work load when operating under constrained
	resources. An example of such a work shedding mechanism is rate-		resources. An example of such a work shedding mechanism is rate-
	limiting.		limiting.
	3.3. Hierarchy		3.3. Hierarchy
	skipping to change at page 8, line 14		skipping to change at page 8, line 14
	processing of the configuration change for two I2RS clients must		processing of the configuration change for two I2RS clients must
	detect an I2RS collision and resolve the collision using the priority		detect an I2RS collision and resolve the collision using the priority
	mechanism.		mechanism.
	Ephemeral-REQ-13: Multi-headed control is required for collisions and		Ephemeral-REQ-13: Multi-headed control is required for collisions and
	the priority resolution of collisions. Multi-headed control is not		the priority resolution of collisions. Multi-headed control is not
	tied to ephemeral state. I2RS protocol MUST NOT mandate the internal		tied to ephemeral state. I2RS protocol MUST NOT mandate the internal
	mechanism for how AAA protocols (E.g. Radius or Diameter) or		mechanism for how AAA protocols (E.g. Radius or Diameter) or
	mechanisms distribute priority per identity except that any AAA		mechanisms distribute priority per identity except that any AAA
	protocols MUST operate over a secure transport layer (See Radius		protocols MUST operate over a secure transport layer (See Radius
	[RFC6614] and Diameter [RFC6733]. distribute priority per identity.		[RFC6614] and Diameter [RFC6733]). Mechanisms that prevent
	Mechanisms which prevent collisions of two clients trying to modify		collisions of two clients trying to modify the same node of data are
	the same node of data are the focus.		the focus.
	Ephemeral-REQ-14: A deterministic conflict resolution mechanism MUST		Ephemeral-REQ-14: A deterministic conflict resolution mechanism MUST
	be provided to handle the error scenario that two clients, with the		be provided to handle the error scenario that two clients, with the
	same priority, update the same configuration data node. The I2RS		same priority, update the same configuration data node. The I2RS
	architecture gives one way that this could be achieved, by specifying		architecture gives one way that this could be achieved, by specifying
	that the first update wins. Other solutions, that prevent		that the first update wins. Other solutions, that prevent
	oscillation of the config data node, are also acceptable.		oscillation of the config data node, are also acceptable.
	8. Multiple Message Transactions		8. Multiple Message Transactions
	skipping to change at page 10, line 12		skipping to change at page 10, line 12
	o Joel Halpern,		o Joel Halpern,
	o Thomas Nadeau,		o Thomas Nadeau,
	o Juergen Schoenwaelder,		o Juergen Schoenwaelder,
	o Kent Watsen,		o Kent Watsen,
	o Robert Wilton, and		o Robert Wilton, and
	o Joe Clark,		o Joe Clarke
	13. References		13. References
	13.1. Normative References:		13.1. Normative References:
	[I-D.ietf-i2rs-protocol-security-requirements]		[I-D.ietf-i2rs-protocol-security-requirements]
	Hares, S., Migault, D., and J. Halpern, "I2RS Security		Hares, S., Migault, D., and J. Halpern, "I2RS Security
	Related Requirements", draft-ietf-i2rs-protocol-security-		Related Requirements", draft-ietf-i2rs-protocol-security-
	requirements-11 (work in progress), September 2016.		requirements-11 (work in progress), September 2016.
End of changes. 7 change blocks.
	10 lines changed or deleted		10 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/