draft-ietf-netconf-privcand-03.txt		draft-ietf-netconf-privcand-04.txt
	Internet Engineering Task Force JG. Cumming		Internet Engineering Task Force JG. Cumming
	Internet-Draft Nokia		Internet-Draft Nokia
	Updates: 6241, 8526, 9144 (if approved) R. Wills		Updates: 6241, 8342, 8526, 9144 (if approved) R. Wills
	Intended status: Standards Track Cisco Systems		Intended status: Standards Track Cisco Systems
	Expires: 1 December 2024 30 May 2024		Expires: 3 January 2025 2 July 2024
	NETCONF Private Candidates		NETCONF Private Candidates
	draft-ietf-netconf-privcand-03		draft-ietf-netconf-privcand-04
	Abstract		Abstract
	This document provides a mechanism to extend the Network		This document provides a mechanism to extend the Network
	Configuration Protocol (NETCONF) and RESTCONF protocol to support		Configuration Protocol (NETCONF) and RESTCONF protocol to support
	multiple clients making configuration changes simultaneously and		multiple clients making configuration changes simultaneously and
	ensuring that they commit only those changes that they defined.		ensuring that they commit only those changes that they defined.
	This document addresses two specific aspects: The interaction with a		This document addresses two specific aspects: The interaction with a
	private candidate over the NETCONF and RESTCONF protocols and the		private candidate over the NETCONF and RESTCONF protocols and the
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 1 December 2024.		This Internet-Draft will expire on 3 January 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
			1.2. Updates to RFC 6241 and RFC 8526 . . . . . . . . . . . . 4
			1.3. Updates to RFC 8342 . . . . . . . . . . . . . . . . . . . 4
			1.4. Updates to RFC 9144 . . . . . . . . . . . . . . . . . . . 4
	2. Definitions and terminology . . . . . . . . . . . . . . . . . 4		2. Definitions and terminology . . . . . . . . . . . . . . . . . 4
	2.1. Session specific datastore . . . . . . . . . . . . . . . 4		2.1. Session specific datastore . . . . . . . . . . . . . . . 4
	2.2. Shared candidate configuration . . . . . . . . . . . . . 4		2.2. Shared candidate configuration . . . . . . . . . . . . . 4
	2.3. Private candidate configuration . . . . . . . . . . . . . 4		2.3. Private candidate configuration . . . . . . . . . . . . . 4
	3. Limitations using the shared candidate configuration for		3. Limitations using the shared candidate configuration for
	multiple clients . . . . . . . . . . . . . . . . . . . . 5		multiple clients . . . . . . . . . . . . . . . . . . . . 5
	3.1. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1.1. Unintended deployment of alternate users configuration		3.1.1. Unintended deployment of alternate users configuration
	changes . . . . . . . . . . . . . . . . . . . . . . . 5		changes . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Current mitigation strategies . . . . . . . . . . . . . . 5		3.2. Current mitigation strategies . . . . . . . . . . . . . . 6
	3.2.1. Locking the shared candidate configuration		3.2.1. Locking the shared candidate configuration
	datastore . . . . . . . . . . . . . . . . . . . . . . 5		datastore . . . . . . . . . . . . . . . . . . . . . . 6
	3.2.2. Always use the running configuration datastore . . . 6		3.2.2. Always use the running configuration datastore . . . 6
	3.2.3. Fine-grained locking . . . . . . . . . . . . . . . . 6		3.2.3. Fine-grained locking . . . . . . . . . . . . . . . . 6
	4. Private candidates solution . . . . . . . . . . . . . . . . . 6		4. Private candidates solution . . . . . . . . . . . . . . . . . 7
	4.1. What is a private candidate . . . . . . . . . . . . . . . 7		4.1. What is a private candidate . . . . . . . . . . . . . . . 7
	4.2. When is a private candidate created . . . . . . . . . . . 7		4.2. When is a private candidate created . . . . . . . . . . . 7
	4.3. When is a private candidate destroyed . . . . . . . . . . 7		4.3. When is a private candidate destroyed . . . . . . . . . . 8
	4.4. How to signal the use of private candidates . . . . . . . 7		4.4. How to signal the use of private candidates . . . . . . . 8
	4.4.1. Server . . . . . . . . . . . . . . . . . . . . . . . 7		4.4.1. Server . . . . . . . . . . . . . . . . . . . . . . . 8
	4.4.2. NETCONF client . . . . . . . . . . . . . . . . . . . 8		4.4.2. NETCONF client . . . . . . . . . . . . . . . . . . . 8
	4.4.3. RESTCONF client . . . . . . . . . . . . . . . . . . . 10		4.4.3. RESTCONF client . . . . . . . . . . . . . . . . . . . 11
	4.5. Interaction between running and private-candidate(s) . . 11		4.5. Interaction between running and private-candidate(s) . . 12
	4.6. Detecting and resolving conflicts . . . . . . . . . . . . 13		4.6. Detecting and resolving conflicts . . . . . . . . . . . . 14
	4.6.1. What is a conflict? . . . . . . . . . . . . . . . . . 13		4.6.1. What is a conflict? . . . . . . . . . . . . . . . . . 14
	4.6.2. Detecting and reporting conflicts . . . . . . . . . . 14		4.6.2. Detecting and reporting conflicts . . . . . . . . . . 15
	4.6.3. Conflict resolution . . . . . . . . . . . . . . . . . 15		4.6.3. Conflict resolution . . . . . . . . . . . . . . . . . 16
	4.6.4. Default resolution mode and advertisement of this		4.6.4. Default resolution mode and advertisement of this
	mode . . . . . . . . . . . . . . . . . . . . . . . . 22		mode . . . . . . . . . . . . . . . . . . . . . . . . 23
	4.6.5. Supported resolution modes . . . . . . . . . . . . . 23		4.6.5. Supported resolution modes . . . . . . . . . . . . . 24
	4.7. NETCONF operations . . . . . . . . . . . . . . . . . . . 23		4.7. NETCONF operations . . . . . . . . . . . . . . . . . . . 24
	4.7.1. New NETCONF operations . . . . . . . . . . . . . . . 23		4.7.1. New NETCONF operations . . . . . . . . . . . . . . . 24
	4.7.2. Updated NETCONF operations . . . . . . . . . . . . . 24		4.7.2. Updated NETCONF operations . . . . . . . . . . . . . 25
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 28		6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
	7.1. Normative References . . . . . . . . . . . . . . . . . . 28		7.1. Normative References . . . . . . . . . . . . . . . . . . 29
	7.2. Informative References . . . . . . . . . . . . . . . . . 29		7.2. Informative References . . . . . . . . . . . . . . . . . 30
	Appendix A. Behaviour with unaltered NETCONF operations . . . . 29		Appendix A. Behaviour with unaltered NETCONF operations . . . . 30
	A.1. <get> . . . . . . . . . . . . . . . . . . . . . . . . . . 29		A.1. <get> . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	A.2. <cancel-commit> . . . . . . . . . . . . . . . . . . . . . 29		A.2. <cancel-commit> . . . . . . . . . . . . . . . . . . . . . 30
	Appendix B. YANG modules . . . . . . . . . . . . . . . . . . . . 29		Appendix B. YANG modules . . . . . . . . . . . . . . . . . . . . 30
	B.1. ietf-netconf@2024-04-16.yang . . . . . . . . . . . . . . 29		B.1. ietf-netconf@2024-04-16.yang . . . . . . . . . . . . . . 30
	B.2. ietf-datastores@2024-04-16.yang . . . . . . . . . . . . . 51		B.2. ietf-datastores@2024-04-16.yang . . . . . . . . . . . . . 52
	B.3. ietf-nmda-compare@2024-04-16.yang . . . . . . . . . . . . 53		B.3. ietf-nmda-compare@2024-04-16.yang . . . . . . . . . . . . 55
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 58		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 59
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
	1. Introduction		1. Introduction
	NETCONF [RFC6241] and RESTCONF [RFC8040] both provide a mechanism for		NETCONF [RFC6241] and RESTCONF [RFC8040] both provide a mechanism for
	one or more clients to make configuration changes to a device running		one or more clients to make configuration changes to a device running
	as a NETCONF/RESTCONF server. Each client has the ability to make		as a NETCONF/RESTCONF server. Each client has the ability to make
	one or more configuration changes to the server's shared candidate		one or more configuration changes to the server's shared candidate
	configuration.		configuration.
	As the name shared candidate suggests, all clients have access to the		As the name shared candidate suggests, all clients have access to the
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	candidates.		candidates.
	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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
			1.2. Updates to RFC 6241 and RFC 8526
			This document updates [RFC6241] to augment the NETCONF <edit-config>,
			<copy-config>, <get-config>, <commit>, <lock> and <unlock> operations
			to describe how they work with a private candidate datastore. These
			updates are described in Section 4.7.2. This document also adds a
			new <update> operation, described in Section 4.7.1.
			This document also updates [RFC8526] to augment the NETCONF <edit-
			data> and <get-data> operations to describe how they work with a
			private candidate datastore. These updates are described in
			Section 4.7.2.
			1.3. Updates to RFC 8342
			This document updates [RFC8342] to show how the private candidate
			datastore relates to other datastores. This is shown in
			Section 4.4.2.2.
			Specifially, NMDA is updated to add additional writeable
			configuration datastores called private candidates.
			1.4. Updates to RFC 9144
			This document updates [RFC9144] to augment the <compare> operation to
			describe how it works with the private candidate datastore. These
			updates are described in Section 4.7.2.4.
	2. Definitions and terminology		2. Definitions and terminology
	2.1. Session specific datastore		2.1. Session specific datastore
	A session specific datastore is a configuration datastore that,		A session specific datastore is a configuration datastore that,
	unlike the candidate and running configuration datastores which have		unlike the candidate and running configuration datastores which have
	only one per system, is bound to the specific NETCONF session.		only one per system, is bound to the specific NETCONF session.
	2.2. Shared candidate configuration		2.2. Shared candidate configuration
	skipping to change at page 9, line 15 ¶		skipping to change at page 10, line 9 ¶
	4.4.2.2. Private candidate datastore		4.4.2.2. Private candidate datastore
	The private candidate configuration datastore is exposed as its own		The private candidate configuration datastore is exposed as its own
	datastore similar to other NMDA [RFC8342] capable datastores. This		datastore similar to other NMDA [RFC8342] capable datastores. This
	datastore is called private-candidate.		datastore is called private-candidate.
	+-------------+ +-----------+ +---------------------+		+-------------+ +-----------+ +---------------------+
	| <candidate> | | <startup> | | <private-candidate> |-+		| <candidate> | | <startup> | | <private-candidate> |-+
	| (ct, rw) |<---+ +--->| (ct, rw) | +->| (ct, rw) | |-+		| (ct, rw) |<---+ +--->| (ct, rw) | +->| (ct, rw) | |-+
	+-------------+ | | +-----------+ | +---------------------+ | |		+-------------+ | | +-----------+ | +---------------------+ | |
	| | | | | +---------------------+ |		| | | | | +----------------------+ |
	| +-----------+<--------+ | +---------------------+		| +-----------+<--------+ | +----------------------+
	+-------->| <running> | | | // multiple		+-------->| <running> | | | // multiple
	| (ct, rw) |-------------------+ | // private-candidates		| (ct, rw) |-------------------+ | // private-candidates
	+-----------+<-------------------------------+ // possible		+-----------+<-------------------------------+ // possible
	|		|
	| // configuration transformations,		| // configuration transformations,
	| // e.g., removal of nodes marked as		| // e.g., removal of nodes marked as
	| // "inactive", expansion of		| // "inactive", expansion of
	| // templates		| // templates
	v		v
	+------------+		+------------+
	skipping to change at page 24, line 31 ¶		skipping to change at page 25, line 31 ¶
	Sending an <edit-config> request to private-candidate after one has		Sending an <edit-config> request to private-candidate after one has
	been sent to the shared candidate datastore in the same session will		been sent to the shared candidate datastore in the same session will
	fail (and visa-versa).		fail (and visa-versa).
	Multiple <edit-config> requests may be sent to the private-candidate		Multiple <edit-config> requests may be sent to the private-candidate
	datastore in a single session.		datastore in a single session.
	4.7.2.2. <edit-data>		4.7.2.2. <edit-data>
	The <edit-data> operation is updated to accept private-candidate as		The <edit-data> [RFC8526] operation is updated to accept private-
	valid input to the <datastore> field. (datastore is an identityref		candidate as valid input to the <datastore> field. (datastore is an
	and so the actual input will be ds:private-candidate).		identityref and so the actual input will be ds:private-candidate).
	The use of <edit-data> will create a private candidate configuration		The use of <edit-data> will create a private candidate configuration
	if one does not already exist for that NETCONF session.		if one does not already exist for that NETCONF session.
	Multiple <edit-data> requests may be sent to the private-candidate		Multiple <edit-data> requests may be sent to the private-candidate
	datastore in a single session.		datastore in a single session.
	4.7.2.3. <lock> and <unlock>		4.7.2.3. <lock> and <unlock>
	Performing a <lock> on the private-candidate datastore is a valid		Performing a <lock> on the private-candidate datastore is a valid
	skipping to change at page 26, line 19 ¶		skipping to change at page 27, line 19 ¶
	The use of <get-config> will create a private candidate configuration		The use of <get-config> will create a private candidate configuration
	if one does not already exist for that NETCONF session.		if one does not already exist for that NETCONF session.
	Sending an <get-config> request to private-candidate after one has		Sending an <get-config> request to private-candidate after one has
	been sent to the shared candidate datastore in the same session will		been sent to the shared candidate datastore in the same session will
	fail (and visa-versa).		fail (and visa-versa).
	4.7.2.6. <get-data>		4.7.2.6. <get-data>
	The <get-data> operation accepts the private-candidate as a valid		The <get-data> [RFC8526] operation accepts the private-candidate as a
	datastore.		valid datastore.
	The use of <get-data> will create a private candidate configuration		The use of <get-data> will create a private candidate configuration
	if one does not already exist for that NETCONF session.		if one does not already exist for that NETCONF session.
	Sending an <get-data> request to private-candidate after one has been		Sending an <get-data> request to private-candidate after one has been
	sent to the shared candidate datastore in the same session will fail		sent to the shared candidate datastore in the same session will fail
	(and visa-versa).		(and visa-versa).
	4.7.2.7. <copy-config>		4.7.2.7. <copy-config>
	skipping to change at page 29, line 5 ¶		skipping to change at page 30, line 5 ¶
	[RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote		[RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote
	Procedure Call (RPC) for NETCONF", RFC 5717,		Procedure Call (RPC) for NETCONF", RFC 5717,
	DOI 10.17487/RFC5717, December 2009,		DOI 10.17487/RFC5717, December 2009,
	<https://www.rfc-editor.org/info/rfc5717>.		<https://www.rfc-editor.org/info/rfc5717>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc8040>.		<https://www.rfc-editor.org/info/rfc8040>.
			[RFC8526] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
			and R. Wilton, "NETCONF Extensions to Support the Network
			Management Datastore Architecture", RFC 8526,
			DOI 10.17487/RFC8526, March 2019,
			<https://www.rfc-editor.org/info/rfc8526>.
	[RFC8527] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,		[RFC8527] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
	and R. Wilton, "RESTCONF Extensions to Support the Network		and R. Wilton, "RESTCONF Extensions to Support the Network
	Management Datastore Architecture", RFC 8527,		Management Datastore Architecture", RFC 8527,
	DOI 10.17487/RFC8527, March 2019,		DOI 10.17487/RFC8527, March 2019,
	<https://www.rfc-editor.org/info/rfc8527>.		<https://www.rfc-editor.org/info/rfc8527>.
	7.2. Informative References		7.2. Informative References
	Appendix A. Behaviour with unaltered NETCONF operations		Appendix A. Behaviour with unaltered NETCONF operations
End of changes. 16 change blocks.
	42 lines changed or deleted		79 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/