diff options
Diffstat (limited to 'doc/rfc/rfc7407.txt')
| -rw-r--r-- | doc/rfc/rfc7407.txt | 4931 |
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] + |