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/