<?xml version="1.0" encoding="UTF-8"?> <module name="ietf-netconf-server" xmlns="urn:ietf:params:xml:ns:yang:yin:1" xmlns:ncs="urn:ietf:params:xml:ns:yang:ietf-netconf-server" xmlns:inet="urn:ietf:params:xml:ns:yang:ietf-inet-types" xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name" xmlns:ss="urn:ietf:params:xml:ns:yang:ietf-ssh-server" xmlns:ts="urn:ietf:params:xml:ns:yang:ietf-tls-server"> <yang-version value="1.1"/> <namespace uri="urn:ietf:params:xml:ns:yang:ietf-netconf-server"/> <prefix value="ncs"/> <import module="ietf-inet-types"> <prefix value="inet"/> <reference> <text>RFC 6991: Common YANG Data Types</text> </reference> </import> <import module="ietf-x509-cert-to-name"> <prefix value="x509c2n"/> <reference> <text>RFC 7407: A YANG Data Model for SNMP Configuration</text> </reference> </import> <import module="ietf-ssh-server"> <prefix value="ss"/> <revision-date date="2016-11-02"/> <reference> <text>RFC YYYY: SSH Client and Server Models</text> </reference> </import> <import module="ietf-tls-server"> <prefix value="ts"/> <revision-date date="2016-11-02"/> <reference> <text>RFC ZZZZ: TLS Client and Server Models</text> </reference> </import> <organization> <text>IETF NETCONF (Network Configuration) Working Group</text> </organization> <contact> <text>WG Web: &lt;http://tools.ietf.org/wg/netconf/&gt; WG List: &lt;mailto:netconf@ietf.org&gt; WG Chair: Mehmet Ersue &lt;mailto:mehmet.ersue@nsn.com&gt; WG Chair: Mahesh Jethanandani &lt;mailto:mjethanandani@gmail.com&gt; Editor: Kent Watsen &lt;mailto:kwatsen@juniper.net&gt;</text> </contact> <description> <text>This module contains a collection of YANG definitions for configuring NETCONF servers. Copyright (c) 2014 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or 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). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices.</text> </description> <revision date="2016-11-02"> <description> <text>Initial version</text> </description> <reference> <text>RFC XXXX: NETCONF Client and Server Models</text> </reference> </revision> <feature name="listen"> <description> <text>The 'listen' feature indicates that the NETCONF server supports opening a port to accept NETCONF client connections using at least one transport (e.g., SSH, TLS, etc.).</text> </description> </feature> <feature name="ssh-listen"> <description> <text>The 'ssh-listen' feature indicates that the NETCONF server supports opening a port to accept NETCONF over SSH client connections.</text> </description> <reference> <text>RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)</text> </reference> </feature> <feature name="tls-listen"> <description> <text>The 'tls-listen' feature indicates that the NETCONF server supports opening a port to accept NETCONF over TLS client connections.</text> </description> <reference> <text>RFC 7589: Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication</text> </reference> </feature> <feature name="call-home"> <description> <text>The 'call-home' feature indicates that the NETCONF server supports initiating NETCONF call home connections to NETCONF clients using at least one transport (e.g., SSH, TLS, etc.).</text> </description> <reference> <text>RFC YYYY: NETCONF Call Home and RESTCONF Call Home</text> </reference> </feature> <feature name="ssh-call-home"> <description> <text>The 'ssh-call-home' feature indicates that the NETCONF server supports initiating a NETCONF over SSH call home connection to NETCONF clients.</text> </description> <reference> <text>RFC YYYY: NETCONF Call Home and RESTCONF Call Home</text> </reference> </feature> <feature name="tls-call-home"> <description> <text>The 'tls-call-home' feature indicates that the NETCONF server supports initiating a NETCONF over TLS call home connection to NETCONF clients.</text> </description> <reference> <text>RFC YYYY: NETCONF Call Home and RESTCONF Call Home</text> </reference> </feature> <grouping name="cert-maps-grouping"> <description> <text>A grouping that defines a container around the cert-to-name structure defined in RFC 7407.</text> </description> <container name="cert-maps"> <description> <text>The cert-maps container is used by a TLS-based NETCONF server to map the NETCONF client's presented X.509 certificate to a NETCONF username. If no matching and valid cert-to-name list entry can be found, then the NETCONF server MUST close the connection, and MUST NOT accept NETCONF messages over it.</text> </description> <reference> <text>RFC WWWW: NETCONF over TLS, Section 7</text> </reference> <uses name="x509c2n:cert-to-name"/> </container> </grouping> <grouping name="endpoints-container"> <description> <text>This grouping is used by both the ssh and tls containers for call-home configurations.</text> </description> <container name="endpoints"> <description> <text>Container for the list of endpoints.</text> </description> <list name="endpoint"> <key value="name"/> <min-elements value="1"/> <ordered-by value="user"/> <description> <text>User-ordered list of endpoints for this NETCONF client. Defining more than one enables high-availability.</text> </description> <leaf name="name"> <type name="string"/> <description> <text>An arbitrary name for this endpoint.</text> </description> </leaf> <leaf name="address"> <type name="inet:host"/> <mandatory value="true"/> <description> <text>The IP address or hostname of the endpoint. If a hostname is configured and the DNS resolution results in more than one IP address, the NETCONF server will process the IP addresses as if they had been explicitly configured in place of the hostname.</text> </description> </leaf> <leaf name="port"> <type name="inet:port-number"/> <description> <text>The IP port for this endpoint. The NETCONF server will use the IANA-assigned well-known port if no value is specified.</text> </description> </leaf> </list> </container> </grouping> <container name="netconf-server"> <description> <text>Top-level container for NETCONF server configuration.</text> </description> <container name="session-options"> <description> <text>NETCONF session options, independent of transport or connection strategy.</text> </description> <leaf name="hello-timeout"> <type name="uint16"/> <units name="seconds"/> <default value="600"/> <description> <text>Specifies the maximum number of seconds that a SSH/TLS connection may wait for a hello message to be received. A connection will be dropped if no hello message is received before this number of seconds elapses. If set to zero, then the server will wait forever for a hello message.</text> </description> </leaf> </container> <container name="listen"> <if-feature name="listen"/> <description> <text>Configures listen behavior</text> </description> <leaf name="max-sessions"> <type name="uint16"/> <default value="0"/> <description> <text>Specifies the maximum number of concurrent sessions that can be active at one time. The value 0 indicates that no artificial session limit should be used.</text> </description> </leaf> <leaf name="idle-timeout"> <type name="uint16"/> <units name="seconds"/> <default value="3600"/> <description> <text>Specifies the maximum number of seconds that a NETCONF session may remain idle. A NETCONF 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.</text> </description> </leaf> <list name="endpoint"> <key value="name"/> <description> <text>List of endpoints to listen for NETCONF connections on.</text> </description> <leaf name="name"> <type name="string"/> <description> <text>An arbitrary name for the NETCONF listen endpoint.</text> </description> </leaf> <choice name="transport"> <mandatory value="true"/> <description> <text>Selects between available transports.</text> </description> <case name="ssh"> <if-feature name="ssh-listen"/> <container name="ssh"> <description> <text>SSH-specific listening configuration for inbound connections.</text> </description> <uses name="ss:listening-ssh-server-grouping"> <refine target-node="port"> <default value="830"/> </refine> </uses> </container> </case> <case name="tls"> <if-feature name="tls-listen"/> <container name="tls"> <description> <text>TLS-specific listening configuration for inbound connections.</text> </description> <uses name="ts:listening-tls-server-grouping"> <refine target-node="port"> <default value="6513"/> </refine> <augment target-node="client-auth"> <description> <text>Augments in the cert-to-name structure.</text> </description> <uses name="cert-maps-grouping"/> </augment> </uses> </container> </case> </choice> </list> </container> <container name="call-home"> <if-feature name="call-home"/> <description> <text>Configures call-home behavior</text> </description> <list name="netconf-client"> <key value="name"/> <description> <text>List of NETCONF clients the NETCONF server is to initiate call-home connections to.</text> </description> <leaf name="name"> <type name="string"/> <description> <text>An arbitrary name for the remote NETCONF client.</text> </description> </leaf> <choice name="transport"> <mandatory value="true"/> <description> <text>Selects between available transports.</text> </description> <case name="ssh"> <if-feature name="ssh-call-home"/> <container name="ssh"> <description> <text>Specifies SSH-specific call-home transport configuration.</text> </description> <uses name="endpoints-container"> <refine target-node="endpoints/endpoint/port"> <default value="4334"/> </refine> </uses> <uses name="ss:non-listening-ssh-server-grouping"/> </container> </case> <case name="tls"> <if-feature name="tls-call-home"/> <container name="tls"> <description> <text>Specifies TLS-specific call-home transport configuration.</text> </description> <uses name="endpoints-container"> <refine target-node="endpoints/endpoint/port"> <default value="4335"/> </refine> </uses> <uses name="ts:non-listening-tls-server-grouping"> <augment target-node="client-auth"> <description> <text>Augments in the cert-to-name structure.</text> </description> <uses name="cert-maps-grouping"/> </augment> </uses> </container> </case> </choice> <container name="connection-type"> <description> <text>Indicates the kind of connection to use.</text> </description> <choice name="connection-type"> <description> <text>Selects between available connection types.</text> </description> <case name="persistent-connection"> <container name="persistent"> <presence value="true"/> <description> <text>Maintain a persistent connection to the NETCONF client. If the connection goes down, immediately start trying to reconnect to it, using the reconnection strategy. This connection type minimizes any NETCONF client to NETCONF server data-transfer delay, albeit at the expense of holding resources longer.</text> </description> <leaf name="idle-timeout"> <type name="uint32"/> <units name="seconds"/> <default value="86400"/> <description> <text>Specifies the maximum number of seconds that a a NETCONF session may remain idle. A NETCONF 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.</text> </description> </leaf> <container name="keep-alives"> <description> <text>Configures the keep-alive policy, to proactively test the aliveness of the SSH/TLS client. An unresponsive SSH/TLS client will be dropped after approximately max-attempts * max-wait seconds.</text> </description> <reference> <text>RFC YYYY: NETCONF Call Home and RESTCONF Call Home, Section 3.1, item S6</text> </reference> <leaf name="max-wait"> <type name="uint16"> <range value="1..max"/> </type> <units name="seconds"/> <default value="30"/> <description> <text>Sets the amount of time in seconds after which if no data has been received from the SSH/TLS client, a SSH/TLS-level message will be sent to test the aliveness of the SSH/TLS client.</text> </description> </leaf> <leaf name="max-attempts"> <type name="uint8"/> <default value="3"/> <description> <text>Sets the maximum number of sequential keep-alive messages that can fail to obtain a response from the SSH/TLS client before assuming the SSH/TLS client is no longer alive.</text> </description> </leaf> </container> </container> </case> <case name="periodic-connection"> <container name="periodic"> <presence value="true"/> <description> <text>Periodically connect to the NETCONF client, so that the NETCONF client may deliver messages pending for the NETCONF server. The NETCONF client must close the connection when it is ready to release it. Once the connection has been closed, the NETCONF server will restart its timer until the next connection.</text> </description> <leaf name="idle-timeout"> <type name="uint16"/> <units name="seconds"/> <default value="300"/> <description> <text>Specifies the maximum number of seconds that a a NETCONF session may remain idle. A NETCONF 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.</text> </description> </leaf> <leaf name="reconnect_timeout"> <type name="uint16"> <range value="1..max"/> </type> <units name="minutes"/> <default value="60"/> <description> <text>Sets the maximum amount of unconnected time the NETCONF server will wait before re-establishing a connection to the NETCONF client. The NETCONF server may initiate a connection before this time if desired (e.g., to deliver an event notification message).</text> </description> </leaf> </container> </case> </choice> </container> <container name="reconnect-strategy"> <description> <text>The reconnection strategy directs how a NETCONF server reconnects to a NETCONF client, after discovering its connection to the client has dropped, even if due to a reboot. The NETCONF server starts with the specified endpoint and tries to connect to it max-attempts times before trying the next endpoint in the list (round robin).</text> </description> <leaf name="start-with"> <type name="enumeration"> <enum name="first-listed"> <description> <text>Indicates that reconnections should start with the first endpoint listed.</text> </description> </enum> <enum name="last-connected"> <description> <text>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. NETCONF servers SHOULD be able to remember the last endpoint connected to across reboots.</text> </description> </enum> </type> <default value="first-listed"/> <description> <text>Specifies which of the NETCONF client's endpoints the NETCONF server should start with when trying to connect to the NETCONF client.</text> </description> </leaf> <leaf name="max-attempts"> <type name="uint8"> <range value="1..max"/> </type> <default value="3"/> <description> <text>Specifies the number times the NETCONF server tries to connect to a specific endpoint before moving on to the next endpoint in the list (round robin).</text> </description> </leaf> </container> </list> </container> </container> </module>