draft-ietf-netconf-configuration-tracing-04.txt		draft-ietf-netconf-configuration-tracing-05.txt
	OPSAWG J. Quilbeuf		OPSAWG J. Quilbeuf
	Internet-Draft B. Claise		Internet-Draft B. Claise
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: 4 September 2025 T. Graf		Expires: 19 September 2025 T. Graf
	Swisscom		Swisscom
	D. Lopez		D. Lopez
	Telefonica I+D		Telefonica I+D
	Q. Sun		Q. Sun
	China Telecom		China Telecom
	3 March 2025		18 March 2025
	External Trace ID for Configuration Tracing		External Trace ID for Configuration Tracing
	draft-ietf-netconf-configuration-tracing-04		draft-ietf-netconf-configuration-tracing-05
	Abstract		Abstract
	Network equipment are often configured by a variety of network		Network equipment are often configured by a variety of network
	management systems (NMS), protocols, and teams. If a network issue		management systems (NMS), protocols, and teams. If a network issue
	arises (e.g., because of a wrong configuration change), it is		arises (e.g., because of a wrong configuration change), it is
	important to quickly identify the root cause and obtain the reason		important to quickly identify the root cause and obtain the reason
	for pushing that modification. Another potential network issue can		for pushing that modification. Another potential network issue can
	stem from concurrent NMSes with overlapping intents, each having		stem from concurrent NMSes with overlapping intents, each having
	their own tasks to perform. In such a case, it is important to map		their own tasks to perform. In such a case, it is important to map
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	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 4 September 2025.		This Internet-Draft will expire on 19 September 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2025 IETF Trust and the persons identified as the		Copyright (c) 2025 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
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 4 ¶
	4.2. Client ID . . . . . . . . . . . . . . . . . . . . . . . . 6		4.2. Client ID . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.3. Instantiating the YANG module . . . . . . . . . . . . . . 6		4.3. Instantiating the YANG module . . . . . . . . . . . . . . 6
	4.4. Using the YANG module . . . . . . . . . . . . . . . . . . 7		4.4. Using the YANG module . . . . . . . . . . . . . . . . . . 7
	5. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9		5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.2. YANG module ietf-external-transaction-id . . . . . . . . 10		5.2. YANG module ietf-external-transaction-id . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
	9. Open Issues / TODO . . . . . . . . . . . . . . . . . . . . . 14		9. Open Issues / TODO . . . . . . . . . . . . . . . . . . . . . 14
	10. Normative References . . . . . . . . . . . . . . . . . . . . 14		10. Normative References . . . . . . . . . . . . . . . . . . . . 15
	11. Informative References . . . . . . . . . . . . . . . . . . . 16		11. Informative References . . . . . . . . . . . . . . . . . . . 16
	Appendix A. Changes between revisions . . . . . . . . . . . . . 16		Appendix A. Changes between revisions . . . . . . . . . . . . . 17
	Appendix B. Example of NETCONF message . . . . . . . . . . . . . 17		Appendix B. Example of NETCONF message . . . . . . . . . . . . . 17
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	Issues arising in the network, for instance violation of some SLAs,		Issues arising in the network, for instance violation of some SLAs,
	might be due to some configuration modification. In the context of		might be due to some configuration modification. In the context of
	automated networks, the assurance system needs not only to identify		automated networks, the assurance system needs not only to identify
	and revert the problematic configuration modification, but also to		and revert the problematic configuration modification, but also to
	make sure that it won't happen again and that the fix will not		make sure that it won't happen again and that the fix will not
	disrupt other services. To cover the last two points, it is		disrupt other services. To cover the last two points, it is
	imperative to understand the cause of the problematic configuration		imperative to understand the cause of the problematic configuration
	skipping to change at page 13, line 41 ¶		skipping to change at page 13, line 41 ¶
	This data node is present only when the configuration was		This data node is present only when the configuration was
	pushed by a compatible system.";		pushed by a compatible system.";
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	6. Security Considerations		6. Security Considerations
	The YANG module specified in this document defines a schema for data		This section is modeled after the template described in Section 3.7
	that is designed to be accessed via network management protocols such		of [I-D.ietf-netmod-rfc8407bis].
	as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
	is the secure transport layer, and the mandatory-to-implement secure		The "ietf-external-transaction-id" module defines a data model that
	transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer		is designed to be accessed via YANG-based management protocols, such
	is HTTPS, and the mandatory-to-implement secure transport is TLS		as NETCONF [RFC6241] and RESTCONF[RFC8040]. These protocols have to
	[RFC8446].		use a secure transport layer (e.g., SSH [RFC6242], TLS [RFC8446] and
			QUIC [RFC9000]) and have to use mutual authentication.
	The Network Configuration Access Control Model (NACM) [RFC8341]		The Network Configuration Access Control Model (NACM) [RFC8341]
	provides the means to restrict access for particular NETCONF or		provides the means to restrict access for particular NETCONF or
	RESTCONF users to a preconfigured subset of all available NETCONF or		RESTCONF users to a preconfigured subset of all available NETCONF or
	RESTCONF protocol operations and content.		RESTCONF protocol operations and content.
	Some of the readable data nodes in this YANG module may be considered		Some of the readable data nodes in this YANG module may be considered
	sensitive or vulnerable in some network environments. It is thus		sensitive or vulnerable in some network environments. It is thus
	important to control read access (e.g., via get, get-config, or		important to control read access (e.g., via get, get-config, or
	notification) to these data nodes. These are the subtrees and data		notification) to these data nodes. Specifically, the following
	nodes and their sensitivity/vulnerability:		subtrees and data nodes have particular sensitivities/
			vulnerabilities:
	* external-transactions-id/configuration-change exposes information		* external-transactions-id/configuration-change exposes information
	about which user or external system can configure the device and		about which user or external system can configure the device and
	could help an attacker to send its own configuration to the		could help an attacker to send its own configuration to the
	device. It could also give some information about the		device. It could also give some information about the
	architecture of the configuration, i.e. what are the controllers		architecture of the configuration, i.e. what are the controllers
	and the orchestrators.		and the orchestrators.
	7. IANA Considerations		7. IANA Considerations
	skipping to change at page 15, line 9 ¶		skipping to change at page 15, line 11 ¶
	This section is to be removed before publishing as an RFC.		This section is to be removed before publishing as an RFC.
	None		None
	10. Normative References		10. Normative References
	[I-D.ietf-netconf-restconf-trace-ctx-headers]		[I-D.ietf-netconf-restconf-trace-ctx-headers]
	Gagliano, R., Larsson, K., and J. Lindblad, "RESTCONF		Gagliano, R., Larsson, K., and J. Lindblad, "RESTCONF
	Extension to Support Trace Context Headers", Work in		Extension to Support Trace Context Headers", Work in
	Progress, Internet-Draft, draft-ietf-netconf-restconf-		Progress, Internet-Draft, draft-ietf-netconf-restconf-
	trace-ctx-headers-06, 12 December 2024,		trace-ctx-headers-06, 3 March 2025,
	<https://datatracker.ietf.org/api/v1/doc/document/draft-		<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
	ietf-netconf-restconf-trace-ctx-headers/>.		restconf-trace-ctx-headers-06>.
	[I-D.ietf-netconf-trace-ctx-extension]		[I-D.ietf-netconf-trace-ctx-extension]
	Gagliano, R., Larsson, K., and J. Lindblad, "NETCONF		Gagliano, R., Larsson, K., and J. Lindblad, "NETCONF
	Extension to support Trace Context propagation", Work in		Extension to support Trace Context propagation", Work in
	Progress, Internet-Draft, draft-ietf-netconf-trace-ctx-		Progress, Internet-Draft, draft-ietf-netconf-trace-ctx-
	extension-04, 3 March 2025,		extension-04, 3 March 2025,
	<https://datatracker.ietf.org/api/v1/doc/document/draft-		<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
	ietf-netconf-trace-ctx-extension/>.		trace-ctx-extension-04>.
	[I-D.ietf-netconf-transaction-id]		[I-D.ietf-netconf-transaction-id]
	Lindblad, J., "Transaction ID Mechanism for NETCONF", Work		Lindblad, J., "Transaction ID Mechanism for NETCONF", Work
	in Progress, Internet-Draft, draft-ietf-netconf-		in Progress, Internet-Draft, draft-ietf-netconf-
	transaction-id-07, 19 October 2024,		transaction-id-07, 19 October 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-		<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
	transaction-id-07>.		transaction-id-07>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	skipping to change at page 16, line 21 ¶		skipping to change at page 16, line 25 ¶
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[W3C-Trace-Context]		[W3C-Trace-Context]
	"W3C Recommendation on Trace Context", 23 November 2021,		"W3C Recommendation on Trace Context", 23 November 2021,
	<https://www.w3.org/TR/2021/REC-trace-context-		<https://www.w3.org/TR/2021/REC-trace-context-
	1-20211123/>.		1-20211123/>.
	11. Informative References		11. Informative References
			[I-D.ietf-netmod-rfc8407bis]
			Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
			Authors and Reviewers of Documents Containing YANG Data
			Models", Work in Progress, Internet-Draft, draft-ietf-
			netmod-rfc8407bis-22, 14 January 2025,
			<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
			rfc8407bis-22>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010,
	<https://www.rfc-editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.
			[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
			Multiplexed and Secure Transport", RFC 9000,
			DOI 10.17487/RFC9000, May 2021,
			<https://www.rfc-editor.org/info/rfc9000>.
	[RFC9417] Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T.		[RFC9417] Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T.
	Arumugam, "Service Assurance for Intent-Based Networking		Arumugam, "Service Assurance for Intent-Based Networking
	Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023,		Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023,
	<https://www.rfc-editor.org/info/rfc9417>.		<https://www.rfc-editor.org/info/rfc9417>.
	Appendix A. Changes between revisions		Appendix A. Changes between revisions
	This section is to be removed before publishing as an RFC.		This section is to be removed before publishing as an RFC.
			04 -> 05
			* Fix security considerations template
	03 -> 04		03 -> 04
	* Add security and IANA considerations		* Add security and IANA considerations
	01 -> 02		01 -> 02
	* Remove YANG specific annotation for the mechanism to pass the		* Remove YANG specific annotation for the mechanism to pass the
	client-id.		client-id.
	* Align with NETCONF Trace context draft.		* Align with NETCONF Trace context draft.
End of changes. 14 change blocks.
	22 lines changed or deleted		41 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/