Diff: rfc9640v4.txt - rfc9640.txt

	rfc9640v4.txt	rfc9640.txt

	skipping to change at line 167 ¶	skipping to change at line 167 ¶
	accessible nodes that are "config false".	accessible nodes that are "config false".

	1.4. Conventions	1.4. 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-crypto-types" Module	2. The "ietf-crypto-types" Module

	This section defines a YANG 1.1 [RFC7950] module called "ietf-crypto-	This section defines a YANG 1.1 [RFC7950] module called "ietf-crypto-
	types". A high-level overview of the module is provided in	types". A high-level overview of the module is provided in
	Section 2.1. Examples illustrating the module's use are provided in	Section 2.1. Examples illustrating the module's use are provided in
	Section 2.2. The YANG module itself is defined in Section 2.3.	Section 2.2. The YANG module itself is defined in Section 2.3.

	2.1. Data Model Overview	2.1. Data Model Overview

	This section provides an overview of the "ietf-crypto-types" module	This section provides an overview of the "ietf-crypto-types" module

	skipping to change at line 916 ¶	skipping to change at line 923 ¶
	\| +--:(asymmetric-key-ref)	\| +--:(asymmetric-key-ref)
	\| +--rw asymmetric-key-ref? leafref	\| +--rw asymmetric-key-ref? leafref
	+--rw encrypted-value-format identityref	+--rw encrypted-value-format identityref
	+--rw encrypted-value binary	+--rw encrypted-value binary

	2.2.1.3. Usage Example for the Example Module	2.2.1.3. Usage Example for the Example Module

	Finally, the following example illustrates various symmetric and	Finally, the following example illustrates various symmetric and
	asymmetric keys as they might appear in configuration.	asymmetric keys as they might appear in configuration.


	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 ================

	<symmetric-keys	<symmetric-keys
	xmlns="https://example.com/ns/example-crypto-types-usage"	xmlns="https://example.com/ns/example-crypto-types-usage"
	xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">	xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
	<symmetric-key>	<symmetric-key>
	<name>ex-hidden-symmetric-key</name>	<name>ex-hidden-symmetric-key</name>
	<hidden-symmetric-key/>	<hidden-symmetric-key/>
	</symmetric-key>	</symmetric-key>
	<symmetric-key>	<symmetric-key>

	skipping to change at line 1040 ¶	skipping to change at line 1042 ¶
	<encrypted-value>BASE64VALUE=</encrypted-value>	<encrypted-value>BASE64VALUE=</encrypted-value>
	</encrypted-password>	</encrypted-password>
	</password>	</password>
	</passwords>	</passwords>

	2.2.2. The "generate-csr" Action	2.2.2. The "generate-csr" Action

	The following example illustrates the "generate-csr" action,	The following example illustrates the "generate-csr" action,
	discussed in Section 2.1.4.10, with the NETCONF protocol.	discussed in Section 2.1.4.10, with the NETCONF protocol.


	The following example uses the XML [W3C.REC-xml-20081126] encoding.

	REQUEST	REQUEST

	<rpc message-id="101"	<rpc message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
	xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">	xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
	<action xmlns="urn:ietf:params:xml:ns:yang:1">	<action xmlns="urn:ietf:params:xml:ns:yang:1">
	<asymmetric-keys	<asymmetric-keys
	xmlns="https://example.com/ns/example-crypto-types-usage">	xmlns="https://example.com/ns/example-crypto-types-usage">
	<asymmetric-key>	<asymmetric-key>
	<name>ex-hidden-asymmetric-key</name>	<name>ex-hidden-asymmetric-key</name>
	<generate-csr>	<generate-csr>
	<csr-format>ct:p10-csr-format</csr-format>	<csr-format>ct:p10-csr-format</csr-format>
	<csr-info>BASE64VALUE=</csr-info>	<csr-info>BASE64VALUE=</csr-info>
	</generate-csr>	</generate-csr>
	</asymmetric-key>	</asymmetric-key>
	</asymmetric-keys>	</asymmetric-keys>
	</action>	</action>
	</rpc>	</rpc>


	The following example uses the XML [W3C.REC-xml-20081126] encoding.

	RESPONSE	RESPONSE

	=============== NOTE: '\' line wrapping per RFC 8792 ================	=============== NOTE: '\' line wrapping per RFC 8792 ================

	<rpc-reply message-id="101"	<rpc-reply message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<p10-csr xmlns="https://example.com/ns/example-crypto-types-usage"\	<p10-csr xmlns="https://example.com/ns/example-crypto-types-usage"\
	>BASE64VALUE=</p10-csr>	>BASE64VALUE=</p10-csr>
	</rpc-reply>	</rpc-reply>

	2.2.3. The "certificate-expiration" Notification	2.2.3. The "certificate-expiration" Notification

	The following example illustrates the "certificate-expiration"	The following example illustrates the "certificate-expiration"
	notification, discussed in Section 2.1.4.7, with the NETCONF	notification, discussed in Section 2.1.4.7, with the NETCONF
	protocol.	protocol.


	The following example uses the XML [W3C.REC-xml-20081126] encoding.

	=============== NOTE: '\' line wrapping per RFC 8792 ================	=============== NOTE: '\' line wrapping per RFC 8792 ================

	<notification	<notification
	xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">	xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<eventTime>2018-05-25T00:01:00Z</eventTime>	<eventTime>2018-05-25T00:01:00Z</eventTime>
	<asymmetric-keys xmlns="https://example.com/ns/example-crypto-type\	<asymmetric-keys xmlns="https://example.com/ns/example-crypto-type\
	s-usage">	s-usage">
	<asymmetric-key>	<asymmetric-key>
	<name>ex-hidden-asymmetric-key</name>	<name>ex-hidden-asymmetric-key</name>
	<certificates>	<certificates>

	skipping to change at line 2315 ¶	skipping to change at line 2311 ¶
	The cleartext key values are the "cleartext-symmetric-key" node	The cleartext key values are the "cleartext-symmetric-key" node
	defined in the "symmetric-key-grouping" grouping (Section 2.1.4.3)	defined in the "symmetric-key-grouping" grouping (Section 2.1.4.3)
	and the "cleartext-private-key" node defined in the "asymmetric-key-	and the "cleartext-private-key" node defined in the "asymmetric-key-
	pair-grouping" grouping (Section 2.1.4.6).	pair-grouping" grouping (Section 2.1.4.6).

	3.8. Considerations for the "ietf-crypto-types" YANG Module	3.8. Considerations for the "ietf-crypto-types" YANG Module

	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 in this document defines "grouping" statements that	The "ietf-crypto-types" YANG module defines "grouping" statements
	are designed to be accessed via YANG-based management protocols, such	that are designed to be accessed via YANG-based management protocols,
	as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols	such as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these
	have mandatory-to-implement secure transport layers (e.g., Secure	protocols have mandatory-to-implement secure transport layers (e.g.,
	Shell (SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and	Secure Shell (SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and
	mandatory-to-implement mutual authentication.	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.

	Since the module in this document only defines groupings, these	Since the module in this document only defines groupings, these
	considerations are primarily for the designers of other modules that	considerations are primarily for the designers of other modules that
	use these groupings.	use these groupings.

	skipping to change at line 2573 ¶	skipping to change at line 2569 ¶

	[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>.

	[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for	[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
	System Management", RFC 7317, DOI 10.17487/RFC7317, August	System Management", RFC 7317, DOI 10.17487/RFC7317, August
	2014, <https://www.rfc-editor.org/info/rfc7317>.	2014, <https://www.rfc-editor.org/info/rfc7317>.


		[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

End of changes. 7 change blocks.
	16 lines changed or deleted	17 lines changed or added
This html diff was produced by rfcdiff 1.48.