idnits 2.17.1
draft-ietf-netconf-netconf-client-server-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 202 has weird spacing: '...rw name str...'
== Line 232 has weird spacing: '...rw name str...'
== Line 679 has weird spacing: '...rw name str...'
== Line 717 has weird spacing: '...erprint x50...'
== Line 730 has weird spacing: '...address ine...'
== (2 more instances...)
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document date (July 8, 2016) is 2847 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Obsolete informational reference (is this intentional?): RFC 5246
(Obsoleted by RFC 8446)
Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 NETCONF Working Group K. Watsen
3 Internet-Draft Juniper Networks
4 Intended status: Standards Track G. Wu
5 Expires: January 9, 2017 Cisco Networks
6 J. Schoenwaelder
7 Jacobs University Bremen
8 July 8, 2016
10 NETCONF Client and Server Models
11 draft-ietf-netconf-netconf-client-server-00
13 Abstract
15 This document defines two YANG modules, one module to configure a
16 NETCONF client and the other module to configure a NETCONF server.
17 Both modules support both the SSH and TLS transport protocols, and
18 support both standard NETCONF and NETCONF Call Home connections.
20 Editorial Note (To be removed by RFC Editor)
22 This draft contains many placeholder values that need to be replaced
23 with finalized values at the time of publication. This note
24 summarizes all of the substitutions that are needed. No other RFC
25 Editor instructions are specified elsewhere in this document.
27 This document contains references to other drafts in progress, both
28 in the Normative References section, as well as in body text
29 throughout. Please update the following references to reflect their
30 final RFC assignments:
32 o draft-ietf-netconf-system-keychain
34 o draft-ietf-netconf-ssh-client-server
36 o draft-ietf-netconf-tls-client-server
38 Artwork in this document contains shorthand references to drafts in
39 progress. Please apply the following replacements:
41 o "XXXX" --> the assigned RFC value for this draft
43 o "YYYY" --> the assigned RFC value for draft-ietf-netconf-ssh-
44 client-server
46 o "ZZZZ" --> the assigned RFC value for draft-ietf-netconf-tls-
47 client-server
49 o "AAAA" --> the assigned RFC value for draft-ietf-netconf-call-home
51 Artwork in this document contains placeholder values for the date of
52 publication of this draft. Please apply the following replacement:
54 o "2016-07-08" --> the publication date of this draft
56 The following two Appendix sections are to be removed prior to
57 publication:
59 o Appendix A. Change Log
61 o Appendix B. Open Issues
63 Status of This Memo
65 This Internet-Draft is submitted in full conformance with the
66 provisions of BCP 78 and BCP 79.
68 Internet-Drafts are working documents of the Internet Engineering
69 Task Force (IETF). Note that other groups may also distribute
70 working documents as Internet-Drafts. The list of current Internet-
71 Drafts is at http://datatracker.ietf.org/drafts/current/.
73 Internet-Drafts are draft documents valid for a maximum of six months
74 and may be updated, replaced, or obsoleted by other documents at any
75 time. It is inappropriate to use Internet-Drafts as reference
76 material or to cite them other than as "work in progress."
78 This Internet-Draft will expire on January 9, 2017.
80 Copyright Notice
82 Copyright (c) 2016 IETF Trust and the persons identified as the
83 document authors. All rights reserved.
85 This document is subject to BCP 78 and the IETF Trust's Legal
86 Provisions Relating to IETF Documents
87 (http://trustee.ietf.org/license-info) in effect on the date of
88 publication of this document. Please review these documents
89 carefully, as they describe your rights and restrictions with respect
90 to this document. Code Components extracted from this document must
91 include Simplified BSD License text as described in Section 4.e of
92 the Trust Legal Provisions and are provided without warranty as
93 described in the Simplified BSD License.
95 Table of Contents
97 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
98 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
99 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
100 2. The NETCONF Client Model . . . . . . . . . . . . . . . . . . 4
101 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 5
102 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 6
103 2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 8
104 3. The NETCONF Server Model . . . . . . . . . . . . . . . . . . 14
105 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 15
106 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 17
107 3.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 21
108 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 31
109 4.1. Support all NETCONF transports . . . . . . . . . . . . . 31
110 4.2. Enable each transport to select which keys to use . . . . 32
111 4.3. Support authenticating NETCONF clients certificates . . . 32
112 4.4. Support mapping authenticated NETCONF client certificates
113 to usernames . . . . . . . . . . . . . . . . . . . . . . 32
114 4.5. Support both listening for connections and call home . . 32
115 4.6. For Call Home connections . . . . . . . . . . . . . . . . 32
116 4.6.1. Support more than one NETCONF client . . . . . . . . 32
117 4.6.2. Support NETCONF clients having more than one endpoint 33
118 4.6.3. Support a reconnection strategy . . . . . . . . . . . 33
119 4.6.4. Support both persistent and periodic connections . . 33
120 4.6.5. Reconnection strategy for periodic connections . . . 33
121 4.6.6. Keep-alives for persistent connections . . . . . . . 33
122 4.6.7. Customizations for periodic connections . . . . . . . 34
123 5. Security Considerations . . . . . . . . . . . . . . . . . . . 34
124 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
125 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 34
126 6.2. The YANG Module Names Registry . . . . . . . . . . . . . 34
127 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
128 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
129 8.1. Normative References . . . . . . . . . . . . . . . . . . 35
130 8.2. Informative References . . . . . . . . . . . . . . . . . 36
131 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 38
132 A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 38
133 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 38
134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
136 1. Introduction
138 This document defines two YANG [RFC6020] modules, one module to
139 configure a NETCONF client and the other module to configure a
140 NETCONF server. Both modules support both the SSH and TLS transport
141 protocols, and support both standard NETCONF and NETCONF Call Home
142 connections.
144 NETCONF is defined by [RFC6241]. SSH is defined by [RFC4252],
145 [RFC4253], and [RFC4254]. TLS is defined by [RFC5246]. NETCONF Call
146 Home is defined by [draft-ietf-netconf-call-home]).
148 1.1. Terminology
150 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
152 document are to be interpreted as described in RFC 2119 [RFC2119].
154 1.2. Tree Diagrams
156 A simplified graphical representation of the data models is used in
157 this document. The meaning of the symbols in these diagrams is as
158 follows:
160 o Brackets "[" and "]" enclose list keys.
162 o Braces "{" and "}" enclose feature names, and indicate that the
163 named feature must be present for the subtree to be present.
165 o Abbreviations before data node names: "rw" means configuration
166 (read-write) and "ro" state data (read-only).
168 o Symbols after data node names: "?" means an optional node, "!"
169 means a presence container, and "*" denotes a list and leaf-list.
171 o Parentheses enclose choice and case nodes, and case nodes are also
172 marked with a colon (":").
174 o Ellipsis ("...") stands for contents of subtrees that are not
175 shown.
177 2. The NETCONF Client Model
179 The NETCONF client model presented in this section supports both
180 clients initiating connections to servers, as well as clients
181 listening for connections from servers calling home.
183 This model supports both the SSH and TLS transport protocols, using
184 the SSH client and TLS client groupings defined in
185 [draft-ietf-netconf-ssh-client-server] and
186 [draft-ietf-netconf-tls-client-server] respectively.
188 All private keys and trusted certificates are held in the keychain
189 model defined in [draft-ietf-netconf-system-keychain].
191 YANG feature statements are used to enable implementations to
192 advertise which parts of the model the NETCONF client supports.
194 2.1. Tree Diagram
196 Note: all lines are folded at column 71 with no '\' character.
198 module: ietf-netconf-client
199 +--rw netconf-client
200 +--rw initiate {initiate}?
201 | +--rw netconf-server* [name]
202 | +--rw name string
203 | +--rw (transport)
204 | +--:(ssh) {ssh-initiate}?
205 | +--rw ssh
206 | +--rw address inet:host
207 | +--rw port? inet:port-number
208 | +--rw server-auth
209 | | +--rw trusted-ssh-host-keys? -> /kc:keychain/
210 trusted-ssh-host-keys/name
211 | | +--rw trusted-ca-certs? -> /kc:keychain/
212 trusted-certificates/name {ssh-x509-certs}?
213 | | +--rw trusted-server-certs? -> /kc:keychain/
214 trusted-certificates/name
215 | +--rw client-auth
216 | +--rw matches* [name]
217 | +--rw name string
218 | +--rw match* [name]
219 | | +--rw name string
220 | | +--rw trusted-ssh-host-keys? -> /kc:key
221 chain/trusted-ssh-host-keys/name
222 | | +--rw trusted-ca-certs? -> /kc:key
223 chain/trusted-certificates/name
224 | | +--rw trusted-server-certs? -> /kc:key
225 chain/trusted-certificates/name
226 | +--rw user-auth-credentials? -> /kc:keycha
227 in/user-auth-credentials/user-auth-credential/username
228 +--rw listen {listen}?
229 +--rw max-sessions? uint16
230 +--rw idle-timeout? uint16
231 +--rw endpoint* [name]
232 +--rw name string
233 +--rw (transport)
234 +--:(ssh) {ssh-listen}?
235 +--rw ssh
236 +--rw address? inet:ip-address
237 +--rw port? inet:port-number
238 +--rw server-auth
239 | +--rw trusted-ssh-host-keys? -> /kc:keychain/
240 trusted-ssh-host-keys/name
241 | +--rw trusted-ca-certs? -> /kc:keychain/
242 trusted-certificates/name {ssh-x509-certs}?
243 | +--rw trusted-server-certs? -> /kc:keychain/
244 trusted-certificates/name
245 +--rw client-auth
246 +--rw matches* [name]
247 +--rw name string
248 +--rw match* [name]
249 | +--rw name string
250 | +--rw trusted-ssh-host-keys? -> /kc:key
251 chain/trusted-ssh-host-keys/name
252 | +--rw trusted-ca-certs? -> /kc:key
253 chain/trusted-certificates/name
254 | +--rw trusted-server-certs? -> /kc:key
255 chain/trusted-certificates/name
256 +--rw user-auth-credentials? -> /kc:keycha
257 in/user-auth-credentials/user-auth-credential/username
259 2.2. Example Usage
261 The following example illustrates configuring a NETCONF client to
262 initiate connections, using both the SSH and TLS transport protocols,
263 as well as listening for call-home connections, again using both the
264 SSH and TLS transport protocols.
266 This example is consistent with the examples presented in Section 2.2
267 of [draft-ietf-netconf-system-keychain].
269
272
273
274
275 corp-fw1
276
277 corp-fw1.example.com
278
279
280 deployment-specific-ca-certs
281
282
283
284
285
286
287 deployment-specific-ca-certs
288
289
290 Bob
291
292
293
294
295
297
298
299
300 Intranet-facing listener
301
302 11.22.33.44
303
304
305 deployment-specific-ca-certs
306
307
308 explicitly-trusted-server-certs
309
310
311 explicitly-trusted-ssh-host-keys
312
313
314
315
316
317
318 deployment-specific-ca-certs
319
320
321 admin
322
323
324
325
326 explicitly-trusted-server-certs
327
328
329 admin
330
331
332
333
334 explicitly-trusted-ssh-host-keys
336
337
338 admin
339
340
341
342
343
344
346 2.3. YANG Model
348 This YANG module imports YANG types from [RFC6991] and [RFC7407].
350 file "ietf-netconf-client@2016-07-08.yang"
352 module ietf-netconf-client {
353 yang-version 1.1;
355 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-client";
356 prefix "ncc";
358 import ietf-inet-types {
359 prefix inet;
360 reference
361 "RFC 6991: Common YANG Data Types";
362 }
364 import ietf-x509-cert-to-name {
365 prefix x509c2n;
366 reference
367 "RFC 7407: A YANG Data Model for SNMP Configuration";
368 }
370 import ietf-ssh-client {
371 prefix ss;
372 revision-date 2016-07-08; // stable grouping definitions
373 reference
374 "RFC YYYY: SSH Client and Server Models";
375 }
377 import ietf-tls-client {
378 prefix ts;
379 revision-date 2016-07-08; // stable grouping definitions
380 reference
381 "RFC ZZZZ: TLS Client and Server Models";
382 }
383 organization
384 "IETF NETCONF (Network Configuration) Working Group";
386 contact
387 "WG Web:
388 WG List:
390 WG Chair: Mehmet Ersue
391
393 WG Chair: Mahesh Jethanandani
394
396 Author: Kent Watsen
397
399 Author: Gary Wu
400 ";
402 description
403 "This module contains a collection of YANG definitions for
404 configuring NETCONF servers.
406 Copyright (c) 2014 IETF Trust and the persons identified as
407 authors of the code. All rights reserved.
409 Redistribution and use in source and binary forms, with or
410 without modification, is permitted pursuant to, and subject
411 to the license terms contained in, the Simplified BSD
412 License set forth in Section 4.c of the IETF Trust's
413 Legal Provisions Relating to IETF Documents
414 (http://trustee.ietf.org/license-info).
416 This version of this YANG module is part of RFC XXXX; see
417 the RFC itself for full legal notices.";
419 revision "2016-07-08" {
420 description
421 "Initial version";
422 reference
423 "RFC XXXX: NETCONF Client and Server Models";
424 }
426 // Features
428 feature initiate {
429 description
430 "The 'initiate' feature indicates that the NETCONF client
431 supports initiating NETCONF connections to NETCONF servers
432 using at least one transport (e.g., SSH, TLS, etc.).";
433 }
435 feature ssh-initiate {
436 description
437 "The 'ssh-initiate' feature indicates that the NETCONF client
438 supports initiating SSH connections to NETCONF servers.";
439 reference
440 "RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)";
441 }
443 feature tls-initiate {
444 description
445 "The 'tls-initiate' feature indicates that the NETCONF client
446 supports initiating TLS connections to NETCONF servers.";
447 reference
448 "RFC 7589: Using the NETCONF Protocol over Transport
449 Layer Security (TLS) with Mutual X.509
450 Authentication";
451 }
453 feature listen {
454 description
455 "The 'listen' feature indicates that the NETCONF client
456 supports opening a port to accept NETCONF server call home
457 connections using at least one transport (e.g., SSH, TLS, etc.).";
458 }
460 feature ssh-listen {
461 description
462 "The 'ssh-listen' feature indicates that the NETCONF client
463 supports opening a port to listen for incoming NETCONF
464 server call-home SSH connections.";
465 reference
466 "RFC AAAA: NETCONF Call Home and RESTCONF Call Home";
467 }
469 feature tls-listen {
470 description
471 "The 'tls-listen' feature indicates that the NETCONF client
472 supports opening a port to listen for incoming NETCONF
473 server call-home TLS connections.";
474 reference
475 "RFC AAAA: NETCONF Call Home and RESTCONF Call Home";
476 }
477 container netconf-client {
478 description
479 "Top-level container for NETCONF client configuration.";
481 container initiate {
482 if-feature initiate;
483 description
484 "Configures client intiating underlying TCP connections.";
485 list netconf-server {
486 key name;
487 description
488 "List of NETCONF servers the NETCONF client is to initiate
489 connections to.";
490 leaf name {
491 type string;
492 description
493 "An arbitrary name for the NETCONF server.";
494 }
495 choice transport {
496 mandatory true;
497 description
498 "Selects between available transports.";
499 case ssh {
500 if-feature ssh-initiate;
501 container ssh {
502 description
503 "Specifies SSH-specific transport configuration.";
504 leaf address {
505 type inet:host;
506 mandatory true;
507 description
508 "The IP address or hostname of the endpoint. If a
509 hostname is configured and the DNS resolution results
510 in more than one IP address, the NETCONF client
511 will process the IP addresses as if they had been
512 explicitly configured in place of the hostname.";
513 }
514 leaf port {
515 type inet:port-number;
516 default 830;
517 description
518 "The IP port for this endpoint. The NETCONF client will
519 use the IANA-assigned well-known port if no value is
520 specified.";
521 }
522 uses ss:initiating-ssh-client-grouping;
523 }
524 }
526 /*
527 case tls {
528 if-feature tls-initiate;
529 container tls {
530 description
531 "Specifies TLS-specific transport configuration.";
532 uses endpoints-container {
533 refine endpoints/endpoint/port {
534 default 6513;
535 }
536 }
537 uses ts:listening-tls-client-grouping {
538 augment "client-auth" {
539 description
540 "Augments in the cert-to-name structure.";
541 uses cert-maps-grouping;
542 }
543 }
544 }
545 }
546 */
547 }
548 }
549 } // end initiate
551 container listen {
552 if-feature listen;
553 description
554 "Configures client accepting call-home TCP connections.";
555 leaf max-sessions {
556 type uint16;
557 default 0;
558 description
559 "Specifies the maximum number of concurrent sessions
560 that can be active at one time. The value 0 indicates
561 that no artificial session limit should be used.";
562 }
563 leaf idle-timeout {
564 type uint16;
565 units "seconds";
566 default 3600; // one hour
567 description
568 "Specifies the maximum number of seconds that a NETCONF
569 session may remain idle. A NETCONF session will be dropped
570 if it is idle for an interval longer than this number of
571 seconds. If set to zero, then the server will never drop
572 a session because it is idle. Sessions that have a
573 notification subscription active are never dropped.";
575 }
576 list endpoint {
577 key name;
578 description
579 "List of endpoints to listen for NETCONF connections on.";
580 leaf name {
581 type string;
582 description
583 "An arbitrary name for the NETCONF listen endpoint.";
584 }
585 choice transport {
586 mandatory true;
587 description
588 "Selects between available transports.";
589 case ssh {
590 if-feature ssh-listen;
591 container ssh {
592 description
593 "SSH-specific listening configuration for inbound
594 connections.";
595 uses ss:listening-ssh-client-grouping {
596 refine port {
597 default 4334;
598 }
599 }
600 }
601 }
602 /*
603 case tls {
604 if-feature tls-listen;
605 container tls {
606 description
607 "TLS-specific listening configuration for inbound
608 connections.";
609 uses ts:listening-tls-client-grouping {
610 refine port {
611 default 4335;
612 }
613 augment "client-auth" {
614 description
615 "Augments in the cert-to-name structure.";
616 uses cert-maps-grouping;
617 }
618 }
619 }
620 }
621 */
622 }
624 }
625 } // end listen
626 }
628 grouping cert-maps-grouping {
629 description
630 "A grouping that defines a container around the
631 cert-to-name structure defined in RFC 7407.";
632 container cert-maps {
633 uses x509c2n:cert-to-name;
634 description
635 "The cert-maps container is used by a TLS-based NETCONF
636 server to map the NETCONF client's presented X.509
637 certificate to a NETCONF username. If no matching and
638 valid cert-to-name list entry can be found, then the
639 NETCONF server MUST close the connection, and MUST NOT
640 accept NETCONF messages over it.";
641 reference
642 "RFC WWWW: NETCONF over TLS, Section 7";
643 }
644 }
646 }
648
650 3. The NETCONF Server Model
652 The NETCONF server model presented in this section supports servers
653 both listening for connections as well as initiating call-home
654 connections.
656 This model also supports both the SSH and TLS transport protocols,
657 using the SSH server and TLS server groupings defined in
658 [draft-ietf-netconf-ssh-client-server] and
659 [draft-ietf-netconf-tls-client-server] respectively.
661 All private keys and trusted certificates are held in the keychain
662 model defined in [draft-ietf-netconf-system-keychain].
664 YANG feature statements are used to enable implementations to
665 advertise which parts of the model the NETCONF server supports.
667 3.1. Tree Diagram
669 Note: all lines are folded at column 71 with no '\' character.
671 module: ietf-netconf-server
672 +--rw netconf-server
673 +--rw session-options
674 | +--rw hello-timeout? uint16
675 +--rw listen {listen}?
676 | +--rw max-sessions? uint16
677 | +--rw idle-timeout? uint16
678 | +--rw endpoint* [name]
679 | +--rw name string
680 | +--rw (transport)
681 | +--:(ssh) {ssh-listen}?
682 | | +--rw ssh
683 | | +--rw address? inet:ip-address
684 | | +--rw port? inet:port-number
685 | | +--rw host-keys
686 | | | +--rw host-key* [name]
687 | | | +--rw name string
688 | | | +--rw (type)?
689 | | | +--:(public-key)
690 | | | | +--rw public-key? -> /kc:keychain/p
691 rivate-keys/private-key/name
692 | | | +--:(certificate)
693 | | | +--rw certificate? -> /kc:keychain/p
694 rivate-keys/private-key/certificate-chains/certificate-chain/name {ssh-
695 x509-certs}?
696 | | +--rw client-cert-auth {ssh-x509-certs}?
697 | | +--rw trusted-ca-certs? -> /kc:keychain/t
698 rusted-certificates/name
699 | | +--rw trusted-client-certs? -> /kc:keychain/t
700 rusted-certificates/name
701 | +--:(tls) {tls-listen}?
702 | +--rw tls
703 | +--rw address? inet:ip-address
704 | +--rw port? inet:port-number
705 | +--rw certificates
706 | | +--rw certificate* [name]
707 | | +--rw name -> /kc:keychain/private-keys/p
708 rivate-key/certificate-chains/certificate-chain/name
709 | +--rw client-auth
710 | +--rw trusted-ca-certs? -> /kc:keychain/t
711 rusted-certificates/name
712 | +--rw trusted-client-certs? -> /kc:keychain/t
713 rusted-certificates/name
714 | +--rw cert-maps
715 | +--rw cert-to-name* [id]
716 | +--rw id uint32
717 | +--rw fingerprint x509c2n:tls-fingerpr
718 int
719 | +--rw map-type identityref
720 | +--rw name string
721 +--rw call-home {call-home}?
722 +--rw netconf-client* [name]
723 +--rw name string
724 +--rw (transport)
725 | +--:(ssh) {ssh-call-home}?
726 | | +--rw ssh
727 | | +--rw endpoints
728 | | | +--rw endpoint* [name]
729 | | | +--rw name string
730 | | | +--rw address inet:host
731 | | | +--rw port? inet:port-number
732 | | +--rw host-keys
733 | | | +--rw host-key* [name]
734 | | | +--rw name string
735 | | | +--rw (type)?
736 | | | +--:(public-key)
737 | | | | +--rw public-key? -> /kc:keychain/p
738 rivate-keys/private-key/name
739 | | | +--:(certificate)
740 | | | +--rw certificate? -> /kc:keychain/p
741 rivate-keys/private-key/certificate-chains/certificate-chain/name {ssh-
742 x509-certs}?
743 | | +--rw client-cert-auth {ssh-x509-certs}?
744 | | +--rw trusted-ca-certs? -> /kc:keychain/t
745 rusted-certificates/name
746 | | +--rw trusted-client-certs? -> /kc:keychain/t
747 rusted-certificates/name
748 | +--:(tls) {tls-call-home}?
749 | +--rw tls
750 | +--rw endpoints
751 | | +--rw endpoint* [name]
752 | | +--rw name string
753 | | +--rw address inet:host
754 | | +--rw port? inet:port-number
755 | +--rw certificates
756 | | +--rw certificate* [name]
757 | | +--rw name -> /kc:keychain/private-keys/p
758 rivate-key/certificate-chains/certificate-chain/name
759 | +--rw client-auth
760 | +--rw trusted-ca-certs? -> /kc:keychain/t
761 rusted-certificates/name
762 | +--rw trusted-client-certs? -> /kc:keychain/t
764 rusted-certificates/name
765 | +--rw cert-maps
766 | +--rw cert-to-name* [id]
767 | +--rw id uint32
768 | +--rw fingerprint x509c2n:tls-fingerpr
769 int
770 | +--rw map-type identityref
771 | +--rw name string
772 +--rw connection-type
773 | +--rw (connection-type)?
774 | +--:(persistent-connection)
775 | | +--rw persistent!
776 | | +--rw idle-timeout? uint32
777 | | +--rw keep-alives
778 | | +--rw max-wait? uint16
779 | | +--rw max-attempts? uint8
780 | +--:(periodic-connection)
781 | +--rw periodic!
782 | +--rw idle-timeout? uint16
783 | +--rw reconnect_timeout? uint16
784 +--rw reconnect-strategy
785 +--rw start-with? enumeration
786 +--rw max-attempts? uint8
788 3.2. Example Usage
790 The following example illustrates configuring a NETCONF server to
791 listen for NETCONF client connections using both the SSH and TLS
792 transport protocols, as well as configuring call-home to two NETCONF
793 clients, one using SSH and the other using TLS.
795 This example is consistent with the examples presented in Section 2.2
796 of [draft-ietf-netconf-system-keychain].
798
800
802
803
804 netconf/ssh
805
806 11.22.33.44
807
808
809 my-rsa-key
810
811
812 TPM key
813
814
815
816
817 deployment-specific-ca-certs
818
819
820 explicitly-trusted-client-certs
821
822
823
824
826
827
828 netconf/tls
829
830 11.22.33.44
831
832 ex-key-sect571r1-cert
833
834
835
836 deployment-specific-ca-certs
837
838
839 explicitly-trusted-client-certs
840
841
842
843 1
844 11:0A:05:11:00
845 x509c2n:san-any
846
847
848 2
849 B3:4F:A1:8C:54
850 x509c2n:specified
851 scooby-doo
852
853
854
855
856
858
859
860
861
862 config-mgr
863
864
865
866 east-data-center
867 11.22.33.44
868
869
870 west-data-center
871 55.66.77.88
872
873
874
875
876 TPM key
877
878
879
880
881 deployment-specific-ca-certs
882
883
884 explicitly-trusted-client-certs
885
886
887
888
889
890 300
891 60
892
893
894
895 last-connected
896 3
897
898
900
901
902 event-correlator
903
904
905
906 east-data-center
907 22.33.44.55
909
910
911 west-data-center
912 33.44.55.66
913
914
915
916 ex-key-sect571r1-cert
917
918
919
920 deployment-specific-ca-certs
921
922
923 explicitly-trusted-client-certs
924
925
926
927 1
928 11:0A:05:11:00
929 x509c2n:san-any
930
931
932 2
933 B3:4F:A1:8C:54
934 x509c2n:specified
935 scooby-doo
936
937
938
939
940
941
942 300
943
944 30
945 3
946
947
948
949
950 first-listed
951 3
952
953
955
956
958 3.3. YANG Model
960 This YANG module imports YANG types from [RFC6991] and [RFC7407].
962 file "ietf-netconf-server@2016-07-08.yang"
964 module ietf-netconf-server {
965 yang-version 1.1;
967 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-server";
968 prefix "ncs";
970 import ietf-inet-types {
971 prefix inet;
972 reference
973 "RFC 6991: Common YANG Data Types";
974 }
976 import ietf-x509-cert-to-name {
977 prefix x509c2n;
978 reference
979 "RFC 7407: A YANG Data Model for SNMP Configuration";
980 }
982 import ietf-ssh-server {
983 prefix ss;
984 revision-date 2016-07-08; // stable grouping definitions
985 reference
986 "RFC YYYY: SSH Client and Server Models";
987 }
989 import ietf-tls-server {
990 prefix ts;
991 revision-date 2016-07-08; // stable grouping definitions
992 reference
993 "RFC ZZZZ: TLS Client and Server Models";
994 }
996 organization
997 "IETF NETCONF (Network Configuration) Working Group";
999 contact
1000 "WG Web:
1001 WG List:
1003 WG Chair: Mehmet Ersue
1004
1006 WG Chair: Mahesh Jethanandani
1007
1009 Editor: Kent Watsen
1010 ";
1012 description
1013 "This module contains a collection of YANG definitions for
1014 configuring NETCONF servers.
1016 Copyright (c) 2014 IETF Trust and the persons identified as
1017 authors of the code. All rights reserved.
1019 Redistribution and use in source and binary forms, with or
1020 without modification, is permitted pursuant to, and subject
1021 to the license terms contained in, the Simplified BSD
1022 License set forth in Section 4.c of the IETF Trust's
1023 Legal Provisions Relating to IETF Documents
1024 (http://trustee.ietf.org/license-info).
1026 This version of this YANG module is part of RFC XXXX; see
1027 the RFC itself for full legal notices.";
1029 revision "2016-07-08" {
1030 description
1031 "Initial version";
1032 reference
1033 "RFC XXXX: NETCONF Client and Server Models";
1034 }
1036 // Features
1038 feature listen {
1039 description
1040 "The 'listen' feature indicates that the NETCONF server
1041 supports opening a port to accept NETCONF client connections
1042 using at least one transport (e.g., SSH, TLS, etc.).";
1043 }
1045 feature ssh-listen {
1046 description
1047 "The 'ssh-listen' feature indicates that the NETCONF server
1048 supports opening a port to accept NETCONF over SSH
1049 client connections.";
1050 reference
1051 "RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)";
1053 }
1055 feature tls-listen {
1056 description
1057 "The 'tls-listen' feature indicates that the NETCONF server
1058 supports opening a port to accept NETCONF over TLS
1059 client connections.";
1060 reference
1061 "RFC 7589: Using the NETCONF Protocol over Transport
1062 Layer Security (TLS) with Mutual X.509
1063 Authentication";
1064 }
1066 feature call-home {
1067 description
1068 "The 'call-home' feature indicates that the NETCONF server
1069 supports initiating NETCONF call home connections to NETCONF
1070 clients using at least one transport (e.g., SSH, TLS, etc.).";
1071 reference
1072 "RFC YYYY: NETCONF Call Home and RESTCONF Call Home";
1073 }
1075 feature ssh-call-home {
1076 description
1077 "The 'ssh-call-home' feature indicates that the NETCONF
1078 server supports initiating a NETCONF over SSH call
1079 home connection to NETCONF clients.";
1080 reference
1081 "RFC YYYY: NETCONF Call Home and RESTCONF Call Home";
1082 }
1084 feature tls-call-home {
1085 description
1086 "The 'tls-call-home' feature indicates that the NETCONF
1087 server supports initiating a NETCONF over TLS call
1088 home connection to NETCONF clients.";
1089 reference
1090 "RFC YYYY: NETCONF Call Home and RESTCONF Call Home";
1091 }
1093 // top-level container (groupings below)
1094 container netconf-server {
1095 description
1096 "Top-level container for NETCONF server configuration.";
1098 container session-options { // SHOULD WE REMOVE THIS ALTOGETHER?
1099 description
1100 "NETCONF session options, independent of transport
1101 or connection strategy.";
1102 leaf hello-timeout {
1103 type uint16;
1104 units "seconds";
1105 default 600;
1106 description
1107 "Specifies the maximum number of seconds that a SSH/TLS
1108 connection may wait for a hello message to be received.
1109 A connection will be dropped if no hello message is
1110 received before this number of seconds elapses. If set
1111 to zero, then the server will wait forever for a hello
1112 message.";
1113 }
1114 }
1116 container listen {
1117 if-feature listen;
1118 description
1119 "Configures listen behavior";
1120 leaf max-sessions {
1121 type uint16;
1122 default 0;
1123 description
1124 "Specifies the maximum number of concurrent sessions
1125 that can be active at one time. The value 0 indicates
1126 that no artificial session limit should be used.";
1127 }
1128 leaf idle-timeout {
1129 type uint16;
1130 units "seconds";
1131 default 3600; // one hour
1132 description
1133 "Specifies the maximum number of seconds that a NETCONF
1134 session may remain idle. A NETCONF session will be dropped
1135 if it is idle for an interval longer than this number of
1136 seconds. If set to zero, then the server will never drop
1137 a session because it is idle. Sessions that have a
1138 notification subscription active are never dropped.";
1139 }
1140 list endpoint {
1141 key name;
1142 description
1143 "List of endpoints to listen for NETCONF connections on.";
1144 leaf name {
1145 type string;
1146 description
1147 "An arbitrary name for the NETCONF listen endpoint.";
1149 }
1150 choice transport {
1151 mandatory true;
1152 description
1153 "Selects between available transports.";
1154 case ssh {
1155 if-feature ssh-listen;
1156 container ssh {
1157 description
1158 "SSH-specific listening configuration for inbound
1159 connections.";
1160 uses ss:listening-ssh-server-grouping {
1161 refine port {
1162 default 830;
1163 }
1164 }
1165 }
1166 }
1167 case tls {
1168 if-feature tls-listen;
1169 container tls {
1170 description
1171 "TLS-specific listening configuration for inbound
1172 connections.";
1173 uses ts:listening-tls-server-grouping {
1174 refine port {
1175 default 6513;
1176 }
1177 augment "client-auth" {
1178 description
1179 "Augments in the cert-to-name structure.";
1180 uses cert-maps-grouping;
1181 }
1182 }
1183 }
1184 }
1185 }
1186 }
1187 }
1189 container call-home {
1190 if-feature call-home;
1191 description
1192 "Configures call-home behavior";
1193 list netconf-client {
1194 key name;
1195 description
1196 "List of NETCONF clients the NETCONF server is to initiate
1197 call-home connections to.";
1198 leaf name {
1199 type string;
1200 description
1201 "An arbitrary name for the remote NETCONF client.";
1202 }
1203 choice transport {
1204 mandatory true;
1205 description
1206 "Selects between available transports.";
1207 case ssh {
1208 if-feature ssh-call-home;
1209 container ssh {
1210 description
1211 "Specifies SSH-specific call-home transport
1212 configuration.";
1213 uses endpoints-container {
1214 refine endpoints/endpoint/port {
1215 default 4334;
1216 }
1217 }
1218 uses ss:non-listening-ssh-server-grouping;
1219 }
1220 }
1221 case tls {
1222 if-feature tls-call-home;
1223 container tls {
1224 description
1225 "Specifies TLS-specific call-home transport
1226 configuration.";
1227 uses endpoints-container {
1228 refine endpoints/endpoint/port {
1229 default 4335;
1230 }
1231 }
1232 uses ts:non-listening-tls-server-grouping {
1233 augment "client-auth" {
1234 description
1235 "Augments in the cert-to-name structure.";
1236 uses cert-maps-grouping;
1237 }
1238 }
1239 }
1240 }
1241 }
1242 container connection-type {
1243 description
1244 "Indicates the kind of connection to use.";
1246 choice connection-type {
1247 description
1248 "Selects between available connection types.";
1249 case persistent-connection {
1250 container persistent {
1251 presence true;
1252 description
1253 "Maintain a persistent connection to the NETCONF
1254 client. If the connection goes down, immediately
1255 start trying to reconnect to it, using the
1256 reconnection strategy.
1258 This connection type minimizes any NETCONF client
1259 to NETCONF server data-transfer delay, albeit at
1260 the expense of holding resources longer.";
1261 leaf idle-timeout {
1262 type uint32;
1263 units "seconds";
1264 default 86400; // one day;
1265 description
1266 "Specifies the maximum number of seconds that a
1267 a NETCONF session may remain idle. A NETCONF
1268 session will be dropped if it is idle for an
1269 interval longer than this number of seconds.
1270 If set to zero, then the server will never drop
1271 a session because it is idle. Sessions that
1272 have a notification subscription active are
1273 never dropped.";
1274 }
1275 container keep-alives {
1276 description
1277 "Configures the keep-alive policy, to proactively
1278 test the aliveness of the SSH/TLS client. An
1279 unresponsive SSH/TLS client will be dropped after
1280 approximately max-attempts * max-wait seconds.";
1281 reference
1282 "RFC YYYY: NETCONF Call Home and RESTCONF Call
1283 Home, Section 3.1, item S6";
1284 leaf max-wait {
1285 type uint16 {
1286 range "1..max";
1287 }
1288 units seconds;
1289 default 30;
1290 description
1291 "Sets the amount of time in seconds after which
1292 if no data has been received from the SSH/TLS
1293 client, a SSH/TLS-level message will be sent
1294 to test the aliveness of the SSH/TLS client.";
1295 }
1296 leaf max-attempts {
1297 type uint8;
1298 default 3;
1299 description
1300 "Sets the maximum number of sequential keep-alive
1301 messages that can fail to obtain a response from
1302 the SSH/TLS client before assuming the SSH/TLS
1303 client is no longer alive.";
1304 }
1305 }
1306 }
1307 }
1308 case periodic-connection {
1309 container periodic {
1310 presence true;
1311 description
1312 "Periodically connect to the NETCONF client, so that
1313 the NETCONF client may deliver messages pending for
1314 the NETCONF server. The NETCONF client must close
1315 the connection when it is ready to release it. Once
1316 the connection has been closed, the NETCONF server
1317 will restart its timer until the next connection.";
1318 leaf idle-timeout {
1319 type uint16;
1320 units "seconds";
1321 default 300; // five minutes
1322 description
1323 "Specifies the maximum number of seconds that a
1324 a NETCONF session may remain idle. A NETCONF
1325 session will be dropped if it is idle for an
1326 interval longer than this number of seconds.
1327 If set to zero, then the server will never drop
1328 a session because it is idle. Sessions that
1329 have a notification subscription active are
1330 never dropped.";
1331 }
1332 leaf reconnect_timeout {
1333 type uint16 {
1334 range "1..max";
1335 }
1336 units minutes;
1337 default 60;
1338 description
1339 "Sets the maximum amount of unconnected time the
1340 NETCONF server will wait before re-establishing
1341 a connection to the NETCONF client. The NETCONF
1342 server may initiate a connection before this
1343 time if desired (e.g., to deliver an event
1344 notification message).";
1345 }
1346 }
1347 }
1348 }
1349 }
1350 container reconnect-strategy {
1351 description
1352 "The reconnection strategy directs how a NETCONF server
1353 reconnects to a NETCONF client, after discovering its
1354 connection to the client has dropped, even if due to a
1355 reboot. The NETCONF server starts with the specified
1356 endpoint and tries to connect to it max-attempts times
1357 before trying the next endpoint in the list (round
1358 robin).";
1359 leaf start-with {
1360 type enumeration {
1361 enum first-listed {
1362 description
1363 "Indicates that reconnections should start with
1364 the first endpoint listed.";
1365 }
1366 enum last-connected {
1367 description
1368 "Indicates that reconnections should start with
1369 the endpoint last connected to. If no previous
1370 connection has ever been established, then the
1371 first endpoint configured is used. NETCONF
1372 servers SHOULD be able to remember the last
1373 endpoint connected to across reboots.";
1374 }
1375 }
1376 default first-listed;
1377 description
1378 "Specifies which of the NETCONF client's endpoints the
1379 NETCONF server should start with when trying to connect
1380 to the NETCONF client.";
1381 }
1382 leaf max-attempts {
1383 type uint8 {
1384 range "1..max";
1385 }
1386 default 3;
1387 description
1388 "Specifies the number times the NETCONF server tries to
1389 connect to a specific endpoint before moving on to the
1390 next endpoint in the list (round robin).";
1391 }
1392 }
1393 }
1394 }
1395 }
1397 grouping cert-maps-grouping {
1398 description
1399 "A grouping that defines a container around the
1400 cert-to-name structure defined in RFC 7407.";
1401 container cert-maps {
1402 uses x509c2n:cert-to-name;
1403 description
1404 "The cert-maps container is used by a TLS-based NETCONF
1405 server to map the NETCONF client's presented X.509
1406 certificate to a NETCONF username. If no matching and
1407 valid cert-to-name list entry can be found, then the
1408 NETCONF server MUST close the connection, and MUST NOT
1409 accept NETCONF messages over it.";
1410 reference
1411 "RFC WWWW: NETCONF over TLS, Section 7";
1412 }
1413 }
1415 grouping endpoints-container {
1416 description
1417 "This grouping is used by both the ssh and tls containers
1418 for call-home configurations.";
1419 container endpoints {
1420 description
1421 "Container for the list of endpoints.";
1422 list endpoint {
1423 key name;
1424 min-elements 1;
1425 ordered-by user;
1426 description
1427 "User-ordered list of endpoints for this NETCONF client.
1428 Defining more than one enables high-availability.";
1429 leaf name {
1430 type string;
1431 description
1432 "An arbitrary name for this endpoint.";
1433 }
1434 leaf address {
1435 type inet:host;
1436 mandatory true;
1437 description
1438 "The IP address or hostname of the endpoint. If a
1439 hostname is configured and the DNS resolution results
1440 in more than one IP address, the NETCONF server
1441 will process the IP addresses as if they had been
1442 explicitly configured in place of the hostname.";
1443 }
1444 leaf port {
1445 type inet:port-number;
1446 description
1447 "The IP port for this endpoint. The NETCONF server will
1448 use the IANA-assigned well-known port if no value is
1449 specified.";
1450 }
1451 }
1452 }
1453 }
1455 }
1457
1459 4. Design Considerations
1461 Editorial: this section is a hold over from before, previously called
1462 "Objectives". It was only written two support the "server" (not the
1463 "client"). The question is if it's better to add the missing
1464 "client" parts, or remove this section altogether.
1466 The primary purpose of the YANG modules defined herein is to enable
1467 the configuration of the NETCONF client and servers. This scope
1468 includes the following objectives:
1470 4.1. Support all NETCONF transports
1472 The YANG module should support all current NETCONF transports, namely
1473 NETCONF over SSH [RFC6242], NETCONF over TLS [RFC7589], and to be
1474 extensible to support future transports as necessary.
1476 Because implementations may not support all transports, the modules
1477 should use YANG "feature" statements so that implementations can
1478 accurately advertise which transports are supported.
1480 4.2. Enable each transport to select which keys to use
1482 Servers may have a multiplicity of host-keys or server-certificates
1483 from which subsets may be selected for specific uses. For instance,
1484 a NETCONF server may want to use one set of SSH host-keys when
1485 listening on port 830, and a different set of SSH host-keys when
1486 calling home. The data models provided herein should enable
1487 configuration of which keys to use on a per-use basis.
1489 4.3. Support authenticating NETCONF clients certificates
1491 When a certificate is used to authenticate a NETCONF client, there is
1492 a need to configure the server to know how to authenticate the
1493 certificates. The server should be able to authenticate the client's
1494 certificate either by using path-validation to a configured trust
1495 anchor or by matching the client-certificate to one previously
1496 configured.
1498 4.4. Support mapping authenticated NETCONF client certificates to
1499 usernames
1501 When a client certificate is used for TLS client authentication, the
1502 NETCONF server must be able to derive a username from the
1503 authenticated certificate. Thus the modules defined herein should
1504 enable this mapping to be configured.
1506 4.5. Support both listening for connections and call home
1508 The NETCONF protocols were originally defined as having the server
1509 opening a port to listen for client connections. More recently the
1510 NETCONF working group defined support for call-home
1511 ([draft-ietf-netconf-call-home]), enabling the server to initiate the
1512 connection to the client. Thus the modules defined herein should
1513 enable configuration for both listening for connections and calling
1514 home. Because implementations may not support both listening for
1515 connections and calling home, YANG "feature" statements should be
1516 used so that implementation can accurately advertise the connection
1517 types it supports.
1519 4.6. For Call Home connections
1521 The following objectives only pertain to call home connections.
1523 4.6.1. Support more than one NETCONF client
1525 A NETCONF server may be managed by more than one NETCONF client. For
1526 instance, a deployment may have one client for provisioning and
1527 another for fault monitoring. Therefore, when it is desired for a
1528 server to initiate call home connections, it should be able to do so
1529 to more than one client.
1531 4.6.2. Support NETCONF clients having more than one endpoint
1533 A NETCONF client managing a NETCONF server may implement a high-
1534 availability strategy employing a multiplicity of active and/or
1535 passive endpoint. Therefore, when it is desired for a server to
1536 initiate call home connections, it should be able to connect to any
1537 of the client's endpoints.
1539 4.6.3. Support a reconnection strategy
1541 Assuming a NETCONF client has more than one endpoint, then it becomes
1542 necessary to configure how a NETCONF server should reconnect to the
1543 client should it lose its connection to one the client's endpoints.
1544 For instance, the NETCONF server may start with first endpoint
1545 defined in a user-ordered list of endpoints or with the last
1546 endpoints it was connected to.
1548 4.6.4. Support both persistent and periodic connections
1550 NETCONF clients may vary greatly on how frequently they need to
1551 interact with a NETCONF server, how responsive interactions need to
1552 be, and how many simultaneous connections they can support. Some
1553 clients may need a persistent connection to servers to optimize real-
1554 time interactions, while others prefer periodic interactions in order
1555 to minimize resource requirements. Therefore, when it is necessary
1556 for server to initiate connections, it should be configurable if the
1557 connection is persistent or periodic.
1559 4.6.5. Reconnection strategy for periodic connections
1561 The reconnection strategy should apply to both persistent and
1562 periodic connections. How it applies to periodic connections becomes
1563 clear when considering that a periodic "connection" is a logical
1564 connection to a single server. That is, the periods of
1565 unconnectedness are intentional as opposed to due to external
1566 reasons. A periodic "connection" should always reconnect to the same
1567 server until it is no longer able to, at which time the reconnection
1568 strategy guides how to connect to another server.
1570 4.6.6. Keep-alives for persistent connections
1572 If a persistent connection is desired, it is the responsibility of
1573 the connection initiator to actively test the "aliveness" of the
1574 connection. The connection initiator must immediately work to
1575 reestablish a persistent connection as soon as the connection is
1576 lost. How often the connection should be tested is driven by NETCONF
1577 client requirements, and therefore keep-alive settings should be
1578 configurable on a per-client basis.
1580 4.6.7. Customizations for periodic connections
1582 If a periodic connection is desired, it is necessary for the NETCONF
1583 server to know how often it should connect. This frequency
1584 determines the maximum amount of time a NETCONF client may have to
1585 wait to send data to a server. A server may connect to a client
1586 before this interval expires if desired (e.g., to send data to a
1587 client).
1589 5. Security Considerations
1591 A denial of service (DoS) attack MAY occur if the NETCONF server
1592 limits the maximum number of NETCONF sessions it will accept (i.e.
1593 the 'max-sessions' field in the ietf-netconf-server module is not
1594 zero) and either the "hello-timeout" or "idle-timeout" fields in
1595 ietf-netconf-server module have been set to indicate the NETCONF
1596 server should wait forever (i.e. set to zero).
1598 6. IANA Considerations
1600 6.1. The IETF XML Registry
1602 This document registers two URIs in the IETF XML registry [RFC2119].
1603 Following the format in [RFC3688], the following registrations are
1604 requested:
1606 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-client
1607 Registrant Contact: The NETCONF WG of the IETF.
1608 XML: N/A, the requested URI is an XML namespace.
1610 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-server
1611 Registrant Contact: The NETCONF WG of the IETF.
1612 XML: N/A, the requested URI is an XML namespace.
1614 6.2. The YANG Module Names Registry
1616 This document registers two YANG modules in the YANG Module Names
1617 registry [RFC6020]. Following the format in [RFC6020], the the
1618 following registrations are requested:
1620 name: ietf-netconf-client
1621 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-client
1622 prefix: ncc
1623 reference: RFC XXXX
1625 name: ietf-netconf-server
1626 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-server
1627 prefix: ncs
1628 reference: RFC XXXX
1630 7. Acknowledgements
1632 The authors would like to thank for following for lively discussions
1633 on list and in the halls (ordered by last name): Andy Bierman, Martin
1634 Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk,
1635 Ladislav Lhotka, Radek Krejci, Tom Petch, Phil Shafer, Sean Turner,
1636 and Bert Wijnen.
1638 Juergen Schoenwaelder and was partly funded by Flamingo, a Network of
1639 Excellence project (ICT-318488) supported by the European Commission
1640 under its Seventh Framework Programme.
1642 8. References
1644 8.1. Normative References
1646 [draft-ietf-netconf-ssh-client-server]
1647 Watsen, K., "SSH Client and Server Models", draft-ieft-
1648 netconf-ssh-client-server-00 (work in progress), 2016,
1649 .
1652 [draft-ietf-netconf-system-keychain]
1653 Watsen, K., "System Keychain Model", draft-ieft-netconf-
1654 system-keychain-00 (work in progress), 2016,
1655 .
1658 [draft-ietf-netconf-tls-client-server]
1659 Watsen, K., "TLS Client and Server Models", draft-ieft-
1660 netconf-tls-client-server-00 (work in progress), 2016,
1661 .
1664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1665 Requirement Levels", BCP 14, RFC 2119,
1666 DOI 10.17487/RFC2119, March 1997,
1667 .
1669 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
1670 the Network Configuration Protocol (NETCONF)", RFC 6020,
1671 DOI 10.17487/RFC6020, October 2010,
1672 .
1674 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1675 and A. Bierman, Ed., "Network Configuration Protocol
1676 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1677 .
1679 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
1680 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
1681 .
1683 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
1684 RFC 6991, DOI 10.17487/RFC6991, July 2013,
1685 .
1687 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
1688 SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
1689 December 2014, .
1691 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
1692 NETCONF Protocol over Transport Layer Security (TLS) with
1693 Mutual X.509 Authentication", RFC 7589,
1694 DOI 10.17487/RFC7589, June 2015,
1695 .
1697 8.2. Informative References
1699 [draft-ietf-netconf-call-home]
1700 Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
1701 draft-ieft-netconf-call-home-17 (work in progress), 2015,
1702 .
1705 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1706 DOI 10.17487/RFC3688, January 2004,
1707 .
1709 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
1710 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
1711 January 2006, .
1713 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
1714 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
1715 January 2006, .
1717 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
1718 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254,
1719 January 2006, .
1721 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1722 (TLS) Protocol Version 1.2", RFC 5246,
1723 DOI 10.17487/RFC5246, August 2008,
1724 .
1726 Appendix A. Change Log
1728 A.1. server-model-09 to 00
1730 o This draft was split out from draft-ietf-netconf-server-model-09.
1732 o Added in previously missing ietf-netconf-client module.
1734 o Added in new features 'listen' and 'call-home' so future
1735 transports can be augmented in.
1737 Appendix B. Open Issues
1739 Please see: https://github.com/netconf-wg/netconf-client-server/
1740 issues.
1742 Authors' Addresses
1744 Kent Watsen
1745 Juniper Networks
1747 EMail: kwatsen@juniper.net
1749 Gary Wu
1750 Cisco Networks
1752 EMail: garywu@cisco.com
1754 Juergen Schoenwaelder
1755 Jacobs University Bremen
1757 EMail: j.schoenwaelder@jacobs-university.de