NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 18-Mar-98
Chair(s):
Russ Mundy <mundy@tis.com>
Operations and Management Area Director(s):
John Curran <jcurran@bbn.com>
Michael O'Dell <mo@uu.net>
Operations and Management Area Advisor:
Michael O'Dell <mo@uu.net>
Mailing Lists:
General Discussion:snmpv3@tis.com
To Subscribe: snmpv3-request@tis.com
Archive: ftp://ftp.tis.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 Module Specification SNMPv3 Proxy Specification
Goals and Milestones:
Apr 97 |
|
Working Group meeting at Memphis IETF to discuss SNMPv3 recommended approach, discuss Working Group Charter and the plan for completion. |
Apr 97 |
|
Post first SNMPv3 Internet-Draft, Modules and Interface Definitions. |
Jun 97 |
|
Post revised SNMPv3 Modules and Interface Definitions Internet-Drafts. |
Jul 97 |
|
Post initial SNMPv3 Message Processing and Control Module Internet-Draft. |
Jul 97 |
|
Post initial SNMPv3 Security Model Module Internet-Draft. |
Aug 97 |
|
Finalize SNMPV3 Modules and Interface Definitions Internet-Draft and review other I-Ds at Munich IETF. |
Sep 97 |
|
Post revised SNMPv3 Message Processing and Control Module Internet-Draft. |
Sep 97 |
|
Post initial SNMPv3 Proxy Specification Internet-Draft. |
Sep 97 |
|
Post revised SNMPv3 Security Model Module Internet-Draft. |
Sep 97 |
|
Post revised SNMPv3 Local Processing Module Internet-Draft. |
Sep 97 |
|
Submit SNMPv3 Modules and Interface Definitions to IESG for consideration as a Proposed Standard. |
Apr 98 |
|
All SNMPv3 specifications submitted to IESG for consideration as Proposed Standards. |
Internet-Drafts:
· Local Processing Model for version 3 of the Simple Network Management Protocol (SNMPv3)
· User-based Security Model for version 3 of the Simple Network Management Protocol (SNMPv3)
· User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
Request For Comments:
RFC |
Status |
Title |
RFC2271 |
PS |
An Architecture for Describing SNMP Management Frameworks |
RFC2272 |
PS |
Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) |
RFC2273 |
PS |
SNMPv3 Applications |
RFC2274 |
PS |
User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) |
RFC2275 |
PS |
View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) |
Minutes of the SNMP Version 3 (snmpv3) Working Group
Reported by David Levi <levi@snmp.com>
List Comments Incorporated by Russ Mundy <mundy@tis.com>
The meeting started with an intro by Russ Mundy, including the agenda for the meeting. The agenda was modified slightly (it was decided to move discussion about address loss in traps to later in the meeting).
Reports on implementation (and planned implementation) followed. There are currently several commercial and public domain implementations available or under development. The following have implemented or are currently implementing:
· SNMP Research, Inc
· IBM
· Epilogue/ISI
· BMC/Peer
· UCDavis
· University of Braunschweig
· University of Montreal
In addition, Cisco, Ascend, and 3Com said they intended to include SNMPv3 in products.
Interoperability testing was planned for later in the week. Also, at the previous IETF meeting (in Washington DC), implementations by SNMP Research and the University of Braunschweig were able to exchange noAuth/noPriv SNMPv3 packets to a limited extent (this was the first reported interoperation of independent implementations).
There was discussion about having an SNMPv3 interoperability bake-off. It is expected that this will happen sometime before the next IETF meeting in August. There is also a need to have implementations on the Internet for people to test.
Jeff Case commented on the SNMPv3 HotSpot to be held at the May Interop+Networld in Las Vegas. There are currently 10 organizations planning to participate in the HotSpot. The HotSpot will basically be a demonstration of SNMPv3 technology and interoperability.
The snmpCommunityMIB which was recently posted to the snmpv3 mailing list was discussed briefly. Basically, the MIB will provide mappings between snmpv1/v2c community strings and snmpv3 securityNames and contextNames. This will allow snmpv1 and snmpv2c to be 'retro-fitted' to make use of the snmpv3 access control mechanisms. Note that this mib is based on the community MIB which was part of the snmpv2* proposal, and has been shown to work within an implementation of snmpv2*.
We then went into discussion about the status of the various snmpv3 documents, how to proceed with these documents, and what future documents will be written. The discussion focused on:
· what needs to be done to move rfcs 2271-5 to draft standard
· what needs to be done with rfcs 1902-8
· an overview document
· a coexistence and transition document
· issues related to SMI versions
David Perkins brought up the issue about the status of the SMIv2. The problem is that the SMIv2 is holding up standards advancement of MIBs that are written in the SMIv2 format. There was general agreement that the SMIv2 needed to be moved to full standard relatively quickly. David Perkins and others volunteered to do the edits necessary to accomplish this (this includes rfcs 1902-4).
The discussion about SMIv2 also brought up the issue about what to do with older standards track MIBs that are written in the SMIv1. The question is whether these MIBs should be converted to SMIv2. Some people were concerned that this would just be wasted effort, and that having multiple versions of these MIBs would be confusing to the marketplace. A benefit to doing the conversion would be that we could add conformance/compliance statements. It was noted that you can make editorial changes to documents and still be able to recycle at the same standards level. It may be possible to categorize conversion of MIBs as editorial changes, and this would make it easier to get the converted MIBs into rfcs. Need to be clear that other parts of documents should not be 'tinkered with' when doing a MIB conversion. The Area Directors for the WG will seek clarification from the IESG on this issue.
Discussion about how to deal with rfcs 2271-5. We talked about whether we should try to advance to draft status at the August IETF. It was pointed out that the up-dated, replacement documents should not be posted as multiple IDs since this would give the impression that SNMPv3 is unstable. The suggested alternative was posting needed changes on a web site which is publicized on the mail list so that consensus on changes can be reached before the replacement documents are published as IDs.
The only requirement in rfc2026 for documents to move to draft standard is to have 'sufficient operational experience'. Testing is being done to obtain this, and we believe we will fulfill this requirement soon. We decided to aim for advancing rfc2271-5 sometime between the August and December IETF meetings. We also decided that the document editors would post accumulated document changes, and that we need to have more interoperability testing before August.
Template users were discussed briefly. Basically, a template user is a snmpv3 usm user that is not used for snmpv3 communications, and is only used for creating new users. When creating a new user, you would clone an existing template user, and then modify the new user's keys. There is a question as to whether three template users are required to allow creation of users with noAuthnoPriv, authNoPriv, and authPriv capabilities, or whether this can be accomplished with a single template. The way rfc2274 is written, unless you are allowed to 'downgrade' a users auth and priv protocols, you either need to have three templates, or you have to accept having users who have unused auth or priv keys. This topic needs more discussion.
The coexistence and transition document will basically merge rfc1908, rfc2089, the snmpCommunityMIB, and some text to describe a community based security model. The schedule is to have an initial document ready at the end of May or early June, and to try to get the document to proposed standard status in December.
There was a comment made about trying to make rfc1905 more SMI-independent, to allow work to be done on the SMI without affecting protocol operations.
The work for updating documents was divided as follows:
· rfc2271-2275, the document editors are responsible for updates
· rfc2271 - Randy Presuhn, Bert Wijnen
· rfc2272 - Jeff Case, Randy Presuhn, Bert Wijnen
· rfc2273 - David Levi, Paul Meyer, Bob Stewart
· rfc2274 - Uri Blumenthal, Bert Wijnen
· rfc2275 - Bert Wijnen, Randy Presuhn, Keith McCloghrie
· rfc1902-1904 (SMI stuff), David Perkins, Juergen Schoenwaelder, Keith McCloghrie
· The overview document, Jeff Case, Dave Partain, Bob Stewart, Russ Mundy, Shawn Routhier
· Coexistence/Transition document, David Levi, Rob Frye, Shawn Routhier, Bert Wijnen
· rfc1905-1906 (proto ops, transport mappings), Jeff Case
· rfc1907 (snmpv2 mib), Juergen Schoenwaelder
· Dan Romanascu volunteered to deal with updating existing SMIv1 MIBs to SMIv2
The editor teams for each of these documents will develop a work plan that will provide milestones and dates. These work plans will be the basis for most of the milestones and dates needed for the revision of the WG charter.
There was some discussion about the issue of trap source loss when converting traps from snmpv3 to snmpv2c or snmpv1. The problem is that snmpv2c traps do not contain either an agent_addr (like snmpv1 traps), or a contextEngineID (like snmpv3 traps). There has been discussion on the snmpv3 mailing list about possibly defining some addition varbinds to be included in snmpv2c traps to try to address this problem. Some additional points made during the meeting were:
· Is there a good reason to fix v2c in this regard, when you can use v3 noauth/nopriv?
· There are already applications deployed which use snmpv2c, and which need a solution to this problem
· We should *not* try to avoid using snmpv3 technology by attempting to retrofit v1 and v2c. We should be encouraging the use of snmpv3 instead.
· The use of snmpEngineID as a trap's source means management applications must store information about devices keyed on snmpEngineID rather than on IP address
The need for improved boilerplate text for documents was mentioned. Andy Bierman will work on this (there is already some useful stuff in other documents he has worked on).
We briefly talked about what to do with rfc1901, rfc1909, and rfc1910. We decided no action is required for rfc1909 and rfc1910, but the WG will recommend to the IESG that they should become historic. We further decided that we will do nothing with rfc1901 for now but that it may become informational or historic in the future.
There was some discussion about the various IDs published by David Perkins and others as possible items for the WG. From these IDs, the most important thing appears to be the need for additional 64-bit types (like Gauge64). One possible solution is to have a Gauge64 TC whose underlying type is Counter64. It was not clear where this work should be done:
· perhaps it should be put in 1902
· perhaps we could start a series of 'annex' documents in which new generally useful TCs could be placed.