rfc9648v4.txt		rfc9648.txt
	skipping to change at line 55 ¶		skipping to change at line 55 ¶
	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 Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	in the Revised BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
			1.1. Conventions
	2. Requirements Language		2. Requirements Language
	3. YANG Module Overview		3. YANG Module Overview
	3.1. Scope		3.1. Scope
	3.2. Model Design		3.2. Model Design
	3.3. Tree Diagram		3.3. Tree Diagram
	4. TCP YANG Data Model		4. TCP YANG Data Model
	5. IANA Considerations		5. IANA Considerations
	5.1. The IETF XML Registry		5.1. The IETF XML Registry
	5.2. The YANG Module Names Registry		5.2. The YANG Module Names Registry
	6. Security Considerations		6. Security Considerations
	skipping to change at line 139 ¶		skipping to change at line 140 ¶
	* TCP-related configuration of a NAT (e.g., NAT44, NAT64, or		* TCP-related configuration of a NAT (e.g., NAT44, NAT64, or
	Destination NAT) is defined in "A YANG Module for Network Address		Destination NAT) is defined in "A YANG Module for Network Address
	Translation (NAT) and Network Prefix Translation (NPT)" [RFC8512]		Translation (NAT) and Network Prefix Translation (NPT)" [RFC8512]
	and "A YANG Data Model for Dual-Stack Lite (DS-Lite)" [RFC8513].		and "A YANG Data Model for Dual-Stack Lite (DS-Lite)" [RFC8513].
	* TCP-AO and TCP MD5 configuration for Layer 3 VPNs is modeled in "A		* TCP-AO and TCP MD5 configuration for Layer 3 VPNs is modeled in "A
	YANG Network Data Model for Layer 3 VPNs" [RFC9182]. This model		YANG Network Data Model for Layer 3 VPNs" [RFC9182]. This model
	assumes that TCP-AO-specific parameters are preconfigured in		assumes that TCP-AO-specific parameters are preconfigured in
	addition to the key chain parameters.		addition to the key chain parameters.
			1.1. Conventions
			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. Requirements Language		2. 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		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. YANG Module Overview		3. YANG Module Overview
	skipping to change at line 871 ¶		skipping to change at line 881 ¶
	<CODE ENDS>		<CODE ENDS>
	5. IANA Considerations		5. IANA Considerations
	5.1. The IETF XML Registry		5.1. The IETF XML Registry
	IANA has registered the following URI in the "ns" registry defined in		IANA has registered the following URI in the "ns" registry defined in
	the "IETF XML Registry" [RFC3688].		the "IETF XML Registry" [RFC3688].
	URI: urn:ietf:params:xml:ns:yang:ietf-tcp		URI: urn:ietf:params:xml:ns:yang:ietf-tcp
	Registrant Contact: The IESG.		Registrant Contact: The IESG
	XML: N/A; the requested URI is an XML namespace.		XML: N/A; the requested URI is an XML namespace.
	5.2. The YANG Module Names Registry		5.2. The YANG Module Names Registry
	IANA has registered the following in the "YANG Module Names" registry		IANA has registered the following in the "YANG Module Names" registry
	created by "YANG - A Data Modeling Language for the Network		created by "YANG - A Data Modeling Language for the Network
	Configuration Protocol (NETCONF)" [RFC6020].		Configuration Protocol (NETCONF)" [RFC6020].
	Name: ietf-tcp		Name: ietf-tcp
	Namespace: urn:ietf:params:xml:ns:yang:ietf-tcp		Namespace: urn:ietf:params:xml:ns:yang:ietf-tcp
	skipping to change at line 893 ¶		skipping to change at line 903 ¶
	Reference: RFC 9648		Reference: RFC 9648
	This is not an IANA maintained module; however, the URI and other		This is not an IANA maintained module; however, the URI and other
	details of the module are maintained by IANA.		details of the module are maintained by IANA.
	6. Security Considerations		6. Security Considerations
	This section is modeled after the template defined in Section 3.7.1		This section is modeled after the template defined in Section 3.7.1
	of [RFC8407].		of [RFC8407].
	The YANG module specified in this document defines a schema for data		The "ietf-tcp" YANG module defines a schema for data that is designed
	that is designed to be accessed via YANG-based management protocols,		to be accessed via YANG-based management protocols, such as NETCONF
	such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols		[RFC6241] and RESTCONF [RFC8040]. These protocols have mandatory-to-
	have mandatory-to-implement secure transport layers (e.g., Secure		implement secure transport layers (e.g., Secure Shell (SSH)
	Shell (SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and		[RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and mandatory-to-
	mandatory-to-implement mutual authentication.		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 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.
	There are a number of data nodes defined in this YANG module that are		There are a number of data nodes defined in this YANG module that are
	writable/creatable/deletable (i.e., "config true", which is the		writable/creatable/deletable (i.e., "config true", which is the
	default). These data nodes may be considered sensitive or vulnerable		default). These data nodes may be considered sensitive or vulnerable
	in some network environments. Write operations (e.g., edit-config)		in some network environments. Write operations (e.g., edit-config)
	skipping to change at line 1097 ¶		skipping to change at line 1107 ¶
	Information Version 2 (SMIv2) MIB Modules to YANG		Information Version 2 (SMIv2) MIB Modules to YANG
	Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012,		Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012,
	<https://www.rfc-editor.org/info/rfc6643>.		<https://www.rfc-editor.org/info/rfc6643>.
	[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of		[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
	BGP, LDP, PCEP, and MSDP Issues According to the Keying		BGP, LDP, PCEP, and MSDP Issues According to the Keying
	and Authentication for Routing Protocols (KARP) Design		and Authentication for Routing Protocols (KARP) Design
	Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,		Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
	<https://www.rfc-editor.org/info/rfc6952>.		<https://www.rfc-editor.org/info/rfc6952>.
			[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>.
	[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>.
	[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C.,		[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C.,
	Vinapamula, S., and Q. Wu, "A YANG Module for Network		Vinapamula, S., and Q. Wu, "A YANG Module for Network
	Address Translation (NAT) and Network Prefix Translation		Address Translation (NAT) and Network Prefix Translation
	(NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019,		(NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019,
	<https://www.rfc-editor.org/info/rfc8512>.		<https://www.rfc-editor.org/info/rfc8512>.
	skipping to change at line 1165 ¶		skipping to change at line 1180 ¶
	Recommendation REC-xml-20081126, November 2008,		Recommendation REC-xml-20081126, November 2008,
	<https://www.w3.org/TR/2008/REC-xml-20081126/>.		<https://www.w3.org/TR/2008/REC-xml-20081126/>.
	Appendix A. Examples		Appendix A. Examples
	A.1. Keepalive Configuration		A.1. Keepalive Configuration
	This particular example demonstrates how a particular connection can		This particular example demonstrates how a particular connection can
	be configured for keepalives.		be configured for keepalives.
	The following example uses the XML [W3C.REC-xml-20081126] encoding.
	Note that long lines in examples are wrapped as described in
	[RFC8792].
	NOTE: '\' line wrapping per RFC 8792		NOTE: '\' line wrapping per RFC 8792
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!--		<!--
	This example shows how TCP keepalive, MSS, and PMTU can be configure\		This example shows how TCP keepalive, MSS, and PMTU can be configure\
	d for a given connection. An idle connection is dropped after		d for a given connection. An idle connection is dropped after
	idle-time + (max-probes * probe-interval).		idle-time + (max-probes * probe-interval).
	-->		-->
	<tcp		<tcp
	xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp">		xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp">
	skipping to change at line 1204 ¶		skipping to change at line 1214 ¶
	</connections>		</connections>
	</tcp>		</tcp>
	A.2. TCP-AO Configuration		A.2. TCP-AO Configuration
	The following example demonstrates how to model a TCP-AO [RFC5925]		The following example demonstrates how to model a TCP-AO [RFC5925]
	configuration for the example in "TCP Authentication Option (TCP-AO)		configuration for the example in "TCP Authentication Option (TCP-AO)
	Test Vectors" [RFC9235]. The IP addresses and other parameters are		Test Vectors" [RFC9235]. The IP addresses and other parameters are
	taken from the test vectors.		taken from the test vectors.
	The following example uses the XML [W3C.REC-xml-20081126] encoding.
	NOTE: '\' line wrapping per RFC 8792		NOTE: '\' line wrapping per RFC 8792
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!--		<!--
	This example sets TCP-AO configuration parameters similarly to		This example sets TCP-AO configuration parameters similarly to
	the examples in RFC 9235.		the examples in RFC 9235.
	-->		-->
	<key-chains		<key-chains
	xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain">		xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain">
End of changes. 7 change blocks.
	14 lines changed or deleted		22 lines changed or added
This html diff was produced by rfcdiff 1.48.