rfc9645v3.txt		rfc9645.txt
	skipping to change at line 237 ¶		skipping to change at line 237 ¶
	[RFC8342]) and <system> [SYSTEM-CONFIG] if implemented.		[RFC8342]) and <system> [SYSTEM-CONFIG] if implemented.
	1.5. Conventions		1.5. Conventions
	Various examples in this document use "BASE64VALUE=" as a placeholder		Various examples in this document use "BASE64VALUE=" as a placeholder
	value for binary data that has been base64 encoded (per Section 9.8		value for binary data that has been base64 encoded (per Section 9.8
	of [RFC7950]). This placeholder value is used because real		of [RFC7950]). This placeholder value is used because real
	base64-encoded structures are often many lines long and hence		base64-encoded structures are often many lines long and hence
	distracting to the example being presented.		distracting to the example being presented.
			Various examples in this document use the XML [W3C.REC-xml-20081126]
			encoding. Other encodings, such as JSON [RFC8259], could
			alternatively be used.
			Various examples in this document contain long lines that may be
			folded, as described in [RFC8792].
	2. The "ietf-tls-common" Module		2. The "ietf-tls-common" Module
	The TLS common model presented in this section contains features and		The TLS common model presented in this section contains features and
	groupings common to both TLS clients and TLS servers. The "hello-		groupings common to both TLS clients and TLS servers. The "hello-
	params-grouping" grouping can be used to configure the list of TLS		params-grouping" grouping can be used to configure the list of TLS
	algorithms permitted by the TLS client or TLS server. The lists of		algorithms permitted by the TLS client or TLS server. The lists of
	algorithms are ordered such that, if multiple algorithms are		algorithms are ordered such that, if multiple algorithms are
	permitted by the client, the algorithm that appears first in its list		permitted by the client, the algorithm that appears first in its list
	and that is also permitted by the server is used for the TLS		and that is also permitted by the server is used for the TLS
	transport layer connection. The ability to restrict the algorithms		transport layer connection. The ability to restrict the algorithms
	skipping to change at line 513 ¶		skipping to change at line 520 ¶
	import ietf-crypto-types {		import ietf-crypto-types {
	prefix ct;		prefix ct;
	reference		reference
	"RFC 9640: YANG Data Types and Groupings for Cryptography";		"RFC 9640: YANG Data Types and Groupings for Cryptography";
	}		}
	import ietf-keystore {		import ietf-keystore {
	prefix ks;		prefix ks;
	reference		reference
	"RFC 9642: A YANG Data Model for a Keystore and Keystore		"RFC 9642: A YANG Data Model for a Keystore";
	Operations";
	}		}
	organization		organization
	"IETF NETCONF (Network Configuration) Working Group";		"IETF NETCONF (Network Configuration) Working Group";
	contact		contact
	"WG List: NETCONF WG list <mailto:netconf@ietf.org>		"WG List: NETCONF WG list <mailto:netconf@ietf.org>
	WG Web: https://datatracker.ietf.org/wg/netconf		WG Web: https://datatracker.ietf.org/wg/netconf
	Author: Kent Watsen <mailto:kent+ietf@watsen.net>		Author: Kent Watsen <mailto:kent+ietf@watsen.net>
	Author: Jeff Hartley <mailto:intensifysecurity@gmail.com>		Author: Jeff Hartley <mailto:intensifysecurity@gmail.com>
	skipping to change at line 1570 ¶		skipping to change at line 1576 ¶
	HeartbeatRequest messages, as defined by RFC 6520,		HeartbeatRequest messages, as defined by RFC 6520,
	to this TLS client.";		to this TLS client.";
	reference		reference
	"RFC 6520: Transport Layer Security (TLS) and Datagram		"RFC 6520: Transport Layer Security (TLS) and Datagram
	Transport Layer Security (DTLS) Heartbeat Extension";		Transport Layer Security (DTLS) Heartbeat Extension";
	}		}
	container test-peer-aliveness {		container test-peer-aliveness {
	presence "Indicates that the TLS client proactively tests the		presence "Indicates that the TLS client proactively tests the
	aliveness of the remote TLS server.";		aliveness of the remote TLS server.";
	description		description
	"Configures the keep-alive policy to proactively test		"Configures the keepalive policy to proactively test
	the aliveness of the TLS server. An unresponsive		the aliveness of the TLS server. An unresponsive
	TLS server is dropped after approximately max-wait		TLS server is dropped after approximately max-wait
	* max-attempts seconds. The TLS client MUST send		* max-attempts seconds. The TLS client MUST send
	HeartbeatRequest messages, as defined in RFC 6520.";		HeartbeatRequest messages, as defined in RFC 6520.";
	reference		reference
	"RFC 6520: Transport Layer Security (TLS) and Datagram		"RFC 6520: Transport Layer Security (TLS) and Datagram
	Transport Layer Security (DTLS) Heartbeat Extension";		Transport Layer Security (DTLS) Heartbeat Extension";
	leaf max-wait {		leaf max-wait {
	type uint16 {		type uint16 {
	range "1..max";		range "1..max";
	skipping to change at line 1594 ¶		skipping to change at line 1600 ¶
	description		description
	"Sets the amount of time in seconds, after which a		"Sets the amount of time in seconds, after which a
	TLS-level message will be sent to test the		TLS-level message will be sent to test the
	aliveness of the TLS server if no data has been		aliveness of the TLS server if no data has been
	received from the TLS server.";		received from the TLS server.";
	}		}
	leaf max-attempts {		leaf max-attempts {
	type uint8;		type uint8;
	default "3";		default "3";
	description		description
	"Sets the maximum number of sequential keep-alive		"Sets the maximum number of sequential keepalive
	messages that can fail to obtain a response from		messages that can fail to obtain a response from
	the TLS server before assuming the TLS server is		the TLS server before assuming the TLS server is
	no longer alive.";		no longer alive.";
	}		}
	}		}
	}		}
	} // grouping tls-client-grouping		} // grouping tls-client-grouping
	}		}
	<CODE ENDS>		<CODE ENDS>
	skipping to change at line 2368 ¶		skipping to change at line 2374 ¶
	HeartbeatRequest messages, as defined by RFC 6520,		HeartbeatRequest messages, as defined by RFC 6520,
	to this TLS server.";		to this TLS server.";
	reference		reference
	"RFC 6520: Transport Layer Security (TLS) and Datagram		"RFC 6520: Transport Layer Security (TLS) and Datagram
	Transport Layer Security (DTLS) Heartbeat Extension";		Transport Layer Security (DTLS) Heartbeat Extension";
	}		}
	container test-peer-aliveness {		container test-peer-aliveness {
	presence "Indicates that the TLS server proactively tests the		presence "Indicates that the TLS server proactively tests the
	aliveness of the remote TLS client.";		aliveness of the remote TLS client.";
	description		description
	"Configures the keep-alive policy to proactively test		"Configures the keepalive policy to proactively test
	the aliveness of the TLS client. An unresponsive		the aliveness of the TLS client. An unresponsive
	TLS client is dropped after approximately max-wait		TLS client is dropped after approximately max-wait
	* max-attempts seconds.";		* max-attempts seconds.";
	leaf max-wait {		leaf max-wait {
	type uint16 {		type uint16 {
	range "1..max";		range "1..max";
	}		}
	units "seconds";		units "seconds";
	default "30";		default "30";
	description		description
	"Sets the amount of time in seconds, after which a		"Sets the amount of time in seconds, after which a
	TLS-level message will be sent to test the		TLS-level message will be sent to test the
	aliveness of the TLS client if no data has been		aliveness of the TLS client if no data has been
	received from the TLS client.";		received from the TLS client.";
	}		}
	leaf max-attempts {		leaf max-attempts {
	type uint8;		type uint8;
	default "3";		default "3";
	description		description
	"Sets the maximum number of sequential keep-alive		"Sets the maximum number of sequential keepalive
	messages that can fail to obtain a response from		messages that can fail to obtain a response from
	the TLS client before assuming the TLS client is		the TLS client before assuming the TLS client is
	no longer alive.";		no longer alive.";
	}		}
	}		}
	} // container keepalives		} // container keepalives
	} // grouping tls-server-grouping		} // grouping tls-server-grouping
	}		}
	<CODE ENDS>		<CODE ENDS>
	skipping to change at line 2410 ¶		skipping to change at line 2416 ¶
	5. Security Considerations		5. Security Considerations
	The three IETF YANG modules in this document define groupings and		The three IETF YANG modules in this document define groupings and
	will not be deployed as standalone modules. Their security		will not be deployed as standalone modules. Their security
	implications may be context dependent based on their use in other		implications may be context dependent based on their use in other
	modules. The designers of modules that import these grouping must		modules. The designers of modules that import these grouping must
	conduct their own analysis of the security considerations.		conduct their own analysis of the security considerations.
	5.1. Considerations for the "iana-tls-cipher-suite-algs" YANG Module		5.1. Considerations for the "iana-tls-cipher-suite-algs" YANG Module
	This section follows the template defined in Section 3.7.1 of		This section is modeled after the template defined in Section 3.7.1
	[RFC8407].		of [RFC8407].
	The "iana-tls-cipher-suite-algs" YANG module defines a data model		The "iana-tls-cipher-suite-algs" YANG module defines a data model
	that is designed to be accessed via YANG-based network management		that is designed to be accessed via YANG-based management protocols,
	protocols such as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of		such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols
	these protocols have mandatory-to-implement secure transport layers		have mandatory-to-implement secure transport layers (e.g., Secure
	(e.g., SSH, TLS) with mutual authentication.		Shell (SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and
			mandatory-to-implement 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 users to a		provides the means to restrict access for particular users to a
	preconfigured subset of all available protocol operations and		preconfigured subset of all available protocol operations and
	content.		content.
	This YANG module defines YANG enumerations, for a public IANA-		This YANG module defines YANG enumerations, for a public IANA-
	maintained registry.		maintained registry.
	YANG enumerations are not security-sensitive, as they are statically		YANG enumerations are not security-sensitive, as they are statically
	defined in the publicly accessible YANG module. IANA MAY deprecate		defined in the publicly accessible YANG module. IANA MAY deprecate
	and/or obsolete enumerations over time as needed to address security		and/or obsolete enumerations over time as needed to address security
	issues found in the algorithms.		issues found in the algorithms.
	This module does not define any writable nodes, RPCs, actions, or		This module does not define any writable nodes, RPCs, actions, or
	notifications, and thus the security considerations for such are not		notifications, and thus the security considerations for such are not
	provided here.		provided here.
	5.2. Considerations for the "ietf-tls-common" YANG Module		5.2. Considerations for the "ietf-tls-common" YANG Module
	This section follows the template defined in Section 3.7.1 of		This section is modeled after the template defined in Section 3.7.1
	[RFC8407].		of [RFC8407].
	The "ietf-tls-common" YANG module defines "grouping" statements that		The "ietf-tls-common" YANG module defines a data model that is
	are designed to be accessed via YANG-based management protocols such		designed to be accessed via YANG-based management protocols, such as
	as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols		NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have
	have mandatory-to-implement secure transport layers (e.g., SSH, TLS)		mandatory-to-implement secure transport layers (e.g., Secure Shell
	with mutual authentication.		(SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and mandatory-to-
			implement 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 users to a		provides the means to restrict access for particular users to a
	preconfigured subset of all available protocol operations and		preconfigured subset of all available protocol operations and
	content.		content.
	Please be aware that this YANG module uses groupings from other YANG		Please be aware that this YANG module uses groupings from other YANG
	modules that define nodes that may be considered sensitive or		modules that define nodes that may be considered sensitive or
	vulnerable in network environments. Please review the Security		vulnerable in network environments. Please review the Security
	Considerations for dependent YANG modules for information as to which		Considerations for dependent YANG modules for information as to which
	skipping to change at line 2479 ¶		skipping to change at line 2487 ¶
	This module defines the "generate-asymmetric-key-pair" RPC that may,		This module defines the "generate-asymmetric-key-pair" RPC that may,
	if the "ct:cleartext-private-keys" feature is enabled and the client		if the "ct:cleartext-private-keys" feature is enabled and the client
	requests it, return the private clear in cleartext form. It is NOT		requests it, return the private clear in cleartext form. It is NOT
	RECOMMENDED for private keys to pass the server's security perimeter.		RECOMMENDED for private keys to pass the server's security perimeter.
	This module does not define any actions or notifications, and thus		This module does not define any actions or notifications, and thus
	the security considerations for such are not provided here.		the security considerations for such are not provided here.
	5.3. Considerations for the "ietf-tls-client" YANG Module		5.3. Considerations for the "ietf-tls-client" YANG Module
	This section follows the template defined in Section 3.7.1 of		This section is modeled after the template defined in Section 3.7.1
	[RFC8407].		of [RFC8407].
	The "ietf-tls-client" YANG module defines "grouping" statements that		The "ietf-tls-client" YANG module defines a data model that is
	are designed to be accessed via YANG-based management protocols such		designed to be accessed via YANG-based management protocols, such as
	as NETCONF [RFC6241] or RESTCONF [RFC8040]. Both of these protocols		NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have
	have mandatory-to-implement secure transport layers (e.g., SSH, TLS)		mandatory-to-implement secure transport layers (e.g., Secure Shell
	with mutual authentication.		(SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and mandatory-to-
			implement mutual authentication.
	The Network Access Control Model (NACM) [RFC8341] provides the means		The Network Configuration Access Control Model (NACM) [RFC8341]
	to restrict access for particular users to a preconfigured subset of		provides the means to restrict access for particular users to a
	all available protocol operations and content.		preconfigured subset of all available protocol operations and
			content.
	Please be aware that this YANG module uses groupings from other YANG		Please be aware that this YANG module uses groupings from other YANG
	modules that define nodes that may be considered sensitive or		modules that define nodes that may be considered sensitive or
	vulnerable in network environments. Please review the Security		vulnerable in network environments. Please review the Security
	Considerations for dependent YANG modules for information as to which		Considerations for dependent YANG modules for information as to which
	nodes may be considered sensitive or vulnerable in network		nodes may be considered sensitive or vulnerable in network
	environments.		environments.
	None of the readable data nodes defined in this YANG module are		None of the readable data nodes defined in this YANG module are
	considered sensitive or vulnerable in network environments. The NACM		considered sensitive or vulnerable in network environments. The NACM
	skipping to change at line 2516 ¶		skipping to change at line 2526 ¶
	any modification to a key or reference to a key may dramatically		any modification to a key or reference to a key may dramatically
	alter the implemented security policy. For this reason, the NACM		alter the implemented security policy. For this reason, the NACM
	extension "default-deny-write" has been set for all data nodes		extension "default-deny-write" has been set for all data nodes
	defined in this module.		defined in this module.
	This module does not define any RPCs, actions, or notifications, and		This module does not define any RPCs, actions, or notifications, and
	thus the security considerations for such are not provided here.		thus the security considerations for such are not provided here.
	5.4. Considerations for the "ietf-tls-server" YANG Module		5.4. Considerations for the "ietf-tls-server" YANG Module
	This section follows the template defined in Section 3.7.1 of		This section is modeled after the template defined in Section 3.7.1
	[RFC8407].		of [RFC8407].
	The "ietf-tls-server" YANG module defines "grouping" statements that		The "ietf-tls-server" YANG module defines a data model that is
	are designed to be accessed via YANG-based management protocols such		designed to be accessed via YANG-based management protocols, such as
	as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols		NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have
	have mandatory-to-implement secure transport layers (e.g., SSH, TLS)		mandatory-to-implement secure transport layers (e.g., Secure Shell
	with mutual authentication.		(SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and mandatory-to-
			implement 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 users to a		provides the means to restrict access for particular users to a
	preconfigured subset of all available protocol operations and		preconfigured subset of all available protocol operations and
	content.		content.
	Please be aware that this YANG module uses groupings from other YANG		Please be aware that this YANG module uses groupings from other YANG
	modules that define nodes that may be considered sensitive or		modules that define nodes that may be considered sensitive or
	vulnerable in network environments. Please review the Security		vulnerable in network environments. Please review the Security
	Considerations for dependent YANG modules for information as to which		Considerations for dependent YANG modules for information as to which
	skipping to change at line 2622 ¶		skipping to change at line 2633 ¶
	[RFC8407BIS].		[RFC8407BIS].
	IANA used the script in Appendix A to generate the IANA-maintained		IANA used the script in Appendix A to generate the IANA-maintained
	"iana-tls-cipher-suite-algs" YANG module. The YANG module is		"iana-tls-cipher-suite-algs" YANG module. The YANG module is
	available from the "YANG Parameters" registry [IANA-YANG-PARAMETERS].		available from the "YANG Parameters" registry [IANA-YANG-PARAMETERS].
	IANA has added the following note to the registry:		IANA has added the following note to the registry:
	| New values must not be directly added to the "iana-tls-cipher-		| New values must not be directly added to the "iana-tls-cipher-
	| suite-algs" YANG module. They must instead be added to the "TLS		| suite-algs" YANG module. They must instead be added to the "TLS
	| Cipher Suites" registry under the "Transport Layer Security (TLS)		| Cipher Suites" registry in the the "Transport Layer Security (TLS)
	| Parameters" registry group [IANA-CIPHER-ALGS].		| Parameters" registry group [IANA-CIPHER-ALGS].
	When a value is added to the "TLS Cipher Suites" registry, a new		When a value is added to the "TLS Cipher Suites" registry, a new
	"enum" statement must be added to the "iana-tls-cipher-suite-algs"		"enum" statement must be added to the "iana-tls-cipher-suite-algs"
	YANG module. The "enum" statement, and substatements thereof, should		YANG module. The "enum" statement, and substatements thereof, should
	be defined as follows:		be defined as follows:
	enum		enum
	Replicates a name from the registry.		Replicates a name from the registry.
	skipping to change at line 2704 ¶		skipping to change at line 2715 ¶
	"Digital Signature Standard (DSS)", FIPS 186-5,		"Digital Signature Standard (DSS)", FIPS 186-5,
	DOI 10.6028/NIST.FIPS.186-5, February 2023,		DOI 10.6028/NIST.FIPS.186-5, February 2023,
	<https://nvlpubs.nist.gov/nistpubs/FIPS/		<https://nvlpubs.nist.gov/nistpubs/FIPS/
	NIST.FIPS.186-5.pdf>.		NIST.FIPS.186-5.pdf>.
	[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,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
			[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
			Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
			January 2006, <https://www.rfc-editor.org/info/rfc4252>.
	[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key		[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
	Ciphersuites for Transport Layer Security (TLS)",		Ciphersuites for Transport Layer Security (TLS)",
	RFC 4279, DOI 10.17487/RFC4279, December 2005,		RFC 4279, DOI 10.17487/RFC4279, December 2005,
	<https://www.rfc-editor.org/info/rfc4279>.		<https://www.rfc-editor.org/info/rfc4279>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	skipping to change at line 2780 ¶		skipping to change at line 2795 ¶
	[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic		[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
	Curve Cryptography (ECC) Cipher Suites for Transport Layer		Curve Cryptography (ECC) Cipher Suites for Transport Layer
	Security (TLS) Versions 1.2 and Earlier", RFC 8422,		Security (TLS) Versions 1.2 and Earlier", RFC 8422,
	DOI 10.17487/RFC8422, August 2018,		DOI 10.17487/RFC8422, August 2018,
	<https://www.rfc-editor.org/info/rfc8422>.		<https://www.rfc-editor.org/info/rfc8422>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	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>.
			[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>.
	[RFC9640] Watsen, K., "YANG Data Types and Groupings for		[RFC9640] Watsen, K., "YANG Data Types and Groupings for
	Cryptography", RFC 9640, DOI 10.17487/RFC9640, September		Cryptography", RFC 9640, DOI 10.17487/RFC9640, September
	2024, <https://www.rfc-editor.org/info/rfc9640>.		2024, <https://www.rfc-editor.org/info/rfc9640>.
	[RFC9641] Watsen, K., "A YANG Data Model for a Truststore",		[RFC9641] Watsen, K., "A YANG Data Model for a Truststore",
	RFC 9641, DOI 10.17487/RFC9641, September 2024,		RFC 9641, DOI 10.17487/RFC9641, September 2024,
	<https://www.rfc-editor.org/info/rfc9641>.		<https://www.rfc-editor.org/info/rfc9641>.
	[RFC9642] Watsen, K., "A YANG Data Model for a Keystore", RFC 9642,		[RFC9642] Watsen, K., "A YANG Data Model for a Keystore", RFC 9642,
	DOI 10.17487/RFC9642, September 2024,		DOI 10.17487/RFC9642, September 2024,
	skipping to change at line 2840 ¶		skipping to change at line 2860 ¶
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<https://www.rfc-editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.
	[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",		[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
	RFC 8071, DOI 10.17487/RFC8071, February 2017,		RFC 8071, DOI 10.17487/RFC8071, February 2017,
	<https://www.rfc-editor.org/info/rfc8071>.		<https://www.rfc-editor.org/info/rfc8071>.
			[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
			Interchange Format", STD 90, RFC 8259,
			DOI 10.17487/RFC8259, December 2017,
			<https://www.rfc-editor.org/info/rfc8259>.
	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",		[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,		BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.		<https://www.rfc-editor.org/info/rfc8340>.
	[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,		[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
	and R. Wilton, "Network Management Datastore Architecture		and R. Wilton, "Network Management Datastore Architecture
	(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,		(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
	<https://www.rfc-editor.org/info/rfc8342>.		<https://www.rfc-editor.org/info/rfc8342>.
	[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of		[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
	Documents Containing YANG Data Models", BCP 216, RFC 8407,		Documents Containing YANG Data Models", BCP 216, RFC 8407,
	DOI 10.17487/RFC8407, October 2018,		DOI 10.17487/RFC8407, October 2018,
	<https://www.rfc-editor.org/info/rfc8407>.		<https://www.rfc-editor.org/info/rfc8407>.
	[RFC8407BIS]		[RFC8407BIS]
	Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for		Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
	Authors and Reviewers of Documents Containing YANG Data		Authors and Reviewers of Documents Containing YANG Data
	Models", Work in Progress, Internet-Draft, draft-ietf-		Models", Work in Progress, Internet-Draft, draft-ietf-
	netmod-rfc8407bis-14, 5 July 2024,		netmod-rfc8407bis-15, 10 September 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-		<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
	rfc8407bis-14>.		rfc8407bis-15>.
	[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS		[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
	1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,		1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
	<https://www.rfc-editor.org/info/rfc8996>.		<https://www.rfc-editor.org/info/rfc8996>.
	[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", STD 97, RFC 9110,		Ed., "HTTP Semantics", STD 97, RFC 9110,
	DOI 10.17487/RFC9110, June 2022,		DOI 10.17487/RFC9110, June 2022,
	<https://www.rfc-editor.org/info/rfc9110>.		<https://www.rfc-editor.org/info/rfc9110>.
	skipping to change at line 2896 ¶		skipping to change at line 2921 ¶
	Servers", RFC 9644, DOI 10.17487/RFC9644, September 2024,		Servers", RFC 9644, DOI 10.17487/RFC9644, September 2024,
	<https://www.rfc-editor.org/info/rfc9644>.		<https://www.rfc-editor.org/info/rfc9644>.
	[SYSTEM-CONFIG]		[SYSTEM-CONFIG]
	Ma, Q., Wu, Q., and C. Feng, "System-defined		Ma, Q., Wu, Q., and C. Feng, "System-defined
	Configuration", Work in Progress, Internet-Draft, draft-		Configuration", Work in Progress, Internet-Draft, draft-
	ietf-netmod-system-config-08, 18 June 2024,		ietf-netmod-system-config-08, 18 June 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-		<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
	system-config-08>.		system-config-08>.
			[W3C.REC-xml-20081126]
			Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E.,
			and F. Yergeau, "Extensible Markup Language (XML) 1.0
			(Fifth Edition)", W3C Recommendation REC-xml-20081126,
			November 2008, <https://www.w3.org/TR/xml/>.
	Appendix A. Script to Generate IANA-Maintained YANG Modules		Appendix A. Script to Generate IANA-Maintained YANG Modules
	This section is not normative.		This section is not normative.
	The Python <https://www.python.org> script contained in this section		The Python <https://www.python.org> script contained in this section
	was used to create the initial IANA-maintained "iana-tls-cipher-		was used to create the initial IANA-maintained "iana-tls-cipher-
	suite-algs" YANG module maintained at [IANA-YANG-PARAMETERS].		suite-algs" YANG module maintained at [IANA-YANG-PARAMETERS].
	Run the script using the command 'python gen-yang-modules.py' to		Run the script using the command 'python gen-yang-modules.py' to
	produce the YANG module file in the current directory.		produce the YANG module file in the current directory.
End of changes. 22 change blocks.
	39 lines changed or deleted		70 lines changed or added
This html diff was produced by rfcdiff 1.48.