<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>

<?rfc rfcedstyle="yes"?>  
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>

<rfc number="7407" ipr="trust200902" category="std" submissionType="IETF" consensus="yes">
    <front>
    <title abbrev="YANG Data Model for SNMP Configuration">A YANG Data Model for SNMP Configuration</title>

    <author initials="M" surname="Bjorklund" fullname='Martin Bjorklund' >
      <organization>Tail-f Systems</organization>
      <address>
        <email>mbj@tail-f.com</email>
      </address>
    </author>
    <author initials="J" surname="Schoenwaelder" fullname='Juergen Schoenwaelder' >
      <organization>Jacobs University</organization>
      <address>
        <email>j.schoenwaelder@jacobs-university.de</email>
      </address>
    </author>
	<date month="December" year="2014"/>


<!-- [rfced] Please insert any keywords (beyond those that appear in 
the title) for use on http://www.rfc-editor.org/search.
-->

<keyword>example</keyword>



    <abstract>
	<t>
This document defines a collection of YANG definitions for
configuring SNMP engines.
	</t>
</abstract>
</front>
<middle>
<section title="Introduction">
    <t>
This document defines a YANG <xref target="RFC6020"/> data model for the
configuration of SNMP engines. The configuration model is consistent
with the MIB modules defined in <xref target="RFC3411"/>, <xref target="RFC3412"/>, <xref target="RFC3413"/>,
<xref target="RFC3414"/>, <xref target="RFC3415"/>, <xref target="RFC3417"/>,
<xref target="RFC3418"/>, <xref target="RFC3419"/>, <xref target="RFC3584"/>,
<xref target="RFC3826"/>, <xref target="RFC5591"/>,
<xref target="RFC5592"/>, and
<xref target="RFC6353"/> but takes advantage of YANG&apos;s ability to define hierarchical
configuration data models.
    </t>
    <t>
The configuration data model in particular has been designed for SNMP
deployments where SNMP runs in read-only mode and the Network
Configuration Protocol (NETCONF) is used to
configure the SNMP agent. Nevertheless, the data model allows
implementations that support write access both via SNMP and NETCONF in
order to interwork with SNMP management applications
manipulating SNMP agent configuration using SNMP.


 Further details can
be found in <xref target="implementation"/>.
    </t>
    <t>
The YANG data model focuses on configuration. Operational state
objects are not explicitly modeled. The operational state of an SNMP
agent can be accessed either directly via SNMP or, alternatively, via
NETCONF using the read-only translation of the relevant SNMP MIB
modules into YANG modules <xref target="RFC6643"/>.
    </t>
    <t>
This document also defines a YANG data model for mapping an X.509
certificate to a name.
    </t>
    <t>
The keywords &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, and
&quot;OPTIONAL&quot; in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/>.
    </t>
</section>
<section title="Data Model">
    <t>
In order to preserve the modularity of SNMP, the YANG configuration
data model is organized in a set of YANG submodules, all sharing the
same module namespace. This allows adding configuration support for
additional SNMP features while keeping the number of namespaces that
have to be dealt with down to a minimum.
    </t>
<section title="Tree Diagrams">
    <t>
A simplified graphical representation of the data model is used in
this document.  The meaning of the symbols in these
diagrams is as follows:
    </t>
<t>
 <list style="symbols">
 <t>
Brackets &quot;[&quot; and &quot;]&quot; enclose list keys.
 </t>
 <t>
Abbreviations before data node names: &quot;rw&quot; means configuration
(read-write), and &quot;ro&quot; means state data (read-only).
 </t>
 <t>
Symbols after data node names: &quot;?&quot; means an optional node, &quot;!&quot; means
a presence container, and &quot;*&quot; denotes a list and leaf-list.
 </t>
 <t>
Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (&quot;:&quot;).
 </t>
 <t>
Ellipsis (&quot;...&quot;) stands for contents of subtrees that are not shown.
 </t>
 </list>
</t>
</section>
<section title="General Considerations" anchor="general">
    <t>
Most YANG nodes are mapped 1-1 to the corresponding MIB object.  The
&quot;reference&quot; statement is used to indicate which corresponding MIB
object the YANG node is mapped to.  When there is not a simple 1-1
mapping, the &quot;description&quot; statement explains the mapping.
    </t>
    <t>
The persistency models in SNMP and NETCONF are quite different.  In
NETCONF, the persistency is defined by the datastore, whereas in SNMP,
it is defined either explicitly in the data model or on a row-by-row
basis using the Textual Convention &quot;StorageType&quot;.  Thus, in the
YANG model defined here, the &quot;StorageType&quot; columns are not present.
For implementation guidelines, see <xref target="implementation"/>.
    </t>
    <t>
In SNMP, row creation and deletion are controlled using the
Textual Convention &quot;RowStatus&quot;.  In NETCONF, creation and deletion
are handled by the protocol, not in the data model.  Thus, in the
YANG model defined here, the &quot;RowStatus&quot; columns are not present.
    </t>
</section>
<section title="Common Definitions">
    <t>
The submodule &quot;ietf&nbhy;snmp&nbhy;common&quot; defines a set of common typedefs and
the top-level container &quot;snmp&quot;.  All configuration parameters defined
in the other submodules are organized under this top-level container.
    </t>
</section>
<section title="Engine Configuration">
    <t>
The submodule &quot;ietf&nbhy;snmp&nbhy;engine&quot;, which defines configuration
parameters that are specific to SNMP engines, has the following
structure:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      +--rw engine
         +--rw enabled?               boolean
         +--rw listen* [name]
         |  +--rw name    snmp:identifier
         |  +--rw (transport)
         |     +--:(udp)
         |        +--rw udp
         |           +--rw ip      inet:ip-address
         |           +--rw port?   inet:port-number
         +--rw version
         |  +--rw v1?    empty
         |  +--rw v2c?   empty
         |  +--rw v3?    empty
         +--rw engine-id?             snmp:engine-id
         +--rw enable-authen-traps?   boolean
	    ]]></artwork>
	</figure>
    <t>
The leaf &quot;/snmp/engine/enabled&quot; can be used to enable/disable an SNMP
engine.
    </t>
    <t>
The list &quot;/snmp/engine/listen&quot; provides configuration of the transport
endpoints the engine is listening to.  In this submodule, SNMP over
UDP is defined.  The Secure Shell (SSH) Protocol, Transport Layer Security (TLS), and Datagram Transport Layer Security (DTLS)
are also supported, defined in &quot;ietf&nbhy;snmp&nbhy;ssh&quot; (<xref target="ssh"/>) and
&quot;ietf&nbhy;snmp&nbhy;tls&quot; (<xref target="tls"/>), respectively.  The &quot;transport&quot; choice is
expected to be augmented for other transports.
    </t>
    <t>
The &quot;/snmp/engine/version&quot; container can be used to enable/disable the
different message processing models <xref target="RFC3411"/>.
    </t>
</section>
<section title="Target Configuration" anchor="target">
    <t>
The submodule &quot;ietf&nbhy;snmp&nbhy;target&quot;, which defines configuration
parameters that correspond to the objects in SNMP-TARGET-MIB,
has the following structure:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      +--rw target* [name]
      |  +--rw name       snmp:identifier
      |  +--rw (transport)
      |  |  +--:(udp)
      |  |     +--rw udp
      |  |        +--rw ip               inet:ip-address
      |  |        +--rw port?            inet:port-number
      |  |        +--rw prefix-length?   uint8
      |  +--rw tag*       snmp:identifier
      |  +--rw timeout?   uint32
      |  +--rw retries?   uint8
      |  +--rw target-params  snmp:identifier
      +--rw target-params* [name]
         +--rw name    snmp:identifier
         +--rw (params)?
	    ]]></artwork>
	</figure>
    <t>
An entry in the list &quot;/snmp/target&quot; corresponds to an
&quot;snmpTargetAddrEntry&quot;.
    </t>
    <t>
The &quot;snmpTargetAddrTDomain&quot; and &quot;snmpTargetAddrTAddress&quot; objects are
mapped to transport-specific YANG nodes.  Each transport is configured
as a separate case in the &quot;transport&quot; choice.  In this submodule, SNMP
over UDP is defined.  TLS and DTLS are also supported, defined in
&quot;ietf&nbhy;snmp&nbhy;tls&quot; (<xref target="tls"/>).  The &quot;transport&quot; choice is expected to be
augmented for other transports.
    </t>
    <t>
An entry in the list &quot;/snmp/target&nbhy;params&quot; corresponds to an
&quot;snmpTargetParamsEntry&quot;.  This list contains a choice &quot;params&quot;, which
is augmented by submodules specific to the security model, currently,
&quot;ietf&nbhy;snmp&nbhy;community&quot; (<xref target="community"/>), &quot;ietf&nbhy;snmp&nbhy;usm&quot; (<xref target="usm"/>), and
&quot;ietf&nbhy;snmp&nbhy;tls&quot; (<xref target="tls"/>).
    </t>
</section>
<section title="Notification Configuration">
    <t>
The submodule &quot;ietf&nbhy;snmp&nbhy;notification&quot;, which defines configuration
parameters that correspond to the objects in SNMP-NOTIFICATION-MIB,
has the following structure:
    </t>


	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      +--rw notify* [name]
      |  +--rw name    snmp:identifier
      |  +--rw tag     snmp:identifier
      |  +--rw type?   enumeration
      +--rw notify-filter-profile* [name]
         +--rw name       snmp:identifier
         +--rw include*   snmp:wildcard-object-identifier
         +--rw exclude*   snmp:wildcard-object-identifier
	    ]]></artwork>
	</figure>
    <t>
This submodule also augments the &quot;target&nbhy;params&quot; list defined in the
&quot;ietf&nbhy;snmp&nbhy;target&quot; submodule (<xref target="target"/>) with one leaf:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      +--rw target-params* [name]
         ...
         +--rw notify-filter-profile?   leafref
	    ]]></artwork>
	</figure>
    <t>
An entry in the list &quot;/snmp/notify&quot; corresponds to an
&quot;snmpNotifyEntry&quot;.
    </t>
    <t>
An entry in the list &quot;/snmp/notify&nbhy;filter&nbhy;profile&quot; corresponds to an
&quot;snmpNotifyFilterProfileEntry&quot;.  In the MIB, there is a sparse
relationship between &quot;snmpTargetParamsTable&quot; and
&quot;snmpNotifyFilterProfileTable&quot;.  In the YANG model, this sparse
relationship is represented with a leafref leaf
&quot;notify&nbhy;filter&nbhy;profile&quot; in the &quot;/snmp/target&nbhy;params&quot; list, which refers to an
entry in the &quot;/snmp/notify&nbhy;filter&nbhy;profile&quot; list.
    </t>
    <t>
The &quot;snmpNotifyFilterTable&quot; is represented as a list &quot;filter&quot; within
the &quot;/snmp/notify&nbhy;filter&nbhy;profile&quot; list.
    </t>
    <t>
This submodule defines the feature &quot;notification&nbhy;filter&quot;. A server
implements this feature if it supports SNMP notification filtering
<xref target="RFC3413"/>.
    </t>
</section>
<section title="Proxy Configuration" anchor="proxy">
    <t>
The submodule &quot;ietf&nbhy;snmp&nbhy;proxy&quot;, which defines configuration
parameters that correspond to the objects in SNMP-PROXY-MIB,
has the following structure:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      +--rw proxy* [name]
         +--rw name                    snmp:identifier
         +--rw type                    enumeration
         +--rw context-engine-id       snmp:engine-id
         +--rw context-name?           snmp:context-name
         +--rw target-params-in?       snmp:identifier
         +--rw single-target-out?      snmp:identifier
         +--rw multiple-target-out?    snmp:identifier
	    ]]></artwork>
	</figure>
    <t>
An entry in the list &quot;/snmp/proxy&quot; corresponds to an
&quot;snmpProxyEntry&quot;.
    </t>
    <t>
This submodule defines the feature &quot;proxy&quot;. A server implements this
feature if it can act as an SNMP proxy <xref target="RFC3413"/>.
    </t>
</section>
<section title="Community Configuration" anchor="community">
    <t>
The submodule &quot;ietf&nbhy;snmp&nbhy;community&quot;, which defines configuration
parameters that correspond to the objects in SNMP-COMMUNITY-MIB,
has the following structure:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      +--rw community* [index]
         +--rw index            snmp:identifier
         +--rw (name)?
         |  +--:(text-name)
         |  |  +--rw text-name?       string
         |  +--:(binary-name)
         |     +--rw binary-name?     binary
         +--rw security-name    snmp:security-name
         +--rw engine-id?       snmp:engine-id
         +--rw context?         snmp:context-name
         +--rw target-tag?      snmp:identifier
	    ]]></artwork>
	</figure>
    <t>
This submodule also augments the &quot;/snmp/target&nbhy;params/params&quot; choice with nodes
for the Community-based Security Model used by SNMPv1 and SNMPv2c:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      +--rw target-params* [name]
      |  ...
      |  +--rw (params)?
      |     +--:(v1)
      |     |  +--rw v1
      |     |     +--rw security-name    snmp:security-name
      |     +--:(v2c)
      |        +--rw v2c
      |           +--rw security-name    snmp:security-name
      +--rw target* [name]
         +--rw mms?       union
	    ]]></artwork>
	</figure>
    <t>
An entry in the list &quot;/snmp/community&quot; corresponds to an
&quot;snmpCommunityEntry&quot;.
    </t>
    <t>
When a case &quot;v1&quot; or &quot;v2c&quot; is chosen, it implies an
snmpTargetParamsMPModel 0 (SNMPv1) or 1 (SNMPv2), and an
snmpTargetParamsSecurityModel 1 (SNMPv1) or 2 (SNMPv2), respectively.
Both cases imply an snmpTargetParamsSecurityLevel of noAuthNoPriv.
    </t>
</section>
<section title="View-Based Access Control Model Configuration">
    <t>
The submodule &quot;ietf&nbhy;snmp&nbhy;vacm&quot;, which defines configuration
parameters that correspond to the objects in SNMP-VIEW-BASED-ACM-MIB,
has the following structure:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      +--rw vacm
         +--rw group* [name]
         |  +--rw name      group-name
         |  +--rw member* [security-name]
         |  |  +--rw security-name     snmp:security-name
         |  |  +--rw security-model*   snmp:security-model
         |  +--rw access* [context security-model security-level]
         |     +--rw context           snmp:context-name
         |     +--rw context-match?    enumeration
         |     +--rw security-model    snmp:security-model-or-any
         |     +--rw security-level    snmp:security-level
         |     +--rw read-view?        view-name
         |     +--rw write-view?       view-name
         |     +--rw notify-view?      view-name
         +--rw view* [name]
            +--rw name       view-name
            +--rw include*   snmp:wildcard-object-identifier
            +--rw exclude*   snmp:wildcard-object-identifier
	    ]]></artwork>
	</figure>



    <t>
The &quot;vacmSecurityToGroupTable&quot; and &quot;vacmAccessTable&quot; are mapped to a
structure of nested lists in the YANG model.  Groups are defined in
the list &quot;/snmp/vacm/group&quot;, and for each group, there is a sublist
&quot;member&quot; that maps to &quot;vacmSecurityToGroupTable&quot; and a sublist
&quot;access&quot; that maps to &quot;vacmAccessTable&quot;.
    </t>
    <t>
MIB views are defined in the list &quot;/snmp/vacm/view&quot;, and for each MIB
view, there is a leaf-list of included subtree families and a
leaf-list of excluded subtree families. This is more compact and thus
a more readable representation of the &quot;vacmViewTreeFamilyTable&quot;.
    </t>
</section>
<section title="User-Based Security Model Configuration" anchor="usm">
    <t>
The submodule &quot;ietf&nbhy;snmp&nbhy;usm&quot;, which defines configuration
parameters that correspond to the objects in SNMP-USER-BASED-SM-MIB,
has the following structure:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      +--rw usm
         +--rw local
         |  +--rw user* [name]
         |     +-- {common user params}
         +--rw remote* [engine-id]
            +--rw engine-id    snmp:engine-id
            +--rw user* [name]
               +-- {common user params}
	    ]]></artwork>
	</figure>
    <t>
The &quot;{common user params}&quot; are:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw name    snmp:identifier
   +--rw auth!
   |  +--rw (protocol)
   |     +--:(md5)
   |     |  +--rw md5
   |     |     +-- rw key    yang:hex-string
   |     +--:(sha)
   |        +--rw sha
   |           +-- rw key    yang:hex-string
   +--rw priv!
      +--rw (protocol)
         +--:(des)
         |  +--rw des
         |     +-- rw key    yang:hex-string
         +--:(aes)
            +--rw aes
               +-- rw key    yang:hex-string
	    ]]></artwork>
	</figure>
    <t>
This submodule also augments the &quot;/snmp/target&nbhy;params/params&quot; choice with nodes
for the SNMP User-based Security Model.
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      +--rw target-params* [name]
         ...
         +--rw (params)?
            +--:(usm)
               +--rw usm
                  +--rw user-name         snmp:security-name
                  +--rw security-level    security-level
	    ]]></artwork>
	</figure>
    <t>
In the MIB, there is a single table with local and remote users,
indexed by the engine ID and user name.  In the YANG model, there is one
list of local users and a nested list of remote users.
    </t>
    <t>
In the MIB, there are several objects related to changing the
authentication and privacy keys.  These objects are not present in the
YANG model.  However, the localized key can be changed.  This implies
that if the engine ID is changed, all users keys need to be changed as
well.
    </t>
</section>
<section title="Transport Security Model Configuration" anchor="tsm">
    <t>
The submodule &quot;ietf&nbhy;snmp&nbhy;tsm&quot;, which defines configuration
parameters that correspond to the objects in SNMP-TSM-MIB,
has the following structure:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      +--rw tsm
         +--rw use-prefix?   boolean
	    ]]></artwork>
	</figure>
    <t>
This submodule also augments the &quot;/snmp/target&nbhy;params/params&quot; choice with nodes
for the SNMP Transport Security Model.
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      +--rw target-params* [name]
         ...
         +--rw (params)?
            +--:(tsm)
               +--rw tsm
                  +--rw security-name     snmp:security-name
                  +--rw security-level    security-level
	    ]]></artwork>
	</figure>
    <t>
This submodule defines the feature &quot;tsm&quot;. A server implements this
feature if it supports the Transport Security Model (TSM) <xref target="RFC5591"/>.
    </t>
</section>
<section title="Transport Layer Security Transport Model Configuration" anchor="tls">
    <t>
The submodule &quot;ietf&nbhy;snmp&nbhy;tls&quot;, which defines configuration
parameters that correspond to the objects in SNMP-TLS-TM-MIB,
has the following structure:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      ...
      +--rw target* [name]
      |  ...
      |  +--rw (transport)
      |     ...
      |     +--:(tls)
      |     |  +--rw tls
      |     |     +-- {common (d)tls transport params}
      |     +--:(dtls)
      |        +--rw dtls
      |           +-- {common (d)tls transport params}
      +--rw tlstm
         +--rw cert-to-name* [id]
            +--rw id             uint32
            +--rw fingerprint    x509c2n:tls-fingerprint
            +--rw map-type       identityref
            +--rw name           string
	    ]]></artwork>
	</figure>
    <t>
The &quot;{common (d)tls transport params}&quot; are:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw ip?                   inet:host
   +--rw port?                 inet:port-number
   +--rw client-fingerprint?   x509c2n:tls-fingerprint
   +--rw server-fingerprint?   x509c2n:tls-fingerprint
   +--rw server-identity?      snmp:admin-string
	    ]]></artwork>
	</figure>
    <t>
This submodule also augments the &quot;/snmp/engine/listen/transport&quot; choice with
objects for the D(TLS) transport endpoints:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      +--rw engine
         ...
         +--rw listen* [name]
            ...
            +--rw (transport)
               ...
               +--:(tls)
               |  +--rw tls
               |     +--rw ip      inet:ip-address
               |     +--rw port?   inet:port-number
               +--:(dtls)
                  +--rw dtls
                     +--rw ip      inet:ip-address
                     +--rw port?   inet:port-number
	    ]]></artwork>
	</figure>
    <t>
This submodule defines the feature &quot;tlstm&quot;. A server implements this
feature if it supports the Transport Layer Security (TLS) Transport
Model (TLSTM) <xref target="RFC6353"/>.
    </t>
</section>
<section title="Secure Shell Transport Model Configuration" anchor="ssh">
    <t>
The submodule &quot;ietf&nbhy;snmp&nbhy;ssh&quot;, which defines configuration
parameters that correspond to the objects in SNMP-SSH-TM-MIB,
has the following structure:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      ...
      +--rw target* [name]
        ...
        +--rw (transport)
           ...
           +--:(ssh)
              +--rw ssh
                 +--rw ip          inet:host
                 +--rw port?       inet:port-number
                 +--rw username?   string
	    ]]></artwork>
	</figure>
    <t>
It also augments the &quot;/snmp/engine/listen/transport&quot; choice with
objects for the SSH transport endpoints:
    </t>
	<figure>
	    <artwork><![CDATA[
   +--rw snmp
      +--rw engine
         ...
         +--rw listen* [name]
            ...
            +--rw (transport)
               ...
               +--:(ssh)
                  +--rw ssh
                     +--rw ip          inet:host
                     +--rw port?       inet:port-number
                     +--rw username?   string
	    ]]></artwork>
	</figure>
    <t>
This submodule defines the feature &quot;sshtm&quot;. A server implements this
feature if it supports the Secure Shell Transport Model (SSHTM)
<xref target="RFC5592"/>.
    </t>
</section>
</section>
<section title="Implementation Guidelines" anchor="implementation">
    <t>
This section describes some challenges for implementations that
support both the YANG models defined in this document and either
read-write or read-only SNMP access to the same data, using the
standard MIB modules.
    </t>
    <t>
As described in <xref target="general"/>, the persistency models in NETCONF and SNMP
are quite different.  This poses a challenge for an implementation to
support both NETCONF and SNMP access to the same data, in particular
if the data is writable over both protocols.  Specifically, the
configuration data may exist in some combination of the three NETCONF
configuration datastores, and this data must be mapped to rows in the
SNMP tables, in some SNMP contexts, with proper values for the
StorageType columns.
    </t>
    <t>
This problem is not new; it has been handled in many implementations
that support configuration of the SNMP engine over a command line
interface (CLI), which normally have a persistency model similar to
NETCONF.
    </t>
    <t>
Since there is not one solution that works for all cases, this
document does not provide a recommended solution.  Instead, some of the
challenges involved are described below.
    </t>
<section title="Supporting read-only SNMP Access">
    <t>
If a device implements only :writable-running, it is trivial to map
the contents of &quot;running&quot; to data in the SNMP tables, where all
instances of the StorageType columns have the value &quot;nonVolatile&quot;.
    </t>
    <t>
If a device implements :candidate but not :startup, the
implementation may choose to not expose the contents of the &quot;candidate&quot;
datastore over SNMP and map the contents of &quot;running&quot; as described
above.  As an option, the contents of &quot;candidate&quot; might be accessible
in a separate SNMP context.
    </t>
    <t>
If a device implements :startup, the handling of StorageType becomes
more difficult.  Since the contents of &quot;running&quot; and &quot;startup&quot; might
differ, data in "running" cannot automatically be mapped to instances
with StorageType &quot;nonVolatile&quot;.  If a particular entry exists in
&quot;running&quot; but not in &quot;startup&quot;, its StorageType should be
&quot;volatile&quot;.  If a particular entry exists in &quot;startup&quot; but not
&quot;running&quot;, it should not be mapped to an SNMP instance, at least not
in the default SNMP context.
    </t>
</section>
<section title="Supporting read-write SNMP Access">
    <t>
If the implementation supports read-write access to data over SNMP,
and specifically creation of table rows, special attention has to be
given to the handling of the RowStatus and StorageType columns.  The
problem is to determine which table rows to store in the configuration
datastores and which configuration datastore is appropriate for each
row.
    </t>
    <t>
The SNMP tables contain a mix of configured data and operational
state, and only rows with an &quot;active&quot; RowStatus column should be
stored in a configuration datastore.
    </t>
    <t>
If a device implements only :writable-running, &quot;active&quot; rows with a
&quot;nonVolatile&quot; StorageType column can be stored in &quot;running&quot;.  Rows
with a &quot;volatile&quot; StorageType column are operational state.
    </t>
    <t>
If a device implements :candidate but not :writable-running, all
configuration changes typically go through the &quot;candidate&quot;, even if
they are done over SNMP.  An implementation might have to perform
some automatic commit of the &quot;candidate&quot; when data is written over
SNMP, since there is no explicit &quot;commit&quot; operation in SNMP.
    </t>
    <t>
If a device implements :startup, &quot;nonVolatile&quot; rows cannot just be
written to &quot;running&quot;; they must also be copied into &quot;startup&quot;.
&quot;volatile&quot; rows may be treated as operational state and not copied to
any datastore, or they may be copied into &quot;running&quot;.

    </t>
    <t>
Cooperating SNMP management applications may use spin lock objects
(snmpTargetSpinLock <xref target="RFC3413"/>, usmUserSpinLock <xref
target="RFC3414"/>, vacmViewSpinLock <xref target="RFC3415"/>) to
coordinate concurrent write
requests. Implementations supporting modifications of MIB objects
protected by a spin lock via NETCONF should ensure that the spin lock
objects are properly incremented whenever objects are changed via
NETCONF. This allows cooperating SNMP management applications to
discover that concurrent modifications are taking place.
    </t>
</section>
</section>
<section title="Definitions">
<section title="Module &apos;ietf-x509-cert-to-name&apos;">
    <t>
This YANG module imports typedefs from <xref target="RFC6991"/>.
    </t>


<t>&lt;CODE BEGINS> file "ietf-x509-cert-to-name.yang"</t>
	<figure>
	    <artwork><![CDATA[
module ietf-x509-cert-to-name {

  namespace "urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name";
  prefix x509c2n;

  import ietf-yang-types {
    prefix yang;
  }

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     WG Chair: Thomas Nadeau
               <mailto:tnadeau@lucidvision.com>

     WG Chair: Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>

     Editor:   Martin Bjorklund
               <mailto:mbj@tail-f.com>

     Editor:   Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>";

  description
    "This module contains a collection of YANG definitions for
     extracting a name from an X.509 certificate.

     The algorithm used to extract a name from an X.509 certificate
     was first defined in RFC 6353.

     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 7407; see
     the RFC itself for full legal notices.";

  reference
    "RFC 6353: Transport Layer Security (TLS) Transport Model for
       the Simple Network Management Protocol (SNMP)";

  revision 2014-12-10 {
    description
      "Initial revision.";
    reference
      "RFC 7407: A YANG Data Model for SNMP Configuration";

  }

  typedef tls-fingerprint {
    type yang:hex-string {
      pattern '([0-9a-fA-F]){2}(:([0-9a-fA-F]){2}){0,254}';
    }
    description
     "A fingerprint value that can be used to uniquely reference
      other data of potentially arbitrary length.

      A tls-fingerprint value is composed of a 1-octet hashing
      algorithm identifier followed by the fingerprint value.  The
      first octet value identifying the hashing algorithm is taken
      from the IANA 'TLS HashAlgorithm Registry' (RFC 5246).  The
      remaining octets are filled using the results of the hashing
      algorithm.";
    reference 
     "RFC 6353: Transport Layer Security (TLS) Transport Model 
        for the Simple Network Management Protocol (SNMP).
        SNMP-TLS-TM-MIB.SnmpTLSFingerprint";
  }

  /* Identities */

  identity cert-to-name {
    description
      "Base identity for algorithms to derive a name from a
       certificate.";
  }

  identity specified {
    base cert-to-name;
    description
      "Directly specifies the name to be used for the certificate.
       The value of the leaf 'name' in the cert-to-name list is
       used.";
    reference 
      "RFC 6353: Transport Layer Security (TLS) Transport Model 
         for the Simple Network Management Protocol (SNMP).
         SNMP-TLS-TM-MIB.snmpTlstmCertSpecified";
  }

  identity san-rfc822-name {
    base cert-to-name;
    description
      "Maps a subjectAltName's rfc822Name to a name.  The local part
       of the rfc822Name is passed unaltered, but the host-part of 
       the name must be passed in lowercase.  For example, the
       rfc822Name field FooBar@Example.COM is mapped to name
       FooBar@example.com.";
    reference 
      "RFC 6353: Transport Layer Security (TLS) Transport Model 
         for the Simple Network Management Protocol (SNMP).
         SNMP-TLS-TM-MIB.snmpTlstmCertSANRFC822Name";
  }

  identity san-dns-name {
    base cert-to-name;
    description
      "Maps a subjectAltName's dNSName to a name after first
       converting it to all lowercase (RFC 5280 does not specify
       converting to lowercase, so this involves an extra step).
       This mapping results in a 1:1 correspondence between
       subjectAltName dNSName values and the name values.";
    reference 
      "RFC 6353: Transport Layer Security (TLS) Transport Model 
         for the Simple Network Management Protocol (SNMP).
         SNMP-TLS-TM-MIB.snmpTlstmCertSANDNSName";
  }

  identity san-ip-address {
    base cert-to-name;
    description
      "Maps a subjectAltName's iPAddress to a name by
       transforming the binary-encoded address as follows:

         1) for IPv4, the value is converted into a
            decimal-dotted quad address (e.g., '192.0.2.1').

         2) for IPv6 addresses, the value is converted into a
            32-character, all-lowercase hexadecimal string
            without any colon separators.

       This mapping results in a 1:1 correspondence between
       subjectAltName iPAddress values and the name values.";
    reference 
      "RFC 6353: Transport Layer Security (TLS) Transport Model 
         for the Simple Network Management Protocol (SNMP).
         SNMP-TLS-TM-MIB.snmpTlstmCertSANIpAddress";
  }

  identity san-any {
    base cert-to-name;
    description
      "Maps any of the following fields using the corresponding
       mapping algorithms:

         +------------+-----------------+
         | Type       | Algorithm       |
         |------------+-----------------|
         | rfc822Name | san-rfc822-name |
         | dNSName    | san-dns-name    |
         | iPAddress  | san-ip-address  |
         +------------+-----------------+

       The first matching subjectAltName value found in the
       certificate of the above types MUST be used when deriving
       the name.  The mapping algorithm specified in the
       'Algorithm' column MUST be used to derive the name.

       This mapping results in a 1:1 correspondence between
       subjectAltName values and name values.  The three sub-mapping
       algorithms produced by this combined algorithm cannot produce
       conflicting results between themselves.";
    reference 
      "RFC 6353: Transport Layer Security (TLS) Transport Model 
         for the Simple Network Management Protocol (SNMP).
         SNMP-TLS-TM-MIB.snmpTlstmCertSANAny";
  }

  identity common-name {
    base cert-to-name;
    description
      "Maps a certificate's CommonName to a name after converting
       it to a UTF-8 encoding.  The usage of CommonNames is
       deprecated, and users are encouraged to use subjectAltName
       mapping methods instead.  This mapping results in a 1:1
       correspondence between certificate CommonName values and name
       values.";
    reference 
      "RFC 6353: Transport Layer Security (TLS) Transport Model 
         for the Simple Network Management Protocol (SNMP).
         SNMP-TLS-TM-MIB.snmpTlstmCertCommonName";
  }

  /*
   * Groupings
   */

  grouping cert-to-name {
    description
      "Defines nodes for mapping certificates to names.  Modules
       that use this grouping should describe how the resulting
       name is used.";

    list cert-to-name {
      key id;
      description
        "This list defines how certificates are mapped to names.
         The name is derived by considering each cert-to-name
         list entry in order.  The cert-to-name entry's fingerprint
         determines whether the list entry is a match:

         1) If the cert-to-name list entry's fingerprint value
            matches that of the presented certificate, then consider
            the list entry a successful match.

         2) If the cert-to-name list entry's fingerprint value
            matches that of a locally held copy of a trusted CA
            certificate, and that CA certificate was part of the CA
            certificate chain to the presented certificate, then
            consider the list entry a successful match.

        Once a matching cert-to-name list entry has been found, the
        map-type is used to determine how the name associated with
        the certificate should be determined.  See the map-type
        leaf's description for details on determining the name value.
        If it is impossible to determine a name from the cert-to-name
        list entry's data combined with the data presented in the
        certificate, then additional cert-to-name list entries MUST
        be searched to look for another potential match.

        Security administrators are encouraged to make use of
        certificates with subjectAltName fields that can be mapped to
        names so that a single root CA certificate can allow all
        child certificates' subjectAltName fields to map directly to 
        a name via a 1:1 transformation.";
      reference 
       "RFC 6353: Transport Layer Security (TLS) Transport Model 
          for the Simple Network Management Protocol (SNMP).
          SNMP-TLS-TM-MIB.snmpTlstmCertToTSNEntry";

      leaf id {
        type uint32;
        description
          "The id specifies the order in which the entries in the
           cert-to-name list are searched.  Entries with lower
           numbers are searched first.";
        reference 
          "RFC 6353: Transport Layer Security (TLS) Transport Model 
             for the Simple Network Management Protocol 
             (SNMP).
             SNMP-TLS-TM-MIB.snmpTlstmCertToTSNID";
      }

      leaf fingerprint {
        type x509c2n:tls-fingerprint;
        mandatory true;
        description
          "Specifies a value with which the fingerprint of the
           full certificate presented by the peer is compared.  If
           the fingerprint of the full certificate presented by the
           peer does not match the fingerprint configured, then the
           entry is skipped, and the search for a match continues.";
        reference 
          "RFC 6353: Transport Layer Security (TLS) Transport Model 
             for the Simple Network Management Protocol 
             (SNMP).
             SNMP-TLS-TM-MIB.snmpTlstmCertToTSNFingerprint";
      }

      leaf map-type {
        type identityref {
          base cert-to-name;
        }
        mandatory true;
        description
          "Specifies the algorithm used to map the certificate
           presented by the peer to a name.

           Mappings that need additional configuration objects should
           use the 'when' statement to make them conditional based on
           the map-type.";
        reference 
          "RFC 6353: Transport Layer Security (TLS) Transport Model 
             for the Simple Network Management Protocol 
             (SNMP).
             SNMP-TLS-TM-MIB.snmpTlstmCertToTSNMapType";
      }

      leaf name {
        when "../map-type = 'x509c2n:specified'";
        type string;
        mandatory true;
        description
          "Directly specifies the NETCONF username when the
           map-type is 'specified'.";
        reference 
          "RFC 6353: Transport Layer Security (TLS) Transport Model 
             for the Simple Network Management Protocol 
             (SNMP).
             SNMP-TLS-TM-MIB.snmpTlstmCertToTSNData";
      }
    }
  }
}
	    ]]></artwork>
	</figure>
<t>&lt;CODE ENDS></t>
</section>
<section title="Module &apos;ietf-snmp&apos;">
<t>&lt;CODE BEGINS> file "ietf-snmp.yang"</t>
	<figure>
	    <artwork><![CDATA[
module ietf-snmp {

  namespace "urn:ietf:params:xml:ns:yang:ietf-snmp";
  prefix snmp;

  include ietf-snmp-common {
    revision-date 2014-12-10;
  }
  include ietf-snmp-engine {
    revision-date 2014-12-10;
  }
  include ietf-snmp-target {
    revision-date 2014-12-10;
  }
  include ietf-snmp-notification {
    revision-date 2014-12-10;
  }
  include ietf-snmp-proxy {
    revision-date 2014-12-10;
  }
  include ietf-snmp-community {
    revision-date 2014-12-10;
  }
  include ietf-snmp-usm {
    revision-date 2014-12-10;
  }
  include ietf-snmp-tsm {
    revision-date 2014-12-10;
  }
  include ietf-snmp-vacm {
    revision-date 2014-12-10;
  }
  include ietf-snmp-tls {
    revision-date 2014-12-10;
  }
  include ietf-snmp-ssh {
    revision-date 2014-12-10;
  }

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     WG Chair: Thomas Nadeau
               <mailto:tnadeau@lucidvision.com>

     WG Chair: Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>

     Editor:   Martin Bjorklund
               <mailto:mbj@tail-f.com>

     Editor:   Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>";

  description
    "This module contains a collection of YANG definitions for
     configuring SNMP engines.

     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 7407; see
     the RFC itself for full legal notices.";

  revision 2014-12-10 {
    description
      "Initial revision.";
    reference
      "RFC 7407: A YANG Data Model for SNMP Configuration";
  }

}
	    ]]></artwork>
	</figure>
<t>&lt;CODE ENDS></t>
</section>
<section title="Submodule &apos;ietf-snmp-common&apos;">
<t>&lt;CODE BEGINS> file "ietf-snmp-common.yang"</t>
	<figure>
	    <artwork><![CDATA[
submodule ietf-snmp-common {

  belongs-to ietf-snmp {
    prefix snmp;
  }

  import ietf-yang-types {
    prefix yang;
  }

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     WG Chair: Thomas Nadeau
               <mailto:tnadeau@lucidvision.com>

     WG Chair: Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>

     Editor:   Martin Bjorklund
               <mailto:mbj@tail-f.com>

     Editor:   Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>";

  description
    "This submodule contains a collection of common YANG definitions
     for configuring SNMP engines.

     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 7407; see
     the RFC itself for full legal notices.";

  revision 2014-12-10 {
    description
      "Initial revision.";
    reference
      "RFC 7407: A YANG Data Model for SNMP Configuration";
  }

  /* Collection of SNMP-specific data types */

  typedef admin-string {
    type string {
      length "0..255";
    }
    description
      "Represents SnmpAdminString as defined in RFC 3411.

      Note that the size of an SnmpAdminString is measured in
      octets, not characters.";
    reference 
      "RFC 3411: An Architecture for Describing Simple Network 
         Management Protocol (SNMP) Management Frameworks.
         SNMP-FRAMEWORK-MIB.SnmpAdminString";
  }

  typedef identifier {
    type admin-string {
      length "1..32";
    }
    description
      "Identifiers are used to name items in the SNMP configuration
      datastore.";
  }

  typedef context-name {
    type admin-string {
      length "0..32";
    }
    description
      "The context type represents an SNMP context name.";
    reference
      "RFC 3411: An Architecture for Describing Simple Network
         Management Protocol (SNMP) Management Frameworks";
  }

  typedef security-name {
    type admin-string {
      length "1..32";
    }
    description
      "The security-name type represents an SNMP security name.";
    reference
      "RFC 3411: An Architecture for Describing Simple Network
         Management Protocol (SNMP) Management Frameworks";
  }

  typedef security-model {
    type union {
      type enumeration {
        enum v1  { value 1; }
        enum v2c { value 2; }
        enum usm { value 3; }
        enum tsm { value 4; }
      }
      type int32 {
        range "1..2147483647";
      }
    }
    reference
      "RFC 3411: An Architecture for Describing Simple Network
         Management Protocol (SNMP) Management Frameworks";
  }

  typedef security-model-or-any {
    type union {
      type enumeration {
        enum any { value 0; }
      }
      type security-model;
    }
    reference
      "RFC 3411: An Architecture for Describing Simple Network
         Management Protocol (SNMP) Management Frameworks";
  }

  typedef security-level {
    type enumeration {
      enum no-auth-no-priv { value 1; }
      enum auth-no-priv    { value 2; }
      enum auth-priv       { value 3; }
    }
    reference
      "RFC 3411: An Architecture for Describing Simple Network
         Management Protocol (SNMP) Management Frameworks";
  }

  typedef engine-id {
    type yang:hex-string {
      pattern '([0-9a-fA-F]){2}(:([0-9a-fA-F]){2}){4,31}';
    }
    description
      "The engine ID specified as a list of colon-specified 
      hexadecimal octets, e.g., '80:00:02:b8:04:61:62:63'.";
    reference
      "RFC 3411: An Architecture for Describing Simple Network
         Management Protocol (SNMP) Management Frameworks";
  }

  typedef wildcard-object-identifier {
    type string;
    description
      "The wildcard-object-identifier type represents an SNMP object
      identifier where subidentifiers can be given either as a label,
      in numeric form, or a wildcard, represented by an asterisk 
      ('*').";
  }

  typedef tag-value {
    type string {
      length "0..255";
    }
    description
      "Represents SnmpTagValue as defined in RFC 3413.

      Note that the size of an SnmpTagValue is measured in
      octets, not characters.";
    reference 
      "RFC 3413: Simple Network Management Protocol (SNMP) 
         Applications.
         SNMP-TARGET-MIB.SnmpTagValue";
  }

  container snmp {
    description
      "Top-level container for SNMP-related configuration and
      status objects.";
  }

}
	    ]]></artwork>
	</figure>
<t>&lt;CODE ENDS></t>
</section>
<section title="Submodule &apos;ietf-snmp-engine&apos;">
<t>&lt;CODE BEGINS> file "ietf-snmp-engine.yang"</t>
	<figure>
	    <artwork><![CDATA[
submodule ietf-snmp-engine {

  belongs-to ietf-snmp {
    prefix snmp;
  }

  import ietf-inet-types {
    prefix inet;
  }

  include ietf-snmp-common;

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     WG Chair: Thomas Nadeau
               <mailto:tnadeau@lucidvision.com>

     WG Chair: Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>

     Editor:   Martin Bjorklund
               <mailto:mbj@tail-f.com>

     Editor:   Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>";

  description
    "This submodule contains a collection of YANG definitions
     for configuring SNMP engines.

     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 7407; see
     the RFC itself for full legal notices.";

  revision 2014-12-10 {
    description
      "Initial revision.";
    reference
      "RFC 7407: A YANG Data Model for SNMP Configuration";
  }

  augment /snmp:snmp {

    container engine {

      description
        "Configuration of the SNMP engine.";

      leaf enabled {
        type boolean;
        default "false";
        description
          "Enables the SNMP engine.";
      }

      list listen {
        key "name";
        description
          "Configuration of the transport endpoints on which the
           engine listens.";

        leaf name {
          type snmp:identifier;
          description
            "An arbitrary name for the list entry.";
        }

        choice transport {
          mandatory true;
          description
            "The transport-protocol-specific parameters for this
             endpoint.  Submodules providing configuration for
             additional transports are expected to augment this
             choice.";
          case udp {
            container udp {
              leaf ip {
                type inet:ip-address;
                mandatory true;
                description
                  "The IPv4 or IPv6 address on which the engine
                   listens.";
              }
              leaf port {
                type inet:port-number;
                description
                  "The UDP port on which the engine listens.

                   If the port is not configured, an engine that
                   acts as a Command Responder uses port 161, and
                   an engine that acts as a Notification Receiver
                   uses port 162.";
              }
            }
          }
        }
      }

      container version {
        description
          "SNMP version used by the engine.";
        leaf v1 {
          type empty;
        }
        leaf v2c {
          type empty;
        }
        leaf v3 {
          type empty;
        }
      }

      leaf engine-id {
        type snmp:engine-id;
        description
          "The local SNMP engine's administratively assigned unique
           identifier.

           If this leaf is not set, the device automatically
           calculates an engine ID, as described in RFC 3411.  A
           server MAY initialize this leaf with the automatically
           created value.";
        reference 
          "RFC 3411: An Architecture for Describing Simple Network 
             Management Protocol (SNMP) Management 
             Frameworks.
             SNMP-FRAMEWORK-MIB.snmpEngineID";
      }

      leaf enable-authen-traps {
        type boolean;
        description
          "Indicates whether the SNMP entity is permitted to
           generate authenticationFailure traps.";
        reference 
          "RFC 3418: Management Information Base (MIB) for the
             Simple Network Management Protocol (SNMP)
             SNMPv2-MIB.snmpEnableAuthenTraps";
      }
    }
  }
}
	    ]]></artwork>
	</figure>
<t>&lt;CODE ENDS></t>
</section>
<section title="Submodule &apos;ietf-snmp-target&apos;">


<t>&lt;CODE BEGINS> file "ietf-snmp-target.yang"</t>
	<figure>
	    <artwork><![CDATA[
submodule ietf-snmp-target {

  belongs-to ietf-snmp {
    prefix snmp;
  }

  import ietf-inet-types {
    prefix inet;
  }

  include ietf-snmp-common;

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     WG Chair: Thomas Nadeau
               <mailto:tnadeau@lucidvision.com>

     WG Chair: Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>

     Editor:   Martin Bjorklund
               <mailto:mbj@tail-f.com>

     Editor:   Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>";

  description
    "This submodule contains a collection of YANG definitions
     for configuring SNMP targets.

     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 7407; see
     the RFC itself for full legal notices.";

  reference
    "RFC 3413: Simple Network Management Protocol (SNMP) 
       Applications";

  revision 2014-12-10 {
    description
      "Initial revision.";
    reference
      "RFC 7407: A YANG Data Model for SNMP Configuration";
  }

  augment /snmp:snmp {

    list target {
      key name;
      description
        "List of targets.";
      reference 
        "RFC 3413: Simple Network Management Protocol (SNMP) 
           Applications.
           SNMP-TARGET-MIB.snmpTargetAddrTable";

      leaf name {
        type snmp:identifier;
        description
          "Identifies the target.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP) 
             Applications.
             SNMP-TARGET-MIB.snmpTargetAddrName";
      }
      choice transport {
        mandatory true;
        description
          "Transport address of the target.

           The snmpTargetAddrTDomain and snmpTargetAddrTAddress
           objects are mapped to transport-specific YANG nodes.  Each
           transport is configured as a separate case in this
           choice.  Submodules providing configuration for additional
           transports are expected to augment this choice.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP) 
             Applications.
             SNMP-TARGET-MIB.snmpTargetAddrTDomain
             SNMP-TARGET-MIB.snmpTargetAddrTAddress";
        case udp {
          reference 
           "RFC 3417: Transport Mappings for the Simple Network 
              Management Protocol (SNMP).
              SNMPv2-TM.snmpUDPDomain
            RFC 3419: Textual Conventions for Transport Addresses.
              TRANSPORT-ADDRESS-MIB.transportDomainUdpIpv4
              TRANSPORT-ADDRESS-MIB.transportDomainUdpIpv4z
              TRANSPORT-ADDRESS-MIB.transportDomainUdpIpv6
              TRANSPORT-ADDRESS-MIB.transportDomainUdpIpv6z";
          container udp {
            leaf ip {
              type inet:ip-address;
              mandatory true;
              reference 
                "RFC 3413: Simple Network Management Protocol (SNMP).
                   SNMP-TARGET-MIB.snmpTargetAddrTAddress";
            }
            leaf port {
              type inet:port-number;
              default 162;
              description
                "UDP port number.";
              reference 
                "RFC 3413: Simple Network Management Protocol (SNMP).
                   SNMP-TARGET-MIB.snmpTargetAddrTAddress";
            }
            leaf prefix-length {
              type uint8;
              description
                "The value of this leaf must match the value of
                 ../snmp:ip.  If ../snmp:ip contains an IPv4 address,
                 this leaf must be less than or equal to 32.  If it
                 contains an IPv6 address, it must be less than or
                 equal to 128.

                 Note that the prefix-length is currently only used
                 by the Community-based Security Model to filter
                 incoming messages.  Furthermore, the prefix-length
                 filtering does not cover all possible filters
                 supported by the corresponding MIB object.";
              reference 
                "RFC 3584: Coexistence between Version 1, Version 2, 
                   and Version 3 of the Internet-standard 
                   Network Management Framework. 
                   SNMP-COMMUNITY-MIB.snmpTargetAddrTMask";
            }
          }
        }
      }
      leaf-list tag {
        type snmp:tag-value;
        description
          "List of tag values used to select target addresses.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications.
             SNMP-TARGET-MIB.snmpTargetAddrTagList";
      }
      leaf timeout {
        type uint32;
        units "0.01 seconds";
        default 1500;
        description
          "Needed only if this target can receive
           InformRequest-PDUs.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications.
             SNMP-TARGET-MIB.snmpTargetAddrTimeout";
      }
      leaf retries {
        type uint8;
        default 3;
        description
          "Needed only if this target can receive
           InformRequest-PDUs.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications.
             SNMP-TARGET-MIB.snmpTargetAddrRetryCount";
      }
      leaf target-params {
        type snmp:identifier;
        mandatory true;
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP).
             Applications.
             SNMP-TARGET-MIB.snmpTargetAddrParams";
      }
    }

    list target-params {
      key name;
      description
        "List of target parameters.";
      reference 
        "RFC 3413: Simple Network Management Protocol (SNMP). 
           Applications.
           SNMP-TARGET-MIB.snmpTargetParamsTable";

      leaf name {
        type snmp:identifier;
      }
      choice params {
        description
          "This choice is augmented with case nodes containing
           configuration parameters specific to the security model.";
      }
    }
  }
}
	    ]]></artwork>
	</figure>
<t>&lt;CODE ENDS></t>
</section>
<section title="Submodule &apos;ietf-snmp-notification&apos;">
<t>&lt;CODE BEGINS> file "ietf-snmp-notification.yang"</t>
	<figure>
	    <artwork><![CDATA[
submodule ietf-snmp-notification {

  belongs-to ietf-snmp {
    prefix snmp;
  }

  include ietf-snmp-common;
  include ietf-snmp-target;

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     WG Chair: Thomas Nadeau
               <mailto:tnadeau@lucidvision.com>

     WG Chair: Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>

     Editor:   Martin Bjorklund
               <mailto:mbj@tail-f.com>

     Editor:   Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>";

  description
    "This submodule contains a collection of YANG definitions
     for configuring SNMP notifications.

     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 7407; see
     the RFC itself for full legal notices.";

  reference
    "RFC 3413: Simple Network Management Protocol (SNMP)
       Applications";

  revision 2014-12-10 {
    description
      "Initial revision.";
    reference
      "RFC 7407: A YANG Data Model for SNMP Configuration";
  }

  feature notification-filter {
    description
      "A server implements this feature if it supports SNMP
      notification filtering.";
    reference
      "RFC 3413: Simple Network Management Protocol (SNMP)
         Applications";
  }

  augment /snmp:snmp {

    list notify {
      key name;
      description
        "Targets that will receive notifications.

         Entries in this list are mapped 1-1 to entries in
         snmpNotifyTable, except that if an entry in snmpNotifyTable
         has an snmpNotifyTag for which no snmpTargetAddrEntry 
         exists, then the snmpNotifyTable entry is not mapped to an 
         entry in this list.";
      reference 
        "RFC 3413: Simple Network Management Protocol (SNMP). 
           Applications. 
           SNMP-NOTIFICATION-MIB.snmpNotifyTable";

      leaf name {
        type snmp:identifier;
        description
          "An arbitrary name for the list entry.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications. 
             SNMP-NOTIFICATION-MIB.snmpNotifyName";
      }
      leaf tag {
        type snmp:tag-value;
        mandatory true;
        description
          "Target tag, selects a set of notification targets.

           Implementations MAY restrict the values of this leaf
           to be one of the available values of /snmp/target/tag in
           a valid configuration.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications. 
             SNMP-NOTIFICATION-MIB.snmpNotifyTag";
      }
      leaf type {
        type enumeration {
          enum trap { value 1; }
          enum inform { value 2; }
        }
        default trap;
        description
          "Defines the notification type to be generated.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications. 
             SNMP-NOTIFICATION-MIB.snmpNotifyType";
      }
    }

    list notify-filter-profile {
      if-feature snmp:notification-filter;
      key name;

      description
        "Notification filter profiles.

         The leaf /snmp/target/notify-filter-profile is used
         to associate a filter profile with a target.

         If an entry in this list is referred to by one or more
         /snmp/target/notify-filter-profile items, each such
         notify-filter-profile is represented by one
         snmpNotifyFilterProfileEntry.

         If an entry in this list is not referred to by any
         /snmp/target/notify-filter-profile, the entry is not mapped
         to snmpNotifyFilterProfileTable.";
      reference 
        "RFC 3413: Simple Network Management Protocol (SNMP). 
           Applications. 
           SNMP-NOTIFICATION-MIB.snmpNotifyFilterProfileTable
           SNMP-NOTIFICATION-MIB.snmpNotifyFilterTable";

      leaf name {
        type snmp:identifier;
        description
          "Name of the filter profile.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications. 
             SNMP-NOTIFICATION-MIB.snmpNotifyFilterProfileName";
      }

      leaf-list include {
        type snmp:wildcard-object-identifier;
        description
          "A family of subtrees included in this filter.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications. 
             SNMP-NOTIFICATION-MIB.snmpNotifyFilterSubtree
             SNMP-NOTIFICATION-MIB.snmpNotifyFilterMask
             SNMP-NOTIFICATION-MIB.snmpNotifyFilterType";
      }

      leaf-list exclude {
        type snmp:wildcard-object-identifier;
        description
          "A family of subtrees excluded from this filter.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications. 
             SNMP-NOTIFICATION-MIB.snmpNotifyFilterSubtree
             SNMP-NOTIFICATION-MIB.snmpNotifyFilterMask
             SNMP-NOTIFICATION-MIB.snmpNotifyFilterType";
      }
    }

  }

  augment /snmp:snmp/snmp:target-params {
    reference 
      "RFC 3413: Simple Network Management Protocol (SNMP). 
         Applications. 
         SNMP-NOTIFICATION-MIB.snmpNotifyFilterProfileTable";
    leaf notify-filter-profile {
      if-feature snmp:notification-filter;
      type leafref {
        path "/snmp/notify-filter-profile/name";
      }
      description
        "This leafref leaf is used to represent the sparse
         relationship between the /snmp/target-params list and the
         /snmp/notify-filter-profile list.";
      reference 
        "RFC 3413: Simple Network Management Protocol (SNMP). 
           Applications. 
           SNMP-NOTIFICATION-MIB.snmpNotifyFilterProfileName";
    }
  }

}
	    ]]></artwork>
	</figure>
<t>&lt;CODE ENDS></t>
</section>
<section title="Submodule &apos;ietf-snmp-proxy&apos;">
<t>&lt;CODE BEGINS> file "ietf-snmp-proxy.yang"</t>
	<figure>
	    <artwork><![CDATA[
submodule ietf-snmp-proxy {

  belongs-to ietf-snmp {
    prefix snmp;
  }

  include ietf-snmp-common;
  include ietf-snmp-target;

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     WG Chair: Thomas Nadeau
               <mailto:tnadeau@lucidvision.com>

     WG Chair: Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>

     Editor:   Martin Bjorklund
               <mailto:mbj@tail-f.com>

     Editor:   Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>";

  description
    "This submodule contains a collection of YANG definitions
     for configuring SNMP proxies.

     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 7407; see
     the RFC itself for full legal notices.";

  reference
    "RFC 3413: Simple Network Management Protocol (SNMP)
       Applications";

  revision 2014-12-10 {
    description
      "Initial revision.";
    reference
      "RFC 7407: A YANG Data Model for SNMP Configuration";
  }

  feature proxy {
    description
      "A server implements this feature if it can act as an
      SNMP proxy.";
    reference
      "RFC 3413: Simple Network Management Protocol (SNMP)
         Applications";
  }

  augment /snmp:snmp {
    if-feature snmp:proxy;

    list proxy {
      key name;

      description
        "List of proxy parameters.";
      reference 
        "RFC 3413: Simple Network Management Protocol (SNMP). 
           Applications. 
           SNMP-PROXY-MIB.snmpProxyTable";

      leaf name {
        type snmp:identifier;
        description
          "Identifies the proxy parameter entry.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications. 
             SNMP-PROXY-MIB.snmpProxyName";
      }
      leaf type {
        type enumeration {
          enum read { value 1; }
          enum write { value 2; }
          enum trap { value 3; }
          enum inform { value 4; }
        }
        mandatory true;
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications. 
             SNMP-PROXY-MIB.snmpProxyType";
      }
      leaf context-engine-id {
        type snmp:engine-id;
        mandatory true;
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications. 
             SNMP-PROXY-MIB.snmpProxyContextEngineID";
      }
      leaf context-name {
        type snmp:context-name;
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications. 
             SNMP-PROXY-MIB.snmpProxyContextName";
      }
      leaf target-params-in {
        type snmp:identifier;
        description
          "The name of a target parameters list entry.

           Implementations MAY restrict the values of this
           leaf to be one of the available values of
           /snmp/target-params/name in a valid configuration.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications. 
             SNMP-PROXY-MIB.snmpProxyTargetParamsIn";
      }
      leaf single-target-out {
        when "../type = 'read' or ../type = 'write'";
        type snmp:identifier;
        description
          "Implementations MAY restrict the values of this leaf
           to be one of the available values of /snmp/target/name in
           a valid configuration.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications. 
             SNMP-PROXY-MIB.snmpProxySingleTargetOut";
      }
      leaf multiple-target-out {
        when "../type = 'trap' or ../type = 'inform'";
        type snmp:tag-value;
        description
          "Implementations MAY restrict the values of this leaf
           to be one of the available values of /snmp/target/tag in
           a valid configuration.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications. 
             SNMP-PROXY-MIB.snmpProxyMultipleTargetOut";
      }
    }
  }
}
	    ]]></artwork>
	</figure>
<t>&lt;CODE ENDS></t>
</section>
<section title="Submodule &apos;ietf-snmp-community&apos;">
<t>&lt;CODE BEGINS> file "ietf-snmp-community.yang"</t>
	<figure>
	    <artwork><![CDATA[
submodule ietf-snmp-community {

  belongs-to ietf-snmp {
    prefix snmp;
  }

  import ietf-netconf-acm {
    prefix nacm;
  }

  include ietf-snmp-common;
  include ietf-snmp-target;
  include ietf-snmp-proxy;

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     WG Chair: Thomas Nadeau
               <mailto:tnadeau@lucidvision.com>

     WG Chair: Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>

     Editor:   Martin Bjorklund
               <mailto:mbj@tail-f.com>

     Editor:   Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>";

  description
    "This submodule contains a collection of YANG definitions
     for configuring community-based SNMP.

     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 7407; see
     the RFC itself for full legal notices.";

  reference
    "RFC 3584: Coexistence between Version 1, Version 2, and 
       Version 3 of the Internet-standard Network 
       Management Framework";

  revision 2014-12-10 {
    description
      "Initial revision.";
    reference
      "RFC 7407: A YANG Data Model for SNMP Configuration";
  }

  augment /snmp:snmp {

    list community {
      key index;

      description
        "List of communities.";
      reference 
        "RFC 3584: Coexistence between Version 1, Version 2, 
           and Version 3 of the Internet-standard 
           Network Management Framework.
           SNMP-COMMUNITY-MIB.snmpCommunityTable";

      leaf index {
        type snmp:identifier;
        description
          "Index into the community list.";
        reference 
          "RFC 3584: Coexistence between Version 1, Version 2, 
             and Version 3 of the Internet-standard 
             Network Management Framework.
             SNMP-COMMUNITY-MIB.snmpCommunityIndex";
      }
      choice name {
        nacm:default-deny-all;
        description
          "The community name, specified as either a string or
           a binary value.  The binary name is used when the
           community name contains characters that are not legal
           in a string.

           If not set, the value of 'security-name' is operationally
           used as the snmpCommunityName.";
        reference 
          "RFC 3584: Coexistence between Version 1, Version 2, 
             and Version 3 of the Internet-standard 
             Network Management Framework.
             SNMP-COMMUNITY-MIB.snmpCommunityName";
        leaf text-name {
          type string;
          description
            "A community name that can be represented as a
             YANG string.";
        }
        leaf binary-name {
          type binary;
          description
            "A community name represented as a binary value.";
        }
      }
      leaf security-name {
        type snmp:security-name;
        mandatory true;
        nacm:default-deny-all;
        description
          "The snmpCommunitySecurityName of this entry.";
        reference 
          "RFC 3584: Coexistence between Version 1, Version 2, 
             and Version 3 of the Internet-standard 
             Network Management Framework.
             SNMP-COMMUNITY-MIB.snmpCommunitySecurityName";
      }
      leaf engine-id {
        if-feature snmp:proxy;
        type snmp:engine-id;
        description
          "If not set, the value of the local SNMP engine is
           operationally used by the device.";
        reference 
          "RFC 3584: Coexistence between Version 1, Version 2, 
             and Version 3 of the Internet-standard 
             Network Management Framework.
             SNMP-COMMUNITY-MIB.snmpCommunityContextEngineID";
      }
      leaf context {
        type snmp:context-name;
        default "";
        description
          "The context in which management information is accessed
           when using the community string specified by this entry.";
        reference 
          "RFC 3584: Coexistence between Version 1, Version 2, 
             and Version 3 of the Internet-standard 
             Network Management Framework.
             SNMP-COMMUNITY-MIB.snmpCommunityContextName";
      }
      leaf target-tag {
        type snmp:tag-value;
        description
          "Used to limit access for this community to the specified
           targets.

           Implementations MAY restrict the values of this leaf
           to be one of the available values of /snmp/target/tag in
           a valid configuration.";
        reference 
          "RFC 3584: Coexistence between Version 1, Version 2, 
             and Version 3 of the Internet-standard 
             Network Management Framework.
             SNMP-COMMUNITY-MIB.snmpCommunityTransportTag";
      }
    }
  }

  grouping v1-target-params {
    container v1 {
      description
        "SNMPv1 parameters type.
         Represents snmpTargetParamsMPModel '0',
         snmpTargetParamsSecurityModel '1', and
         snmpTargetParamsSecurityLevel 'noAuthNoPriv'.";
      leaf security-name {
        type snmp:security-name;
        mandatory true;
        description
          "Implementations MAY restrict the values of this leaf
           to be one of the available values of
           /snmp/community/security-name in a valid configuration.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications.
             SNMP-TARGET-MIB.snmpTargetParamsSecurityName";
      }
    }
  }

  grouping v2c-target-params {
    container v2c {
      description
        "SNMPv2 community parameters type.
         Represents snmpTargetParamsMPModel '1',
         snmpTargetParamsSecurityModel '2', and
         snmpTargetParamsSecurityLevel 'noAuthNoPriv'.";
      leaf security-name {
        type snmp:security-name;
        mandatory true;
        description
          "Implementations MAY restrict the values of this leaf
           to be one of the available values of
           /snmp/community/security-name in a valid configuration.";
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications.
             SNMP-TARGET-MIB.snmpTargetParamsSecurityName";
      }
    }
  }

  augment /snmp:snmp/snmp:target-params/snmp:params {
    case v1 {
      uses v1-target-params;
    }
    case v2c {
      uses v2c-target-params;
    }
  }

  augment /snmp:snmp/snmp:target {
    when "snmp:v1 or snmp:v2c";
    leaf mms {
      type union {
        type enumeration {
          enum "unknown" { value 0; }
        }
        type int32 {
          range "484..max";
        }
      }
      default "484";
      description
        "The maximum message size.";
      reference 
        "RFC 3584: Coexistence between Version 1, Version 2, 
           and Version 3 of the Internet-standard 
           Network Management Framework.
           SNMP-COMMUNITY-MIB.snmpTargetAddrMMS";
    }
  }

}
	    ]]></artwork>
	</figure>
<t>&lt;CODE ENDS></t>
</section>


<section title="Submodule &apos;ietf-snmp-vacm&apos;">
<t>&lt;CODE BEGINS> file "ietf-snmp-vacm.yang"</t>
	<figure>
	    <artwork><![CDATA[
submodule ietf-snmp-vacm {

  belongs-to ietf-snmp {
    prefix snmp;
  }

  include ietf-snmp-common;

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     WG Chair: Thomas Nadeau
               <mailto:tnadeau@lucidvision.com>

     WG Chair: Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>

     Editor:   Martin Bjorklund
               <mailto:mbj@tail-f.com>

     Editor:   Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>";

  description
    "This submodule contains a collection of YANG definitions
     for configuring the View-based Access Control Model (VACM)
     of SNMP.

     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 7407; see
     the RFC itself for full legal notices.";

  reference
    "RFC 3415: View-based Access Control Model (VACM) for the
       Simple Network Management Protocol (SNMP)";

  revision 2014-12-10 {
    description
      "Initial revision.";
    reference
      "RFC 7407: A YANG Data Model for SNMP Configuration";
  }

  typedef view-name {
    type snmp:identifier;
    description
      "The view-name type represents an SNMP VACM view name.";
  }

  typedef group-name {
    type snmp:identifier;
    description
      "The group-name type represents an SNMP VACM group name.";
  }

  augment /snmp:snmp {

    container vacm {
      description
        "Configuration of the View-based Access Control Model.";

      list group {
        key name;
        description
          "VACM groups.

           This data model has a different structure than the MIB.
           Groups are explicitly defined in this list, and group
           members are defined in the 'member' list (mapped to
           vacmSecurityToGroupTable), and access for the group is
           defined in the 'access' list (mapped to
           vacmAccessTable).";
        reference 
          "RFC 3415: View-based Access Control Model (VACM) for the
             Simple Network Management Protocol (SNMP).
             SNMP-VIEW-BASED-ACM-MIB.vacmSecurityToGroupTable
             SNMP-VIEW-BASED-ACM-MIB.vacmAccessTable";

        leaf name {
          type group-name;
          description
            "The name of this VACM group.";
          reference 
            "RFC 3415: View-based Access Control Model (VACM) for the
               Simple Network Management Protocol (SNMP).
               SNMP-VIEW-BASED-ACM-MIB.vacmGroupName";
        }

        list member {
          key "security-name";
          description
            "A member of this VACM group.

             A specific combination of security-name and
             security-model MUST NOT be present in more than
             one group.";
          reference
            "RFC 3415: View-based Access Control Model (VACM) for the
               Simple Network Management Protocol (SNMP).
               SNMP-VIEW-BASED-ACM-MIB.vacmSecurityToGroupTable";

          leaf security-name {
            type snmp:security-name;
            description
              "The securityName of a group member.";
            reference 
              "RFC 3415: View-based Access Control Model (VACM) for 
                 the Simple Network Management Protocol (SNMP).
                 SNMP-VIEW-BASED-ACM-MIB.vacmSecurityName";
          }

          leaf-list security-model {
            type snmp:security-model;
            min-elements 1;
            description
              "The security models under which this security-name
               is a member of this group.";
            reference 
              "RFC 3415: View-based Access Control Model (VACM) for 
                 the Simple Network Management Protocol (SNMP).
                 SNMP-VIEW-BASED-ACM-MIB.vacmSecurityModel";
          }
        }

        list access {
          key "context security-model security-level";
          description
            "Definition of access right for groups.";
          reference 
            "RFC 3415: View-based Access Control Model (VACM) for 
               the Simple Network Management Protocol (SNMP).
               SNMP-VIEW-BASED-ACM-MIB.vacmAccessTable";

          leaf context {
            type snmp:context-name;
            description
              "The context (prefix) under which the access rights
               apply.";
            reference
              "RFC 3415: View-based Access Control Model (VACM) for 
                 the Simple Network Management Protocol (SNMP).
                 SNMP-VIEW-BASED-ACM-MIB.vacmAccessContextPrefix";
          }

          leaf context-match {
            type enumeration {
              enum exact { value 1; }
              enum prefix { value 2; }
            }
            default exact;
            reference
              "RFC 3415: View-based Access Control Model (VACM) for 
                 the Simple Network Management Protocol (SNMP).
                 SNMP-VIEW-BASED-ACM-MIB.vacmAccessContextMatch";
          }

          leaf security-model {
            type snmp:security-model-or-any;
            description
              "The security model under which the access rights
              apply.";
            reference
              "RFC 3415: View-based Access Control Model (VACM) for 
                 the Simple Network Management Protocol (SNMP).
                 SNMP-VIEW-BASED-ACM-MIB.vacmAccessSecurityModel";
          }

          leaf security-level {
            type snmp:security-level;
            description
              "The minimum security level under which the access
               rights apply.";
            reference
              "RFC 3415: View-based Access Control Model (VACM) for 
                 the Simple Network Management Protocol (SNMP).
                 SNMP-VIEW-BASED-ACM-MIB.vacmAccessSecurityLevel";
          }

          leaf read-view {
            type view-name;
            description
              "The name of the MIB view of the SNMP context
               authorizing read access.  If this leaf does not
               exist in a configuration, it maps to a zero-length
               vacmAccessReadViewName.

               Implementations MAY restrict the values of this
               leaf to be one of the available values of
               /snmp/vacm/view/name in a valid configuration.";
            reference
              "RFC 3415: View-based Access Control Model (VACM) for 
                 the Simple Network Management Protocol (SNMP).
                 SNMP-VIEW-BASED-ACM-MIB.vacmAccessReadViewName";
          }

          leaf write-view {
            type view-name;
            description
              "The name of the MIB view of the SNMP context
               authorizing write access.  If this leaf does not
               exist in a configuration, it maps to a zero-length
               vacmAccessWriteViewName.

               Implementations MAY restrict the values of this
               leaf to be one of the available values of
               /snmp/vacm/view/name in a valid configuration.";
            reference
              "RFC 3415: View-based Access Control Model (VACM) for 
                 the Simple Network Management Protocol (SNMP).
                 SNMP-VIEW-BASED-ACM-MIB.vacmAccessWriteViewName";
          }

          leaf notify-view {
            type view-name;
            description
              "The name of the MIB view of the SNMP context
               authorizing notify access.  If this leaf does not
               exist in a configuration, it maps to a zero-length
               vacmAccessNotifyViewName.

               Implementations MAY restrict the values of this
               leaf to be one of the available values of
               /snmp/vacm/view/name in a valid configuration.";
            reference
              "RFC 3415: View-based Access Control Model (VACM) for 
                   the Simple Network Management Protocol (SNMP).
                   SNMP-VIEW-BASED-ACM-MIB.vacmAccessNotifyViewName";
          }
        }
      }

      list view {
        key name;
        description
          "Definition of MIB views.";
        reference 
          "RFC 3415: View-based Access Control Model (VACM) for 
             the Simple Network Management Protocol (SNMP).
             SNMP-VIEW-BASED-ACM-MIB.vacmViewTreeFamilyTable";

        leaf name {
          type view-name;
          description
            "The name of this VACM MIB view.";
          reference 
            "RFC 3415: View-based Access Control Model (VACM) for 
               the Simple Network Management Protocol (SNMP).
               SNMP-VIEW-BASED-ACM-MIB.vacmViewTreeFamilyName";
        }

        leaf-list include {
          type snmp:wildcard-object-identifier;
          description
            "A family of subtrees included in this MIB view.";
          reference
              "RFC 3415: View-based Access Control Model (VACM) for 
                 the Simple Network Management Protocol (SNMP).
                 SNMP-VIEW-BASED-ACM-MIB.vacmViewTreeFamilySubtree
                 SNMP-VIEW-BASED-ACM-MIB.vacmViewTreeFamilyMask
                 SNMP-VIEW-BASED-ACM-MIB.vacmViewTreeFamilyType";
        }

        leaf-list exclude {
          type snmp:wildcard-object-identifier;
          description
            "A family of subtrees excluded from this MIB view.";
          reference
            "RFC 3415: View-based Access Control Model (VACM) for 
               the Simple Network Management Protocol (SNMP).
               SNMP-VIEW-BASED-ACM-MIB.vacmViewTreeFamilySubtree
               SNMP-VIEW-BASED-ACM-MIB.vacmViewTreeFamilyMask
               SNMP-VIEW-BASED-ACM-MIB.vacmViewTreeFamilyType";
        }
      }
    }
  }
}
	    ]]></artwork>
	</figure>
<t>&lt;CODE ENDS></t>
</section>
<section title="Submodule &apos;ietf-snmp-usm&apos;">
    <t>
This YANG submodule imports YANG extensions from
<xref target="RFC6536"/>.
    </t>
<t>&lt;CODE BEGINS> file "ietf-snmp-usm.yang"</t>
	<figure>
	    <artwork><![CDATA[
submodule ietf-snmp-usm {

  belongs-to ietf-snmp {
    prefix snmp;
  }

  import ietf-yang-types {
    prefix yang;
  }
  import ietf-netconf-acm {
    prefix nacm;
  }

  include ietf-snmp-common;
  include ietf-snmp-target;
  include ietf-snmp-proxy;

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     WG Chair: Thomas Nadeau
               <mailto:tnadeau@lucidvision.com>

     WG Chair: Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>

     Editor:   Martin Bjorklund
               <mailto:mbj@tail-f.com>

     Editor:   Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>";

  description
    "This submodule contains a collection of YANG definitions for
     configuring the User-based Security Model (USM) of SNMP.

     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 7407; see
     the RFC itself for full legal notices.";

  reference
    "RFC 3414: User-based Security Model (USM) for version 3 of the
       Simple Network Management Protocol (SNMPv3)";

  revision 2014-12-10 {
    description
      "Initial revision.";
    reference
      "RFC 7407: A YANG Data Model for SNMP Configuration";
  }

  grouping key {
    leaf key {
      type yang:hex-string;
      mandatory true;
      nacm:default-deny-all;
      description
        "Localized key specified as a list of colon-specified
         hexadecimal octets.";
    }
  }

  grouping user-list {
    list user {
      key "name";

      reference 
        "RFC 3414: User-based Security Model (USM) for version 3 
           of the Simple Network Management Protocol (SNMPv3).
           SNMP-USER-BASED-SM-MIB.usmUserTable";

      leaf name {
        type snmp:identifier;
        reference 
          "RFC 3414: User-based Security Model (USM) for version 3 
             of the Simple Network Management Protocol (SNMPv3).
             SNMP-USER-BASED-SM-MIB.usmUserName";
      }
      container auth {
        presence "enables authentication";
        description
          "Enables authentication of the user.";
        choice protocol {
          mandatory true;
          reference 
            "RFC 3414: User-based Security Model (USM) for version 3 
               of the Simple Network Management Protocol (SNMPv3).
               SNMP-USER-BASED-SM-MIB.usmUserAuthProtocol";
          container md5 {
            uses key;
            reference
              "RFC 3414: User-based Security Model (USM) for  
                 version 3 of the Simple Network Management Protocol 
                 (SNMPv3).
                 SNMP-USER-BASED-SM-MIB.usmHMACMD5AuthProtocol";
          }
          container sha {
            uses key;
            reference
              "RFC 3414: User-based Security Model (USM) for 
                 version 3 of the Simple Network Management Protocol 
                 (SNMPv3).
                 SNMP-USER-BASED-SM-MIB.usmHMACSHAAuthProtocol";
          }
        }
      }
      container priv {
        must "../auth" {
          error-message
            "when privacy (confidentiality) is used, "
          + "authentication must also be used";
        }
        presence "enables encryption";
        description
          "Enables encryption of SNMP messages.";

        choice protocol {
          mandatory true;
          reference 
            "RFC 3414: User-based Security Model (USM) for version 3 
               of the Simple Network Management Protocol (SNMPv3).
               SNMP-USER-BASED-SM-MIB.usmUserPrivProtocol";
          container des {
            uses key;
            reference 
              "RFC 3414: User-based Security Model (USM) for  
                 version 3 of the Simple Network Management Protocol 
                 (SNMPv3).
                 SNMP-USER-BASED-SM-MIB.usmDESPrivProtocol";
          }
          container aes {
            uses key;
            reference 
              "RFC 3826: The Advanced Encryption Standard (AES) 
                 Cipher Algorithm in the SNMP User-based Security 
                 Model.
                 SNMP-USM-AES-MIB.usmAesCfb128Protocol";
          }
        }
      }
    }
  }

  augment /snmp:snmp {

    container usm {
      description
        "Configuration of the User-based Security Model.";
      container local {
        uses user-list;
      }

      list remote {
        key "engine-id";

        leaf engine-id {
          type snmp:engine-id;
          reference 
            "RFC 3414: User-based Security Model (USM) for version 3 
               of the Simple Network Management Protocol (SNMPv3).
               SNMP-USER-BASED-SM-MIB.usmUserEngineID";
        }

        uses user-list;
      }
    }
  }

  grouping usm-target-params {
    container usm {
      description
        "User-based SNMPv3 parameters type.

         Represents snmpTargetParamsMPModel '3' and
         snmpTargetParamsSecurityModel '3'.";
      leaf user-name {
        type snmp:security-name;
        mandatory true;
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications.
             SNMP-TARGET-MIB.snmpTargetParamsSecurityName";
      }
      leaf security-level {
        type snmp:security-level;
        mandatory true;
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications.
             SNMP-TARGET-MIB.snmpTargetParamsSecurityLevel";
      }
    }
  }

  augment /snmp:snmp/snmp:target-params/snmp:params {
    case usm {
      uses usm-target-params;
    }
  }

}
	    ]]></artwork>
	</figure>
<t>&lt;CODE ENDS></t>
</section>
<section title="Submodule &apos;ietf-snmp-tsm&apos;">
<t>&lt;CODE BEGINS> file "ietf-snmp-tsm.yang"</t>
	<figure>
	    <artwork><![CDATA[
submodule ietf-snmp-tsm {

  belongs-to ietf-snmp {
    prefix snmp;
  }

  include ietf-snmp-common;
  include ietf-snmp-target;
  include ietf-snmp-proxy;

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     WG Chair: Thomas Nadeau
               <mailto:tnadeau@lucidvision.com>

     WG Chair: Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>

     Editor:   Martin Bjorklund
               <mailto:mbj@tail-f.com>

     Editor:   Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>";

  description
    "This submodule contains a collection of YANG definitions for
     configuring the Transport Security Model (TSM) of SNMP.

     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 7407; see
     the RFC itself for full legal notices.";

  reference
    "RFC 5591: Transport Security Model for the
       Simple Network Management Protocol (SNMP)";

  revision 2014-12-10 {
    description
      "Initial revision.";
    reference
      "RFC 7407: A YANG Data Model for SNMP Configuration";
  }

  feature tsm {
    description
      "A server implements this feature if it supports the
      Transport Security Model for SNMP.";
    reference
      "RFC 5591: Transport Security Model for the
         Simple Network Management Protocol (SNMP)";
  }

  augment /snmp:snmp {
    if-feature tsm;
    container tsm {
      description
        "Configuration of the Transport Security Model.";

      leaf use-prefix {
        type boolean;
        default false;
        reference 
          "RFC 5591: Transport Security Model for the Simple 
             Network Management Protocol (SNMP).
             SNMP-TSM-MIB.snmpTsmConfigurationUsePrefix";
      }
    }
  }

  grouping tsm-target-params {
    container tsm {
      description
        "Transport-based security SNMPv3 parameters type.

         Represents snmpTargetParamsMPModel '3' and
         snmpTargetParamsSecurityModel '4'.";
      leaf security-name {
        type snmp:security-name;
        mandatory true;
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications.
             SNMP-TARGET-MIB.snmpTargetParamsSecurityName";
      }
      leaf security-level {
        type snmp:security-level;
        mandatory true;
        reference 
          "RFC 3413: Simple Network Management Protocol (SNMP). 
             Applications.
             SNMP-TARGET-MIB.snmpTargetParamsSecurityLevel";
      }
    }
  }

  augment /snmp:snmp/snmp:target-params/snmp:params {
    if-feature tsm;
    case tsm {
      uses tsm-target-params;
    }
  }

}
	    ]]></artwork>
	</figure>
<t>&lt;CODE ENDS></t>
</section>
<section title="Submodule &apos;ietf-snmp-tls&apos;">
<t>&lt;CODE BEGINS> file "ietf-snmp-tls.yang"</t>
	<figure>
	    <artwork><![CDATA[
submodule ietf-snmp-tls {

  belongs-to ietf-snmp {
    prefix snmp;
  }

  import ietf-inet-types {
    prefix inet;
  }
  import ietf-x509-cert-to-name {
    prefix x509c2n;
  }

  include ietf-snmp-common;
  include ietf-snmp-engine;
  include ietf-snmp-target;

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     WG Chair: Thomas Nadeau
               <mailto:tnadeau@lucidvision.com>

     WG Chair: Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>

     Editor:   Martin Bjorklund
               <mailto:mbj@tail-f.com>

     Editor:   Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>";

  description
    "This submodule contains a collection of YANG definitions for
     configuring the Transport Layer Security Transport Model (TLSTM)
     of SNMP.

     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 7407; see
     the RFC itself for full legal notices.";

  reference
    "RFC 6353: Transport Layer Security (TLS) Transport Model for
       the Simple Network Management Protocol (SNMP)";

  revision 2014-12-10 {
    description
      "Initial revision.";
    reference
      "RFC 7407: A YANG Data Model for SNMP Configuration";
  }

  feature tlstm {
    description
      "A server implements this feature if it supports the
      Transport Layer Security Transport Model for SNMP.";
    reference
      "RFC 6353: Transport Layer Security (TLS) Transport Model for
         the Simple Network Management Protocol (SNMP)";
  }

  augment /snmp:snmp/snmp:engine/snmp:listen/snmp:transport {
    if-feature tlstm;
    case tls {
      container tls {
        description
          "A list of IPv4 and IPv6 addresses and ports to which the
           engine listens for SNMP messages over TLS.";

        leaf ip {
          type inet:ip-address;
          mandatory true;
          description
            "The IPv4 or IPv6 address on which the engine listens
             for SNMP messages over TLS.";
        }
        leaf port {
          type inet:port-number;
          description
            "The TCP port on which the engine listens for SNMP
             messages over TLS.

             If the port is not configured, an engine that
             acts as a Command Responder uses port 10161, and
             an engine that acts as a Notification Receiver
             uses port 10162.";
        }
      }
    }
    case dtls {
      container dtls {
        description
          "A list of IPv4 and IPv6 addresses and ports to which the
           engine listens for SNMP messages over DTLS.";

        leaf ip {
          type inet:ip-address;
          mandatory true;
          description
            "The IPv4 or IPv6 address on which the engine listens
             for SNMP messages over DTLS.";
        }
        leaf port {
          type inet:port-number;
          description
            "The UDP port on which the engine listens for SNMP
             messages over DTLS.

             If the port is not configured, an engine that
             acts as a Command Responder uses port 10161, and
             an engine that acts as a Notification Receiver
             uses port 10162.";
        }
      }
    }
  }

  augment /snmp:snmp {
    if-feature tlstm;
    container tlstm {
      uses x509c2n:cert-to-name {
        description
          "Defines how certificates are mapped to names.  The
           resulting name is used as a security name.";
        refine cert-to-name/map-type {
          description
            "Mappings that use the snmpTlstmCertToTSNData column
             need to augment the cert-to-name list with
             additional configuration objects corresponding
             to the snmpTlstmCertToTSNData value.  Such objects
             should use the 'when' statement to make them
             conditional based on the map-type.";
        }
      }
    }
  }

  grouping tls-transport {
    leaf ip {
      type inet:host;
      mandatory true;
      reference 
        "RFC 3413: Simple Network Management Protocol (SNMP). 
           Applications.
           SNMP-TARGET-MIB.snmpTargetAddrTAddress
         RFC 6353: Transport Layer Security (TLS) Transport Model 
           for the Simple Network Management Protocol (SNMP).           
           SNMP-TLS-TM-MIB.SnmpTLSAddress";
    }
    leaf port {
      type inet:port-number;
      default 10161;
      reference 
        "RFC 3413: Simple Network Management Protocol (SNMP). 
           Applications.
           SNMP-TARGET-MIB.snmpTargetAddrTAddress
         RFC 6353: Transport Layer Security (TLS) Transport Model 
           for the Simple Network Management Protocol (SNMP).           
           SNMP-TLS-TM-MIB.SnmpTLSAddress";
    }
    leaf client-fingerprint {
      type x509c2n:tls-fingerprint;
      reference 
        "RFC 6353: Transport Layer Security (TLS) Transport Model 
           for the Simple Network Management Protocol (SNMP).
           SNMP-TLS-TM-MIB.snmpTlstmParamsClientFingerprint";
    }
    leaf server-fingerprint {
      type x509c2n:tls-fingerprint;
      reference 
        "RFC 6353: Transport Layer Security (TLS) Transport Model 
           for the Simple Network Management Protocol (SNMP).
           SNMP-TLS-TM-MIB.snmpTlstmAddrServerFingerprint";
    }
    leaf server-identity {
      type snmp:admin-string;
      reference 
        "RFC 6353: Transport Layer Security (TLS) Transport Model 
           for the Simple Network Management Protocol (SNMP).
           SNMP-TLS-TM-MIB.snmpTlstmAddrServerIdentity";
    }
  }

  augment /snmp:snmp/snmp:target/snmp:transport {
    if-feature tlstm;
    case tls {
      reference 
        "RFC 6353: Transport Layer Security (TLS) Transport Model 
           for the Simple Network Management Protocol (SNMP).
           SNMP-TLS-TM-MIB.snmpTLSTCPDomain";
      container tls {
        uses tls-transport;
      }
    }
  }

  augment /snmp:snmp/snmp:target/snmp:transport {
    if-feature tlstm;
    case dtls {
      reference 
        "RFC 6353: Transport Layer Security (TLS) Transport Model 
           for the Simple Network Management Protocol (SNMP).
           SNMP-TLS-TM-MIB.snmpDTLSUDPDomain";
      container dtls {
        uses tls-transport;
      }
    }
  }
}
	    ]]></artwork>
	</figure>
<t>&lt;CODE ENDS></t>
</section>
<section title="Submodule &apos;ietf-snmp-ssh&apos;">
<t>&lt;CODE BEGINS> file "ietf-snmp-ssh.yang"</t>
	<figure>
	    <artwork><![CDATA[
submodule ietf-snmp-ssh {

  belongs-to ietf-snmp {
    prefix snmp;
  }

  import ietf-inet-types {
    prefix inet;
  }

  include ietf-snmp-common;
  include ietf-snmp-engine;
  include ietf-snmp-target;

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     WG Chair: Thomas Nadeau
               <mailto:tnadeau@lucidvision.com>

     WG Chair: Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>

     Editor:   Martin Bjorklund
               <mailto:mbj@tail-f.com>

     Editor:   Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>";

  description
    "This submodule contains a collection of YANG definitions for
     configuring the Secure Shell Transport Model (SSHTM)
     of SNMP.

     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 7407; see
     the RFC itself for full legal notices.";

  reference
    "RFC 5592: Secure Shell Transport Model for the
       Simple Network Management Protocol (SNMP)";

  revision 2014-12-10 {
    description
      "Initial revision.";
    reference
      "RFC 7407: A YANG Data Model for SNMP Configuration";
  }

  feature sshtm {
    description
      "A server implements this feature if it supports the
      Secure Shell Transport Model for SNMP.";
    reference
      "RFC 5592: Secure Shell Transport Model for the
         Simple Network Management Protocol (SNMP)";
  }

  augment /snmp:snmp/snmp:engine/snmp:listen/snmp:transport {
    if-feature sshtm;
    case ssh {
      container ssh {
        description
          "The IPv4 or IPv6 address and port to which the
           engine listens for SNMP messages over SSH.";

        leaf ip {
          type inet:ip-address;
          mandatory true;
          description
            "The IPv4 or IPv6 address on which the engine listens
             for SNMP messages over SSH.";
        }
        leaf port {
          type inet:port-number;
          description
            "The TCP port on which the engine listens for SNMP
             messages over SSH.

             If the port is not configured, an engine that
             acts as a Command Responder uses port 5161, and
             an engine that acts as a Notification Receiver
             uses port 5162.";
        }
      }
    }
  }

  augment /snmp:snmp/snmp:target/snmp:transport {
    if-feature sshtm;
    case ssh {
      reference 
        "RFC 5592: Secure Shell Transport Model for the
           Simple Network Management Protocol (SNMP).
           SNMP-SSH-TM-MIB.snmpSSHDomain";
      container ssh {
        leaf ip {
          type inet:host;
          mandatory true;
          reference 
            "RFC 3413: Simple Network Management Protocol (SNMP). 
               Applications.
               SNMP-TARGET-MIB.snmpTargetAddrTAddress
             RFC 5592: Secure Shell Transport Model for the
               Simple Network Management Protocol (SNMP).
               SNMP-SSH-TM-MIB.SnmpSSHAddress";
        }
        leaf port {
          type inet:port-number;
          default 5161;
          reference 
            "RFC 3413: Simple Network Management Protocol (SNMP). 
               Applications.
               SNMP-TARGET-MIB.snmpTargetAddrTAddress
             RFC 5592: Secure Shell Transport Model for the
               Simple Network Management Protocol (SNMP).
               SNMP-SSH-TM-MIB.SnmpSSHAddress";
        }
        leaf username {
          type string;
          reference 
            "RFC 3413: Simple Network Management Protocol (SNMP). 
               Applications.
               SNMP-TARGET-MIB.snmpTargetAddrTAddress
             RFC 5592: Secure Shell Transport Model for the
               Simple Network Management Protocol (SNMP).
               SNMP-SSH-TM-MIB.SnmpSSHAddress";
        }
      }
    }
  }
}

	    ]]></artwork>
	</figure>
<t>&lt;CODE ENDS></t>
</section>
</section>
<section title="IANA Considerations" anchor="iana">
    <t>
This document registers two URIs in the "IETF XML Registry"
<xref target="RFC3688"/>.  Following the format in RFC 3688, the
following registrations have been made.
    </t>
	<figure>
	    <artwork><![CDATA[
     URI: urn:ietf:params:xml:ns:yang:ietf-snmp
     Registrant Contact: The NETMOD WG of the IETF.
     XML: N/A, the requested URI is an XML namespace.

     URI: urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name
     Registrant Contact: The NETMOD WG of the IETF.
     XML: N/A, the requested URI is an XML namespace.
	    ]]></artwork>
	</figure>
    <t>
This document registers the following YANG modules in the "YANG Module
Names" registry <xref target="RFC6020"/>.
    </t>
	<figure>
	    <artwork><![CDATA[
     name:         ietf-snmp
     namespace:    urn:ietf:params:xml:ns:yang:ietf-snmp
     prefix:       snmp
     reference:    RFC 7407

     name:         ietf-x509-cert-to-name
     namespace:    urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name
     prefix:       x509c2n
     reference:    RFC 7407
	    ]]></artwork>
	</figure>
    <t>
The document registers the following YANG submodules in the "YANG
Module Names" registry <xref target="RFC6020"/>.
    </t>
	<figure>
	    <artwork><![CDATA[
     name:         ietf-snmp-common
     parent:       ietf-snmp
     reference:    RFC 7407

     name:         ietf-snmp-engine
     parent:       ietf-snmp
     reference:    RFC 7407

     name:         ietf-snmp-community
     parent:       ietf-snmp
     reference:    RFC 7407

     name:         ietf-snmp-notification
     parent:       ietf-snmp
     reference:    RFC 7407

     name:         ietf-snmp-target
     parent:       ietf-snmp
     reference:    RFC 7407

     name:         ietf-snmp-vacm
     parent:       ietf-snmp
     reference:    RFC 7407

     name:         ietf-snmp-usm
     parent:       ietf-snmp
     reference:    RFC 7407

     name:         ietf-snmp-tsm
     parent:       ietf-snmp
     reference:    RFC 7407

     name:         ietf-snmp-tls
     parent:       ietf-snmp
     reference:    RFC 7407

     name:         ietf-snmp-ssh
     parent:       ietf-snmp
     reference:    RFC 7407
	    ]]></artwork>
	</figure>
</section>

<section title="Security Considerations">

    <t>
The YANG module and submodules defined in this memo are designed to be
accessed via the NETCONF protocol <xref target="RFC6241"/>.  The
lowest NETCONF layer is the secure transport layer and the
mandatory to implement secure transport is SSH <xref target="RFC6242"/>.
The NETCONF access control model <xref target="RFC6536"/> provides the
means to restrict access for particular NETCONF users to a pre-configured
subset of all available NETCONF protocol operations and content. 
    </t>
    <t>
There are a number of data nodes defined in the YANG module and
submodules which are writable/creatable/deletable (i.e., config true,
which is the default).  These data nodes may be considered sensitive
or vulnerable in some network environments.  Write operations (e.g.,
edit-config) to these data nodes without proper protection can have a
negative effect on network operations.  These are the subtrees and
data nodes and their sensitivity/vulnerability:
    </t>
<t>
 <list style="symbols">
 <t>
The "/snmp/engine" subtree contains the configuration of general
parameters of an SNMP engine such as the endpoints to listen on, the
transports and SNMP versions enabled, or the engine&apos;s
identity. Write access to this subtree should only be granted to
entities configuring general SNMP engine parameters.
 </t>
 <t>
The "/snmp/target" subtree contains the configuration of SNMP targets
and, in particular, which transports to use and their security
parameters. Write access to this subtree should only be granted to
the security administrator and entities configuring SNMP
notification forwarding behavior.
 </t>
 <t>
The "/snmp/notify" and "/snmp/notify-filter-profile" subtrees contain
the configuration for the SNMP notification forwarding and filtering
mechanism. Write access to these subtrees should only be granted to
entities configuring SNMP notification forwarding behavior.


 </t>
 <t>
The "/snmp/proxy" subtree contains the configuration for SNMP
proxies. Write access to this subtree should only be granted to
entities configuring SNMP proxies.
 </t>
 <t>
The "/snmp/community" subtree contains the configuration of the
Community-based Security Model. Write access to this subtree should
only be granted to the security administrator.
 </t>
 <t>
The "/snmp/usm" subtree contains the configuration of the User-based
Security Model. Write access to this subtree should only be granted
to the security administrator.
 </t>
 <t>
The "/snmp/tsm" subtree contains the configuration of the Transport
Layer Security (TLS) Transport Model for SNMP. Write access to this subtree should
only be granted to the security administrator.
 </t>
 <t>
The "/snmp/tlstm" subtree contains the configuration of the SNMP
transport over (D)TLS and, in particular, the configuration of how
certificates are mapped to SNMP security names. Write access to this
subtree should only be granted to the security administrator.
 </t>
 <t>
The "/snmp/vacm" subtree contains the configuration of the View-based
Access Control Model used by SNMP to authorize access to
management information via SNMP. Write access to this subtree should
only be granted to the security administrator.
 </t>
 </list>
</t>
    <t>
Some of the readable data nodes in the YANG module and submodules may
be considered sensitive or vulnerable in some network environments.
It is thus important to control read access (e.g., via get,
get-config, or notification) to these data nodes.  These are the
subtrees and data nodes and their sensitivity/vulnerability:
    </t>
<t>
 <list style="symbols">
 <t>
The "/snmp/engine" subtree exposes general information about
an SNMP engine such as which version(s) of SNMP are enabled or which
transports are enabled.
 </t>
 <t>
The "/snmp/target" subtree exposes information about which transports are
used to reach certain SNMP targets and which transport-specific
parameters are used.
 </t>
 <t>
The "/snmp/notify" and "/snmp/notify-filter-profile" subtrees expose
information about how notifications are filtered and forwarded to
notification targets.
 </t>
 <t>
The "/snmp/proxy" subtree exposes information about proxy
relationships.
 </t>
 <t>
The "/snmp/community", "/snmp/usm", "/snmp/tsm", "/snmp/tlstm", and
"/snmp/vacm" subtrees are specifically sensitive since they expose
information about the authentication and authorization policy used
by an SNMP engine.
 </t>
 </list>
</t>
    <t>
Changes to the SNMP access control rules should be done in an
atomic way (through a single edit-config or a single commit), or care
must be taken that they are done in a sequence that does not temporarily
open access to resources. Implementations supporting SNMP write
access must ensure that any SNMP access control rule changes over
NETCONF are also atomic to the SNMP instrumentation.  In particular,
changes involving an internal delete/create cycle (e.g., to move a
user to a different group) must be done with sufficient protections
such that even a power fail immediately after the delete does not
leave the administrator locked out.
    </t>
    <t>
Security administrators need to ensure that NETCONF access control
rules and SNMP access control rules implement a consistent security
policy. Specifically, the SNMP access control rules should prevent
accidental leakage of sensitive security parameters such as community
strings. See the Security Considerations section of <xref target="RFC3584"/> for
further details.
    </t>
</section>
</middle>
<back>
<references title="Normative References">

<reference anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>

</front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>

<reference anchor="RFC6020" target='http://www.rfc-editor.org/info/rfc6020'>

<front>
<title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'>
<organization /></author>
<date year='2010' month='October' />
</front>

<seriesInfo name='RFC' value='6020' />
<format type='TXT' octets='324178' target='http://www.rfc-editor.org/rfc/rfc6020.txt' />
</reference>


<reference anchor="RFC6991" target='http://www.rfc-editor.org/info/rfc6991'>
<front>
<title>Common YANG Data Types</title>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'>
<organization /></author>
<date year='2013' month='July' />
</front>

<seriesInfo name='RFC' value='6991' />
<format type='TXT' octets='60242' target='http://www.rfc-editor.org/rfc/rfc6991.txt' />
</reference>


<reference anchor="RFC6241" target='http://www.rfc-editor.org/info/rfc6241'>
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author initials='R.' surname='Enns' fullname='R. Enns'>
<organization /></author>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'>
<organization /></author>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'>
<organization /></author>
<author initials='A.' surname='Bierman' fullname='A. Bierman'>
<organization /></author>
<date year='2011' month='June' />
</front>
<seriesInfo name='RFC' value='6241' />
<format type='TXT' octets='209465' target='http://www.rfc-editor.org/rfc/rfc6241.txt' />
</reference>


<reference anchor="RFC6242" target='http://www.rfc-editor.org/info/rfc6242'>
<front>
<title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
<author initials='M.' surname='Wasserman' fullname='M. Wasserman'>
<organization /></author>
<date year='2011' month='June' />
</front>
<seriesInfo name='RFC' value='6242' />
<format type='TXT' octets='22704' target='http://www.rfc-editor.org/rfc/rfc6242.txt' />
</reference>


<reference anchor='RFC6536' target='http://www.rfc-editor.org/info/rfc6536'>

<front>
<title>Network Configuration Protocol (NETCONF) Access Control Model</title>
<author initials='A.' surname='Bierman' fullname='A. Bierman'>
<organization /></author>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'>
<organization /></author>
<date year='2012' month='March' />
</front>
<seriesInfo name='RFC' value='6536' />
<format type='TXT' octets='90803' target='http://www.rfc-editor.org/rfc/rfc6536.txt' />
</reference>


</references>

<references title="Informative References">

<reference anchor='RFC3411' target='http://www.rfc-editor.org/info/rfc3411'>
<front>
<title>An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks</title>
<author initials='D.' surname='Harrington' fullname='D. Harrington'>
<organization /></author>
<author initials='R.' surname='Presuhn' fullname='R. Presuhn'>
<organization /></author>
<author initials='B.' surname='Wijnen' fullname='B. Wijnen'>
<organization /></author>
<date year='2002' month='December' />
</front>
<seriesInfo name='STD' value='62' />
<seriesInfo name='RFC' value='3411' />
<format type='TXT' octets='140096' target='http://www.rfc-editor.org/rfc/rfc3411.txt' />
</reference>


<reference anchor='RFC3412' target='http://www.rfc-editor.org/info/rfc3412'>
<front>
<title>Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)</title>
<author initials='J.' surname='Case' fullname='J. Case'>
<organization /></author>
<author initials='D.' surname='Harrington' fullname='D. Harrington'>
<organization /></author>
<author initials='R.' surname='Presuhn' fullname='R. Presuhn'>
<organization /></author>
<author initials='B.' surname='Wijnen' fullname='B. Wijnen'>
<organization /></author>
<date year='2002' month='December' />
</front>
<seriesInfo name='STD' value='62' />
<seriesInfo name='RFC' value='3412' />
<format type='TXT' octets='95710' target='http://www.rfc-editor.org/rfc/rfc3412.txt' />
</reference>


<reference anchor='RFC3413' target='http://www.rfc-editor.org/info/rfc3413'>
<front>
<title>Simple Network Management Protocol (SNMP) Applications</title>
<author initials='D.' surname='Levi' fullname='D. Levi'>
<organization /></author>
<author initials='P.' surname='Meyer' fullname='P. Meyer'>
<organization /></author>
<author initials='B.' surname='Stewart' fullname='B. Stewart'>
<organization /></author>
<date year='2002' month='December' />
</front>
<seriesInfo name='STD' value='62' />
<seriesInfo name='RFC' value='3413' />
<format type='TXT' octets='153719' target='http://www.rfc-editor.org/rfc/rfc3413.txt' />
</reference>



<reference anchor='RFC3414' target='http://www.rfc-editor.org/info/rfc3414'>
<front>
<title>User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)</title>
<author initials='U.' surname='Blumenthal' fullname='U. Blumenthal'>
<organization /></author>
<author initials='B.' surname='Wijnen' fullname='B. Wijnen'>
<organization /></author>
<date year='2002' month='December' />
</front>
<seriesInfo name='STD' value='62' />
<seriesInfo name='RFC' value='3414' />
<format type='TXT' octets='193558' target='http://www.rfc-editor.org/rfc/rfc3414.txt' />
</reference>


<reference anchor='RFC3415' target='http://www.rfc-editor.org/info/rfc3415'>
<front>
<title>View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)</title>
<author initials='B.' surname='Wijnen' fullname='B. Wijnen'>
<organization /></author>
<author initials='R.' surname='Presuhn' fullname='R. Presuhn'>
<organization /></author>
<author initials='K.' surname='McCloghrie' fullname='K. McCloghrie'>
<organization /></author>
<date year='2002' month='December' />
</front>
<seriesInfo name='STD' value='62' />
<seriesInfo name='RFC' value='3415' />
<format type='TXT' octets='82046' target='http://www.rfc-editor.org/rfc/rfc3415.txt' />
</reference>

<reference anchor='RFC3417' target='http://www.rfc-editor.org/info/rfc3417'>

<front>
<title>Transport Mappings for the Simple Network Management Protocol (SNMP)</title>
<author initials='R.' surname='Presuhn' fullname='R. Presuhn'>
<organization /></author>
<date year='2002' month='December' />
</front>
<seriesInfo name='STD' value='62' />
<seriesInfo name='RFC' value='3417' />
<format type='TXT' octets='38650' target='http://www.rfc-editor.org/rfc/rfc3417.txt' />
</reference>



<reference anchor='RFC3418' target='http://www.rfc-editor.org/info/rfc3418'>
<front>
<title>Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)</title>
<author initials='R.' surname='Presuhn' fullname='R. Presuhn'>
<organization /></author>
<date year='2002' month='December' />
</front>
<seriesInfo name='STD' value='62' />
<seriesInfo name='RFC' value='3418' />
<format type='TXT' octets='49096' target='http://www.rfc-editor.org/rfc/rfc3418.txt' />
</reference>


<reference anchor='RFC3419' target='http://www.rfc-editor.org/info/rfc3419'>
<front>
<title>Textual Conventions for Transport Addresses</title>
<author initials='M.' surname='Daniele' fullname='M. Daniele'>
<organization /></author>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'>
<organization /></author>
<date year='2002' month='December' />
</front>
<seriesInfo name='RFC' value='3419' />
<format type='TXT' octets='37466' target='http://www.rfc-editor.org/rfc/rfc3419.txt' />
</reference>



<reference anchor='RFC3584' target='http://www.rfc-editor.org/info/rfc3584'>
<front>
<title>Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework</title>
<author initials='R.' surname='Frye' fullname='R. Frye'>
<organization /></author>
<author initials='D.' surname='Levi' fullname='D. Levi'>
<organization /></author>
<author initials='S.' surname='Routhier' fullname='S. Routhier'>
<organization /></author>
<author initials='B.' surname='Wijnen' fullname='B. Wijnen'>
<organization /></author>
<date year='2003' month='August' />
</front>
<seriesInfo name='BCP' value='74' />
<seriesInfo name='RFC' value='3584' />
<format type='TXT' octets='115222' target='http://www.rfc-editor.org/rfc/rfc3584.txt' />
</reference>


<reference anchor='RFC3688' target='http://www.rfc-editor.org/info/rfc3688'>
<front>
<title>The IETF XML Registry</title>
<author initials='M.' surname='Mealling' fullname='M. Mealling'>
<organization /></author>
<date year='2004' month='January' />
</front>
<seriesInfo name='BCP' value='81' />
<seriesInfo name='RFC' value='3688' />
<format type='TXT' octets='17325' target='http://www.rfc-editor.org/rfc/rfc3688.txt' />
</reference>


<reference anchor='RFC3826' target='http://www.rfc-editor.org/info/rfc3826'>
<front>
<title>The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model</title>
<author initials='U.' surname='Blumenthal' fullname='U. Blumenthal'>
<organization /></author>
<author initials='F.' surname='Maino' fullname='F. Maino'>
<organization /></author>
<author initials='K.' surname='McCloghrie' fullname='K. McCloghrie'>
<organization /></author>
<date year='2004' month='June' />
</front>
<seriesInfo name='RFC' value='3826' />
<format type='TXT' octets='32821' target='http://www.rfc-editor.org/rfc/rfc3826.txt' />
</reference>



<reference anchor="RFC5591" target='http://www.rfc-editor.org/info/rfc5591'>
<front>
<title>Transport Security Model for the Simple Network Management Protocol (SNMP)</title>
<author initials='D.' surname='Harrington' fullname='D. Harrington'>
<organization /></author>
<author initials='W.' surname='Hardaker' fullname='W. Hardaker'>
<organization /></author>
<date year='2009' month='June' />
</front>
<seriesInfo name='STD' value='78' />
<seriesInfo name='RFC' value='5591' />
<format type='TXT' octets='61747' target='http://www.rfc-editor.org/rfc/rfc5591.txt' />
</reference>


<reference anchor="RFC5592" target='http://www.rfc-editor.org/info/rfc5592'>
<front>
<title>Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)</title>
<author initials='D.' surname='Harrington' fullname='D. Harrington'>
<organization /></author>
<author initials='J.' surname='Salowey' fullname='J. Salowey'>
<organization /></author>
<author initials='W.' surname='Hardaker' fullname='W. Hardaker'>
<organization /></author>
<date year='2009' month='June' />
</front>
<seriesInfo name='RFC' value='5592' />
<format type='TXT' octets='82822' target='http://www.rfc-editor.org/rfc/rfc5592.txt' />
</reference>


<reference anchor="RFC6353" target='http://www.rfc-editor.org/info/rfc6353'>
<front>
<title>Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)</title>
<author initials='W.' surname='Hardaker' fullname='W. Hardaker'>
<organization /></author>
<date year='2011' month='July' />
</front>
<seriesInfo name='STD' value='78' />
<seriesInfo name='RFC' value='6353' />
<format type='TXT' octets='148571' target='http://www.rfc-editor.org/rfc/rfc6353.txt' />
</reference>


<reference anchor='RFC6643' target='http://www.rfc-editor.org/info/rfc6643'>
<front>
<title>Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules</title>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'>
<organization /></author>
<date year='2012' month='July' />
</front>
<seriesInfo name='RFC' value='6643' />
<format type='TXT' octets='69140' target='http://www.rfc-editor.org/rfc/rfc6643.txt' />
</reference>


</references>

<section title="Example Configurations">
<section title="Engine Configuration Example">
    <t>
Below is an XML instance document showing a configuration of an SNMP
engine listening on UDP port 161 on IPv4 and IPv6 endpoints and
accepting SNMPv2c and SNMPv3 messages.
    </t>
	<figure>
	    <artwork><![CDATA[
<snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
  <engine>
    <enabled>true</enabled>
    <listen>
      <name>all-ipv4-udp</name>
      <udp>
        <ip>0.0.0.0</ip>
        <port>161</port>
      </udp>
    </listen>
    <listen>
      <name>all-ipv6-udp</name>
      <udp>
        <ip>::</ip>
        <port>161</port>
      </udp>
    </listen>
    <version>
      <v2c/>
      <v3/>
    </version>
    <engine-id>80:00:02:b8:04:61:62:63</engine-id>
  </engine>
</snmp>
	    ]]></artwork>
	</figure>
</section>
<section title="Community Configuration Example" anchor="excommconfig">
    <t>
Below is an XML instance document showing a configuration that maps
the community name &quot;public&quot; to the security-name &quot;community&nbhy;public&quot; on
the local engine with the default context name. The target tag
&quot;community&nbhy;public&nbhy;access&quot; filters the access to this community name.
    </t>
	<figure>
	    <artwork><![CDATA[
<snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
  <community>
    <index>1</index>
    <text-name>public</text-name>
    <security-name>community-public</security-name>
    <target-tag>community-public-access</target-tag>
  </community>
  <target>
    <name>management-station</name>
    <udp>
      <ip>2001:db8::abcd</ip>
      <port>161</port>
    </udp>
    <tag>blue</tag>
    <tag>community-public-access</tag>
    <target-params>v2c-public</target-params>
  </target>
  <target-params>
    <name>v2c-public</name>
    <v2c>
      <security-name>community-public</security-name>
    </v2c>
  </target-params>
</snmp>
	    ]]></artwork>
	</figure>
</section>
<section title="User-Based Security Model Configuration Example" anchor="exuser">
    <t>
Below is an XML instance document showing the configuration of a local
user &quot;joey&quot; who has no authentication or privacy keys. For the remote
SNMP engine identified by the snmpEngineID &apos;800002b804616263&apos;H, two
users are configured. The user &quot;matt&quot; has a localized SHA
authentication key, and the user &quot;russ&quot; has a localized SHA
authentication key and an AES encryption key.
    </t>
	<figure>
	    <artwork><![CDATA[
<snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
  <usm>
    <local>
      <user>
        <name>joey</name>
      </user>
    </local>
    <remote>
      <engine-id>00:00:00:00:00:00:00:00:00:00:00:02</engine-id>
      <user>
        <name>matt</name>
        <auth>
          <sha>
            <!--
                The 'key' value is split into two lines to conform to
                the RFC formatting rules.
            -->
            <key>66:95:fe:bc:92:88:e3:62:82:23:
                 5f:c7:15:1f:12:84:97:b3:8f:3f</key>
          </sha>
        </auth>
      </user>
      <user>
        <name>russ</name>
        <auth>
          <sha>
            <!--
                The 'key' value is split into two lines to conform to
                the RFC formatting rules.
            -->
            <key>66:95:fe:bc:92:88:e3:62:82:23:
                 5f:c7:15:1f:12:84:97:b3:8f:3f</key>
          </sha>
        </auth>
        <priv>
          <aes>
            <!--
                The 'key' value is split into two lines to conform to
                the RFC formatting rules.
            -->
            <key>66:95:fe:bc:92:88:e3:62:82:23:
                 5f:c7:15:1f:12:84</key>
          </aes>
        </priv>
      </user>
    </remote>
  </usm>
  <target>
    <name>bluebox</name>
    <udp>
      <ip>2001:db8::abcd</ip>
      <port>161</port>
    </udp>
    <tag>blue</tag>
    <target-params>matt-auth</target-params>
  </target>
  <target-params>
    <name>matt-auth</name>
    <usm>
      <user-name>matt</user-name>
      <security-level>auth-no-priv</security-level>
    </usm>
  </target-params>
</snmp>
	    ]]></artwork>
	</figure>
</section>
<section title="Target and Notification Configuration Example" anchor="extarget">
    <t>
Below is an XML instance document showing the configuration of a
notification generator application (see Appendix A of <xref target="RFC3413"/>).
Note that the USM-specific objects are defined in the
"ietf-snmp-usm" submodule.
    </t>
	<figure>
	    <artwork><![CDATA[
<snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
  <target>
    <name>addr1</name>
    <udp>
      <ip>192.0.2.3</ip>
      <port>162</port>
    </udp>
    <tag>group1</tag>
    <target-params>joe-auth</target-params>
  </target>
  <target>
    <name>addr2</name>
    <udp>
      <ip>192.0.2.6</ip>
      <port>162</port>
    </udp>
    <tag>group1</tag>
    <target-params>joe-auth</target-params>
  </target>
  <target>
    <name>addr3</name>
    <udp>
      <ip>192.0.2.9</ip>
      <port>162</port>
    </udp>
    <tag>group2</tag>
    <target-params>bob-priv</target-params>
  </target>
  <target-params>
    <name>joe-auth</name>
    <usm>
      <user-name>joe</user-name>
      <security-level>auth-no-priv</security-level>
    </usm>
  </target-params>
  <target-params>
    <name>bob-priv</name>
    <usm>
      <user-name>bob</user-name>
      <security-level>auth-priv</security-level>
    </usm>
  </target-params>
  <notify>
    <name>group1</name>
    <tag>group1</tag>
    <type>trap</type>
  </notify>
  <notify>
    <name>group2</name>
    <tag>group2</tag>
    <type>trap</type>
  </notify>
</snmp>
	    ]]></artwork>
	</figure>
</section>
<section title="Proxy Configuration Example">
    <t>
Below is an XML instance document showing the configuration of a proxy
forwarder application.  It proxies SNMPv2c messages from command
generators to a file server running an SNMPv1 agent that recognizes two
community strings, &quot;private&quot; and &quot;public&quot;, with different associated
read views.  The file server is represented as two &quot;target&quot;
instances, one for each community string.
    </t>
    <t>
If the proxy receives an SNMPv2c message with the community string
&quot;public&quot; from a device in the &quot;Office Network&quot; or &quot;Home Office
Network&quot;, it gets tagged as &quot;trusted&quot;, and the proxy uses the
&quot;private&quot; community string when sending the message to the file
server.  Other SNMPv2c messages with the community string &quot;public&quot;
get tagged as &quot;non&nbhy;trusted&quot;, and the proxy uses the &quot;public&quot; community
string for these messages.   There is also a special &quot;backdoor&quot;
community string that can be used from any location to get &quot;trusted&quot;
access.
    </t>
    <t>
The &quot;Office Network&quot; and &quot;Home Office Network&quot; are represented as two
&quot;target&quot; instances.  These &quot;target&quot; instances have target-params
&quot;none&quot;, which refers to a non-existing target-params entry.
    </t>
	<figure>
	    <artwork><![CDATA[
<snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
  <target>
    <name>File Server (private)</name>
    <udp>
      <ip>192.0.2.1</ip>
    </udp>
    <target-params>v1-private</target-params>
  </target>
  <target>
    <name>File Server (public)</name>
    <udp>
      <ip>192.0.2.1</ip>
    </udp>
    <target-params>v1-public</target-params>
  </target>
  <target>
    <name>Office Network</name>
    <udp>
      <ip>192.0.2.0</ip>
      <prefix-length>24</prefix-length>
    </udp>
    <tag>office</tag>
    <target-params>none</target-params>
  </target>
  <target>
    <name>Home Office Network</name>
    <udp>
      <ip>203.0.113.0</ip>
      <prefix-length>24</prefix-length>
    </udp>
    <tag>home-office</tag>
    <target-params>none</target-params>
  </target>
  <target-params>
    <name>v1-private</name>
    <v1>
      <security-name>private</security-name>
    </v1>
  </target-params>
  <target-params>
    <name>v1-public</name>
    <v1>
      <security-name>public</security-name>
    </v1>
  </target-params>
  <target-params>
    <name>v2c-public</name>
    <v2c>
      <security-name>public</security-name>
    </v2c>
  </target-params>

  <!--
      Communities c1, c2, c3, and c4 are used for incoming messages
      that should be forwarded.

      Communities c3 and c5 are used for outgoing messages to the
      file server.
  -->
  <community>
    <index>c1</index>
    <security-name>public</security-name>
    <engine-id>80:00:61:81:c8</engine-id>
    <context>trusted</context>
    <target-tag>office</target-tag>
  </community>
  <community>
    <index>c2</index>
    <security-name>public</security-name>
    <engine-id>80:00:61:81:c8</engine-id>
    <context>trusted</context>
    <target-tag>home-office</target-tag>
  </community>
  <community>
    <index>c3</index>
    <security-name>public</security-name>
    <engine-id>80:00:61:81:c8</engine-id>
    <context>not-trusted</context>
  </community>
  <community>
    <index>c4</index>
    <text-name>backdoor</text-name>
    <security-name>public</security-name>
    <engine-id>80:00:61:81:c8</engine-id>
    <context>trusted</context>
  </community>
  <community>
    <index>c5</index>
    <security-name>private</security-name>
    <engine-id>80:00:61:81:c8</engine-id>
    <context>trusted</context>
  </community>

  <proxy>
    <name>p1</name>
    <type>read</type>
    <context-engine-id>80:00:61:81:c8</context-engine-id>
    <context-name>trusted</context-name>
    <target-params-in>v2c-public</target-params-in>
    <single-target-out>File Server (private)</single-target-out>
  </proxy>
  <proxy>
    <name>p2</name>
    <type>read</type>
    <context-engine-id>80:00:61:81:c8</context-engine-id>
    <context-name>not-trusted</context-name>
    <target-params-in>v2c-public</target-params-in>
    <single-target-out>File Server (public)</single-target-out>
  </proxy>
</snmp>
	    ]]></artwork>
	</figure>
    <t>
If an SNMPv2c Get request with community string &quot;public&quot; is received
from an IP address tagged as &quot;office&quot; or &quot;home&nbhy;office&quot;, or if the
request is received from anywhere else with community string
&quot;backdoor&quot;, the implied context is &quot;trusted&quot; so
proxy entry &quot;p1&quot; matches.  The request is forwarded to the file
server as SNMPv1 with community &quot;private&quot; using community table
entry &quot;c5&quot; for outbound params lookup.
    </t>
    <t>
If an SNMPv2c Get request with community string &quot;public&quot; is received
from any other IP address, the implied context is &quot;not&nbhy;trusted&quot; so
proxy entry &quot;p2&quot; matches, and the request is forwarded to the file
server as SNMPv1 with community &quot;public&quot;.
    </t>
</section>
<section title="View-Based Access Control Model Configuration Example">
    <t>
Below is an XML instance document showing the minimum-secure VACM
configuration (see Appendix A of <xref target="RFC3415"/>).
    </t>
	<figure>
	    <artwork><![CDATA[
<snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
  <vacm>
    <group>
      <name>initial</name>
      <member>
        <security-name>initial</security-name>
        <security-model>usm</security-model>
      </member>
      <access>
        <context></context>
        <security-model>usm</security-model>
        <security-level>no-auth-no-priv</security-level>
        <read-view>restricted</read-view>
        <notify-view>restricted</notify-view>
      </access>
      <access>
        <context></context>
        <security-model>usm</security-model>
        <security-level>auth-no-priv</security-level>
        <read-view>internet</read-view>
        <write-view>internet</write-view>
        <notify-view>internet</notify-view>
      </access>
    </group>
    <view>
      <name>initial</name>
      <include>1.3.6.1</include>
    </view>
    <view>
      <name>restricted</name>
      <include>1.3.6.1</include>
    </view>
  </vacm>
</snmp>
	    ]]></artwork>
	</figure>
    <t>
The following XML instance document shows the semi-secure VACM
configuration (only the view configuration is different).
    </t>
	<figure>
	    <artwork><![CDATA[
<snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
  <vacm>
    <group>
      <name>initial</name>
      <member>
        <security-name>initial</security-name>
        <security-model>usm</security-model>
      </member>
      <access>
        <context></context>
        <security-model>usm</security-model>
        <security-level>no-auth-no-priv</security-level>
        <read-view>restricted</read-view>
        <notify-view>restricted</notify-view>
      </access>
      <access>
        <context></context>
        <security-model>usm</security-model>
        <security-level>auth-no-priv</security-level>
        <read-view>internet</read-view>
        <write-view>internet</write-view>
        <notify-view>internet</notify-view>
      </access>
    </group>
    <view>
      <name>initial</name>
      <include>1.3.6.1</include>
    </view>
    <view>
      <name>restricted</name>
      <include>1.3.6.1.2.1.1</include>
      <include>1.3.6.1.2.1.11</include>
      <include>1.3.6.1.6.3.10.2.1</include>
      <include>1.3.6.1.6.3.11.2.1</include>
      <include>1.3.6.1.6.3.15.1.1</include>
    </view>
  </vacm>
</snmp>
	    ]]></artwork>
	</figure>
</section>
<section title="Transport Layer Security Transport Model Configuration Example">
    <t>
Below is an XML instance document showing the configuration of the
mapping of certificate to security name (see Appendices A.2 and A.3 of
<xref target="RFC6353"/>).
    </t>
	<figure>
	    <artwork><![CDATA[
<snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp"
      xmlns:x509c2n=
        "urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name">
  <tlstm>
    <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>11:0A:05:11:00</fingerprint>
      <map-type>x509c2n:specified</map-type>
      <name>
        Joe Cool
      </name>
    </cert-to-name>
  </tlstm>
</snmp>	    ]]></artwork>
	</figure>
</section>
</section>

<section title="Acknowledgments">
    <t>
The authors want to thank Wes Hardaker and David Spakes for their
detailed reviews. Additional valuable comments were provided by David
Harrington, Borislav Lukovic, and Randy Presuhn.
    </t>
    <t>
Juergen Schoenwaelder was partly funded by Flamingo, a Network of
Excellence project (ICT-318488) supported by the European Commission
under its Seventh Framework Programme.
    </t>
</section>


</back></rfc>
