A YANG Data Model for SNMP ConfigurationTail-f Systemsmbj@tail-f.comJacobs Universityj.schoenwaelder@jacobs-university.de
This document defines a collection of YANG definitions for
configuring SNMP engines.
This document defines a YANG data model for the
configuration of SNMP engines. The configuration model is consistent
with the MIB modules defined in , , ,
, , , , , , and
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 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-managed management applications
manipulating SNMP agent configuration using SNMP. Further details can
be found in .
The YANG data model focuses on configuration. Operational state
objects are not explicitely modeled. The operational state of an SNMP
agent can either be accessed directly via SNMP or, alternatively, via
NETCONF using the read-only translation of the relevant SNMP MIB
modules into YANG modules .
This document also defines a YANG data model for mapping a 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, .
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.
A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these
diagrams is as follows:
Brackets "[" and "]" enclose list keys.
Abbreviations before data node names: "rw" means configuration
(read-write) and "ro" state data (read-only).
Symbols after data node names: "?" means an optional node, "!" means
a presence container, and "*" denotes a list and leaf-list.
Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
Ellipsis ("...") stands for contents of subtrees that are not shown.
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 by using the TEXTUAL-CONVENTION "StorageType". Thus, in the
YANG model defined here, the "StorageType" columns are not present.
For implementation guidelines, see .
In SNMP, row creation and deletion are controlled by 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.
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.
The submodule "ietf‑snmp‑engine", which defines configuration
parameters that are specific to SNMP engines, has the following
structure:
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. SSH, TLS and Datagram Transport Layer Security (DTLS)
are also supported, defined in "ietf‑snmp‑ssh" () and
"ietf‑snmp‑tls" (), 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 .
The submodule "ietf‑snmp‑target", which defines configuration
parameters that correspond to the objects in SNMP-TARGET-MIB,
has the following structure:
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" (). 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 security model specific submodules, currently
"ietf‑snmp‑community" (), "ietf‑snmp‑usm" (), and
"ietf‑snmp‑tls" ().
The submodule "ietf‑snmp‑notification", which defines configuration
parameters that correspond to the objects in SNMP-NOTIFICATION-MIB,
has the following structure:
It also augments the "target‑params" list defined in the
"ietf‑snmp‑target" submodule () with one leaf:
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
.
The submodule "ietf‑snmp‑proxy", which defines configuration
parameters that correspond to the objects in SNMP-PROXY-MIB,
has the following structure:
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 .
The submodule "ietf‑snmp‑community", which defines configuration
parameters that correspond to the objects in SNMP-COMMUNITY-MIB,
has the following structure:
It also augments the "/snmp/target‑params/params" choice with nodes
for the Community-Based Security Model used by SNMPv1 and SNMPv2c:
An entry in the list "/snmp/community" corresponds to an
"snmpCommunityEntry".
When a case "v1" or "v2c" is chosen, it implies a
snmpTargetParamsMPModel 0 (SNMPv1) or 1 (SNMPv2), and a
snmpTargetParamsSecurityModel 1 (SNMPv1) or 2 (SNMPv2), respectively.
Both cases implies a snmpTargetParamsSecurityLevel of noAuthNoPriv.
The submodule "ietf‑snmp‑vacm", which defines configuration
parameters that correspond to the objects in SNMP-VIEW-BASED-ACM-MIB,
has the following structure:
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".
The submodule "ietf‑snmp‑usm", which defines configuration
parameters that correspond to the objects in SNMP-USER-BASED-SM-MIB,
has the following structure:
The "{common user params}" are:
It also augments the "/snmp/target‑params/params" choice with nodes
for the SNMP User-based Security Model.
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.
The submodule "ietf‑snmp‑tsm", which defines configuration
parameters that correspond to the objects in SNMP-TSM-MIB,
has the following structure:
It also augments the "/snmp/target‑params/params" choice with nodes
for the SNMP Transport Security Model.
This submodule defines the feature "tsm". A server implements this
feature if it supports the Transport Security Model (tsm) .
The submodule "ietf‑snmp‑tls", which defines configuration
parameters that correspond to the objects in SNMP-TLS-TM-MIB,
has the following structure:
The "{common (d)tls transport params}" are:
It also augments the "/snmp/engine/listen/transport" choice with
objects for the D(TLS) transport endpoints:
This submodule defines the feature "tlstm". A server implements this
feature if it supports the Transport Layer Security (TLS) Transport
Model (tlstm) .
The submodule "ietf‑snmp‑ssh", which defines configuration
parameters that correspond to the objects in SNMP-SSH-TM-MIB,
has the following structure:
It also augments the "/snmp/engine/listen/transport" choice with
objects for the SSH transport endpoints:
This submodule defines the feature "sshtm". A server implements this
feature if it supports the Secure Shell (SSH) Transport Model (sshtm)
.
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 , 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.
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.
If the implementation supports read-write access to data over SNMP,
and specifically creation of table rows, special attention has to be
given 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 copied into "running".
Cooperating SNMP management applications may use spin lock objects
(snmpTargetSpinLock , usmUserSpinLock ,
vacmViewSpinLock ) 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.
This YANG module imports typedefs from .
<CODE BEGINS> file "ietf-x509-cert-to-name.yang"<CODE ENDS><CODE BEGINS> file "ietf-snmp.yang"<CODE ENDS><CODE BEGINS> file "ietf-snmp-common.yang"<CODE ENDS><CODE BEGINS> file "ietf-snmp-engine.yang"<CODE ENDS><CODE BEGINS> file "ietf-snmp-target.yang"<CODE ENDS><CODE BEGINS> file "ietf-snmp-notification.yang"<CODE ENDS><CODE BEGINS> file "ietf-snmp-proxy.yang"<CODE ENDS><CODE BEGINS> file "ietf-snmp-community.yang"<CODE ENDS><CODE BEGINS> file "ietf-snmp-vacm.yang"<CODE ENDS>
This YANG submodule imports YANG extensions from
.
<CODE BEGINS> file "ietf-snmp-usm.yang"<CODE ENDS><CODE BEGINS> file "ietf-snmp-tsm.yang"<CODE ENDS><CODE BEGINS> file "ietf-snmp-tls.yang"<CODE ENDS><CODE BEGINS> file "ietf-snmp-ssh.yang"<CODE ENDS>
This document registers two URIs in the IETF XML registry .
Following the format in RFC 3688, the following registrations are
requested to be made.
This document registers the following YANG modules in the YANG Module
Names registry .
The document registers the following YANG submodules in the YANG
Module Names registry .
The YANG module and submodules defined in this memo are designed to be
accessed via the NETCONF protocol . The lowest NETCONF layer
is the secure transport layer and the mandatory-to-implement secure
transport is SSH .
There are a number of data nodes defined in the YANG module and
submodules which are writable/creatable/deletable (i.e., config true,
which is the default). These data nodes may be considered sensitive
or vulnerable in some network environments. Write operations (e.g.,
edit-config) to these data nodes without proper protection can have a
negative effect on network operations. These are the subtrees and
data nodes and their sensitivity/vulnerability:
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.
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.
The /snmp/notify and /snmp/notify-filter-profile subtrees contain
the configuration for SNMP notification forwarding and filtering
mechanism. Write access to this subtree should only be granted to
entities configuring SNMP notification forwarding behavior.
The /snmp/proxy subtree contains the configuration for SNMP
proxies. Write access to this subtree should only be granted to
entities configuring SNMP proxies.
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.
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.
The /snmp/tsm subtree contains the configuration of the transport
layer security model for SNMP. Write access to this subtree should
only be granted to the security administrator.
The /snmp/tlstm subtree contains the configuration of the SNMP
transport over (D)TLS and in particular the configuration how
certificates are mapped to SNMP security names. Write access to this
subtree should only be granted to the security administrator.
The /snmp/vacm subtree contains the configuration of the view-based
access control mechanism used by SNMP to authorize access to
management information via SNMP. Write access to this subtree should
only be granted to the security administrator.
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:
The /snmp/engine subtree subtree exposes general information about
an SNMP engine such as which version(s) of SNMP are enabled or which
transports are enabled.
The /snmp/target subtree exposes information which transports are
used to reach certain SNMP targets which transport specific
parameters are used.
The /snmp/notify and /snmp/notify-filter-profile subtrees exposes
information how notifications are filtered and forwarded to
notification targets.
The /snmp/proxy subtree exposes information about proxy
relationships.
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 either 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 open
temporarily access to resources. Implementations supporting SNMP write
access must ensure that any SNMP access control rule changes over
NETCONF are atomic as well 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 for
further details.
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.
Key words for use in RFCs to Indicate Requirement LevelsHarvard UniversityIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS TRACK]Common YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]Using the NETCONF Protocol over Secure Shell (SSH)This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF) Access Control ModelThe standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. [STANDARDS-TRACK]An Architecture for Describing Simple Network Management Protocol (SNMP) Management FrameworksThis document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. [STANDARDS-TRACK]Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)This document describes the Message Processing and Dispatching for Simple Network Management Protocol (SNMP) messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. This document obsoletes RFC 2572. [STANDARDS-TRACK]Simple Network Management Protocol (SNMP) ApplicationsThis document describes five types of Simple Network Management Protocol (SNMP) applications which make use of an SNMP engine as described in STD 62, RFC 3411. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This document also defines Management Information Base (MIB) modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. This document obsoletes RFC 2573. [STANDARDS-TRACK]User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574. [STANDARDS-TRACK]View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)This document describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture. It defines the Elements of Procedure for controlling access to management information. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for the View- based Access Control Model. This document obsoletes RFC 2575. [STANDARDS-TRACK]Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [STANDARDS-TRACK]Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management FrameworkThe purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.Transport Security Model for the Simple Network Management Protocol (SNMP)This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP).</t><t> This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. [STANDARDS-TRACK]Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol.</t><t> This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. [STANDARDS-TRACK]Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of an SNMP Transport Subsystem to make this protection possible in an interoperable way.</t><t> This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.</t><t> This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG ModulesYANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the Simple Network Management Protocol (SNMP). This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF. [STANDARDS-TRACK]
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.
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.
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 configure. The user "matt" has a localized SHA
authentication key and the user "russ" has a localized SHA
authentication key and an AES encryption key.
Below is an XML instance document showing the configuration of a
notification generator application (see Appendix A of ).
Note that the USM specific objects are defined in the
ietf-snmp-usm.yang submodule.
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 a SNMPv1 agent that recognizes two
community strings, "private" and "public", with different associated
read views. The fileserver is represented as two "target"
instances, one for each community string.
If the proxy receives a 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.
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" and 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".
Below is an XML instance document showing the minimum-secure VACM
configuration (see Appendix A of ).
The following XML instance document shows the semi-secure VACM
configuration (only the view configuration is different).
Below is an XML instance document showing the configuration of the
certificate to security name mapping (see Appendix A.2 and A.3 of
).