draft-ietf-netconf-server-model-02.txt		draft-ietf-netconf-server-model-03.txt
	NETCONF Working Group K. Watsen		NETCONF Working Group K. Watsen
	Internet-Draft Juniper Networks		Internet-Draft Juniper Networks
	Intended status: Standards Track J. Schoenwaelder		Intended status: Standards Track J. Schoenwaelder
	Expires: March 20, 2015 Jacobs University Bremen		Expires: March 26, 2015 Jacobs University Bremen
	September 16, 2014		September 22, 2014
	NETCONF Server Configuration Model		NETCONF Server Configuration Model
	draft-ietf-netconf-server-model-02		draft-ietf-netconf-server-model-03
	Abstract		Abstract
	This draft defines a NETCONF server configuration data model. This		This draft defines a NETCONF server configuration data model. This
	data model enables configuration of the NETCONF service itself,		data model enables configuration of the NETCONF service itself,
	including which transports it supports, what ports they listen on,		including which transports it supports, what ports they listen on,
	whether they support device-initiated connections, and associated		whether they support device-initiated connections, and associated
	parameters.		parameters.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 March 20, 2015.		This Internet-Draft will expire on March 26, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 20		skipping to change at page 2, line 20
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
	2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Support all NETCONF Transports . . . . . . . . . . . . . 3		2.1. Support all NETCONF Transports . . . . . . . . . . . . . 3
	2.2. Align Transport-Specific Configurations . . . . . . . . . 3		2.2. Align Transport-Specific Configurations . . . . . . . . . 3
	2.3. Support both Listening for Connections and Call Home . . 4		2.3. Support both Listening for Connections and Call Home . . 4
	2.4. For Call Home Connections . . . . . . . . . . . . . . . . 4		2.4. For Call Home Connections . . . . . . . . . . . . . . . . 4
	2.4.1. Support More than One Application . . . . . . . . . . 4		2.4.1. Support More than One Application . . . . . . . . . . 4
	2.4.2. Support Applications Having More than One Server . . 4		2.4.2. Support Applications Having More than One Server . . 4
	2.4.3. Support a Reconnection Strategy . . . . . . . . . . . 4		2.4.3. Support a Reconnection Strategy . . . . . . . . . . . 4
	2.4.4. Support both Persistent and Periodic Connections . . 5		2.4.4. Support both Persistent and Periodic Connections . . 4
	2.4.5. Reconnection Strategy for Periodic Connections . . . 5		2.4.5. Reconnection Strategy for Periodic Connections . . . 5
	2.4.6. Keep-Alives for Persistent Connections . . . . . . . 5		2.4.6. Keep-Alives for Persistent Connections . . . . . . . 5
	2.4.7. Customizations for Periodic Connections . . . . . . . 5		2.4.7. Customizations for Periodic Connections . . . . . . . 5
	3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8		3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Keep-Alives for SSH and TLS . . . . . . . . . . . . . . . . . 21		4. Keep-Alives for SSH and TLS . . . . . . . . . . . . . . . . . 21
	4.1. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 21		4.1. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	4.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		4.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 22		5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	skipping to change at page 2, line 43		skipping to change at page 2, line 43
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	9.1. Normative References . . . . . . . . . . . . . . . . . . 24		9.1. Normative References . . . . . . . . . . . . . . . . . . 24
	9.2. Informative References . . . . . . . . . . . . . . . . . 25		9.2. Informative References . . . . . . . . . . . . . . . . . 25
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 26		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 26
	A.1. SSH Transport Configuration . . . . . . . . . . . . . . . 26		A.1. SSH Transport Configuration . . . . . . . . . . . . . . . 26
	A.2. TLS Transport Configuration . . . . . . . . . . . . . . . 26		A.2. TLS Transport Configuration . . . . . . . . . . . . . . . 26
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 27		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 27
	B.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 28		B.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 28
	B.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 28		B.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 28
			B.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 28
	Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 28		Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 28
	1. Introduction		1. Introduction
	This draft defines a NETCONF [RFC6241] server configuration data		This draft defines a NETCONF [RFC6241] server configuration data
	model. This data model enables configuration of the NETCONF service		model. This data model enables configuration of the NETCONF service
	itself, including which transports are supported, what ports does the		itself, including which transports are supported, what ports does the
	server listen on, whether call-home is supported, and associated		server listen on, whether call-home is supported, and associated
	parameters.		parameters.
	skipping to change at page 3, line 37		skipping to change at page 3, line 39
	2. Objectives		2. Objectives
	The primary purpose of the YANG module defined herein is to enable		The primary purpose of the YANG module defined herein is to enable
	the configuration of the NETCONF service on the device. This scope		the configuration of the NETCONF service on the device. This scope
	includes the following objectives:		includes the following objectives:
	2.1. Support all NETCONF Transports		2.1. Support all NETCONF Transports
	The YANG module should support all current NETCONF transports, namely		The YANG module should support all current NETCONF transports, namely
	NETCONF over SSH [RFC6242] and NETCONF over TLS		NETCONF over SSH [RFC6242] and NETCONF over TLS [rfc5539bis], and be
	[I-D.ietf-netconf-rfc5539bis], and be extensible to support future		extensible to support future transports as necessary.
	transports as necessary.
	Since implementations may not support all transports, the module		Since implementations may not support all transports, the module
	should use YANG "feature" statements so that implementations can		should use YANG "feature" statements so that implementations can
	accurately advertise which transports are supported.		accurately advertise which transports are supported.
	2.2. Align Transport-Specific Configurations		2.2. Align Transport-Specific Configurations
	While each transport is unique in its protocol and may have some		While each transport is unique in its protocol and may have some
	distinct configurations, there remains a significant overlap between		distinct configurations, there remains a significant overlap between
	them. Thus the YANG module should use "grouping" statements so that		them. Thus the YANG module should use "grouping" statements so that
	the common aspects can be configured similarly.		the common aspects can be configured similarly.
	2.3. Support both Listening for Connections and Call Home		2.3. Support both Listening for Connections and Call Home
	NETCONF has always supported the server opening a port to listen for		NETCONF has always supported the server opening a port to listen for
	client connections. More recently the NETCONF working group defined		client connections. More recently the NETCONF working group defined
	support for call-home ([I-D.ietf-netconf-rfc5539bis] and		support for call-home ([draft-ietf-netconf-call-home]). The module
	[draft-ieft-netconf-reverse-ssh]). The module should configure both		should configure both listening for connections and call-home.
	listening for connections and call-home.
	Since implementations may not support both listening for connections		Since implementations may not support both listening for connections
	and call home, YANG "feature" statements should be used so that		and call home, YANG "feature" statements should be used so that
	implementation can accurately advertise the connection types it		implementation can accurately advertise the connection types it
	supports.		supports.
	2.4. For Call Home Connections		2.4. For Call Home Connections
	The following objectives only pertain to call home connections.		The following objectives only pertain to call home connections.
	skipping to change at page 6, line 11		skipping to change at page 6, line 9
	to send a notification message, there's a high probability that it		to send a notification message, there's a high probability that it
	will send another shortly thereafter. Likewise, the application may		will send another shortly thereafter. Likewise, the application may
	have a sequence of pending messages to send. Thus, it should be		have a sequence of pending messages to send. Thus, it should be
	possible for a device to hold a connection open until some amount of		possible for a device to hold a connection open until some amount of
	time of no data being transmitted as transpired.		time of no data being transmitted as transpired.
	3. Data Model		3. Data Model
	3.1. Overview		3.1. Overview
	To enable transports to configure listening on one or more ports in a		The following subtree illustrates how this YANG module enables
	common way, the following subtree is defined. This subtree defines		configuration for listening for remote connections, as described in
	SSH and TLS specific containers, each of which refines the default		[RFC6242] and [rfc5539bis]. Feature statements are used to limit
	listening port appropriately. Further, each of these transport		both if listening is supported at all as well as for which
	specific containers use a feature statement, enabling NETCONF servers		transports. If listening for connections is supported, then the
	to accurately advertise what they support.		model enables configuring a list of listening endpoints, each
			configured with a user-specified name (the key field), the transport
			to use (i.e. SSH, TLS), and the IP address and port to listen on.
			The port field is optional, defaulting to the transport-specific port
			when not configured.
	module: ietf-netconf-server		module: ietf-netconf-server
	+--rw netconf-server		+--rw netconf-server
	+--rw listen* [name]		+--rw listen* [name]
	+--rw name string		+--rw name string
	+--rw (transport)		+--rw (transport)
	+--:(ssh) {ssh-listen}?		+--:(ssh) {ssh-listen}?
	| +--rw ssh		| +--rw ssh
	| +--rw address inet:host		| +--rw address inet:host
	| +--rw port? inet:port-number		| +--rw port? inet:port-number
	+--:(tls) {tls-listen}?		+--:(tls) {tls-listen}?
	+--rw tls		+--rw tls
	+--rw address inet:host		+--rw address inet:host
	+--rw port? inet:port-number		+--rw port? inet:port-number
	To enable transports to configure initiating connections to remote		The following subtree illustrates how this YANG module enables
	applications in a common way, the following subtree is defined. This		configuration for call home, as described in
	subtree configures a list of appliacations, each with some transport-		[draft-ietf-netconf-call-home]. Feature statements are used to limit
	specific configuration augmented in. Each of the transport specific		both if call-home is supported at all as well as for which
	containers use a feature statement, enabling NETCONF servers to		transports, if it is. If call-home is supported, then the model
	accurately advertise what they support.		supports configuring a list of applications to connect to. Each
			application is configured with a user-specified name (the key field),
			the transport to be used (i.e. SSH, TLS), and a list of remote
			endpoints, each having a name, an IP address, and an optional port.
			Additionally, the configuration for each remote application indicates
			the connection-type (persistent vs. periodic) and associated
			parameters, as well as the reconnection strategy to use.
	module: ietf-netconf-server		module: ietf-netconf-server
	+--rw netconf-server		+--rw netconf-server
	+--rw call-home		+--rw call-home* [name]
	+--rw network-managers		+--rw name string
	+--rw network-manager* [name]		+--rw (transport)
	+--rw name string		| +--:(ssh) {ssh-call-home}?
	+--rw description? string		| | +--rw ssh
	+--rw endpoints		| | +--rw endpoints
	| +--rw endpoint* [address]		| | | +--rw endpoint* [name]
	| +--rw address inet:host		| | | +--rw name string
	| +--rw port? inet:port-number		| | | +--rw address inet:host
	+--rw transport		| | | +--rw port? inet:port-number
	| +--rw ssh {ssh-call-home}?		| | +--rw host-key* [name]
	| | +--rw host-keys		| | +--rw name string
	| | +--rw host-key* [name]		| +--:(tls) {tls-call-home}?
	| | +--rw name string		| +--rw tls
	| +--rw tls! {tls-call-home}?		| +--rw endpoints
	+--rw connection-type		| +--rw endpoint* [name]
	| +--rw (connection-type)?		| +--rw name string
	| +--:(persistent-connection)		| +--rw address inet:host
	| | +--rw persistent		| +--rw port? inet:port-number
	| | +--rw keep-alives		+--rw connection-type
	| | +--rw interval-secs? uint8		| +--rw (connection-type)?
	| | +--rw count-max? uint8		| +--:(persistent-connection)
	| +--:(periodic-connection)		| | +--rw persistent
	| +--rw periodic		| | +--rw keep-alives
	| +--rw timeout-mins? uint8		| | +--rw interval-secs? uint8
	| +--rw linger-secs? uint8		| | +--rw count-max? uint8
	+--rw reconnect-strategy		| +--:(periodic-connection)
	+--rw start-with? enumeration		| +--rw periodic
	+--rw interval-secs? uint8		| +--rw timeout-mins? uint8
	+--rw count-max? uint8		| +--rw linger-secs? uint8
			+--rw reconnect-strategy
			+--rw start-with? enumeration
			+--rw interval-secs? uint8
			+--rw count-max? uint8
	The following subtree illustrates how this YANG module enables		The following subtree illustrates how this YANG module enables
	authentication of TLS client certificates and mapping TLS clients to		authentication of TLS client certificates and mapping TLS clients to
	NETCONF user names. More specifically, the "trusted-ca-certs" and		NETCONF user names. More specifically, the "trusted-ca-certs" and
	"trusted-client-certs" containers are used to authenticate TLS client		"trusted-client-certs" containers are used to authenticate TLS client
	certificates, while "cert-maps" and "psk-maps" are used to map TLS		certificates, while "cert-maps" and "psk-maps" are used to map TLS
	clients to NETCONF user names.		clients to NETCONF user names.
	module: ietf-netconf-server		module: ietf-netconf-server
	+--rw netconf-server		+--rw netconf-server
	skipping to change at page 13, line 32		skipping to change at page 13, line 32
	refine endpoints/endpoint/port {		refine endpoints/endpoint/port {
	default 9999; // pending IANA assignment		default 9999; // pending IANA assignment
	}		}
	}		}
	list host-key {		list host-key {
	key name;		key name;
	min-elements 1;		min-elements 1;
	ordered-by user;		ordered-by user;
	description		description
	"User-ordered list of host-keys the SSH server		"User-ordered list of host-keys the SSH server
	should advertize.";		should advertise.";
	leaf name {		leaf name {
	type string;		type string;
	mandatory true;		mandatory true;
	description		description
	"The name of a host key the device should		"The name of a host key the device should
	advertise during the SSH key exchange.";		advertise during the SSH key exchange.";
	}		}
	}		}
	}		}
	}		}
	skipping to change at page 24, line 9		skipping to change at page 24, line 9
	Lhotka, Radek Krejci, Tom Petch, and Phil Shafer.		Lhotka, Radek Krejci, Tom Petch, and Phil Shafer.
	Juergen Schoenwaelder and was partly funded by Flamingo, a Network of		Juergen Schoenwaelder and was partly funded by Flamingo, a Network of
	Excellence project (ICT-318488) supported by the European Commission		Excellence project (ICT-318488) supported by the European Commission
	under its Seventh Framework Programme.		under its Seventh Framework Programme.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-netconf-rfc5539bis]
	Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
	NETCONF Protocol over Transport Layer Security (TLS)",
	draft-ietf-netconf-rfc5539bis-04 (work in progress),
	October 2013.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)		[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
	Protocol Architecture", RFC 4251, January 2006.		Protocol Architecture", RFC 4251, January 2006.
	[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)		[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
	Transport Layer Protocol", RFC 4253, January 2006.		Transport Layer Protocol", RFC 4253, January 2006.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
	the Network Configuration Protocol (NETCONF)", RFC 6020,		Network Configuration Protocol (NETCONF)", RFC 6020,
	October 2010.		October 2010.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
	and A. Bierman, Ed., "NETCONF Configuration Protocol", RFC		Bierman, "Network Configuration Protocol (NETCONF)", RFC
	6241, June 2011.		6241, June 2011.
	[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure		[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
	Shell (SSH)", RFC 6242, June 2011.		Shell (SSH)", RFC 6242, June 2011.
	[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport		[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport
	Layer Security (TLS) and Datagram Transport Layer Security		Layer Security (TLS) and Datagram Transport Layer Security
	(DTLS) Heartbeat Extension", RFC 6520, February 2012.		(DTLS) Heartbeat Extension", RFC 6520, February 2012.
	[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration		[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
	Protocol (NETCONF) Access Control Model", RFC 6536, March		Protocol (NETCONF) Access Control Model", RFC 6536, March
	2012.		2012.
	[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,		[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
	July 2013.		July 2013.
	[draft-ieft-netconf-reverse-ssh]		[draft-ietf-netconf-call-home]
	Watsen, K., "NETCONF over SSH Call Home", draft-ieft-		Watsen, K., "NETCONF Call Home", draft-ieft-netconf-call-
	netconf-reverse-ssh-00 (work in progress), May 2014.		home-00 (work in progress), 2014.
	[draft-ietf-netmod-snmp-cfg]		[draft-ietf-netmod-snmp-cfg]
	Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for		Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
	SNMP Configuration", draft-ietf-netmod-snmp-cfg-03 (work		SNMP Configuration", draft-ietf-netmod-snmp-cfg-03 (work
	in progress), November 2013.		in progress), November 2013.
	[draft-ietf-netmod-system-mgmt]		[rfc5539bis]
	Bierman, A., "A YANG Data Model for System Management",		Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
	draft-ieft-netmod-system-mgmt-16 (work in progress), May		NETCONF Protocol over Transport Layer Security (TLS)",
	2014.		draft-ietf-netconf-rfc5539bis-04 (work in progress),
			October 2013.
	9.2. Informative References		9.2. Informative References
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	Appendix A. Examples		Appendix A. Examples
	A.1. SSH Transport Configuration		A.1. SSH Transport Configuration
	skipping to change at page 28, line 23		skipping to change at page 28, line 23
	o removed the "one-to-many" construct		o removed the "one-to-many" construct
	o removed "address" as a key field		o removed "address" as a key field
	o removed "network-manager" terminology		o removed "network-manager" terminology
	o moved open issues to github issues		o moved open issues to github issues
	o brought TLS client auth back into model		o brought TLS client auth back into model
			B.3. 02 to 03
			o fixed tree diagrams and surrounding text
	Appendix C. Open Issues		Appendix C. Open Issues
	Please see: https://github.com/netconf-wg/server-model/issues.		Please see: https://github.com/netconf-wg/server-model/issues.
	Authors' Addresses		Authors' Addresses
	Kent Watsen		Kent Watsen
	Juniper Networks		Juniper Networks
	EMail: kwatsen@juniper.net		EMail: kwatsen@juniper.net
End of changes. 17 change blocks.
	71 lines changed or deleted		83 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/