draft-ietf-netconf-restconf-client-server-05.txt   draft-ietf-netconf-restconf-client-server-06.txt 
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track G. Wu Intended status: Standards Track G. Wu
Expires: May 3, 2018 Cisco Networks Expires: December 6, 2018 Cisco Networks
October 30, 2017 June 4, 2018
RESTCONF Client and Server Models RESTCONF Client and Server Models
draft-ietf-netconf-restconf-client-server-05 draft-ietf-netconf-restconf-client-server-06
Abstract Abstract
This document defines two YANG modules, one module to configure a This document defines two YANG modules, one module to configure a
RESTCONF client and the other module to configure a RESTCONF server. RESTCONF client and the other module to configure a RESTCONF server.
Both modules support the TLS transport protocol with both standard Both modules support the TLS transport protocol with both standard
RESTCONF and RESTCONF Call Home connections. RESTCONF and RESTCONF Call Home connections.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
skipping to change at page 1, line 46 skipping to change at page 1, line 46
progress. Please apply the following replacements: progress. Please apply the following replacements:
o "XXXX" --> the assigned RFC value for this draft o "XXXX" --> the assigned RFC value for this draft
o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-tls-client- o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-tls-client-
server server
Artwork in this document contains placeholder values for the date of Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement: publication of this draft. Please apply the following replacement:
o "2017-10-30" --> the publication date of this draft o "2018-06-04" --> the publication date of this draft
The following Appendix section is to be removed prior to publication: The following Appendix section is to be removed prior to publication:
o Appendix A. Change Log o Appendix A. Change Log
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 May 3, 2018. This Internet-Draft will expire on December 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 51 skipping to change at page 2, line 51
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. The RESTCONF Client Model . . . . . . . . . . . . . . . . . . 3 2. The RESTCONF Client Model . . . . . . . . . . . . . . . . . . 3
2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 6
2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8
3. The RESTCONF Server Model . . . . . . . . . . . . . . . . . . 17 3. The RESTCONF Server Model . . . . . . . . . . . . . . . . . . 17
3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 20 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 20
3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 23 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 23
4. Security Considerations . . . . . . . . . . . . . . . . . . . 33 4. Security Considerations . . . . . . . . . . . . . . . . . . . 32
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 34 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 33
5.2. The YANG Module Names Registry . . . . . . . . . . . . . 34 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 34
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.1. Normative References . . . . . . . . . . . . . . . . . . 34
7.1. Normative References . . . . . . . . . . . . . . . . . . 34 6.2. Informative References . . . . . . . . . . . . . . . . . 35
7.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 37 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 37
A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 37 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 37
A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 37 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 37
A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 37 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 37
A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 37 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 37
A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 38
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This document defines two YANG [RFC7950] modules, one module to This document defines two YANG [RFC7950] modules, one module to
configure a RESTCONF client and the other module to configure a configure a RESTCONF client and the other module to configure a
RESTCONF server [RFC8040]. Both modules support the TLS [RFC5246] RESTCONF server [RFC8040]. Both modules support the TLS [RFC5246]
transport protocol with both standard RESTCONF and RESTCONF Call Home transport protocol with both standard RESTCONF and RESTCONF Call Home
connections [RFC8071]. connections [RFC8071].
1.1. Terminology 1.1. Terminology
skipping to change at page 4, line 7 skipping to change at page 4, line 7
transport currently, thus this model only supports the TLS transport. transport currently, thus this model only supports the TLS transport.
All private keys and trusted certificates are held in the keystore All private keys and trusted certificates are held in the keystore
model defined in [I-D.ietf-netconf-keystore]. model defined in [I-D.ietf-netconf-keystore].
YANG feature statements are used to enable implementations to YANG feature statements are used to enable implementations to
advertise which parts of the model the RESTCONF client supports. advertise which parts of the model the RESTCONF client supports.
2.1. Tree Diagram 2.1. Tree Diagram
The following tree diagram [I-D.ietf-netmod-yang-tree-diagrams] The following tree diagram [RFC8340] provides an overview of the data
provides an overview of the data model for the "ietf-restconf-client" model for the "ietf-restconf-client" module. Just the container is
module. Just the container is displayed below, but there is also a displayed below, but there is also a reuable grouping by the same
reuable grouping by the same name that the container is using. name that the container is using.
[ note: '\' line wrapping for formatting only]
module: ietf-restconf-client [Note: '\' line wrapping for formatting only]
+--rw restconf-client
+--rw initiate {initiate}?
| +--rw restconf-server* [name]
| +--rw name string
| +--rw endpoints
| +--rw endpoint* [name]
| +--rw name string
| +--rw (transport)
| | +--:(tls) {tls-initiate}?
| | +--rw tls
| | +--rw address inet:host
| | +--rw port? inet:port-number\
| | +--rw client-identity module: ietf-restconf-client
| | | +--rw (auth-type) +--rw restconf-client
| | | +--:(certificate) +--rw initiate! {initiate}?
| | | +--rw certificate | +--rw restconf-server* [name]
| | | +--rw algorithm? | +--rw name string
| | | | identityref | +--rw endpoints
| | | +--rw private-key? | +--rw endpoint* [name]
| | | | union | +--rw name string
| | | +--rw public-key? | +--rw (transport)
| | | | binary | | +--:(tls) {tls-initiate}?
| | | +---x generate-private-key | | +--rw tls
| | | | +---w input | | +--rw address inet:host
| | | | +---w algorithm | | +--rw port? inet:port-number
| | | | identityref | | +--rw client-identity
| | | +--rw certificates | | | +--rw (auth-type)
| | | | +--rw certificate* [name] | | | +--:(certificate)
| | | | +--rw name string | | | +--rw certificate
| | | | +--rw value? binary | | | +--rw (local-or-keystore)
| | | +---x generate-certificate-si\ | | | +--:(local)
gning-request | | | | +--rw algorithm
| | | +---w input | | | | | ct:key-algorithm\
| | | | +---w subject -ref
| | | | | binary | | | | +--rw public-key
| | | | +---w attributes? | | | | | binary
| | | | binary | | | | +--rw private-key
| | | +--ro output | | | | | union
| | | +--ro certificate-signi\ | | | | +--rw cert
ng-request | | | | | ct:end-entity-ce\
| | | binary rt-cms
| | +--rw server-auth | | | | +---n certificate-expira\
| | | +--rw pinned-ca-certs? tion
| | | | ks:pinned-certificates | | | | +-- expiration-date?
| | | +--rw pinned-server-certs? | | | | yang:date-and\
| | | ks:pinned-certificates -time
| | +--rw hello-params | | | +--:(keystore)
| | {tls-client-hello-params-config}?\ | | | {keystore-implemen\
ted}?
| | | +--rw reference
| | | ks:asymmetric-ke\
y-certificate-ref
| | +--rw server-auth
| | | +--rw pinned-ca-certs?
| | | | ta:pinned-certificates-ref
| | | +--rw pinned-server-certs?
| | | ta:pinned-certificates-ref
| | +--rw hello-params
| | {tls-client-hello-params-config}?
| | +--rw tls-versions
| | | +--rw tls-version* identityref
| | +--rw cipher-suites
| | +--rw cipher-suite* identityref
| +--rw connection-type
| | +--rw (connection-type)?
| | +--:(persistent-connection)
| | | +--rw persistent!
| | | +--rw idle-timeout? uint32
| | | +--rw keep-alives
| | | +--rw max-wait? uint16
| | | +--rw max-attempts? uint8
| | +--:(periodic-connection)
| | +--rw periodic!
| | +--rw idle-timeout? uint16
| | +--rw reconnect-timeout? uint16
| +--rw reconnect-strategy
| +--rw start-with? enumeration
| +--rw max-attempts? uint8
+--rw listen! {listen}?
+--rw idle-timeout? uint16
+--rw endpoint* [name]
+--rw name string
+--rw (transport)
+--:(tls) {tls-listen}?
+--rw tls
+--rw address? inet:ip-address
+--rw port? inet:port-number
+--rw client-identity
| +--rw (auth-type)
| +--:(certificate)
| +--rw certificate
| +--rw (local-or-keystore)
| +--:(local)
| | +--rw algorithm
| | | ct:key-algorithm-ref
| | +--rw public-key
| | | binary
| | +--rw private-key
| | | union
| | +--rw cert
| | | ct:end-entity-cert-cms\
| | +--rw tls-versions | | +---n certificate-expiration
| | | +--rw tls-version* identityref | | +-- expiration-date?
| | +--rw cipher-suites | | yang:date-and-time
| | +--rw cipher-suite* identityref | +--:(keystore)
| +--rw connection-type | {keystore-implemented}?
| | +--rw (connection-type)? | +--rw reference
| | +--:(persistent-connection) | ks:asymmetric-key-cert\
| | | +--rw persistent! ificate-ref
| | | +--rw idle-timeout? uint32 +--rw server-auth
| | | +--rw keep-alives | +--rw pinned-ca-certs?
| | | +--rw max-wait? uint16 | | ta:pinned-certificates-ref
| | | +--rw max-attempts? uint8 | +--rw pinned-server-certs?
| | +--:(periodic-connection) | ta:pinned-certificates-ref
| | +--rw periodic! +--rw hello-params
| | +--rw idle-timeout? uint16 {tls-client-hello-params-config}?
| | +--rw reconnect-timeout? uint16 +--rw tls-versions
| +--rw reconnect-strategy | +--rw tls-version* identityref
| +--rw start-with? enumeration +--rw cipher-suites
| +--rw max-attempts? uint8 +--rw cipher-suite* identityref
+--rw listen {listen}?
+--rw idle-timeout? uint16
+--rw endpoint* [name]
+--rw name string
+--rw (transport)
+--:(tls) {tls-listen}?
+--rw tls
+--rw address? inet:ip-address
+--rw port? inet:port-number
+--rw client-identity
| +--rw (auth-type)
| +--:(certificate)
| +--rw certificate
| +--rw algorithm?
| | identityref
| +--rw private-key?
| | union
| +--rw public-key?
| | binary
| +---x generate-private-key
| | +---w input
| | +---w algorithm identityre\
f
| +--rw certificates
| | +--rw certificate* [name]
| | +--rw name string
| | +--rw value? binary
| +---x generate-certificate-signing-\
request
| +---w input
| | +---w subject binary
| | +---w attributes? binary
| +--ro output
| +--ro certificate-signing-req\
uest
| binary
+--rw server-auth
| +--rw pinned-ca-certs?
| | ks:pinned-certificates
| +--rw pinned-server-certs?
| ks:pinned-certificates
+--rw hello-params
{tls-client-hello-params-config}?
+--rw tls-versions
| +--rw tls-version* identityref
+--rw cipher-suites
+--rw cipher-suite* identityref
2.2. Example Usage 2.2. Example Usage
The following example illustrates configuring a RESTCONF client to The following example illustrates configuring a RESTCONF client to
initiate connections, as well as listening for call-home connections. initiate connections, as well as listening for call-home connections.
This example is consistent with the examples presented in Section 2.2 This example is consistent with the examples presented in Section 2.2
of [I-D.ietf-netconf-keystore]. of [I-D.ietf-netconf-keystore].
[ note: '\' line wrapping for formatting only] [Note: '\' line wrapping for formatting only]
<restconf-client <restconf-client
xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-client"> xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-client">
<!-- RESTCONF servers to initiate connections to --> <!-- RESTCONF servers to initiate connections to -->
<initiate> <initiate>
<restconf-server> <restconf-server>
<name>corp-fw1</name> <name>corp-fw1</name>
<endpoints> <endpoints>
<endpoint> <endpoint>
<name>corp-fw1.example.com</name> <name>corp-fw1.example.com</name>
<tls> <tls>
<address>corp-fw1.example.com</address> <address>corp-fw1.example.com</address>
<client-identity> <client-identity>
<certificate> <certificate>
<algorithm xmlns:ks="urn:ietf:params:xml:ns:yang:ie\ <algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:i\
tf-keystore">ks:secp521r1</algorithm> etf-crypto-types">ct:secp521r1</algorithm>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
<certificates> <cert>base64encodedvalue==</cert>
<certificate> </certificate>
<name>domain certificate</name> </client-identity>
<value>base64encodedvalue==</value> <server-auth>
</certificate> <pinned-ca-certs>explicitly-trusted-server-ca-certs<\
</certificates> /pinned-ca-certs>
</certificate> <pinned-server-certs>explicitly-trusted-server-certs\
</client-identity> </pinned-server-certs>
<server-auth> </server-auth>
<pinned-server-certs>deployment-specific-ca-certs</pi\ </tls>
nned-server-certs> </endpoint>
</server-auth> <endpoint>
</tls> <name>corp-fw2.example.com</name>
</endpoint> <tls>
<endpoint> <address>corp-fw2.example.com</address>
<name>corp-fw2.example.com</name> <client-identity>
<tls> <certificate>
<address>corp-fw2.example.com</address> <algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:i\
<client-identity> etf-crypto-types">ct:secp521r1</algorithm>
<certificate> <private-key>base64encodedvalue==</private-key>
<algorithm xmlns:ks="urn:ietf:params:xml:ns:yang:ie\ <public-key>base64encodedvalue==</public-key>
tf-keystore">ks:secp521r1</algorithm> <cert>base64encodedvalue==</cert>
<private-key>base64encodedvalue==</private-key> </certificate>
<public-key>base64encodedvalue==</public-key> </client-identity>
<certificates> <server-auth>
<certificate> <pinned-ca-certs>explicitly-trusted-server-ca-certs<\
<name>domain certificate</name> /pinned-ca-certs>
<value>base64encodedvalue==</value> <pinned-server-certs>explicitly-trusted-server-certs\
</certificate> </pinned-server-certs>
</certificates> </server-auth>
</certificate> </tls>
</client-identity> </endpoint>
<server-auth> </endpoints>
<pinned-server-certs>deployment-specific-ca-certs</pi\ </restconf-server>
nned-server-certs> </initiate>
</server-auth>
</tls>
</endpoint> <!-- endpoints to listen for RESTCONF Call Home connections on -->\
</endpoints>
</restconf-server>
</initiate>
<!-- endpoints to listen for RESTCONF Call Home connections on --> <listen>
<listen> <endpoint>
<endpoint> <name>Intranet-facing listener</name>
<name>Intranet-facing listener</name> <tls>
<tls> <address>11.22.33.44</address>
<address>11.22.33.44</address> <client-identity>
<client-identity> <certificate>
<certificate> <algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-cr\
<algorithm xmlns:ks="urn:ietf:params:xml:ns:yang:ietf-key\ ypto-types">ct:secp521r1</algorithm>
store">ks:secp521r1</algorithm> <private-key>base64encodedvalue==</private-key>
<private-key>base64encodedvalue==</private-key> <public-key>base64encodedvalue==</public-key>
<public-key>base64encodedvalue==</public-key> <cert>base64encodedvalue==</cert>
<certificates> </certificate>
<certificate> </client-identity>
<name>domain certificate</name> <server-auth>
<value>base64encodedvalue==</value> <pinned-ca-certs>explicitly-trusted-server-ca-certs</pinne\
</certificate> d-ca-certs>
</certificates> <pinned-server-certs>explicitly-trusted-server-certs</pinn\
</certificate> ed-server-certs>
</client-identity> </server-auth>
<server-auth> </tls>
<pinned-ca-certs>deployment-specific-ca-certs</pinned-ca-ce\ </endpoint>
rts> </listen>
<pinned-server-certs>explicitly-trusted-server-certs</pinne\ </restconf-client>
d-server-certs>
</server-auth>
</tls>
</endpoint>
</listen>
</restconf-client>
2.3. YANG Module 2.3. YANG Module
This YANG module imports YANG types from [RFC6991] and [RFC7407], and This YANG module has normative references to [RFC6991], [RFC8040],
groupings from [I-D.ietf-netconf-tls-client-server]. and [RFC8071], and [I-D.ietf-netconf-tls-client-server].
<CODE BEGINS> file "ietf-restconf-client@2017-10-30.yang" <CODE BEGINS> file "ietf-restconf-client@2018-06-04.yang"
module ietf-restconf-client { module ietf-restconf-client {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-client"; namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-client";
prefix "rcc"; prefix "rcc";
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-tls-client { import ietf-inet-types {
prefix ts; prefix inet;
revision-date 2017-10-30; // stable grouping definitions reference
reference "RFC 6991: Common YANG Data Types";
"RFC ZZZZ: YANG Groupings for TLS Clients and TLS Servers"; }
}
organization import ietf-tls-client {
"IETF NETCONF (Network Configuration) Working Group"; prefix ts;
revision-date 2018-06-04; // stable grouping definitions
reference
"RFC ZZZZ: YANG Groupings for TLS Clients and TLS Servers";
}
contact organization
"WG Web: <http://tools.ietf.org/wg/restconf/> "IETF NETCONF (Network Configuration) Working Group";
WG List: <mailto:restconf@ietf.org>
Author: Kent Watsen contact
<mailto:kwatsen@juniper.net> "WG Web: <http://datatracker.ietf.org/wg/restconf/>
WG List: <mailto:restconf@ietf.org>
Author: Gary Wu Author: Kent Watsen
<mailto:garywu@cisco.com>"; <mailto:kwatsen@juniper.net>
description Author: Gary Wu
"This module contains a collection of YANG definitions for <mailto:garywu@cisco.com>";
configuring RESTCONF clients.
Copyright (c) 2017 IETF Trust and the persons identified as description
authors of the code. All rights reserved. "This module contains a collection of YANG definitions for
configuring RESTCONF clients.
Redistribution and use in source and binary forms, with or Copyright (c) 2017 IETF Trust and the persons identified as
without modification, is permitted pursuant to, and subject authors of the code. All rights reserved.
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see Redistribution and use in source and binary forms, with or
the RFC itself for full legal notices."; without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
revision "2017-10-30" { This version of this YANG module is part of RFC XXXX; see
description the RFC itself for full legal notices.";
"Initial version";
reference
"RFC XXXX: RESTCONF Client and Server Models";
}
// Features revision "2018-06-04" {
description
"Initial version";
reference
"RFC XXXX: RESTCONF Client and Server Models";
}
feature initiate { // Features
description
"The 'initiate' feature indicates that the RESTCONF client
supports initiating RESTCONF connections to RESTCONF servers
using at least one transport (e.g., TLS, etc.).";
}
feature tls-initiate { feature initiate {
if-feature initiate; description
description "The 'initiate' feature indicates that the RESTCONF client
"The 'tls-initiate' feature indicates that the RESTCONF client supports initiating RESTCONF connections to RESTCONF servers
supports initiating TLS connections to RESTCONF servers. This using at least one transport (e.g., TLS, etc.).";
feature exists as TLS might not be a mandatory-to-implement }
transport in the future.";
reference
"RFC 8040: RESTCONF Protocol";
}
feature listen { feature tls-initiate {
description if-feature initiate;
"The 'listen' feature indicates that the RESTCONF client description
supports opening a port to accept RESTCONF server call "The 'tls-initiate' feature indicates that the RESTCONF client
home connections using at least one transport (e.g., supports initiating TLS connections to RESTCONF servers. This
TLS, etc.)."; feature exists as TLS might not be a mandatory to implement
} transport in the future.";
reference
"RFC 8040: RESTCONF Protocol";
}
feature tls-listen { feature listen {
if-feature listen; description
description "The 'listen' feature indicates that the RESTCONF client
"The 'tls-listen' feature indicates that the RESTCONF client supports opening a port to accept RESTCONF server call
supports opening a port to listen for incoming RESTCONF home connections using at least one transport (e.g.,
server call-home TLS connections. This feature exists as TLS, etc.).";
TLS might not be a mandatory-to-implement transport in the }
future.";
reference
"RFC 8071: NETCONF Call Home and RESTCONF Call Home";
}
container restconf-client { feature tls-listen {
uses restconf-client; if-feature listen;
description description
"Top-level container for RESTCONF client configuration."; "The 'tls-listen' feature indicates that the RESTCONF client
} supports opening a port to listen for incoming RESTCONF
grouping restconf-client { server call-home TLS connections. This feature exists as
description TLS might not be a mandatory to implement transport in the
"Top-level grouping for RESTCONF client configuration."; future.";
reference
"RFC 8071: NETCONF Call Home and RESTCONF Call Home";
}
container initiate { container restconf-client {
if-feature initiate; uses restconf-client;
description description
"Configures client initiating underlying TCP connections."; "Top-level container for RESTCONF client configuration.";
list restconf-server { }
key name;
min-elements 1; grouping restconf-client {
description
"Top-level grouping for RESTCONF client configuration.";
container initiate {
if-feature initiate;
presence "Enables client to initiate TCP connections";
description description
"List of RESTCONF servers the RESTCONF client is to initiate "Configures client initiating underlying TCP connections.";
connections to in parallel."; list restconf-server {
leaf name { key name;
type string; min-elements 1;
description
"An arbitrary name for the RESTCONF server.";
}
container endpoints {
description description
"Container for the list of endpoints."; "List of RESTCONF servers the RESTCONF client is to
list endpoint { initiate connections to in parallel.";
key name;
min-elements 1; leaf name {
ordered-by user; type string;
description description
"A non-empty user-ordered list of endpoints for this "An arbitrary name for the RESTCONF server.";
RESTCONF client to try to connect to in sequence. }
Defining more than one enables high-availability."; container endpoints {
leaf name { description
type string; "Container for the list of endpoints.";
description list endpoint {
"An arbitrary name for this endpoint."; key name;
} min-elements 1;
choice transport { ordered-by user;
mandatory true;
description description
"Selects between available transports. This is a "A non-empty user-ordered list of endpoints for this
'choice' statement so as to support additional RESTCONF client to try to connect to in sequence.
transport options to be augmented in."; Defining more than one enables high-availability.";
case tls { leaf name {
if-feature tls-initiate; type string;
container tls { description
description "An arbitrary name for this endpoint.";
"Specifies TLS-specific transport configuration."; }
leaf address { choice transport {
type inet:host; mandatory true;
mandatory true; description
description "Selects between available transports. This is a
"The IP address or hostname of the endpoint. 'choice' statement so as to support additional
If a domain name is configured, then the DNS transport options to be augmented in.";
resolution should happen on each usage attempt. case tls {
If the the DNS resolution results in multiple if-feature tls-initiate;
IP addresses, the IP addresses will be tried container tls {
according to local preference order until a
connection has been established or until all
IP addresses have failed.";
}
leaf port {
type inet:port-number;
default 443;
description description
"The IP port for this endpoint. The RESTCONF "Specifies TLS-specific transport
client will use the IANA-assigned well-known configuration.";
port for 'https' (443) if no value is leaf address {
specified."; type inet:host;
}
uses ts:tls-client-grouping {
refine "client-identity/auth-type" {
mandatory true; mandatory true;
description description
"RESTCONF clients MUST pass some authentication "The IP address or hostname of the endpoint.
credentials."; If a domain name is configured, then the
DNS resolution should happen on each usage
attempt. If the the DNS resolution results
in multiple IP addresses, the IP addresses
will be tried according to local preference
order until a connection has been established
or until all IP addresses have failed.";
}
leaf port {
type inet:port-number;
default 443;
description
"The IP port for this endpoint. The RESTCONF
client will use the IANA-assigned well-known
port for 'https' (443) if no value is
specified.";
}
uses ts:tls-client-grouping {
refine "client-identity/auth-type" {
mandatory true;
description
"RESTCONF clients MUST pass some
authentication credentials.";
}
} }
} }
} } // end tls
} // end tls } // end transport
} // end transport container connection-type {
container connection-type {
description
"Indicates the kind of connection to use.";
choice connection-type {
description description
"Selects between available connection types."; "Indicates the kind of connection to use.";
case persistent-connection { choice connection-type {
container persistent { default persistent-connection;
presence true; description
description "Selects between available connection types.";
"Maintain a persistent connection to the RESTCONF case persistent-connection {
server. If the connection goes down, immediately container persistent {
start trying to reconnect to it, using the presence
reconnection strategy. This connection type "Indicates that a persistent connection is
minimizes any RESTCONF server to RESTCONF client to be maintained.";
data-transfer delay, albeit at the expense of
holding resources longer.";
leaf idle-timeout {
type uint32;
units "seconds";
default 86400; // one day;
description description
"Specifies the maximum number of seconds that "Maintain a persistent connection to the
the underlying TLS session may remain idle. RESTCONF server. If the connection goes down,
A TLS session will be dropped if it is idle immediately start trying to reconnect to it,
for an interval longer than this number of using the reconnection strategy. This
seconds. If set to zero, then the client connection type minimizes any RESTCONF server
will never drop a session because it is idle. to RESTCONF client data-transfer delay, albeit
Sessions that have a notification subscription at the expense of holding resources longer.";
active are never dropped."; leaf idle-timeout {
type uint32;
units "seconds";
default 86400; // one day;
description
"Specifies the maximum number of seconds
that the underlying TLS session may remain
idle. A TLS session will be dropped if it
is idle for an interval longer than this
number of seconds. If set to zero, then
the client will never drop a session
because it is idle. Sessions that have
a notification subscription active are
never dropped.";
}
container keep-alives {
description
"Configures the keep-alive policy, to
proactively test the aliveness of the TLS
server. An unresponsive TLS server will
be dropped after approximately max-attempts
* max-wait seconds.";
reference
"RFC 8071: NETCONF Call Home and RESTCONF
Call Home, Section 3.1, item S6";
leaf max-wait {
type uint16 {
range "1..max";
}
units seconds;
default 30;
description
"Sets the amount of time in seconds after
which if no data has been received from
the TLS server, a TLS-level message will
be sent to test the aliveness of the TLS
server.";
}
leaf max-attempts {
type uint8;
default 3;
description
"Sets the maximum number of sequential
keep-alive messages that can fail to
obtain a response from the TLS server
before assuming the TLS server is no
longer alive.";
}
}
} }
container keep-alives { }
case periodic-connection {
container periodic {
presence
"Indicates that a periodic connection is to be
maintained.";
description description
"Configures the keep-alive policy, to "Periodically connect to the RESTCONF server,
proactively test the aliveness of the TLS so that, e.g., the RESTCONF client can
server. An unresponsive TLS server will be collect data (logs) from the RESTCONF server.
dropped after approximately max-attempts * Once the connection is closed, for whatever
max-wait seconds."; reason, the RESTCONF client will restart its
reference timer until the next connection.";
"RFC 8071: NETCONF Call Home and RESTCONF Call leaf idle-timeout {
Home, Section 3.1, item S6"; type uint16;
leaf max-wait { units "seconds";
default 300; // five minutes
description
"Specifies the maximum number of seconds
that the underlying TLS session may remain
idle. A TLS session will be dropped if it
is idle for an interval longer than this
number of seconds If set to zero, then the
server will never drop a session because
it is idle.";
}
leaf reconnect-timeout {
type uint16 { type uint16 {
range "1..max"; range "1..max";
} }
units seconds; units minutes;
default 30; default 60;
description
"Sets the amount of time in seconds after
which if no data has been received from
the TLS server, a TLS-level message will
be sent to test the aliveness of the TLS
server.";
}
leaf max-attempts {
type uint8;
default 3;
description description
"Sets the maximum number of sequential keep- "Sets the maximum amount of unconnected time
alive messages that can fail to obtain a the RESTCONF client will wait before re-
response from the TLS server before assuming establishing a connection to the RESTCONF
the TLS server is no longer alive."; server. The RESTCONF client may initiate
a connection before this time if desired
(e.g., to set configuration).";
} }
} }
} } // end periodic-connection
} // end connection-type
} } // end connection-type
case periodic-connection { container reconnect-strategy {
container periodic { description
presence true; "The reconnection strategy directs how a RESTCONF
description client reconnects to a RESTCONF server, after
"Periodically connect to the RESTCONF server, so discovering its connection to the server has
that, e.g., the RESTCONF client can collect data dropped, even if due to a reboot. The RESTCONF
(logs) from the RESTCONF server. Once the client starts with the specified endpoint and
connection is closed, for whatever reason, the tries to connect to it max-attempts times before
RESTCONF client will restart its timer until the trying the next endpoint in the list (round
next connection."; robin).";
leaf idle-timeout { leaf start-with {
type uint16; type enumeration {
units "seconds"; enum first-listed {
default 300; // five minutes
description description
"Specifies the maximum number of seconds that "Indicates that reconnections should start
the underlying TLS session may remain idle. A with the first endpoint listed.";
TLS session will be dropped if it is idle for
an interval longer than this number of seconds
If set to zero, then the server will never
drop a session because it is idle.";
} }
leaf reconnect-timeout { enum last-connected {
type uint16 {
range "1..max";
}
units minutes;
default 60;
description description
"Sets the maximum amount of unconnected time "Indicates that reconnections should start
the RESTCONF client will wait before re- with the endpoint last connected to. If
establishing a connection to the RESTCONF no previous connection has ever been
server. The RESTCONF client may initiate a established, then the first endpoint
connection before this time if desired (e.g., configured is used. RESTCONF clients
to set configuration)."; SHOULD be able to remember the last
endpoint connected to across reboots.";
} }
} }
} // end periodic-connection default first-listed;
} // end connection-type description
} // end connection-type "Specifies which of the RESTCONF server's
container reconnect-strategy { endpoints the RESTCONF client should start
description with when trying to connect to the RESTCONF
"The reconnection strategy directs how a RESTCONF client server.";
reconnects to a RESTCONF server, after discovering its
connection to the server has dropped, even if due to a
reboot. The RESTCONF client starts with the specified
endpoint and tries to connect to it max-attempts times
before trying the next endpoint in the list (round
robin).";
leaf start-with {
type enumeration {
enum first-listed {
description
"Indicates that reconnections should start with
the first endpoint listed.";
}
enum last-connected {
description
"Indicates that reconnections should start with
the endpoint last connected to. If no previous
connection has ever been established, then the
first endpoint configured is used. RESTCONF
clients SHOULD be able to remember the last
endpoint connected to across reboots.";
}
} }
default first-listed; leaf max-attempts {
description type uint8 {
"Specifies which of the RESTCONF server's endpoints range "1..max";
the RESTCONF client should start with when trying }
to connect to the RESTCONF server."; default 3;
} description
leaf max-attempts { "Specifies the number times the RESTCONF client
type uint8 { tries to connect to a specific endpoint before
range "1..max"; moving on to the next endpoint in the list
(round robin).";
} }
default 3; } // end reconnect-strategy
description } // end endpoint
"Specifies the number times the RESTCONF client tries } // end endpoints
to connect to a specific endpoint before moving on } // end restconf-server
to the next endpoint in the list (round robin)."; } // end initiate
}
} // end reconnect-strategy
} // end endpoint
} // end endpoints
} // end restconf-server
} // end initiate
container listen { container listen {
if-feature listen; if-feature listen;
description presence "Enables client to accept call-home connections";
"Configures client accepting call-home TCP connections.";
leaf idle-timeout {
type uint16;
units "seconds";
default 3600; // one hour
description
"Specifies the maximum number of seconds that an underlying
TLS session may remain idle. A TLS session will be dropped
if it is idle for an interval longer than this number of
seconds. If set to zero, then the server will never drop
a session because it is idle. Sessions that have a
notification subscription active are never dropped.";
}
list endpoint {
key name;
description description
"List of endpoints to listen for RESTCONF connections."; "Configures client accepting call-home TCP connections.";
leaf name {
type string; leaf idle-timeout {
type uint16;
units "seconds";
default 3600; // one hour
description description
"An arbitrary name for the RESTCONF listen endpoint."; "Specifies the maximum number of seconds that an
underlying TLS session may remain idle. A TLS session
will be dropped if it is idle for an interval longer
than this number of seconds. If set to zero, then
the server will never drop a session because it is
idle. Sessions that have a notification subscription
active are never dropped.";
} }
choice transport {
mandatory true; list endpoint {
key name;
min-elements 1;
description description
"Selects between available transports. This is a 'choice' "List of endpoints to listen for RESTCONF connections.";
statement so as to support additional transport options leaf name {
to be augmented in."; type string;
case tls { description
if-feature tls-listen; "An arbitrary name for the RESTCONF listen endpoint.";
container tls { }
description choice transport {
"TLS-specific listening configuration for inbound mandatory true;
connections."; description
leaf address { "Selects between available transports. This is a
type inet:ip-address; 'choice' statement so as to support additional
description transport options to be augmented in.";
"The IP address to listen on for incoming call-home case tls {
connections. The RESTCONF client will listen on if-feature tls-listen;
all configured interfaces if no value is specified. container tls {
INADDR_ANY (0.0.0.0) or INADDR6_ANY (0:0:0:0:0:0:0:0
a.k.a. ::) MUST be used when the server is to listen
on all IPv4 or IPv6 addresses, respectively.";
}
leaf port {
type inet:port-number;
default 4336;
description description
"The port number to listen on for call-home "TLS-specific listening configuration for inbound
connections. The RESTCONF client will listen connections.";
on the IANA-assigned well-known port for leaf address {
'restconf-ch-tls' (4336) if no value is type inet:ip-address;
specified.";
}
uses ts:tls-client-grouping {
refine "client-identity/auth-type" {
mandatory true;
description description
"RESTCONF clients MUST pass some authentication "The IP address to listen on for incoming call-
credentials."; home connections. The RESTCONF client will
listen on all configured interfaces if no
value is specified. INADDR_ANY (0.0.0.0) or
INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST
be used when the server is to listen on all
IPv4 or IPv6 addresses, respectively.";
}
leaf port {
type inet:port-number;
default 4336;
description
"The port number to listen on for call-home
connections. The RESTCONF client will listen
on the IANA-assigned well-known port for
'restconf-ch-tls' (4336) if no value is
specified.";
}
uses ts:tls-client-grouping {
refine "client-identity/auth-type" {
mandatory true;
description
"RESTCONF clients MUST pass some authentication
credentials.";
}
} }
} }
} }
} } // end transport
} // end transport } // end endpoint
} // end endpoint } // end listen
} // end listen } // end restconf-client
} // end restconf-client }
} <CODE ENDS>
<CODE ENDS>
3. The RESTCONF Server Model 3. The RESTCONF Server Model
The RESTCONF server model presented in this section supports servers The RESTCONF server model presented in this section supports servers
both listening for connections as well as initiating call-home both listening for connections as well as initiating call-home
connections. connections.
All private keys and trusted certificates are held in the keystore All private keys and trusted certificates are held in the keystore
model defined in [I-D.ietf-netconf-keystore]. model defined in [I-D.ietf-netconf-keystore].
YANG feature statements are used to enable implementations to YANG feature statements are used to enable implementations to
advertise which parts of the model the RESTCONF server supports. advertise which parts of the model the RESTCONF server supports.
3.1. Tree Diagram 3.1. Tree Diagram
The following tree diagram [I-D.ietf-netmod-yang-tree-diagrams] The following tree diagram [RFC8340] provides an overview of the data
provides an overview of the data model for the "ietf-restconf-client" model for the "ietf-restconf-client" module. Just the container is
module. Just the container is displayed below, but there is also a displayed below, but there is also a reuable grouping by the same
reuable grouping by the same name that the container is using. name that the container is using.
[ note: '\' line wrapping for formatting only]
module: ietf-restconf-server
+--rw restconf-server
+--rw listen {listen}?
| +--rw endpoint* [name]
| +--rw name string
| +--rw (transport)
| +--:(tls) {tls-listen}?
| +--rw tls
| +--rw address? inet:ip-address
| +--rw port? inet:port-number
| +--rw server-identity
| | +--rw algorithm?
| | | identityref
| | +--rw private-key?
| | | union
| | +--rw public-key?
| | | binary
| | +---x generate-private-key
| | | +---w input
| | | +---w algorithm identityref
| | +--rw certificates
| | | +--rw certificate* [name]
| | | +--rw name string
| | | +--rw value? binary
| | +---x generate-certificate-signing-request
| | +---w input
| | | +---w subject binary
| | | +---w attributes? binary
| | +--ro output
| | +--ro certificate-signing-request
| | binary
| +--rw client-auth
| | +--rw pinned-ca-certs?
| | | ks:pinned-certificates
| | +--rw pinned-client-certs?
| | | ks:pinned-certificates
| | +--rw cert-maps
| | +--rw cert-to-name* [id]
| | +--rw id uint32
| | +--rw fingerprint
| | | x509c2n:tls-fingerprint
| | +--rw map-type identityref
| | +--rw name string
| +--rw hello-params
| {tls-server-hello-params-config}?
| +--rw tls-versions
| | +--rw tls-version* identityref
| +--rw cipher-suites
| +--rw cipher-suite* identityref
+--rw call-home {call-home}?
+--rw restconf-client* [name]
+--rw name string
+--rw endpoints
| +--rw endpoint* [name]
| +--rw name string
| +--rw (transport)
| +--:(tls) {tls-call-home}?
| +--rw tls
| +--rw address inet:host
| +--rw port? inet:port-number\
| +--rw server-identity
| | +--rw algorithm?
| | | identityref
| | +--rw private-key?
| | | union
| | +--rw public-key?
| | | binary
| | +---x generate-private-key
| | | +---w input
| | | +---w algorithm identityref
| | +--rw certificates
| | | +--rw certificate* [name]
| | | +--rw name string
| | | +--rw value? binary
| | +---x generate-certificate-signing-req\
uest
| | +---w input
| | | +---w subject binary
| | | +---w attributes? binary
| | +--ro output
| | +--ro certificate-signing-reques\
t
| | binary
| +--rw client-auth
| | +--rw pinned-ca-certs?
| | | ks:pinned-certificates
| | +--rw pinned-client-certs?
| | | ks:pinned-certificates
| | +--rw cert-maps
| | +--rw cert-to-name* [id]
| | +--rw id uint32
| | +--rw fingerprint
| | | x509c2n:tls-fingerprint
| | +--rw map-type identityref\
| | +--rw name string [Note: '\' line wrapping for formatting only]
| +--rw hello-params
| {tls-server-hello-params-config}?\
| +--rw tls-versions module: ietf-restconf-server
| | +--rw tls-version* identityref +--rw restconf-server
| +--rw cipher-suites +--rw listen! {listen}?
| +--rw cipher-suite* identityref | +--rw endpoint* [name]
+--rw connection-type | +--rw name string
| +--rw (connection-type)? | +--rw (transport)
| +--:(persistent-connection) | +--:(tls) {tls-listen}?
| | +--rw persistent! | +--rw tls
| | +--rw idle-timeout? uint32 | +--rw address? inet:ip-address
| | +--rw keep-alives | +--rw port? inet:port-number
| | +--rw max-wait? uint16 | +--rw server-identity
| | +--rw max-attempts? uint8 | | +--rw (local-or-keystore)
| +--:(periodic-connection) | | +--:(local)
| +--rw periodic! | | | +--rw algorithm
| +--rw idle-timeout? uint16 | | | | ct:key-algorithm-ref
| +--rw reconnect-timeout? uint16 | | | +--rw public-key binary
+--rw reconnect-strategy | | | +--rw private-key union
+--rw start-with? enumeration | | | +--rw cert
+--rw max-attempts? uint8 | | | | ct:end-entity-cert-cms
| | | +---n certificate-expiration
| | | +-- expiration-date?
| | | yang:date-and-time
| | +--:(keystore) {keystore-implemented}?
| | +--rw reference
| | ks:asymmetric-key-certificate-r\
ef
| +--rw client-auth
| | +--rw pinned-ca-certs?
| | | ta:pinned-certificates-ref
| | +--rw pinned-client-certs?
| | | ta:pinned-certificates-ref
| | +--rw cert-maps
| | +--rw cert-to-name* [id]
| | +--rw id uint32
| | +--rw fingerprint
| | | x509c2n:tls-fingerprint
| | +--rw map-type identityref
| | +--rw name string
| +--rw hello-params
| {tls-server-hello-params-config}?
| +--rw tls-versions
| | +--rw tls-version* identityref
| +--rw cipher-suites
| +--rw cipher-suite* identityref
+--rw call-home! {call-home}?
+--rw restconf-client* [name]
+--rw name string
+--rw endpoints
| +--rw endpoint* [name]
| +--rw name string
| +--rw (transport)
| +--:(tls) {tls-call-home}?
| +--rw tls
| +--rw address inet:host
| +--rw port? inet:port-number
| +--rw server-identity
| | +--rw (local-or-keystore)
| | +--:(local)
| | | +--rw algorithm
| | | | ct:key-algorithm-ref
| | | +--rw public-key
| | | | binary
| | | +--rw private-key
| | | | union
| | | +--rw cert
| | | | ct:end-entity-cert-cms
| | | +---n certificate-expiration
| | | +-- expiration-date?
| | | yang:date-and-time
| | +--:(keystore) {keystore-implemented\
}?
| | +--rw reference
| | ks:asymmetric-key-certifi\
cate-ref
| +--rw client-auth
| | +--rw pinned-ca-certs?
| | | ta:pinned-certificates-ref
| | +--rw pinned-client-certs?
| | | ta:pinned-certificates-ref
| | +--rw cert-maps
| | +--rw cert-to-name* [id]
| | +--rw id uint32
| | +--rw fingerprint
| | | x509c2n:tls-fingerprint
| | +--rw map-type identityref
| | +--rw name string
| +--rw hello-params
| {tls-server-hello-params-config}?
| +--rw tls-versions
| | +--rw tls-version* identityref
| +--rw cipher-suites
| +--rw cipher-suite* identityref
+--rw connection-type
| +--rw (connection-type)?
| +--:(persistent-connection)
| | +--rw persistent!
| | +--rw idle-timeout? uint32
| | +--rw keep-alives
| | +--rw max-wait? uint16
| | +--rw max-attempts? uint8
| +--:(periodic-connection)
| +--rw periodic!
| +--rw idle-timeout? uint16
| +--rw reconnect-timeout? uint16
+--rw reconnect-strategy
+--rw start-with? enumeration
+--rw max-attempts? uint8
3.2. Example Usage 3.2. Example Usage
The following example illustrates configuring a RESTCONF server to The following example illustrates configuring a RESTCONF server to
listen for RESTCONF client connections, as well as configuring call- listen for RESTCONF client connections, as well as configuring call-
home to one RESTCONF client. home to one RESTCONF client.
This example is consistent with the examples presented in Section 2.2 This example is consistent with the examples presented in Section 2.2
of [I-D.ietf-netconf-keystore]. of [I-D.ietf-netconf-keystore].
[ note: '\' line wrapping for formatting only] [Note: '\' line wrapping for formatting only]
<restconf-server <restconf-server
xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-server" xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-server"
xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name">\ xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name"\
>
<!-- listening for TLS (HTTPS) connections --> <!-- endpoints to listen for RESTCONF connections on -->
<listen> <listen>
<endpoint> <endpoint>
<name>netconf/tls</name> <name>netconf/tls</name>
<tls> <tls>
<address>11.22.33.44</address> <address>11.22.33.44</address>
<server-identity> <server-identity>
<algorithm xmlns:ks="urn:ietf:params:xml:ns:yang:ietf-keyst\ <algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-cryp\
ore">ks:secp521r1</algorithm> to-types">ct:secp521r1</algorithm>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
<public-key>base64encodedvalue==</public-key> <public-key>base64encodedvalue==</public-key>
<certificates> <cert>base64encodedvalue==</cert>
<certificate> </server-identity>
<name>domain certificate</name> <client-auth>
<value>base64encodedvalue==</value> <pinned-ca-certs>explicitly-trusted-client-ca-certs</pinne\
</certificate> d-ca-certs>
<pinned-client-certs>explicitly-trusted-client-certs</pinn\
ed-client-certs>
<cert-maps>
<cert-to-name>
<id>1</id>
<fingerprint>11:0A:05:11:00</fingerprint>
<map-type>x509c2n:san-any</map-type>
</cert-to-name>
<cert-to-name>
<id>2</id>
<fingerprint>B3:4F:A1:8C:54</fingerprint>
<map-type>x509c2n:specified</map-type>
<name>scooby-doo</name>
</cert-to-name>
</cert-maps>
</client-auth>
</tls>
</endpoint>
</listen>
</certificates> <!-- call home to a RESTCONF client with two endpoints -->
</server-identity> <call-home>
<client-auth> <restconf-client>
<pinned-ca-certs>deployment-specific-ca-certs</pinned-ca-ce\ <name>config-manager</name>
rts> <endpoints>
<pinned-client-certs>explicitly-trusted-client-certs</pinne\ <endpoint>
d-client-certs> <name>east-data-center</name>
<cert-maps> <tls>
<cert-to-name> <address>22.33.44.55</address>
<id>1</id> <server-identity>
<fingerprint>11:0A:05:11:00</fingerprint> <algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-\
<map-type>x509c2n:san-any</map-type> crypto-types">ct:secp521r1</algorithm>
</cert-to-name> <private-key>base64encodedvalue==</private-key>
<cert-to-name> <public-key>base64encodedvalue==</public-key>
<id>2</id> <cert>base64encodedvalue==</cert>
<fingerprint>B3:4F:A1:8C:54</fingerprint> </server-identity>
<map-type>x509c2n:specified</map-type> <client-auth>
<name>scooby-doo</name> <pinned-ca-certs>explicitly-trusted-client-ca-certs</p\
</cert-to-name> inned-ca-certs>
</cert-maps> <pinned-client-certs>explicitly-trusted-client-certs</\
</client-auth> pinned-client-certs>
</tls> <cert-maps>
</endpoint> <cert-to-name>
</listen> <id>1</id>
<fingerprint>11:0A:05:11:00</fingerprint>
<map-type>x509c2n:san-any</map-type>
</cert-to-name>
<cert-to-name>
<id>2</id>
<fingerprint>B3:4F:A1:8C:54</fingerprint>
<map-type>x509c2n:specified</map-type>
<name>scooby-doo</name>
</cert-to-name>
<!-- calling home to a RESTCONF client --> </cert-maps>
<call-home> </client-auth>
<restconf-client> </tls>
<name>config-manager</name> </endpoint>
<endpoints> <endpoint>
<endpoint> <name>west-data-center</name>
<name>east-data-center</name> <tls>
<tls> <address>33.44.55.66</address>
<address>22.33.44.55</address> <server-identity>
<server-identity> <algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-\
<algorithm xmlns:ks="urn:ietf:params:xml:ns:yang:ietf-k\ crypto-types">ct:secp521r1</algorithm>
eystore">ks:secp521r1</algorithm> <private-key>base64encodedvalue==</private-key>
<private-key>base64encodedvalue==</private-key> <public-key>base64encodedvalue==</public-key>
<public-key>base64encodedvalue==</public-key> <cert>base64encodedvalue==</cert>
<certificates> </server-identity>
<certificate> <client-auth>
<name>domain certificate</name> <pinned-ca-certs>explicitly-trusted-client-ca-certs</p\
<value>base64encodedvalue==</value> inned-ca-certs>
</certificate> <pinned-client-certs>explicitly-trusted-client-certs</\
</certificates> pinned-client-certs>
</server-identity> <cert-maps>
<client-auth> <cert-to-name>
<pinned-ca-certs>deployment-specific-ca-certs</pinned-c\ <id>1</id>
<fingerprint>11:0A:05:11:00</fingerprint>
<map-type>x509c2n:san-any</map-type>
</cert-to-name>
<cert-to-name>
<id>2</id>
<fingerprint>B3:4F:A1:8C:54</fingerprint>
<map-type>x509c2n:specified</map-type>
<name>scooby-doo</name>
</cert-to-name>
</cert-maps>
</client-auth>
</tls>
</endpoint>
</endpoints>
<connection-type>
<periodic>
<idle-timeout>300</idle-timeout>
<reconnect-timeout>60</reconnect-timeout>
</periodic>
</connection-type>
<reconnect-strategy>
<start-with>last-connected</start-with>
<max-attempts>3</max-attempts>
</reconnect-strategy>
</restconf-client>
a-certs> </call-home>
<pinned-client-certs>explicitly-trusted-client-certs</p\ </restconf-server>
inned-client-certs>
<cert-maps>
<cert-to-name>
<id>1</id>
<fingerprint>11:0A:05:11:00</fingerprint>
<map-type>x509c2n:san-any</map-type>
</cert-to-name>
<cert-to-name>
<id>2</id>
<fingerprint>B3:4F:A1:8C:54</fingerprint>
<map-type>x509c2n:specified</map-type>
<name>scooby-doo</name>
</cert-to-name>
</cert-maps>
</client-auth>
</tls>
</endpoint>
<endpoint>
<name>west-data-center</name>
<tls>
<address>33.44.55.66</address>
<server-identity>
<algorithm xmlns:ks="urn:ietf:params:xml:ns:yang:ietf-k\
eystore">ks:secp521r1</algorithm>
<private-key>base64encodedvalue==</private-key>
<public-key>base64encodedvalue==</public-key>
<certificates>
<certificate>
<name>domain certificate</name>
<value>base64encodedvalue==</value>
</certificate>
</certificates>
</server-identity>
<client-auth>
<pinned-ca-certs>deployment-specific-ca-certs</pinned-c\
a-certs>
<pinned-client-certs>explicitly-trusted-client-certs</p\
inned-client-certs>
<cert-maps>
<cert-to-name>
<id>1</id>
<fingerprint>11:0A:05:11:00</fingerprint>
<map-type>x509c2n:san-any</map-type>
</cert-to-name>
<cert-to-name>
<id>2</id>
<fingerprint>B3:4F:A1:8C:54</fingerprint>
<map-type>x509c2n:specified</map-type>
<name>scooby-doo</name>
</cert-to-name>
</cert-maps>
</client-auth>
</tls>
</endpoint>
</endpoints>
<connection-type>
<periodic>
<idle-timeout>300</idle-timeout>
<reconnect-timeout>60</reconnect-timeout>
</periodic>
</connection-type>
<reconnect-strategy>
<start-with>last-connected</start-with>
<max-attempts>3</max-attempts>
</reconnect-strategy>
</restconf-client>
</call-home>
</restconf-server>
3.3. YANG Module 3.3. YANG Module
This YANG module imports YANG types from [RFC6991] and [RFC7407], and This YANG module has normative references to [RFC6991], [RFC7407],
groupings from [I-D.ietf-netconf-tls-client-server]. [RFC8040], [RFC8071], and [I-D.ietf-netconf-tls-client-server].
<CODE BEGINS> file "ietf-restconf-server@2017-10-30.yang" <CODE BEGINS> file "ietf-restconf-server@2018-06-04.yang"
module ietf-restconf-server { module ietf-restconf-server {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-server"; namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-server";
prefix "rcs"; prefix "rcs";
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
import ietf-x509-cert-to-name { import ietf-x509-cert-to-name {
prefix x509c2n; prefix x509c2n;
reference reference
"RFC 7407: A YANG Data Model for SNMP Configuration"; "RFC 7407: A YANG Data Model for SNMP Configuration";
} }
import ietf-tls-server {
prefix ts;
revision-date 2017-10-30; // stable grouping definitions
reference
"RFC ZZZZ: YANG Groupings for TLS Clients and TLS Servers";
}
organization import ietf-tls-server {
"IETF NETCONF (Network Configuration) Working Group"; prefix ts;
revision-date 2018-06-04; // stable grouping definitions
reference
"RFC ZZZZ: YANG Groupings for TLS Clients and TLS Servers";
}
contact organization
"WG Web: <http://tools.ietf.org/wg/netconf/> "IETF NETCONF (Network Configuration) Working Group";
WG List: <mailto:netconf@ietf.org>
Author: Kent Watsen contact
<mailto:kwatsen@juniper.net> "WG Web: <http://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Author: Gary Wu Author: Kent Watsen
<mailto:garywu@cisco.com> <mailto:kwatsen@juniper.net>
Author: Juergen Schoenwaelder Author: Gary Wu
<mailto:j.schoenwaelder@jacobs-university.de>"; <mailto:garywu@cisco.com>
description Author: Juergen Schoenwaelder
"This module contains a collection of YANG definitions for <mailto:j.schoenwaelder@jacobs-university.de>";
configuring RESTCONF servers.
Copyright (c) 2017 IETF Trust and the persons identified as description
authors of the code. All rights reserved. "This module contains a collection of YANG definitions for
configuring RESTCONF servers.
Redistribution and use in source and binary forms, with or Copyright (c) 2017 IETF Trust and the persons identified as
without modification, is permitted pursuant to, and subject authors of the code. All rights reserved.
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see Redistribution and use in source and binary forms, with or
the RFC itself for full legal notices."; without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
revision "2017-10-30" { This version of this YANG module is part of RFC XXXX; see
description the RFC itself for full legal notices.";
"Initial version";
reference
"RFC XXXX: RESTCONF Client and Server Models";
}
// Features
feature listen { revision "2018-06-04" {
description description
"The 'listen' feature indicates that the RESTCONF server "Initial version";
supports opening a port to accept RESTCONF client connections reference
using at least one transport (e.g., TLS, etc.)."; "RFC XXXX: RESTCONF Client and Server Models";
} }
feature tls-listen { // Features
if-feature listen;
description
"The 'tls-listen' feature indicates that the RESTCONF server
supports opening a port to listen for incoming RESTCONF
client connections. This feature exists as TLS might not
be a mandatory-to-implement transport in the future.";
reference
"RFC 8040: RESTCONF Protocol";
}
feature call-home { feature listen {
description description
"The 'call-home' feature indicates that the RESTCONF server "The 'listen' feature indicates that the RESTCONF server
supports initiating RESTCONF call home connections to RESTCONF supports opening a port to accept RESTCONF client connections
clients using at least one transport (e.g., TLS, etc.)."; using at least one transport (e.g., TLS, etc.).";
reference }
"RFC 8071: NETCONF Call Home and RESTCONF Call Home";
}
feature tls-call-home { feature tls-listen {
if-feature call-home; if-feature listen;
description description
"The 'tls-call-home' feature indicates that the RESTCONF server "The 'tls-listen' feature indicates that the RESTCONF server
supports initiating connections to RESTCONF clients. This supports opening a port to listen for incoming RESTCONF
feature exists as TLS might not be a mandatory-to-implement client connections. This feature exists as TLS might not
transport in the future."; be a mandatory to implement transport in the future.";
reference reference
"RFC 8071: NETCONF Call Home and RESTCONF Call Home"; "RFC 8040: RESTCONF Protocol";
} }
feature call-home {
description
"The 'call-home' feature indicates that the RESTCONF
server supports initiating RESTCONF call home connections
to RESTCONF clients using at least one transport (e.g.,
TLS, etc.).";
reference
"RFC 8071: NETCONF Call Home and RESTCONF Call Home";
}
container restconf-server { feature tls-call-home {
uses restconf-server; if-feature call-home;
description description
"Top-level container for RESTCONF server configuration."; "The 'tls-call-home' feature indicates that the RESTCONF
} server supports initiating connections to RESTCONF clients.
This feature exists as TLS might not be a mandatory to
implement transport in the future.";
reference
"RFC 8071: NETCONF Call Home and RESTCONF Call Home";
}
grouping restconf-server { container restconf-server {
description uses restconf-server;
"Top-level grouping for RESTCONF server configuration."; description
"Top-level container for RESTCONF server configuration.";
}
container listen { grouping restconf-server {
if-feature listen; description
description "Top-level grouping for RESTCONF server configuration.";
"Configures listen behavior";
list endpoint {
key name;
description
"List of endpoints to listen for RESTCONF connections.";
leaf name {
type string;
description
"An arbitrary name for the RESTCONF listen endpoint.";
}
choice transport {
mandatory true;
description
"Selects between available transports. This is a 'choice'
statement so as to support additional transport options
to be augmented in.";
case tls {
if-feature tls-listen;
container tls {
description
"TLS-specific listening configuration for inbound
connections.";
leaf address {
type inet:ip-address;
description
"The IP address to listen on for incoming connections.
The RESTCONF server will listen on all configured
interfaces if no value is specified. INADDR_ANY
(0.0.0.0) or INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::)
MUST be used when the server is to listen on all IPv4
or IPv6 addresses, respectively.";
}
leaf port {
type inet:port-number;
default 443;
description
"The local port number to listen on. If no value is
specified, the IANA-assigned port value for 'https'
(443) is used.";
}
uses ts:tls-server-grouping {
refine "client-auth" {
must 'pinned-ca-certs or pinned-client-certs';
description
"RESTCONF servers MUST be able to validate
clients.";
}
augment "client-auth" {
description
"Augments in the cert-to-name structure,
so the RESTCONF server can map TLS-layer
client certificates to RESTCONF usernames.";
container cert-maps {
uses x509c2n:cert-to-name;
description
"The cert-maps container is used by a TLS-based
RESTCONF server to map the RESTCONF client's
presented X.509 certificate to a RESTCONF
username. If no matching and valid
cert-to-name list entry can be found, then
the RESTCONF server MUST close the connection,
and MUST NOT accept RESTCONF messages over
it.";
reference
"RFC 7407: A YANG Data Model for SNMP
Configuration.";
}
}
}
} // end tls container
} // end tls case
} // end transport
} // end endpoint
} // end listen
container call-home { container listen {
if-feature call-home; if-feature listen;
description presence "Enables server to listen for TCP connections";
"Configures call-home behavior"; description "Configures listen behavior";
list restconf-client { list endpoint {
key name; key name;
description min-elements 1;
"List of RESTCONF clients the RESTCONF server is to description
initiate call-home connections to in parallel."; "List of endpoints to listen for RESTCONF connections.";
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for the remote RESTCONF client."; "An arbitrary name for the RESTCONF listen endpoint.";
} }
container endpoints { choice transport {
description mandatory true;
"Container for the list of endpoints."; description
list endpoint { "Selects between available transports. This is a
key name; 'choice' statement so as to support additional
min-elements 1; transport options to be augmented in.";
ordered-by user; case tls {
description if-feature tls-listen;
"User-ordered list of endpoints for this RESTCONF container tls {
client. Defining more than one enables high- description
availability."; "TLS-specific listening configuration for inbound
leaf name { connections.";
type string; leaf address {
description type inet:ip-address;
"An arbitrary name for this endpoint."; description
} "The IP address to listen on for incoming
choice transport { connections. The RESTCONF server will listen
mandatory true; on all configured interfaces if no value is
description specified. INADDR_ANY (0.0.0.0) or INADDR6_ANY
"Selects between available transports. This is a (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be used when
'choice' statement so as to support additional the server is to listen on all IPv4 or IPv6
transport options to be augmented in."; addresses, respectively.";
case tls { }
if-feature tls-call-home; leaf port {
container tls { type inet:port-number;
description default 443;
"Specifies TLS-specific call-home transport description
configuration."; "The local port number to listen on. If no value
leaf address { is specified, the IANA-assigned port value for
type inet:host; 'https' (443) is used.";
mandatory true; }
description uses ts:tls-server-grouping {
"The IP address or hostname of the endpoint. refine "client-auth" {
If a domain name is configured, then the DNS must 'pinned-ca-certs or pinned-client-certs';
resolution should happen on each usage attempt. description
If the DNS resolution results in multiple IP "RESTCONF servers MUST be able to validate
addresses, the IP addresses will be tried clients.";
according to local preference order until a }
connection has been established or until all augment "client-auth" {
IP addresses have failed."; description
} "Augments in the cert-to-name structure,
leaf port { so the RESTCONF server can map TLS-layer
type inet:port-number; client certificates to RESTCONF usernames.";
default 4336; container cert-maps {
description uses x509c2n:cert-to-name;
"The IP port for this endpoint. The RESTCONF description
server will use the IANA-assigned well-known "The cert-maps container is used by a TLS-
port for 'restconf-ch-tls' (4336) if no value based RESTCONF server to map the RESTCONF
is specified."; client's presented X.509 certificate to
} a RESTCONF username. If no matching and
uses ts:tls-server-grouping { valid cert-to-name list entry can be found,
refine "client-auth" { then the RESTCONF server MUST close the
connection, and MUST NOT accept RESTCONF
messages over it.";
reference
"RFC 7407: A YANG Data Model for SNMP
Configuration.";
}
}
}
} // end tls container
} // end tls case
} // end transport
} // end endpoint
} // end listen
container call-home {
if-feature call-home;
presence "Enables server to initiate TCP connections";
description "Configures call-home behavior";
list restconf-client {
key name;
min-elements 1;
description
"List of RESTCONF clients the RESTCONF server is to
initiate call-home connections to in parallel.";
leaf name {
type string;
description
"An arbitrary name for the remote RESTCONF client.";
}
container endpoints {
description
"Container for the list of endpoints.";
list endpoint {
key name;
min-elements 1;
ordered-by user;
description
"User-ordered list of endpoints for this RESTCONF
client. Defining more than one enables high-
availability.";
leaf name {
type string;
description
"An arbitrary name for this endpoint.";
}
choice transport {
mandatory true;
description
"Selects between available transports. This is a
'choice' statement so as to support additional
transport options to be augmented in.";
case tls {
if-feature tls-call-home;
container tls {
description
"Specifies TLS-specific call-home transport
configuration.";
leaf address {
type inet:host;
mandatory true;
description
"The IP address or hostname of the endpoint.
If a domain name is configured, then the
DNS resolution should happen on each usage
attempt. If the DNS resolution results in
multiple IP addresses, the IP addresses will
be tried according to local preference order
until a connection has been established or
until all IP addresses have failed.";
}
leaf port {
type inet:port-number;
default 4336;
description
"The IP port for this endpoint. The RESTCONF
server will use the IANA-assigned well-known
port for 'restconf-ch-tls' (4336) if no value
is specified.";
}
uses ts:tls-server-grouping {
refine "client-auth" {
must 'pinned-ca-certs or pinned-client-certs'; must 'pinned-ca-certs or pinned-client-certs';
description description
"RESTCONF servers MUST be able to validate "RESTCONF servers MUST be able to validate
clients."; clients.";
} }
augment "client-auth" { augment "client-auth" {
description description
"Augments in the cert-to-name structure, "Augments in the cert-to-name structure,
so the RESTCONF server can map TLS-layer so the RESTCONF server can map TLS-layer
client certificates to RESTCONF usernames."; client certificates to RESTCONF usernames.";
container cert-maps { container cert-maps {
uses x509c2n:cert-to-name; uses x509c2n:cert-to-name;
description description
"The cert-maps container is used by a "The cert-maps container is used by a
TLS-based RESTCONF server to map the TLS-based RESTCONF server to map the
RESTCONF client's presented X.509 RESTCONF client's presented X.509
certificate to a RESTCONF username. If certificate to a RESTCONF username. If
no matching and valid cert-to-name list no matching and valid cert-to-name list
entry can be found, then the RESTCONF entry can be found, then the RESTCONF
server MUST close the connection, and server MUST close the connection, and
MUST NOT accept RESTCONF messages over MUST NOT accept RESTCONF messages over
it."; it.";
reference reference
"RFC 7407: A YANG Data Model for SNMP "RFC 7407: A YANG Data Model for SNMP
Configuration."; Configuration.";
} }
} }
} }
} }
} }
} // end transport } // end transport
} // end endpoint } // end endpoint
} // end endpoints } // end endpoints
container connection-type { container connection-type {
description description
"Indicates the RESTCONF client's preference for how the "Indicates the RESTCONF client's preference for how the
RESTCONF server's connection is maintained."; RESTCONF server's connection is maintained.";
choice connection-type { choice connection-type {
description default persistent-connection;
"Selects between available connection types."; description
case persistent-connection { "Selects between available connection types.";
container persistent { case persistent-connection {
presence true; container persistent {
description presence
"Maintain a persistent connection to the RESTCONF "Indicates that a persistent connection is to be
client. If the connection goes down, immediately maintained.";
start trying to reconnect to it, using the description
reconnection strategy. "Maintain a persistent connection to the RESTCONF
client. If the connection goes down, immediately
start trying to reconnect to it, using the
reconnection strategy.
This connection type minimizes any RESTCONF client This connection type minimizes any RESTCONF
to RESTCONF server data-transfer delay, albeit at client to RESTCONF server data-transfer delay,
the expense of holding resources longer."; albeit at the expense of holding resources
leaf idle-timeout { longer.";
type uint32; leaf idle-timeout {
units "seconds"; type uint32;
default 86400; // one day; units "seconds";
description default 86400; // one day;
"Specifies the maximum number of seconds that the description
underlying TLS session may remain idle. A TLS "Specifies the maximum number of seconds that
session will be dropped if it is idle for an the underlying TLS session may remain idle.
interval longer than this number of seconds. A TLS session will be dropped if it is idle
If set to zero, then the server will never drop for an interval longer than this number of
a session because it is idle. Sessions that seconds. If set to zero, then the server
have a notification subscription active are will never drop a session because it is idle.
never dropped."; Sessions that have a notification subscription
} active are never dropped.";
container keep-alives { }
description container keep-alives {
"Configures the keep-alive policy, to proactively description
test the aliveness of the TLS client. An "Configures the keep-alive policy, to
unresponsive TLS client will be dropped after proactively test the aliveness of the TLS
approximately (max-attempts * max-wait) client. An unresponsive TLS client will
seconds."; be dropped after approximately (max-attempts
reference * max-wait) seconds.";
"RFC 8071: NETCONF Call Home and RESTCONF Call reference
Home, Section 3.1, item S6"; "RFC 8071: NETCONF Call Home and RESTCONF
leaf max-wait { Call Home, Section 3.1, item S6";
type uint16 { leaf max-wait {
range "1..max"; type uint16 {
} range "1..max";
units seconds; }
default 30; units seconds;
description default 30;
"Sets the amount of time in seconds after which description
if no data has been received from the TLS "Sets the amount of time in seconds after
client, a TLS-level message will be sent to which if no data has been received from
test the aliveness of the TLS client."; the TLS client, a TLS-level message will
} be sent to test the aliveness of the TLS
leaf max-attempts { client.";
type uint8; }
default 3; leaf max-attempts {
description type uint8;
"Sets the maximum number of sequential keep-alive default 3;
messages that can fail to obtain a response from description
the TLS client before assuming the TLS client is "Sets the maximum number of sequential keep-
no longer alive."; alive messages that can fail to obtain a
} response from the TLS client before assuming
} the TLS client is no longer alive.";
} }
} }
case periodic-connection { }
container periodic { }
presence true; case periodic-connection {
description container periodic {
"Periodically connect to the RESTCONF client, so that presence
the RESTCONF client may send requests pending for "Indicates that a periodic connection is to be
the RESTCONF server. Once the connection has been maintained.";
closed, for whatever reason, the server will restart
its timer until the next connection."; description
leaf idle-timeout { "Periodically connect to the RESTCONF client, so
type uint16; that the RESTCONF client may send requests pending
units "seconds"; for the RESTCONF server. Once the connection has
default 300; // five minutes been closed, for whatever reason, the server will
description restart its timer until the next connection.";
"Specifies the maximum number of seconds that the leaf idle-timeout {
underlying TLS session may remain idle. A TLS type uint16;
session will be dropped if it is idle for an units "seconds";
interval longer than this number of seconds. default 300; // five minutes
If set to zero, then the server will never drop description
a session because it is idle. Sessions that "Specifies the maximum number of seconds that
have a notification subscription active are the underlying TLS session may remain idle.
never dropped."; A TLS session will be dropped if it is idle
} for an interval longer than this number of
leaf reconnect-timeout { seconds. If set to zero, then the server
type uint16 { will never drop a session because it is idle.
range "1..max"; Sessions that have a notification subscription
} active are never dropped.";
units minutes; }
default 60; leaf reconnect-timeout {
description type uint16 {
"The maximum amount of unconnected time the range "1..max";
RESTCONF server will wait before re-establishing }
a connection to the RESTCONF client. The units minutes;
RESTCONF server may initiate a connection to default 60;
the RESTCONF client before this time if desired description
(e.g., to deliver a notification)."; "The maximum amount of unconnected time
} the RESTCONF server will wait before
} re-establishing a connection to the
} RESTCONF client. The RESTCONF server
} may initiate a connection to the RESTCONF
} client before this time if desired
container reconnect-strategy { (e.g., to deliver a notification).";
description }
"The reconnection strategy directs how a RESTCONF server }
reconnects to a RESTCONF client after after discovering }
its connection to the client has dropped, even if due to }
a reboot. The RESTCONF server starts with the specified }
endpoint and tries to connect to it max-attempts times container reconnect-strategy {
before trying the next endpoint in the list (round description
robin)."; "The reconnection strategy directs how a RESTCONF
leaf start-with { server reconnects to a RESTCONF client after after
type enumeration { discovering its connection to the client has dropped,
enum first-listed { even if due to a reboot. The RESTCONF server starts
description with the specified endpoint and tries to connect to
"Indicates that reconnections should start with it max-attempts times before trying the next endpoint
the first endpoint listed."; in the list (round robin).";
}
enum last-connected { leaf start-with {
description type enumeration {
"Indicates that reconnections should start with enum first-listed {
the endpoint last connected to. If no previous description
connection has ever been established, then the "Indicates that reconnections should start with
first endpoint configured is used. RESTCONF the first endpoint listed.";
servers SHOULD be able to remember the last }
endpoint connected to across reboots."; enum last-connected {
} description
} "Indicates that reconnections should start with
default first-listed; the endpoint last connected to. If no previous
description connection has ever been established, then the
"Specifies which of the RESTCONF client's endpoints the first endpoint configured is used. RESTCONF
RESTCONF server should start with when trying to connect servers SHOULD be able to remember the last
to the RESTCONF client."; endpoint connected to across reboots.";
} }
leaf max-attempts { }
type uint8 { default first-listed;
range "1..max"; description
} "Specifies which of the RESTCONF client's endpoints
default 3; the RESTCONF server should start with when trying
description to connect to the RESTCONF client.";
"Specifies the number times the RESTCONF server tries to }
connect to a specific endpoint before moving on to the leaf max-attempts {
next endpoint in the list (round robin)."; type uint8 {
} range "1..max";
} }
} default 3;
} description
} "Specifies the number times the RESTCONF server tries
} to connect to a specific endpoint before moving on to
<CODE ENDS> the next endpoint in the list (round robin).";
}
}
}
}
}
}
<CODE ENDS>
4. Security Considerations 4. Security Considerations
The YANG module defined in this document uses a grouping defined in The YANG module defined in this document uses a grouping defined in
[I-D.ietf-netconf-tls-client-server]. Please see the Security [I-D.ietf-netconf-tls-client-server]. Please see the Security
Considerations section in that document for concerns related that Considerations section in that document for concerns related that
grouping. grouping.
The YANG module defined in this document is designed to be accessed The YANG module defined in this document is designed to be accessed
via YANG based management protocols, such as NETCONF [RFC6241] and via YANG based management protocols, such as NETCONF [RFC6241] and
skipping to change at page 34, line 37 skipping to change at page 34, line 29
name: ietf-restconf-client name: ietf-restconf-client
namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-client namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-client
prefix: ncc prefix: ncc
reference: RFC XXXX reference: RFC XXXX
name: ietf-restconf-server name: ietf-restconf-server
namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-server namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-server
prefix: ncs prefix: ncs
reference: RFC XXXX reference: RFC XXXX
6. Acknowledgements 6. References
The authors would like to thank for following for lively discussions
on list and in the halls (ordered by last name): Andy Bierman, Martin
Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David
Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch,
Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen.
7. References
7.1. Normative References 6.1. Normative References
[I-D.ietf-netconf-keystore] [I-D.ietf-netconf-keystore]
Watsen, K., "Keystore Model", draft-ietf-netconf- Watsen, K., "YANG Data Model for a "Keystore" Mechanism",
keystore-02 (work in progress), June 2017. draft-ietf-netconf-keystore-04 (work in progress), October
2017.
[I-D.ietf-netconf-tls-client-server] [I-D.ietf-netconf-tls-client-server]
Watsen, K. and G. Wu, "YANG Groupings for TLS Clients and Watsen, K. and G. Wu, "YANG Groupings for TLS Clients and
TLS Servers", draft-ietf-netconf-tls-client-server-04 TLS Servers", draft-ietf-netconf-tls-client-server-05
(work in progress), October 2017. (work in progress), October 2017.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
skipping to change at page 35, line 39 skipping to change at page 35, line 25
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
RFC 8071, DOI 10.17487/RFC8071, February 2017, RFC 8071, DOI 10.17487/RFC8071, February 2017,
<https://www.rfc-editor.org/info/rfc8071>. <https://www.rfc-editor.org/info/rfc8071>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 6.2. Informative References
[I-D.ietf-netconf-netconf-client-server] [I-D.ietf-netconf-netconf-client-server]
Watsen, K., Wu, G., and J. Schoenwaelder, "NETCONF Client Watsen, K. and G. Wu, "NETCONF Client and Server Models",
and Server Models", draft-ietf-netconf-netconf-client- draft-ietf-netconf-netconf-client-server-05 (work in
server-04 (work in progress), July 2017. progress), October 2017.
[I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-02 (work in progress),
October 2017.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012, DOI 10.17487/RFC6536, March 2012,
<https://www.rfc-editor.org/info/rfc6536>. <https://www.rfc-editor.org/info/rfc6536>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
Appendix A. Change Log Appendix A. Change Log
A.1. 00 to 01 A.1. 00 to 01
o Renamed "keychain" to "keystore". o Renamed "keychain" to "keystore".
A.2. 01 to 02 A.2. 01 to 02
o Filled in previously missing 'ietf-restconf-client' module. o Filled in previously missing 'ietf-restconf-client' module.
skipping to change at page 37, line 43 skipping to change at page 37, line 43
statement. statement.
o Now there are containers and groupings, for both the client and o Now there are containers and groupings, for both the client and
server models. server models.
o Now tree diagrams reference ietf-netmod-yang-tree-diagrams o Now tree diagrams reference ietf-netmod-yang-tree-diagrams
o Updated examples to inline key and certificates (no longer a o Updated examples to inline key and certificates (no longer a
leafref to keystore) leafref to keystore)
A.5. 04 to 05
o Now tree diagrams reference ietf-netmod-yang-tree-diagrams
o Updated examples to inline key and certificates (no longer a
leafref to keystore)
A.6. 05 to 06
o Fixed change log missing section issue.
o Updated examples to match latest updates to the crypto-types,
trust-anchors, and keystore drafts.
o Reduced line length of the YANG modules to fit within 69 columns.
Acknowledgements
The authors would like to thank for following for lively discussions
on list and in the halls (ordered by last name): Andy Bierman, Martin
Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David
Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch,
Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen.
Authors' Addresses Authors' Addresses
Kent Watsen Kent Watsen
Juniper Networks Juniper Networks
EMail: kwatsen@juniper.net EMail: kwatsen@juniper.net
Gary Wu Gary Wu
Cisco Networks Cisco Networks
EMail: garywu@cisco.com EMail: garywu@cisco.com
 End of changes. 110 change blocks. 
1285 lines changed or deleted 1295 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/