2.4.14 SNMP Version 3 (snmpv3)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 28-Nov-00


Russ Mundy <mundy@tislabs.com>
David Harrington <dbh@cabletron.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Randy Bush <randy@psg.com>

Mailing Lists:

General Discussion:snmpv3@lists.tislabs.com
To Subscribe: snmpv3-request@lists.tislabs.com
Archive: ftp://ftp.tislabs.com/pub/ietf/snmpv3

Description of Working Group:

The SNMPv3 Working Group is chartered to prepare recommendations for the next generation of SNMP. The goal of the Working Group is to produce the necessary set of documents that will provide a single standard for the next generation of core SNMP functions.

During the past several years, there have been a number of activities aimed at incorporating security and other improvements to SNMP. Unfortunately, strongly held differences on how to incorporate these improvements into SNMP prevented the SNMPV2 Working Group from coming to closure on a single approach. As a result, two different approaches (commonly called V2u and V2*) have emerged.

The Security and Administrative Framework Evolution for SNMP Advisory Team (the Advisory Team) was formed to provide a single recommended approach for SNMP evolution. The technical starting point for this Working Group will be the recommended approach provided by the Advisory Team.

This approach provides for the convergence of concepts and technical elements of V2u and V2*. The SNMPv3 Working Group is not starting new work and will use as many concepts, technical elements and documentation as practical from the V2u and V2* activities. Previous delays in providing a single standard for the next generation of SNMP core functions dictate that the Working Group move forward as quickly as possible to document and publish Internet Drafts and RFC's. To this end, the Working Group will make use of as much existing documentation as practical. Additionally, functional changes beyond those needed to provide a single approach will be strongly discouraged.

Timely completion of a single approach for SNMPv3 is crucial for the continued success of SNMP. Recognizing the need for prompt completion, the following objectives are provided to the Working Group:

- accommodate the wide range of operational environments with differing management demands;

- facilitate the need to transition from previous, multiple protocols to SNMPv3;

- facilitate the ease of setup and maintenance activities.

Note: SNMPv3 planned specifications:

SNMPv3 Modules and Interface Definitions SNMPv3 Message Processing and Control Module Specification SNMPv3 Security Model Module Specification SNMPv3 Local Processing Mosule Specification SNMPv3 Proxy Specification

Goals and Milestones:



Post first SNMPv3 Internet-Draft, Modules and Interface Definitions.



Working Group meeting at Memphis IETF to discuss SNMPv3 recommended approach, discuss Working Group Charter and the plan for completion.



Post revised SNMPv3 Modules and Interface Definitions Internet-Drafts.



Post initial SNMPv3 Message Processing and Control Module Internet-Draft.



Post initial SNMPv3 Security Model Module Internet-Draft.



Finalize SNMPV3 Modules and Interface Definitions Internet-Draft and review other I-Ds at Munich IETF.



Post revised SNMPv3 Local Processing Module Internet-Draft.



Post revised SNMPv3 Security Model Module Internet-Draft.



Post revised SNMPv3 Message Processing and Control Module Internet-Draft.



Post initial SNMPv3 Proxy Specification Internet-Draft.



Submit SNMPv3 Modules and Interface Definitions to IESG for consideration as a Proposed Standard.



All SNMPv3 specifications submitted to IESG for consideration as Proposed Standards.



Testing of interoperability between independent implementations of SNMPv3 core specifications.



Post the initial Internet Draft of the Intro document.



Post initial Internet Drafts for updating the SNMPv3 core specifications.



Post initial version of the Coexistence document as an Internet-Draft.



SNMPv3 Working Group Meeting at 42nd IETF.



Post revised version of the Intro document Internet-Draft.



Post revised version of the Coexistence document as an Internet-Draft.



Complete Working Group actions on revisions to core specifications and forward documents to the IESG for consideration as Draft Standard RFCs.


Request For Comments:






SNMPv3 Applications



User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)



View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)



Introduction to Version 3 of the Internet standard Network Management Framework



An Architecture for Describing SNMP Management Frameworks



Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)



Coexistence between SNMP versions

Current Meeting Report

SNMPv3 Working Group
49th IETF
San Diego, CA, USA
12 December 2000

Chairs: Russ Mundy (mundy@tislabs.com)

Area Advisor: Randy Bush (randy@psg.com)
Notes: Shawn A. Routhier (sar@epilogue.com)

Mailing Lists:
General Discussion: snmpv3@lists.tislabs.com
To Subscribe: snmpv3-request@lists.tislabs.com
Archive: ftp://ftp.tislabs.com/pub/ietf/snmpv3


The SNMPv3 Working Group met once for one hour during the 49th IETF. There were approximately one hundred attendees. The Working Group generally followed the agenda that was published on the list and the IETF Web site. Several deployment reports were presented and discussed during the meeting. During the Review of Document Status discussion, the sense of WG members in attendance was that we have sufficient experience with the specifications which are at the Draft maturity level that the WG should finalize the remaining details and recommend to the IESG that the current Draft specifications be advanced to full Standard. The activities needed to do this will be done as quickly as possible.


-- We received several reports about deployment experiences.

Carl Kalbfleisch from Verio sent in an e-mail report. The portion of Verio that Carl works in is trying to move to SNMPv3 but the going is slow. As part of this move an RFP that requires the inclusion of SNMPv3 should be appearing soon.

Tom Lehman presented a report from CAIRN. They are attempting to do more effective monitoring with SNMPv3. Today they mainly use web servers with ssl to go to ssl servers which run scripts to collect and manipulate information. The current versions of the scrips use RSH to collect the information, they would like to modify the scripts to use SNMPv3. Tom presented a slide with a CAIRN diagram which gives a better illustrations of this deployment (the slide will be submitted for inclusion in the IETF proceedings).
The CAIRN web site is: www.cairn.net
The contact person for this deployment is: Jaroslav Flidr

Wes Hardaker (hardaker@tislabs.com) presented the results of the Net-SNMP (fromerly UCD-SNMP) survey that he ran. They were attempting to get information on what people are using SNMP for and which version of SNMP is being used. Some of the results that were thought to be of particular interest to the WG were that some folks are using v2c or v3 without using v1 and that v2c is in wide use but v3 has not yet used quite as widely. He also found that the range of the number of hosts per site was much broader for v1 sites than for v3 sites. When asked why they didn't use v3, many people stated that it was because it isn't avaialable on the equipment they use. At least some of these folks would seem to be confused since the equipment which they indicated they managed does support v3. Lastly, Wes also asked what else the respondents wanted in v3. A number of them were content with v3 as it currently exists while others did have some additional desires. The leading desires on the list seemed to be bulk transfer (mostly with some sort of filtering at the agent side). Some other confused folks were asking for security. For more information from this survey can be seen at http://www.netsnmp.org/report In another section of the meeting, a participant stated that SNMPv3 was not being considered at his company due to a lack of integration with RADIUS and the lack of easy centrally controlled management.

-- Dave Harrington also presented information from several deployment reports he received by email that were focused on use of features added to RFCs 1905, 1906, and 1907. A number of these reports looked more like implementor reports rather than delployment reports but did identify use of the added features. As might be expected Dave has requested additional deployment reports, he will also try to generate a new feature list template for the core SNMPv3 specificactions that is similar to one used for 1905/1906/1907 since it seems to help collect information. We also do not need any company names, so if companies would like to send either of the Chairs a report, they can remove identifying information before incorporating that information into the full deployment report.

RFC1905 New Features

New error codes

RFC1906 New Features

SNMPv2 over UDP
SNMPv2 over OSI
SNMPv2 over DDP
AppleTalk Addressing
SNMPv2 over IPX
Proxy to SNMPv1

RFC1907 New Features

The System Group
The SNMP Group
Well-known Traps
The Set Group

-- Juergen Schoenwaelder (schoenw@ibr.cs.tu-bs.de) also reported that he has requested deployment information on the Scotty mailing list.

- REVIEW OF DOCUMENT STATUS (scheduled for 20 minutes):

Our current document set is:
Document Status
-------- ------
1905 Update Draft Standard
1906 Update Draft Standard
1907 Update Draft Standard
2570 Informational
2571 Draft Standard
2572 Draft Standard
2573 Draft Standard
2574 Draft Standard
2575 Draft Standard
2576 Proposed

The full requirements for moving from draft to full are described in RFC-2026 (A poll of the WG attendees indicated that almost no one at this meeting had read these. Russ noted that it would be good for people involved with any IETF activity to read it in order to understand some of the imprortant IETF process and standards requirements of the IETF).

The focus of the discussion was primarily on the specifications that have a status of Draft Standard. The requirements for advancing these specifications from Draft to full Standard are (Ref para 4.1.3, RFC-2026):

A specification for which significant implementation and successful
operational experience has been obtained may be elevated to the
Internet Standard level. An Internet Standard (which may simply be
referred to as a Standard) is characterized by a high degree of
technical maturity and by a generally held belief that the specified
protocol or service provides significant benefit to the Internet

In attempting to determine how to progress the various documents, we seem to have significant implementation experience with technically mature documents and a protocol that provides significant benefits. The remaining area is operational experience. In this area we have not yet put together a report. We had some general discussion about what was required in a deployment report. Randy Bush as AD indicated that we don't need a feature by feature analysis - that is required for the transition from Proposed to Draft but not for the transtion from Draft to full Standard. Significant experience is one of those things that we will know it when we see it (in the deployment reports, etc). Randy also indicated that the limited amount of information the WG has collected on SNMPv3 deployment might be a result of inadequate information collection techniques rather than inadequate deployment. In addition to known and planned SNMPV3 deployments, Wes Hardaker said that he had used SNMPv3 to manage a number of systems (around 100) at UC Davis. The result of the discussion was that the WG should move as quickly as possible with actions needed to send the current Draft specifications to the IESG recommending advancement to full Internet Standard.

Updates to RFCs 1905,6,7

The sepcifications have been finished and given experience with the features in the documents, it is the sense of the working group that we have enough operational experience to proceed with these documents even though we don't have a large number of deployment reports. Once again folks are asked to file reports or, if they are implementors, to try and get their customers to file reports. When asking customers, it is also probably best to specify the functionality in use (v2c or SNMP security etc) rather than to specify the RFCs. Since the documents have completed WG last call, the co-chairs will prepare the deployment report and forward the documents to the IESG. (Additional deployment reports or information will still be very helpful for this activity.)

Updates to 2571,2,3,4,5

There are a small number of edits required to clarify these documents but the list for each document is short (more or less around 5 per document). The group accepted a suggestion to send the edit lists to the Working Group mail list and ask if there are any more editorial items that are required for clarification. We can then respin the documents once more, do the WG last call, assemble the deployment report and forward the specifications to the IESG. (Again, additional deployment reports or information will still be very helpful for this activity.)

- OTHER RELATED ITEMS (scheduled for 15 minutes):

-- There was a discussion about implementors, implementing read-write variables as read-only. The specifcations do allow for this, possibly via the use of a conformance statement. The community does need to make clear that we want to make sure that all standards track MIBs use read-write where possible rather than making the MAX-ACCESS clause for objects READ-ONLY especially for objects that can be used for configuration.

One deployer pointed out that they haven't been using SNMP for configuration in any "dangerous" areas due to a lack of security (before SNMPv3 is deployed), another pointed out that they just don't use SNMP for configuration not due to security issues but just "the way things are done".

An implementor pointed out that while they don't use standard MIBs for setting all that much, they do use a fair number of enterprise MIBs that are settable.

-- Finally the chairs will talk to the ADs about updating the charter and will work on the potential deadlines for various documents.


CAIRN Diagram
Quick Usage Survey