draft-ietf-netmod-snmp-cfg-05.txt   draft-ietf-netmod-snmp-cfg-06.txt 
Network Working Group M. Bjorklund Network Working Group M. Bjorklund
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Intended status: Standards Track J. Schoenwaelder Intended status: Standards Track J. Schoenwaelder
Expires: November 20, 2014 Jacobs University Expires: January 24, 2015 Jacobs University
May 19, 2014 July 23, 2014
A YANG Data Model for SNMP Configuration A YANG Data Model for SNMP Configuration
draft-ietf-netmod-snmp-cfg-05 draft-ietf-netmod-snmp-cfg-06
Abstract Abstract
This document defines a collection of YANG definitions for This document defines a collection of YANG definitions for
configuring SNMP engines. configuring SNMP engines.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 20, 2014. This Internet-Draft will expire on January 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 2.2. General Considerations . . . . . . . . . . . . . . . . . 4
2.2. General Considerations . . . . . . . . . . . . . . . . . . 5 2.3. Common Definitions . . . . . . . . . . . . . . . . . . . 4
2.3. Common Definitions . . . . . . . . . . . . . . . . . . . . 6 2.4. Engine Configuration . . . . . . . . . . . . . . . . . . 4
2.4. Engine Configuration . . . . . . . . . . . . . . . . . . . 6 2.5. Target Configuration . . . . . . . . . . . . . . . . . . 5
2.5. Target Configuration . . . . . . . . . . . . . . . . . . . 6 2.6. Notification Configuration . . . . . . . . . . . . . . . 6
2.6. Notification Configuration . . . . . . . . . . . . . . . . 7 2.7. Proxy Configuration . . . . . . . . . . . . . . . . . . . 7
2.7. Proxy Configuration . . . . . . . . . . . . . . . . . . . 8 2.8. Community Configuration . . . . . . . . . . . . . . . . . 8
2.8. Community Configuration . . . . . . . . . . . . . . . . . 9 2.9. View-based Access Control Model Configuration . . . . . . 9
2.9. View-based Access Control Model Configuration . . . . . . 9 2.10. User-based Security Model Configuration . . . . . . . . . 9
2.10. User-based Security Model Configuration . . . . . . . . . 10 2.11. Transport Security Model Configuration . . . . . . . . . 11
2.11. Transport Security Model Configuration . . . . . . . . . . 11 2.12. Transport Layer Security Transport Model Configuration . 11
2.12. Transport Layer Security Transport Model Configuration . . 12 2.13. Secure Shell Transport Model Configuration . . . . . . . 12
2.13. Secure Shell Transport Model Configuration . . . . . . . . 13 3. Implementation Guidelines . . . . . . . . . . . . . . . . . . 13
3. Implementation Guidelines . . . . . . . . . . . . . . . . . . 15 3.1. Supporting read-only SNMP Access . . . . . . . . . . . . 14
3.1. Supporting read-only SNMP Access . . . . . . . . . . . . . 15 3.2. Supporting read-write SNMP access . . . . . . . . . . . . 14
3.2. Supporting read-write SNMP access . . . . . . . . . . . . 16 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Module 'ietf-x509-cert-to-name' . . . . . . . . . . . . . 15
4.1. Module 'ietf-x509-cert-to-name' . . . . . . . . . . . . . 17 4.2. Module 'ietf-snmp' . . . . . . . . . . . . . . . . . . . 21
4.2. Module 'ietf-snmp' . . . . . . . . . . . . . . . . . . . . 22 4.3. Submodule 'ietf-snmp-common' . . . . . . . . . . . . . . 23
4.3. Submodule 'ietf-snmp-common' . . . . . . . . . . . . . . . 25 4.4. Submodule 'ietf-snmp-engine' . . . . . . . . . . . . . . 27
4.4. Submodule 'ietf-snmp-engine' . . . . . . . . . . . . . . . 29 4.5. Submodule 'ietf-snmp-target' . . . . . . . . . . . . . . 30
4.5. Submodule 'ietf-snmp-target' . . . . . . . . . . . . . . . 32 4.6. Submodule 'ietf-snmp-notification' . . . . . . . . . . . 34
4.6. Submodule 'ietf-snmp-notification' . . . . . . . . . . . . 36 4.7. Submodule 'ietf-snmp-proxy' . . . . . . . . . . . . . . . 38
4.7. Submodule 'ietf-snmp-proxy' . . . . . . . . . . . . . . . 40 4.8. Submodule 'ietf-snmp-community' . . . . . . . . . . . . . 41
4.8. Submodule 'ietf-snmp-community' . . . . . . . . . . . . . 42 4.9. Submodule 'ietf-snmp-vacm' . . . . . . . . . . . . . . . 46
4.9. Submodule 'ietf-snmp-vacm' . . . . . . . . . . . . . . . . 47 4.10. Submodule 'ietf-snmp-usm' . . . . . . . . . . . . . . . . 51
4.10. Submodule 'ietf-snmp-usm' . . . . . . . . . . . . . . . . 52 4.11. Submodule 'ietf-snmp-tsm' . . . . . . . . . . . . . . . . 55
4.11. Submodule 'ietf-snmp-tsm' . . . . . . . . . . . . . . . . 56 4.12. Submodule 'ietf-snmp-tls' . . . . . . . . . . . . . . . . 58
4.12. Submodule 'ietf-snmp-tls' . . . . . . . . . . . . . . . . 59 4.13. Submodule 'ietf-snmp-ssh' . . . . . . . . . . . . . . . . 62
4.13. Submodule 'ietf-snmp-ssh' . . . . . . . . . . . . . . . . 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 67
6. Security Considerations . . . . . . . . . . . . . . . . . . . 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 69
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 69
8.1. Normative References . . . . . . . . . . . . . . . . . . . 73 8.2. Informative References . . . . . . . . . . . . . . . . . 69
8.2. Informative References . . . . . . . . . . . . . . . . . . 73 Appendix A. Example configurations . . . . . . . . . . . . . . . 70
Appendix A. Example configurations . . . . . . . . . . . . . . . 75 A.1. Engine Configuration Example . . . . . . . . . . . . . . 71
A.1. Engine Configuration Example . . . . . . . . . . . . . . . 75 A.2. Community Configuration Example . . . . . . . . . . . . . 71
A.2. Community Configuration Example . . . . . . . . . . . . . 75 A.3. User-based Security Model Configuration Example . . . . . 72
A.3. User-based Security Model Configuration Example . . . . . 76 A.4. Target and Notification Configuration Example . . . . . . 73
A.4. Target and Notification Configuration Example . . . . . . 78 A.5. Proxy Configuration Example . . . . . . . . . . . . . . . 75
A.5. Proxy Configuration Example . . . . . . . . . . . . . . . 79 A.6. View-based Access Control Model Configuration Example . . 78
A.6. View-based Access Control Model Configuration Example . . 82
A.7. Transport Layer Security Transport Model Configuration A.7. Transport Layer Security Transport Model Configuration
Example . . . . . . . . . . . . . . . . . . . . . . . . . 84 Example . . . . . . . . . . . . . . . . . . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
1. Introduction 1. Introduction
This document defines a YANG [RFC6020] data model for the This document defines a YANG [RFC6020] data model for the
configuration of SNMP engines. The configuration model is consistent configuration of SNMP engines. The configuration model is consistent
with the MIB modules defined in [RFC3411], [RFC3412], [RFC3413], with the MIB modules defined in [RFC3411], [RFC3412], [RFC3413],
[RFC3414], [RFC3415], [RFC3418], [RFC3584], [RFC5591], [RFC5592], and [RFC3414], [RFC3415], [RFC3418], [RFC3584], [RFC5591], [RFC5592], and
[RFC6353] but takes advantage of YANG's ability to define [RFC6353] but takes advantage of YANG's ability to define
hierarchical configuration data models. hierarchical configuration data models.
The configuration data model in particular targets SNMP deployments The configuration data model in particular has been designed for SNMP
where SNMP runs in read-only mode and NETCONF is used to configure deployments where SNMP runs in read-only mode and NETCONF is used to
the SNMP agent. Nevertheless, the data model has been designed to configure the SNMP agent. Nevertheless, the data model allows
allow implementations that support write access both via SNMP and implementations that support write access both via SNMP and NETCONF
NETCONF in order to interwork with SNMP-managed management in order to interwork with SNMP-managed management applications
applications manipulating SNMP agent configuration using SNMP. manipulating SNMP agent configuration using SNMP. Further details
can be found in Section 3.
The YANG data model focuses on configuration. Operational state The YANG data model focuses on configuration. Operational state
objects are not explicitely modeled. The operational state of an objects are not explicitely modeled. The operational state of an
SNMP agent can either be accessed directly via SNMP or, SNMP agent can either be accessed directly via SNMP or,
alternatively, via NETCONF using the read-only translation of the alternatively, via NETCONF using the read-only translation of the
relevant SNMP MIB modules into YANG modules [RFC6643]. relevant SNMP MIB modules into YANG modules [RFC6643].
This document also defines a YANG data model for mapping a X.509 This document also defines a YANG data model for mapping a X.509
certificate to a name. certificate to a name.
skipping to change at page 5, line 24 skipping to change at page 4, line 8
A simplified graphical representation of the data model is used in A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these diagrams is as this document. The meaning of the symbols in these diagrams is as
follows: follows:
o Brackets "[" and "]" enclose list keys. o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration o Abbreviations before data node names: "rw" means configuration
(read-write) and "ro" state data (read-only). (read-write) and "ro" state data (read-only).
o Symbols after data node names: "?" means an optional node, "!" o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list. means a presence container, and "*" denotes a list and leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are also o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":"). marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not o Ellipsis ("...") stands for contents of subtrees that are not
shown. shown.
2.2. General Considerations 2.2. General Considerations
skipping to change at page 6, line 17 skipping to change at page 4, line 48
The submodule "ietf-snmp-common" defines a set of common typedefs and The submodule "ietf-snmp-common" defines a set of common typedefs and
the top-level container "snmp". All configuration parameters defined the top-level container "snmp". All configuration parameters defined
in the other submodules are organized under this top-level container. in the other submodules are organized under this top-level container.
2.4. Engine Configuration 2.4. Engine Configuration
The submodule "ietf-snmp-engine", which defines configuration The submodule "ietf-snmp-engine", which defines configuration
parameters that are specific to SNMP engines, has the following parameters that are specific to SNMP engines, has the following
structure: structure:
+--rw snmp +--rw snmp
+--rw engine +--rw engine
+--rw enabled? boolean +--rw enabled? boolean
+--rw listen* [name] +--rw listen* [name]
| +--rw name snmp:identifier | +--rw name snmp:identifier
| +--rw (transport) | +--rw (transport)
| +--:(udp) | +--:(udp)
| +--rw udp | +--rw udp
| +--rw ip inet:ip-address | +--rw ip inet:ip-address
| +--rw port? inet:port-number | +--rw port? inet:port-number
+--rw version +--rw version
| +--rw v1? empty | +--rw v1? empty
| +--rw v2c? empty | +--rw v2c? empty
| +--rw v3? empty | +--rw v3? empty
+--rw engine-id? snmp:engine-id +--rw engine-id? snmp:engine-id
+--rw enable-authen-traps? boolean +--rw enable-authen-traps? boolean
The leaf "/snmp/engine/enabled" can be used to enable/disable an SNMP The leaf "/snmp/engine/enabled" can be used to enable/disable an SNMP
engine. engine.
The list "/snmp/engine/listen" provides configuration of the The list "/snmp/engine/listen" provides configuration of the
transport endpoints the engine is listening to. In this submodule, transport endpoints the engine is listening to. In this submodule,
SNMP over UDP is defined. SSH, TLS and Datagram Transport Layer SNMP over UDP is defined. SSH, TLS and Datagram Transport Layer
Security (DTLS) are also supported, defined in "ietf-snmp-ssh" Security (DTLS) are also supported, defined in "ietf-snmp-ssh"
(Section 2.13) and "ietf-snmp-tls" (Section 2.12), respectively. The (Section 2.13) and "ietf-snmp-tls" (Section 2.12), respectively. The
"transport" choice is expected to be augmented for other transports. "transport" choice is expected to be augmented for other transports.
The "/snmp/engine/version" container can be used to enable/disable The "/snmp/engine/version" container can be used to enable/disable
the different message processing models. the different message processing models [RFC3411].
2.5. Target Configuration 2.5. Target Configuration
The submodule "ietf-snmp-target", which defines configuration The submodule "ietf-snmp-target", which defines configuration
parameters that correspond to the objects in SNMP-TARGET-MIB, has the parameters that correspond to the objects in SNMP-TARGET-MIB, has the
following structure: following structure:
+--rw snmp +--rw snmp
+--rw target* [name] +--rw target* [name]
| +--rw name snmp:identifier | +--rw name snmp:identifier
| +--rw (transport) | +--rw (transport)
| | +--:(udp) | | +--:(udp)
| | +--rw udp | | +--rw udp
| | +--rw ip inet:ip-address | | +--rw ip inet:ip-address
| | +--rw port? inet:port-number | | +--rw port? inet:port-number
| | +--rw prefix-length? uint8 | | +--rw prefix-length? uint8
| +--rw tag* snmp:identifier | +--rw tag* snmp:identifier
| +--rw timeout? uint32 | +--rw timeout? uint32
| +--rw retries? uint8 | +--rw retries? uint8
| +--rw target-params snmp:identifier | +--rw target-params snmp:identifier
+--rw target-params* [name] +--rw target-params* [name]
+--rw name snmp:identifier +--rw name snmp:identifier
+--rw (params)? +--rw (params)?
An entry in the list "/snmp/target" corresponds to an An entry in the list "/snmp/target" corresponds to an
"snmpTargetAddrEntry". "snmpTargetAddrEntry".
The "snmpTargetAddrTDomain" and "snmpTargetAddrTAddress" objects are The "snmpTargetAddrTDomain" and "snmpTargetAddrTAddress" objects are
mapped to transport-specific YANG nodes. Each transport is mapped to transport-specific YANG nodes. Each transport is
configured as a separate case in the "transport" choice. In this configured as a separate case in the "transport" choice. In this
submodule, SNMP over UDP is defined. TLS and DTLS are also submodule, SNMP over UDP is defined. TLS and DTLS are also
supported, defined in "ietf-snmp-tls" (Section 2.12). The supported, defined in "ietf-snmp-tls" (Section 2.12). The
"transport" choice is expected to be augmented for other transports. "transport" choice is expected to be augmented for other transports.
skipping to change at page 7, line 44 skipping to change at page 6, line 44
is augmented by security model specific submodules, currently is augmented by security model specific submodules, currently
"ietf-snmp-community" (Section 2.8), "ietf-snmp-usm" (Section 2.10), "ietf-snmp-community" (Section 2.8), "ietf-snmp-usm" (Section 2.10),
and "ietf-snmp-tls" (Section 2.12). and "ietf-snmp-tls" (Section 2.12).
2.6. Notification Configuration 2.6. Notification Configuration
The submodule "ietf-snmp-notification", which defines configuration The submodule "ietf-snmp-notification", which defines configuration
parameters that correspond to the objects in SNMP-NOTIFICATION-MIB, parameters that correspond to the objects in SNMP-NOTIFICATION-MIB,
has the following structure: has the following structure:
+--rw snmp +--rw snmp
+--rw notify* [name] +--rw notify* [name]
| +--rw name snmp:identifier | +--rw name snmp:identifier
| +--rw tag snmp:identifier | +--rw tag snmp:identifier
| +--rw type? enumeration | +--rw type? enumeration
+--rw notify-filter-profile* [name] +--rw notify-filter-profile* [name]
+--rw name snmp:identifier +--rw name snmp:identifier
+--rw include* snmp:wildcard-object-identifier +--rw include* snmp:wildcard-object-identifier
+--rw exclude* snmp:wildcard-object-identifier +--rw exclude* snmp:wildcard-object-identifier
It also augments the "target-params" list defined in the It also augments the "target-params" list defined in the
"ietf-snmp-target" submodule (Section 2.5) with one leaf: "ietf-snmp-target" submodule (Section 2.5) with one leaf:
+--rw snmp +--rw snmp
+--rw target-params* [name] +--rw target-params* [name]
... ...
+--rw notify-filter-profile? leafref +--rw notify-filter-profile? leafref
An entry in the list "/snmp/notify" corresponds to an An entry in the list "/snmp/notify" corresponds to an
"snmpNotifyEntry". "snmpNotifyEntry".
An entry in the list "/snmp/notify-filter-profile" corresponds to an An entry in the list "/snmp/notify-filter-profile" corresponds to an
"snmpNotifyFilterProfileEntry". In the MIB, there is a sparse "snmpNotifyFilterProfileEntry". In the MIB, there is a sparse
relationship between "snmpTargetParamsTable" and relationship between "snmpTargetParamsTable" and
"snmpNotifyFilterProfileTable". In the YANG model, this sparse "snmpNotifyFilterProfileTable". In the YANG model, this sparse
relationship is represented with a leafref leaf relationship is represented with a leafref leaf
"notify-filter-profile" in the "/snmp/target-params" list, which "notify-filter-profile" in the "/snmp/target-params" list, which
refers to an entry in the "/snmp/notify-filter-profile" list. refers to an entry in the "/snmp/notify-filter-profile" list.
The "snmpNotifyFilterTable" is represented as a list "filter" within The "snmpNotifyFilterTable" is represented as a list "filter" within
the "/snmp/notify-filter-profile" list. the "/snmp/notify-filter-profile" list.
This submodule defines the feature "notification-filter". A server This submodule defines the feature "notification-filter". A server
implements this feature if it supports SNMP notification filtering. implements this feature if it supports SNMP notification filtering
[RFC3413].
2.7. Proxy Configuration 2.7. Proxy Configuration
The submodule "ietf-snmp-proxy", which defines configuration The submodule "ietf-snmp-proxy", which defines configuration
parameters that correspond to the objects in SNMP-PROXY-MIB, has the parameters that correspond to the objects in SNMP-PROXY-MIB, has the
following structure: following structure:
+--rw snmp +--rw snmp
+--rw proxy* [name] +--rw proxy* [name]
+--rw name snmp:identifier +--rw name snmp:identifier
+--rw type enumeration +--rw type enumeration
+--rw context-engine-id snmp:engine-id +--rw context-engine-id snmp:engine-id
+--rw context-name? snmp:context-name +--rw context-name? snmp:context-name
+--rw target-params-in? snmp:identifier +--rw target-params-in? snmp:identifier
+--rw single-target-out? snmp:identifier +--rw single-target-out? snmp:identifier
+--rw multiple-target-out? snmp:identifier +--rw multiple-target-out? snmp:identifier
An entry in the list "/snmp/proxy" corresponds to an An entry in the list "/snmp/proxy" corresponds to an
"snmpProxyEntry". "snmpProxyEntry".
This submodule defines the feature "proxy". A server implements this This submodule defines the feature "proxy". A server implements this
feature if it can act as an SNMP Proxy. feature if it can act as an SNMP Proxy [RFC3413].
2.8. Community Configuration 2.8. Community Configuration
The submodule "ietf-snmp-community", which defines configuration The submodule "ietf-snmp-community", which defines configuration
parameters that correspond to the objects in SNMP-COMMUNITY-MIB, has parameters that correspond to the objects in SNMP-COMMUNITY-MIB, has
the following structure: the following structure:
+--rw snmp +--rw snmp
+--rw community* [index] +--rw community* [index]
+--rw index snmp:identifier +--rw index snmp:identifier
+--rw (name)? +--rw (name)?
| +--:(text-name) | +--:(text-name)
| | +--rw text-name? string | | +--rw text-name? string
| +--:(binary-name) | +--:(binary-name)
| +--rw binary-name? binary | +--rw binary-name? binary
+--rw security-name snmp:security-name +--rw security-name snmp:security-name
+--rw engine-id? snmp:engine-id +--rw engine-id? snmp:engine-id
+--rw context? snmp:context-name +--rw context? snmp:context-name
+--rw target-tag? snmp:identifier +--rw target-tag? snmp:identifier
It also augments the "/snmp/target-params/params" choice with nodes It also augments the "/snmp/target-params/params" choice with nodes
for the Community-Based Security Model used by SNMPv1 and SNMPv2c: for the Community-Based Security Model used by SNMPv1 and SNMPv2c:
+--rw snmp +--rw snmp
+--rw target-params* [name] +--rw target-params* [name]
| ... | ...
| +--rw (params)? | +--rw (params)?
| +--:(v1) | +--:(v1)
| | +--rw v1 | | +--rw v1
| | +--rw security-name snmp:security-name | | +--rw security-name snmp:security-name
| +--:(v2c) | +--:(v2c)
| +--rw v2c | +--rw v2c
| +--rw security-name snmp:security-name | +--rw security-name snmp:security-name
+--rw target* [name] +--rw target* [name]
+--rw mms? union +--rw mms? union
An entry in the list "/snmp/community" corresponds to an An entry in the list "/snmp/community" corresponds to an
"snmpCommunityEntry". "snmpCommunityEntry".
When a case "v1" or "v2c" is chosen, it implies a When a case "v1" or "v2c" is chosen, it implies a
snmpTargetParamsMPModel 0 (SNMPv1) or 1 (SNMPv2), and a snmpTargetParamsMPModel 0 (SNMPv1) or 1 (SNMPv2), and a
snmpTargetParamsSecurityModel 1 (SNMPv1) or 2 (SNMPv2), respectively. snmpTargetParamsSecurityModel 1 (SNMPv1) or 2 (SNMPv2), respectively.
Both cases implies a snmpTargetParamsSecurityLevel of noAuthNoPriv. Both cases implies a snmpTargetParamsSecurityLevel of noAuthNoPriv.
2.9. View-based Access Control Model Configuration 2.9. View-based Access Control Model Configuration
The submodule "ietf-snmp-vacm", which defines configuration The submodule "ietf-snmp-vacm", which defines configuration
parameters that correspond to the objects in SNMP-VIEW-BASED-ACM-MIB, parameters that correspond to the objects in SNMP-VIEW-BASED-ACM-MIB,
has the following structure: has the following structure:
+--rw snmp +--rw snmp
+--rw vacm +--rw vacm
+--rw group* [name] +--rw group* [name]
| +--rw name group-name | +--rw name group-name
| +--rw member* [security-name] | +--rw member* [security-name]
| | +--rw security-name snmp:security-name | | +--rw security-name snmp:security-name
| | +--rw security-model* snmp:security-model | | +--rw security-model* snmp:security-model
| +--rw access* [context security-model security-level] | +--rw access* [context security-model security-level]
| +--rw context snmp:context-name | +--rw context snmp:context-name
| +--rw context-match? enumeration | +--rw context-match? enumeration
| +--rw security-model snmp:security-model-or-any | +--rw security-model snmp:security-model-or-any
| +--rw security-level snmp:security-level | +--rw security-level snmp:security-level
| +--rw read-view? view-name | +--rw read-view? view-name
| +--rw write-view? view-name | +--rw write-view? view-name
| +--rw notify-view? vire-name | +--rw notify-view? vire-name
+--rw view* [name] +--rw view* [name]
+--rw name view-name +--rw name view-name
+--rw include* snmp:wildcard-object-identifier +--rw include* snmp:wildcard-object-identifier
+--rw exclude* snmp:wildcard-object-identifier +--rw exclude* snmp:wildcard-object-identifier
The "vacmSecurityToGroupTable" and "vacmAccessTable" are mapped to a The "vacmSecurityToGroupTable" and "vacmAccessTable" are mapped to a
structure of nested lists in the YANG model. Groups are defined in 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 the list "/snmp/vacm/group" and for each group there is a sublist
"member" that maps to "vacmSecurityToGroupTable", and a sublist "member" that maps to "vacmSecurityToGroupTable", and a sublist
"access" that maps to "vacmAccessTable". "access" that maps to "vacmAccessTable".
MIB views are defined in the list "/snmp/vacm/view" and for each MIB 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- 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 list of excluded subtree families. This is more compact and thus a
more readable representation of the "vacmViewTreeFamilyTable". more readable representation of the "vacmViewTreeFamilyTable".
2.10. User-based Security Model Configuration 2.10. User-based Security Model Configuration
The submodule "ietf-snmp-usm", which defines configuration parameters The submodule "ietf-snmp-usm", which defines configuration parameters
that correspond to the objects in SNMP-USER-BASED-SM-MIB, has the that correspond to the objects in SNMP-USER-BASED-SM-MIB, has the
following structure: following structure:
+--rw snmp +--rw snmp
+--rw usm +--rw usm
+--rw local +--rw local
| +--rw user* [name] | +--rw user* [name]
| +-- {common user params} | +-- {common user params}
+--rw remote* [engine-id] +--rw remote* [engine-id]
+--rw engine-id snmp:engine-id +--rw engine-id snmp:engine-id
+--rw user* [name] +--rw user* [name]
+-- {common user params} +-- {common user params}
The "{common user params}" are: The "{common user params}" are:
+--rw name snmp:identifier +--rw name snmp:identifier
+--rw auth! +--rw auth!
| +--rw (protocol) | +--rw (protocol)
| +--:(md5) | +--:(md5)
| | +--rw md5 | | +--rw md5
| | +-- rw key yang:hex-string | | +-- rw key yang:hex-string
| +--:(sha) | +--:(sha)
| +--rw sha | +--rw sha
| +-- rw key yang:hex-string | +-- rw key yang:hex-string
+--rw priv! +--rw priv!
+--rw (protocol) +--rw (protocol)
+--:(des) +--:(des)
| +--rw des | +--rw des
| +-- rw key yang:hex-string | +-- rw key yang:hex-string
+--:(aes) +--:(aes)
+--rw aes +--rw aes
+-- rw key yang:hex-string +-- rw key yang:hex-string
It also augments the "/snmp/target-params/params" choice with nodes It also augments the "/snmp/target-params/params" choice with nodes
for the SNMP User-based Security Model. for the SNMP User-based Security Model.
+--rw snmp +--rw snmp
+--rw target-params* [name] +--rw target-params* [name]
... ...
+--rw (params)? +--rw (params)?
+--:(usm) +--:(usm)
+--rw usm +--rw usm
+--rw user-name snmp:security-name +--rw user-name snmp:security-name
+--rw security-level security-level +--rw security-level security-level
In the MIB, there is a single table with local and remote users, 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 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. one list of local users, and a nested list of remote users.
In the MIB, there are several objects related to changing the In the MIB, there are several objects related to changing the
authentication and privacy keys. These objects are not present in authentication and privacy keys. These objects are not present in
the YANG model. However, the localized key can be changed. This 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 implies that if the engine id is changed, all users keys need to be
changed as well. changed as well.
2.11. Transport Security Model Configuration 2.11. Transport Security Model Configuration
The submodule "ietf-snmp-tsm", which defines configuration parameters The submodule "ietf-snmp-tsm", which defines configuration parameters
that correspond to the objects in SNMP-TSM-MIB, has the following that correspond to the objects in SNMP-TSM-MIB, has the following
structure: structure:
+--rw snmp +--rw snmp
+--rw tsm +--rw tsm
+--rw use-prefix? boolean +--rw use-prefix? boolean
It also augments the "/snmp/target-params/params" choice with nodes It also augments the "/snmp/target-params/params" choice with nodes
for the SNMP Transport Security Model. for the SNMP Transport Security Model.
+--rw snmp +--rw snmp
+--rw target-params* [name] +--rw target-params* [name]
... ...
+--rw (params)? +--rw (params)?
+--:(tsm) +--:(tsm)
+--rw tsm +--rw tsm
+--rw security-name snmp:security-name +--rw security-name snmp:security-name
+--rw security-level security-level +--rw security-level security-level
This submodule defines the feature "tsm". A server implements this This submodule defines the feature "tsm". A server implements this
feature if it supports the Transport Security Model (tsm) [RFC5591]. feature if it supports the Transport Security Model (tsm) [RFC5591].
2.12. Transport Layer Security Transport Model Configuration 2.12. Transport Layer Security Transport Model Configuration
The submodule "ietf-snmp-tls", which defines configuration parameters The submodule "ietf-snmp-tls", which defines configuration parameters
that correspond to the objects in SNMP-TLS-TM-MIB, has the following that correspond to the objects in SNMP-TLS-TM-MIB, has the following
structure: structure:
+--rw snmp +--rw snmp
... ...
+--rw target* [name] +--rw target* [name]
| ... | ...
| +--rw (transport) | +--rw (transport)
| ... | ...
| +--:(tls) | +--:(tls)
| | +--rw tls | | +--rw tls
| | +-- {common (d)tls transport params} | | +-- {common (d)tls transport params}
| +--:(dtls) | +--:(dtls)
| +--rw dtls | +--rw dtls
| +-- {common (d)tls transport params} | +-- {common (d)tls transport params}
+--rw tlstm +--rw tlstm
+--rw cert-to-name* [id] +--rw cert-to-name* [id]
+--rw id uint32 +--rw id uint32
+--rw fingerprint x509c2n:tls-fingerprint +--rw fingerprint x509c2n:tls-fingerprint
+--rw map-type identityref +--rw map-type identityref
+--rw name string +--rw name string
The "{common (d)tls transport params}" are: The "{common (d)tls transport params}" are:
+--rw ip? inet:host +--rw ip? inet:host
+--rw port? inet:port-number +--rw port? inet:port-number
+--rw client-fingerprint? x509c2n:tls-fingerprint +--rw client-fingerprint? x509c2n:tls-fingerprint
+--rw server-fingerprint? x509c2n:tls-fingerprint +--rw server-fingerprint? x509c2n:tls-fingerprint
+--rw server-identity? snmp:admin-string +--rw server-identity? snmp:admin-string
It also augments the "/snmp/engine/listen/transport" choice with It also augments the "/snmp/engine/listen/transport" choice with
objects for the D(TLS) transport endpoints: objects for the D(TLS) transport endpoints:
+--rw snmp +--rw snmp
+--rw engine +--rw engine
...
+--rw listen* [name]
... ...
+--rw listen* [name] +--rw (transport)
... ...
+--rw (transport) +--:(tls)
... | +--rw tls
+--:(tls) | +--rw ip inet:ip-address
| +--rw tls | +--rw port? inet:port-number
| +--rw ip inet:ip-address +--:(dtls)
| +--rw port? inet:port-number +--rw dtls
+--:(dtls) +--rw ip inet:ip-address
+--rw dtls +--rw port? inet:port-number
+--rw ip inet:ip-address
+--rw port? inet:port-number
This submodule defines the feature "tlstm". A server implements this This submodule defines the feature "tlstm". A server implements this
feature if it supports the Transport Layer Security (TLS) Transport feature if it supports the Transport Layer Security (TLS) Transport
Model (tlstm) [RFC6353]. Model (tlstm) [RFC6353].
2.13. Secure Shell Transport Model Configuration 2.13. Secure Shell Transport Model Configuration
The submodule "ietf-snmp-ssh", which defines configuration parameters The submodule "ietf-snmp-ssh", which defines configuration parameters
that correspond to the objects in SNMP-SSH-TM-MIB, has the following that correspond to the objects in SNMP-SSH-TM-MIB, has the following
structure: structure:
+--rw snmp +--rw snmp
... ...
+--rw target* [name] +--rw target* [name]
...
+--rw (transport)
... ...
+--rw (transport) +--:(ssh)
... +--rw ssh
+--:(ssh) +--rw ip inet:host
+--rw ssh +--rw port? inet:port-number
+--rw ip inet:host +--rw username? string
+--rw port? inet:port-number
+--rw username? string
It also augments the "/snmp/engine/listen/transport" choice with It also augments the "/snmp/engine/listen/transport" choice with
objects for the SSH transport endpoints: objects for the SSH transport endpoints:
+--rw snmp +--rw snmp
+--rw engine +--rw engine
...
+--rw listen* [name]
... ...
+--rw listen* [name] +--rw (transport)
... ...
+--rw (transport) +--:(ssh)
... +--rw ssh
+--:(ssh) +--rw ip inet:host
+--rw ssh +--rw port? inet:port-number
+--rw ip inet:host +--rw username? string
+--rw port? inet:port-number
+--rw username? string
This submodule defines the feature "sshtm". A server implements this This submodule defines the feature "sshtm". A server implements this
feature if it supports the Secure Shell (SSH) Transport Model (sshtm) feature if it supports the Secure Shell (SSH) Transport Model (sshtm)
[RFC5592]. [RFC5592].
3. Implementation Guidelines 3. Implementation Guidelines
This section describes some challenges for implementations that This section describes some challenges for implementations that
support both the YANG models defined in this document, and either support both the YANG models defined in this document, and either
read-write or read-only SNMP access to the same data, using the read-write or read-only SNMP access to the same data, using the
skipping to change at page 37, line 33 skipping to change at page 36, line 6
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A YANG Data Model for SNMP Configuration"; "RFC XXXX: A YANG Data Model for SNMP Configuration";
} }
feature notification-filter { feature notification-filter {
description description
"A server implements this feature if it supports SNMP "A server implements this feature if it supports SNMP
notification filtering."; notification filtering.";
reference
"RFC3413: Simple Network Management Protocol (SNMP)
Applications";
} }
augment /snmp:snmp { augment /snmp:snmp {
list notify { list notify {
key name; key name;
description description
"Targets that will receive notifications. "Targets that will receive notifications.
Entries in this lists are mapped 1-1 to entries in Entries in this lists are mapped 1-1 to entries in
skipping to change at page 41, line 26 skipping to change at page 39, line 50
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A YANG Data Model for SNMP Configuration"; "RFC XXXX: A YANG Data Model for SNMP Configuration";
} }
feature proxy { feature proxy {
description description
"A server implements this feature if it can act as an "A server implements this feature if it can act as an
SNMP Proxy"; SNMP Proxy";
reference
"RFC3413: Simple Network Management Protocol (SNMP)
Applications";
} }
augment /snmp:snmp { augment /snmp:snmp {
if-feature snmp:proxy; if-feature snmp:proxy;
list proxy { list proxy {
key name; key name;
description description
"List of proxy parameters."; "List of proxy parameters.";
skipping to change at page 43, line 4 skipping to change at page 41, line 31
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
4.8. Submodule 'ietf-snmp-community' 4.8. Submodule 'ietf-snmp-community'
<CODE BEGINS> file "ietf-snmp-community.yang" <CODE BEGINS> file "ietf-snmp-community.yang"
submodule ietf-snmp-community { submodule ietf-snmp-community {
belongs-to ietf-snmp { belongs-to ietf-snmp {
prefix snmp; prefix snmp;
} }
import ietf-netconf-acm {
prefix nacm;
}
include ietf-snmp-common; include ietf-snmp-common;
include ietf-snmp-target; include ietf-snmp-target;
include ietf-snmp-proxy; include ietf-snmp-proxy;
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
skipping to change at page 44, line 35 skipping to change at page 43, line 20
"List of communities"; "List of communities";
reference "SNMP-COMMUNITY-MIB.snmpCommunityTable"; reference "SNMP-COMMUNITY-MIB.snmpCommunityTable";
leaf index { leaf index {
type snmp:identifier; type snmp:identifier;
description description
"Index into the community list."; "Index into the community list.";
reference "SNMP-COMMUNITY-MIB.snmpCommunityIndex"; reference "SNMP-COMMUNITY-MIB.snmpCommunityIndex";
} }
choice name { choice name {
nacm:default-deny-all;
description description
"The community name, either specified as a string "The community name, either specified as a string
or as a binary. The binary name is used when the or as a binary. The binary name is used when the
community name contains characters that are not legal community name contains characters that are not legal
in a string. in a string.
If not set, the value of 'security-name' is operationally If not set, the value of 'security-name' is operationally
used as the snmpCommunityName."; used as the snmpCommunityName.";
reference "SNMP-COMMUNITY-MIB.snmpCommunityName"; reference "SNMP-COMMUNITY-MIB.snmpCommunityName";
leaf text-name { leaf text-name {
skipping to change at page 45, line 10 skipping to change at page 43, line 45
} }
leaf binary-name { leaf binary-name {
type binary; type binary;
description description
"A community name represented as a binary value."; "A community name represented as a binary value.";
} }
} }
leaf security-name { leaf security-name {
type snmp:security-name; type snmp:security-name;
mandatory true; mandatory true;
nacm:default-deny-all;
description description
"The snmpCommunitySecurityName of this entry."; "The snmpCommunitySecurityName of this entry.";
reference "SNMP-COMMUNITY-MIB.snmpCommunitySecurityName"; reference "SNMP-COMMUNITY-MIB.snmpCommunitySecurityName";
} }
leaf engine-id { leaf engine-id {
if-feature snmp:proxy; if-feature snmp:proxy;
type snmp:engine-id; type snmp:engine-id;
description description
"If not set, the value of the local SNMP engine is "If not set, the value of the local SNMP engine is
operationally used by the device."; operationally used by the device.";
skipping to change at page 47, line 4 skipping to change at page 45, line 40
augment /snmp:snmp/snmp:target { augment /snmp:snmp/snmp:target {
when "snmp:v1 or snmp:v2c"; when "snmp:v1 or snmp:v2c";
leaf mms { leaf mms {
type union { type union {
type enumeration { type enumeration {
enum "unknown" { value 0; } enum "unknown" { value 0; }
} }
type int32 { type int32 {
range "484..max"; range "484..max";
} }
} }
default "484"; default "484";
description
"The maximum message size.";
reference reference
"SNMP-COMMUNITY-MIB.snmpTargetAddrMMS"; "SNMP-COMMUNITY-MIB.snmpTargetAddrMMS";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
4.9. Submodule 'ietf-snmp-vacm' 4.9. Submodule 'ietf-snmp-vacm'
<CODE BEGINS> file "ietf-snmp-vacm.yang" <CODE BEGINS> file "ietf-snmp-vacm.yang"
submodule ietf-snmp-vacm { submodule ietf-snmp-vacm {
belongs-to ietf-snmp { belongs-to ietf-snmp {
prefix snmp; prefix snmp;
skipping to change at page 71, line 5 skipping to change at page 69, line 7
temporarily access to resources. Implementations supporting SNMP temporarily access to resources. Implementations supporting SNMP
write access must ensure that any SNMP access control rule changes write access must ensure that any SNMP access control rule changes
over NETCONF are atomic as well to the SNMP instrumentation. In over NETCONF are atomic as well to the SNMP instrumentation. In
particular changes involving an internal delete/create cycle (e.g., particular changes involving an internal delete/create cycle (e.g.,
to move a user to a different group) must be done with sufficient to move a user to a different group) must be done with sufficient
protections such that even a power fail immediately after the delete protections such that even a power fail immediately after the delete
does not leave the administrator locked out. does not leave the administrator locked out.
Security administrators need to ensure that NETCONF access control Security administrators need to ensure that NETCONF access control
rules and SNMP access control rules implement a consistent security rules and SNMP access control rules implement a consistent security
policy. 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.
7. Acknowledgments 7. Acknowledgments
The authors want to thank Wes Hardaker and David Spakes for their The authors want to thank Wes Hardaker and David Spakes for their
detailed reviews. Additional valuable comments were provided by detailed reviews. Additional valuable comments were provided by
David Harrington, Borislav Lukovic and Randy Presuhn. David Harrington, Borislav Lukovic and Randy Presuhn.
Juergen Schoenwaelder was partly funded by Flamingo, a Network of Juergen Schoenwaelder was partly funded by Flamingo, a Network of
Excellence project (ICT-318488) supported by the European Commission Excellence project (ICT-318488) supported by the European Commission
under its Seventh Framework Programme. under its Seventh Framework Programme.
skipping to change at page 73, line 17 skipping to change at page 69, line 34
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", Bierman, "Network Configuration Protocol (NETCONF)", RFC
RFC 6241, June 2011. 6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011. Shell (SSH)", RFC 6242, June 2011.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, Protocol (NETCONF) Access Control Model", RFC 6536, March
March 2012. 2012.
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
July 2013. July 2013.
8.2. Informative References 8.2. Informative References
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002. December 2002.
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
"Message Processing and Dispatching for the Simple Network "Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3412, Management Protocol (SNMP)", STD 62, RFC 3412, December
December 2002. 2002.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, Management Protocol (SNMP) Applications", STD 62, RFC
RFC 3413, December 2002. 3413, December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, Management Protocol (SNMP)", STD 62, RFC 3415, December
December 2002. 2002.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the [RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, Simple Network Management Protocol (SNMP)", STD 62, RFC
RFC 3418, December 2002. 3418, December 2002.
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3 "Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework", of the Internet-standard Network Management Framework",
BCP 74, RFC 3584, August 2003. BCP 74, RFC 3584, August 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
for the Simple Network Management Protocol (SNMP)", for the Simple Network Management Protocol (SNMP)", RFC
RFC 5591, June 2009. 5591, June 2009.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009. Protocol (SNMP)", RFC 5592, June 2009.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)", Model for the Simple Network Management Protocol (SNMP)",
RFC 6353, July 2011. RFC 6353, July 2011.
[RFC6643] Schoenwaelder, J., "Translation of Structure of Management [RFC6643] Schoenwaelder, J., "Translation of Structure of Management
 End of changes. 52 change blocks. 
279 lines changed or deleted 296 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/