doc: Add RFC documents

1 files changed, 4931 insertions, 0 deletions

diff --git a/doc/rfc/rfc7407.txt b/doc/rfc/rfc7407.txt
new file mode 100644
index 0000000..051a0dc
--- /dev/null
+++ b/doc/rfc/rfc7407.txt
@@ -0,0 +1,4931 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      M. Bjorklund
+Request for Comments: 7407                                Tail-f Systems
+Category: Standards Track                               J. Schoenwaelder
+ISSN: 2070-1721                                        Jacobs University
+                                                           December 2014
+
+
+                A YANG Data Model for SNMP Configuration
+
+Abstract
+
+   This document defines a collection of YANG definitions for
+   configuring SNMP engines.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7407.
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                    [Page 1]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Data Model ......................................................3
+      2.1. Tree Diagrams ..............................................4
+      2.2. General Considerations .....................................4
+      2.3. Common Definitions .........................................4
+      2.4. Engine Configuration .......................................5
+      2.5. Target Configuration .......................................6
+      2.6. Notification Configuration .................................7
+      2.7. Proxy Configuration ........................................8
+      2.8. Community Configuration ....................................8
+      2.9. View-Based Access Control Model Configuration ..............9
+      2.10. User-Based Security Model Configuration ..................10
+      2.11. Transport Security Model Configuration ...................11
+      2.12. Transport Layer Security Transport Model Configuration ...12
+      2.13. Secure Shell Transport Model Configuration ...............13
+   3. Implementation Guidelines ......................................14
+      3.1. Supporting read-only SNMP Access ..........................15
+      3.2. Supporting read-write SNMP Access .........................15
+   4. Definitions ....................................................16
+      4.1. Module 'ietf-x509-cert-to-name' ...........................16
+      4.2. Module 'ietf-snmp' ........................................22
+      4.3. Submodule 'ietf-snmp-common' ..............................24
+      4.4. Submodule 'ietf-snmp-engine' ..............................28
+      4.5. Submodule 'ietf-snmp-target' ..............................32
+      4.6. Submodule 'ietf-snmp-notification' ........................36
+      4.7. Submodule 'ietf-snmp-proxy' ...............................41
+      4.8. Submodule 'ietf-snmp-community' ...........................44
+      4.9. Submodule 'ietf-snmp-vacm' ................................49
+      4.10. Submodule 'ietf-snmp-usm' ................................55
+      4.11. Submodule 'ietf-snmp-tsm' ................................60
+      4.12. Submodule 'ietf-snmp-tls' ................................63
+      4.13. Submodule 'ietf-snmp-ssh' ................................68
+   5. IANA Considerations ............................................71
+   6. Security Considerations ........................................72
+   7. References .....................................................75
+      7.1. Normative References ......................................75
+      7.2. Informative References ....................................75
+   Appendix A.  Example Configurations ...............................78
+     A.1.  Engine Configuration Example ..............................78
+     A.2.  Community Configuration Example ...........................78
+     A.3.  User-Based Security Model Configuration Example ...........79
+     A.4.  Target and Notification Configuration Example .............81
+     A.5.  Proxy Configuration Example ...............................82
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                    [Page 2]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     A.6.  View-Based Access Control Model Configuration Example .....85
+     A.7.  Transport Layer Security Transport Model Configuration
+           Example ...................................................87
+   Acknowledgments ...................................................88
+   Authors' Addresses ................................................88
+
+1.  Introduction
+
+   This document defines a YANG [RFC6020] data model for the
+   configuration of SNMP engines.  The configuration model is consistent
+   with the MIB modules defined in [RFC3411], [RFC3412], [RFC3413],
+   [RFC3414], [RFC3415], [RFC3417], [RFC3418], [RFC3419], [RFC3584],
+   [RFC3826], [RFC5591], [RFC5592], and [RFC6353] but takes advantage of
+   YANG's ability to define hierarchical configuration data models.
+
+   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 Section 3.
+
+   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 [RFC6643].
+
+   This document also defines a YANG data model for mapping an X.509
+   certificate to a name.
+
+   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in BCP
+   14 [RFC2119].
+
+2.  Data Model
+
+   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.
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                    [Page 3]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+2.1.  Tree Diagrams
+
+   A simplified graphical representation of the data model is used in
+   this document.  The meaning of the symbols in these diagrams is as
+   follows:
+
+   o  Brackets "[" and "]" enclose list keys.
+
+   o  Abbreviations before data node names: "rw" means configuration
+      (read-write), and "ro" means state data (read-only).
+
+   o  Symbols after data node names: "?" means an optional node, "!"
+      means a presence container, and "*" denotes a list and leaf-list.
+
+   o  Parentheses enclose choice and case nodes, and case nodes are also
+      marked with a colon (":").
+
+   o  Ellipsis ("...") stands for contents of subtrees that are not
+      shown.
+
+2.2.  General Considerations
+
+   Most YANG nodes are mapped 1-1 to the corresponding MIB object.  The
+   "reference" 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 "description" statement explains the mapping.
+
+   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 "StorageType".  Thus, in
+   the YANG model defined here, the "StorageType" columns are not
+   present.  For implementation guidelines, see Section 3.
+
+   In SNMP, row creation and deletion are controlled using the Textual
+   Convention "RowStatus".  In NETCONF, creation and deletion are
+   handled by the protocol, not in the data model.  Thus, in the YANG
+   model defined here, the "RowStatus" columns are not present.
+
+2.3.  Common Definitions
+
+   The submodule "ietf-snmp-common" defines a set of common typedefs and
+   the top-level container "snmp".  All configuration parameters defined
+   in the other submodules are organized under this top-level container.
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                    [Page 4]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+2.4.  Engine Configuration
+
+   The submodule "ietf-snmp-engine", which defines configuration
+   parameters that are specific to SNMP engines, has the following
+   structure:
+
+      +--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
+
+   The leaf "/snmp/engine/enabled" can be used to enable/disable an SNMP
+   engine.
+
+   The list "/snmp/engine/listen" 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 "ietf-snmp-ssh" (Section 2.13) and
+   "ietf-snmp-tls" (Section 2.12), respectively.  The "transport" choice
+   is expected to be augmented for other transports.
+
+   The "/snmp/engine/version" container can be used to enable/disable
+   the different message processing models [RFC3411].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                    [Page 5]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+2.5.  Target Configuration
+
+   The submodule "ietf-snmp-target", which defines configuration
+   parameters that correspond to the objects in SNMP-TARGET-MIB, has the
+   following structure:
+
+      +--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)?
+
+   An entry in the list "/snmp/target" corresponds to an
+   "snmpTargetAddrEntry".
+
+   The "snmpTargetAddrTDomain" and "snmpTargetAddrTAddress" objects are
+   mapped to transport-specific YANG nodes.  Each transport is
+   configured as a separate case in the "transport" choice.  In this
+   submodule, SNMP over UDP is defined.  TLS and DTLS are also
+   supported, defined in "ietf-snmp-tls" (Section 2.12).  The
+   "transport" choice is expected to be augmented for other transports.
+
+   An entry in the list "/snmp/target-params" corresponds to an
+   "snmpTargetParamsEntry".  This list contains a choice "params", which
+   is augmented by submodules specific to the security model, currently,
+   "ietf-snmp-community" (Section 2.8), "ietf-snmp-usm" (Section 2.10),
+   and "ietf-snmp-tls" (Section 2.12).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                    [Page 6]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+2.6.  Notification Configuration
+
+   The submodule "ietf-snmp-notification", which defines configuration
+   parameters that correspond to the objects in SNMP-NOTIFICATION-MIB,
+   has the following structure:
+
+      +--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
+
+   This submodule also augments the "target-params" list defined in the
+   "ietf-snmp-target" submodule (Section 2.5) with one leaf:
+
+      +--rw snmp
+         +--rw target-params* [name]
+            ...
+            +--rw notify-filter-profile?   leafref
+
+   An entry in the list "/snmp/notify" corresponds to an
+   "snmpNotifyEntry".
+
+   An entry in the list "/snmp/notify-filter-profile" corresponds to an
+   "snmpNotifyFilterProfileEntry".  In the MIB, there is a sparse
+   relationship between "snmpTargetParamsTable" and
+   "snmpNotifyFilterProfileTable".  In the YANG model, this sparse
+   relationship is represented with a leafref leaf
+   "notify-filter-profile" in the "/snmp/target-params" list, which
+   refers to an entry in the "/snmp/notify-filter-profile" list.
+
+   The "snmpNotifyFilterTable" is represented as a list "filter" within
+   the "/snmp/notify-filter-profile" list.
+
+   This submodule defines the feature "notification-filter".  A server
+   implements this feature if it supports SNMP notification filtering
+   [RFC3413].
+
+
+
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                    [Page 7]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+2.7.  Proxy Configuration
+
+   The submodule "ietf-snmp-proxy", which defines configuration
+   parameters that correspond to the objects in SNMP-PROXY-MIB, has the
+   following structure:
+
+      +--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
+
+   An entry in the list "/snmp/proxy" corresponds to an
+   "snmpProxyEntry".
+
+   This submodule defines the feature "proxy".  A server implements this
+   feature if it can act as an SNMP proxy [RFC3413].
+
+2.8.  Community Configuration
+
+   The submodule "ietf-snmp-community", which defines configuration
+   parameters that correspond to the objects in SNMP-COMMUNITY-MIB, has
+   the following structure:
+
+      +--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
+
+   This submodule also augments the "/snmp/target-params/params" choice
+   with nodes for the Community-based Security Model used by SNMPv1 and
+   SNMPv2c:
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                    [Page 8]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+      +--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
+
+   An entry in the list "/snmp/community" corresponds to an
+   "snmpCommunityEntry".
+
+   When a case "v1" or "v2c" 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.
+
+2.9.  View-Based Access Control Model Configuration
+
+   The submodule "ietf-snmp-vacm", which defines configuration
+   parameters that correspond to the objects in SNMP-VIEW-BASED-ACM-MIB,
+   has the following structure:
+
+      +--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
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                    [Page 9]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+   The "vacmSecurityToGroupTable" and "vacmAccessTable" are mapped to a
+   structure of nested lists in the YANG model.  Groups are defined in
+   the list "/snmp/vacm/group", and for each group, there is a sublist
+   "member" that maps to "vacmSecurityToGroupTable" and a sublist
+   "access" that maps to "vacmAccessTable".
+
+   MIB views are defined in the list "/snmp/vacm/view", 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 "vacmViewTreeFamilyTable".
+
+2.10.  User-Based Security Model Configuration
+
+   The submodule "ietf-snmp-usm", which defines configuration parameters
+   that correspond to the objects in SNMP-USER-BASED-SM-MIB, has the
+   following structure:
+
+      +--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}
+
+   The "{common user params}" are:
+
+      +--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
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 10]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+   This submodule also augments the "/snmp/target-params/params" choice
+   with nodes for the SNMP User-based Security Model.
+
+      +--rw snmp
+         +--rw target-params* [name]
+            ...
+            +--rw (params)?
+               +--:(usm)
+                  +--rw usm
+                     +--rw user-name         snmp:security-name
+                     +--rw security-level    security-level
+
+   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.
+
+   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.
+
+2.11.  Transport Security Model Configuration
+
+   The submodule "ietf-snmp-tsm", which defines configuration parameters
+   that correspond to the objects in SNMP-TSM-MIB, has the following
+   structure:
+
+      +--rw snmp
+         +--rw tsm
+            +--rw use-prefix?   boolean
+
+   This submodule also augments the "/snmp/target-params/params" choice
+   with nodes for the SNMP Transport Security Model.
+
+      +--rw snmp
+         +--rw target-params* [name]
+            ...
+            +--rw (params)?
+               +--:(tsm)
+                  +--rw tsm
+                     +--rw security-name     snmp:security-name
+                     +--rw security-level    security-level
+
+   This submodule defines the feature "tsm".  A server implements this
+   feature if it supports the Transport Security Model (TSM) [RFC5591].
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 11]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+2.12.  Transport Layer Security Transport Model Configuration
+
+   The submodule "ietf-snmp-tls", which defines configuration parameters
+   that correspond to the objects in SNMP-TLS-TM-MIB, has the following
+   structure:
+
+      +--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
+
+   The "{common (d)tls transport params}" are:
+
+      +--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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 12]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+   This submodule also augments the "/snmp/engine/listen/transport"
+   choice with objects for the D(TLS) transport endpoints:
+
+      +--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
+
+   This submodule defines the feature "tlstm".  A server implements this
+   feature if it supports the Transport Layer Security (TLS) Transport
+   Model (TLSTM) [RFC6353].
+
+2.13.  Secure Shell Transport Model Configuration
+
+   The submodule "ietf-snmp-ssh", which defines configuration parameters
+   that correspond to the objects in SNMP-SSH-TM-MIB, has the following
+   structure:
+
+      +--rw snmp
+         ...
+         +--rw target* [name]
+           ...
+           +--rw (transport)
+              ...
+              +--:(ssh)
+                 +--rw ssh
+                    +--rw ip          inet:host
+                    +--rw port?       inet:port-number
+                    +--rw username?   string
+
+
+
+
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 13]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+   It also augments the "/snmp/engine/listen/transport" choice with
+   objects for the SSH transport endpoints:
+
+      +--rw snmp
+         +--rw engine
+            ...
+            +--rw listen* [name]
+               ...
+               +--rw (transport)
+                  ...
+                  +--:(ssh)
+                     +--rw ssh
+                        +--rw ip          inet:host
+                        +--rw port?       inet:port-number
+                        +--rw username?   string
+
+   This submodule defines the feature "sshtm".  A server implements this
+   feature if it supports the Secure Shell Transport Model (SSHTM)
+   [RFC5592].
+
+3.  Implementation Guidelines
+
+   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.
+
+   As described in Section 2.2, 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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 14]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+3.1.  Supporting read-only SNMP Access
+
+   If a device implements only :writable-running, it is trivial to map
+   the contents of "running" to data in the SNMP tables, where all
+   instances of the StorageType columns have the value "nonVolatile".
+
+   If a device implements :candidate but not :startup, the
+   implementation may choose to not expose the contents of the
+   "candidate" datastore over SNMP and map the contents of "running" as
+   described above.  As an option, the contents of "candidate" might be
+   accessible in a separate SNMP context.
+
+   If a device implements :startup, the handling of StorageType becomes
+   more difficult.  Since the contents of "running" and "startup" might
+   differ, data in "running" cannot automatically be mapped to instances
+   with StorageType "nonVolatile".  If a particular entry exists in
+   "running" but not in "startup", its StorageType should be "volatile".
+   If a particular entry exists in "startup" but not "running", it
+   should not be mapped to an SNMP instance, at least not in the default
+   SNMP context.
+
+3.2.  Supporting read-write SNMP Access
+
+   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.
+
+   The SNMP tables contain a mix of configured data and operational
+   state, and only rows with an "active" RowStatus column should be
+   stored in a configuration datastore.
+
+   If a device implements only :writable-running, "active" rows with a
+   "nonVolatile" StorageType column can be stored in "running".  Rows
+   with a "volatile" StorageType column are operational state.
+
+   If a device implements :candidate but not :writable-running, all
+   configuration changes typically go through the "candidate", even if
+   they are done over SNMP.  An implementation might have to perform
+   some automatic commit of the "candidate" when data is written over
+   SNMP, since there is no explicit "commit" operation in SNMP.
+
+   If a device implements :startup, "nonVolatile" rows cannot just be
+   written to "running"; they must also be copied into "startup".
+   "volatile" rows may be treated as operational state and not copied to
+   any datastore, or they may be copied into "running".
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 15]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+   Cooperating SNMP management applications may use spin lock objects
+   (snmpTargetSpinLock [RFC3413], usmUserSpinLock [RFC3414],
+   vacmViewSpinLock [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.
+
+4.  Definitions
+
+4.1.  Module 'ietf-x509-cert-to-name'
+
+   This YANG module imports typedefs from [RFC6991].
+
+   <CODE BEGINS> file "ietf-x509-cert-to-name.yang"
+
+   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.
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 16]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+        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";
+     }
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 17]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     /* 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";
+     }
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 18]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     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";
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 19]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     }
+
+     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
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 20]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+           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;
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 21]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+           }
+           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";
+         }
+       }
+     }
+   }
+
+   <CODE ENDS>
+
+4.2.  Module 'ietf-snmp'
+
+   <CODE BEGINS> file "ietf-snmp.yang"
+
+   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 {
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 22]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+       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>";
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 23]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     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";
+     }
+
+   }
+
+   <CODE ENDS>
+
+4.3.  Submodule 'ietf-snmp-common'
+
+   <CODE BEGINS> file "ietf-snmp-common.yang"
+
+   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>
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 24]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+        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.";
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 25]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+       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";
+         }
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 26]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+       }
+       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
+         ('*').";
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 27]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     }
+
+     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.";
+     }
+
+   }
+
+   <CODE ENDS>
+
+4.4.  Submodule 'ietf-snmp-engine'
+
+   <CODE BEGINS> file "ietf-snmp-engine.yang"
+
+   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/>
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 28]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+        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
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 29]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+             "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.";
+                 }
+               }
+             }
+           }
+         }
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 30]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+         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";
+         }
+       }
+     }
+   }
+
+   <CODE ENDS>
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 31]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+4.5.  Submodule 'ietf-snmp-target'
+
+   <CODE BEGINS> file "ietf-snmp-target.yang"
+
+   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).
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 32]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+        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.";
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 33]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+           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.";
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 34]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+                 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";
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 35]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+         }
+       }
+
+       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.";
+         }
+       }
+     }
+   }
+
+   <CODE ENDS>
+
+4.6.  Submodule 'ietf-snmp-notification'
+
+   <CODE BEGINS> file "ietf-snmp-notification.yang"
+
+   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>
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 36]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+        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 {
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 37]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+       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.";
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 38]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+           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.";
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 39]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+           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";
+       }
+     }
+
+   }
+
+   <CODE ENDS>
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 40]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+4.7.  Submodule 'ietf-snmp-proxy'
+
+   <CODE BEGINS> file "ietf-snmp-proxy.yang"
+
+   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.";
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 41]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     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; }
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 42]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+           }
+           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";
+         }
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 43]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+         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";
+         }
+       }
+     }
+   }
+
+   <CODE ENDS>
+
+4.8.  Submodule 'ietf-snmp-community'
+
+   <CODE BEGINS> file "ietf-snmp-community.yang"
+
+   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>
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 44]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+        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";
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 45]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+         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";
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 46]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+         }
+         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',
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 47]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+            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;
+       }
+     }
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 48]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     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";
+       }
+     }
+
+   }
+
+   <CODE ENDS>
+
+4.9.  Submodule 'ietf-snmp-vacm'
+
+   <CODE BEGINS> file "ietf-snmp-vacm.yang"
+
+   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>
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 49]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+        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.";
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 50]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     }
+
+     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";
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 51]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+             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; }
+               }
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 52]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+               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;
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 53]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+               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.";
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 54]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+             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";
+           }
+         }
+       }
+     }
+   }
+
+   <CODE ENDS>
+
+4.10.  Submodule 'ietf-snmp-usm'
+
+   This YANG submodule imports YANG extensions from [RFC6536].
+
+   <CODE BEGINS> file "ietf-snmp-usm.yang"
+
+   submodule ietf-snmp-usm {
+
+     belongs-to ietf-snmp {
+       prefix snmp;
+     }
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 55]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     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.";
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 56]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     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";
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 57]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+             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;
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 58]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+               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;
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 59]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+           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;
+       }
+     }
+
+   }
+
+   <CODE ENDS>
+
+4.11.  Submodule 'ietf-snmp-tsm'
+
+   <CODE BEGINS> file "ietf-snmp-tsm.yang"
+
+   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>
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 60]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+        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)";
+     }
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 61]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     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;
+       }
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 62]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     }
+
+   }
+
+   <CODE ENDS>
+
+4.12.  Submodule 'ietf-snmp-tls'
+
+   <CODE BEGINS> file "ietf-snmp-tls.yang"
+
+   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>";
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 63]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     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.";
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 64]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+           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.";
+           }
+         }
+       }
+     }
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 65]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     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).
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 66]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+              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;
+         }
+       }
+     }
+   }
+
+   <CODE ENDS>
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 67]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+4.13.  Submodule 'ietf-snmp-ssh'
+
+   <CODE BEGINS> file "ietf-snmp-ssh.yang"
+
+   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
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 68]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+        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.
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 69]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+                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";
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 70]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+           }
+         }
+       }
+     }
+   }
+
+
+   <CODE ENDS>
+
+5.  IANA Considerations
+
+   This document registers two URIs in the "IETF XML Registry"
+   [RFC3688].  Following the format in RFC 3688, the following
+   registrations have been made.
+
+        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.
+
+   This document registers the following YANG modules in the "YANG
+   Module Names" registry [RFC6020].
+
+        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
+   The document registers the following YANG submodules in the "YANG
+   Module Names" registry [RFC6020].
+
+        name:         ietf-snmp-common
+        parent:       ietf-snmp
+        reference:    RFC 7407
+
+        name:         ietf-snmp-engine
+        parent:       ietf-snmp
+        reference:    RFC 7407
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 71]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+        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
+
+6.  Security Considerations
+
+   The YANG module and submodules defined in this memo are designed to
+   be accessed via the NETCONF protocol [RFC6241].  The lowest NETCONF
+   layer is the secure transport layer and the mandatory to implement
+   secure transport is SSH [RFC6242].  The NETCONF access control model
+   [RFC6536] provides the means to restrict access for particular
+   NETCONF users to a pre-configured subset of all available NETCONF
+   protocol operations and content.
+
+   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.,
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 72]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+   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:
+
+   o  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's
+      identity.  Write access to this subtree should only be granted to
+      entities configuring general SNMP engine parameters.
+
+   o  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.
+
+   o  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.
+
+   o  The "/snmp/proxy" subtree contains the configuration for SNMP
+      proxies.  Write access to this subtree should only be granted to
+      entities configuring SNMP proxies.
+
+   o  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.
+
+   o  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.
+
+   o  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.
+
+   o  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.
+
+   o  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.
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 73]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+   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:
+
+   o  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.
+
+   o  The "/snmp/target" subtree exposes information about which
+      transports are used to reach certain SNMP targets and which
+      transport-specific parameters are used.
+
+   o  The "/snmp/notify" and "/snmp/notify-filter-profile" subtrees
+      expose information about how notifications are filtered and
+      forwarded to notification targets.
+
+   o  The "/snmp/proxy" subtree exposes information about proxy
+      relationships.
+
+   o  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.
+
+   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.
+
+   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 [RFC3584] for
+   further details.
+
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 74]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
+              Network Configuration Protocol (NETCONF)", RFC 6020,
+              October 2010, <http://www.rfc-editor.org/info/rfc6020>.
+
+   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
+              Bierman, "Network Configuration Protocol (NETCONF)", RFC
+              6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
+
+   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
+              Shell (SSH)", RFC 6242, June 2011,
+              <http://www.rfc-editor.org/info/rfc6242>.
+
+   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
+              Protocol (NETCONF) Access Control Model", RFC 6536, March
+              2012, <http://www.rfc-editor.org/info/rfc6536>.
+
+   [RFC6991]  Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
+              July 2013, <http://www.rfc-editor.org/info/rfc6991>.
+
+7.2.  Informative References
+
+   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
+              Architecture for Describing Simple Network Management
+              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
+              December 2002, <http://www.rfc-editor.org/info/rfc3411>.
+
+   [RFC3412]  Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
+              "Message Processing and Dispatching for the Simple Network
+              Management Protocol (SNMP)", STD 62, RFC 3412, December
+              2002, <http://www.rfc-editor.org/info/rfc3412>.
+
+   [RFC3413]  Levi, D., Meyer, P., and B. Stewart, "Simple Network
+              Management Protocol (SNMP) Applications", STD 62, RFC
+              3413, December 2002,
+              <http://www.rfc-editor.org/info/rfc3413>.
+
+   [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model
+              (USM) for version 3 of the Simple Network Management
+              Protocol (SNMPv3)", STD 62, RFC 3414, December 2002,
+              <http://www.rfc-editor.org/info/rfc3414>.
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 75]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+   [RFC3415]  Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
+              Access Control Model (VACM) for the Simple Network
+              Management Protocol (SNMP)", STD 62, RFC 3415, December
+              2002, <http://www.rfc-editor.org/info/rfc3415>.
+
+   [RFC3417]  Presuhn, R., "Transport Mappings for the Simple Network
+              Management Protocol (SNMP)", STD 62, RFC 3417, December
+              2002, <http://www.rfc-editor.org/info/rfc3417>.
+
+   [RFC3418]  Presuhn, R., "Management Information Base (MIB) for the
+              Simple Network Management Protocol (SNMP)", STD 62, RFC
+              3418, December 2002,
+              <http://www.rfc-editor.org/info/rfc3418>.
+
+   [RFC3419]  Daniele, M. and J. Schoenwaelder, "Textual Conventions for
+              Transport Addresses", RFC 3419, December 2002,
+              <http://www.rfc-editor.org/info/rfc3419>.
+
+   [RFC3584]  Frye, R., Levi, D., Routhier, S., and B. Wijnen,
+              "Coexistence between Version 1, Version 2, and Version 3
+              of the Internet-standard Network Management Framework",
+              BCP 74, RFC 3584, August 2003,
+              <http://www.rfc-editor.org/info/rfc3584>.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              January 2004, <http://www.rfc-editor.org/info/rfc3688>.
+
+   [RFC3826]  Blumenthal, U., Maino, F., and K. McCloghrie, "The
+              Advanced Encryption Standard (AES) Cipher Algorithm in the
+              SNMP User-based Security Model", RFC 3826, June 2004,
+              <http://www.rfc-editor.org/info/rfc3826>.
+
+   [RFC5591]  Harrington, D. and W. Hardaker, "Transport Security Model
+              for the Simple Network Management Protocol (SNMP)", STD
+              78, RFC 5591, June 2009,
+              <http://www.rfc-editor.org/info/rfc5591>.
+
+   [RFC5592]  Harrington, D., Salowey, J., and W. Hardaker, "Secure
+              Shell Transport Model for the Simple Network Management
+              Protocol (SNMP)", RFC 5592, June 2009,
+              <http://www.rfc-editor.org/info/rfc5592>.
+
+   [RFC6353]  Hardaker, W., "Transport Layer Security (TLS) Transport
+              Model for the Simple Network Management Protocol (SNMP)",
+              STD 78, RFC 6353, July 2011,
+              <http://www.rfc-editor.org/info/rfc6353>.
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 76]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+   [RFC6643]  Schoenwaelder, J., "Translation of Structure of Management
+              Information Version 2 (SMIv2) MIB Modules to YANG
+              Modules", RFC 6643, July 2012,
+              <http://www.rfc-editor.org/info/rfc6643>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 77]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+Appendix A.  Example Configurations
+
+A.1.  Engine Configuration Example
+
+   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.
+
+   <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>
+
+A.2.  Community Configuration Example
+
+   Below is an XML instance document showing a configuration that maps
+   the community name "public" to the security-name "community-public"
+   on the local engine with the default context name.  The target tag
+   "community-public-access" filters the access to this community name.
+
+   <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>
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 78]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+       <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>
+
+A.3.  User-Based Security Model Configuration Example
+
+   Below is an XML instance document showing the configuration of a
+   local user "joey" who has no authentication or privacy keys.  For the
+   remote SNMP engine identified by the snmpEngineID
+   '800002b804616263'H, two users are configured.  The user "matt" has a
+   localized SHA authentication key, and the user "russ" has a localized
+   SHA authentication key and an AES encryption key.
+
+   <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>
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 79]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+         <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>
+
+
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 80]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+A.4.  Target and Notification Configuration Example
+
+   Below is an XML instance document showing the configuration of a
+   notification generator application (see Appendix A of [RFC3413]).
+   Note that the USM-specific objects are defined in the "ietf-snmp-usm"
+   submodule.
+
+   <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>
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 81]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     </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>
+
+A.5.  Proxy Configuration Example
+
+   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, "private" and "public", with
+   different associated read views.  The file server is represented as
+   two "target" instances, one for each community string.
+
+   If the proxy receives an SNMPv2c message with the community string
+   "public" from a device in the "Office Network" or "Home Office
+   Network", it gets tagged as "trusted", and the proxy uses the
+   "private" community string when sending the message to the file
+   server.  Other SNMPv2c messages with the community string "public"
+   get tagged as "non-trusted", and the proxy uses the "public"
+   community string for these messages.  There is also a special
+   "backdoor" community string that can be used from any location to get
+   "trusted" access.
+
+   The "Office Network" and "Home Office Network" are represented as two
+   "target" instances.  These "target" instances have target-params
+   "none", which refers to a non-existing target-params entry.
+
+   <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>
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 82]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+       </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>
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 83]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+       <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>
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 84]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+     </proxy>
+   </snmp>
+
+   If an SNMPv2c Get request with community string "public" is received
+   from an IP address tagged as "office" or "home-office", or if the
+   request is received from anywhere else with community string
+   "backdoor", the implied context is "trusted" so proxy entry "p1"
+   matches.  The request is forwarded to the file server as SNMPv1 with
+   community "private" using community table entry "c5" for outbound
+   params lookup.
+
+   If an SNMPv2c Get request with community string "public" is received
+   from any other IP address, the implied context is "not-trusted" so
+   proxy entry "p2" matches, and the request is forwarded to the file
+   server as SNMPv1 with community "public".
+
+A.6.  View-Based Access Control Model Configuration Example
+
+   Below is an XML instance document showing the minimum-secure VACM
+   configuration (see Appendix A of [RFC3415]).
+
+   <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>
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 85]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+       </view>
+       <view>
+         <name>restricted</name>
+         <include>1.3.6.1</include>
+       </view>
+     </vacm>
+   </snmp>
+
+   The following XML instance document shows the semi-secure VACM
+   configuration (only the view configuration is different).
+
+   <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>
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 86]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+   </snmp>
+
+A.7.  Transport Layer Security Transport Model Configuration Example
+
+   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 [RFC6353]).
+
+   <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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 87]
+
+RFC 7407         YANG Data Model for SNMP Configuration    December 2014
+
+
+Acknowledgments
+
+   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.
+
+   Juergen Schoenwaelder was partly funded by Flamingo, a Network of
+   Excellence project (ICT-318488) supported by the European Commission
+   under its Seventh Framework Programme.
+
+Authors' Addresses
+
+   Martin Bjorklund
+   Tail-f Systems
+
+   EMail: mbj@tail-f.com
+
+
+   Juergen Schoenwaelder
+   Jacobs University
+
+   EMail: j.schoenwaelder@jacobs-university.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bjorklund & Schoenwaelder    Standards Track                   [Page 88]
+