2.4.18 SNMP Version 3 (snmpv3)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 26-Nov-97

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:

No Request For Comments

Current Meeting Report

Minutes of the SNMP Version 3 (SNMPv3) WG

Chair: Russ Mundy, TIS

Reported by: Shawn A. Routhier, Epilogue

Russ opened the meeting with the agenda and a hope that we would be able to finish this meeting early.

Agenda

I. Status Report on Current Ids
II. Proposed Additional WG Docs
III. SNMPv3 Implementation Status Reports
IV. Potential Interoperability Demos
V. Discussion of Charter Revisions.

I. Status Report on Current IDs

The current ID's were approved as proposed standards with a clarification requested for the USM document. The approved IDs were:

<draft-ietf-snmpv3-next-gen-arch-07.txt>
<draft-ietf-snmpv3-v3mpc-model-07.txt>
<draft-ietf-snmpv3-appl-05.txt>
<draft-ietf-snmpv3-usm-04.txt>
<draft-ietf-snmpv3-acm-05.txt>

Thanks was given to the workers who put in large amounts of time and effort producing the specifications.

II. Proposed Additional WG Documents

We discussed what, if any, additional documents were required. The proposed additional documents discussed were:

The consensus was that an overview (road map) document was desired. This would describe how the pieces relate to each other for SNMPv3 and the 190x series, it also might contain applicability statements. The AD (Mike O'Dell) stated that due to the importance of the information that might be contained in this document, it might be appropriate for it to be a standards track document.

We shall examine RFC1908 and RFC2089 and see if those documents can be used to deal with handling v1/v2c by SNMPv3. As neither of those docs address adding v1/v2c into schemes such as the one for view control, we may need additional text to cover such issues.

We moved onto discussing what changes might be required for 1901 - 1908. The changes discussed were mostly not caused by V3 but were from other areas. We had: IPv6 related items, such as textual conventions, 64-bit integers for RMON, and the drafts that Dave Perkins had published earlier in 1997. The most urgent of these is the 64-bit integers for RMON. Some concern was expressed over the effects these changes could have on the elevation potential of 1902-1908. The AD (again Mike) notes that if backwards compatibility is preserved we might still be able to upgrade the documents (1902 - 1908) from draft to full. The end result was that we need to think this through and determine what minimizes the end to end delay but there don't seem to be any show stoppers.

Russ is now looking for editors for various documents, he also will be talking with Dave Perkins about Dave's previous posts for modifying the SMI.

III. Implementation Status Reports:

Several groups had implementations in various states, although no interoperability testing has been done as yet.

Dave Levi (SNMP Research) has been implementing for some time and hasn't found any problems with the docs, but he also pointed out that due to his involvement writing the docs he isn't the best candidate for reviewing them. He also hasn't run into any major technical problems. One item he noted was related to unknownEngineIds; there is some text that says you are supposed to increment unknownEngineIds but requires you know whether or not you are authoritative to take the correct action. It was not clear if (or how) you could determine whether or not you were authoritative at that point in the text.

Ylian Saint-Hilaire, Omar Cherkaoui (University of Quebec in Montreal) have implemented most of the modules in Java. They have been using debugging versions rather than field tools and have not added security or things related to it yet. For them modularity was a prime objective and they have chosen to follow the ASIs when implementing the code. They allow live attach and detach of security and application modules. They have tested all input/output of SNMPv3 packets, and have partially tested input/output for their modules. They do plan to make it publicly available and some information may be found at "http://atm.teleinfo.uqam.ca/snmp."

Bert Wijnen (IBM Research) has started work and plans to include security and acm but not including the proxy stuff at the start. He doesn't intend to follow the ASIs while coding.

Randy Presuhn (BMC), they are early in the implementation of v3 but looking at it from an agentx perspective. They feel there may be some problems with the key change objects and the way they are accessed. There is some discussion about why the key change objects are the way they are (basically to allow for a simpler ACM table while allowing a user to change his own keys).

Shawn Routhier (Epilogue/ISI) has started work, they will be starting with the security features and may defer the proxy. They also won't be using the ASI's while coding.

Juergen Schoenwaelder (TU Braunschweig) has started an implementation, but has found several items that were unclear. He is somewhat less optimistic than Dave Levi and Ylian Saint-Hillaire.

There was a small amount of discussion about the testing of the remote configuration of access control and security items. The one group that has an implementation also has a tool to do this and thought that it was working well.

IV. Interoperability Demos

We then turned to the possible timing and location of interoperability demos. Dave Levi mentioned that there has been some contact with Interop about doing something like a technology showcase in the Las Vegas Interop (May 5-7 1998). Some 7 or 8 groups are interested and may be able to participate. Other suggested and possible testing options include: BMC in either Houston or Sunnyvale, TIS in mid to late 1998, somewhere else in the DC area around the end of March (next IETF), and Interworking Labs. (Editors note: Interworking Labs has hosted various testing events in the past and so their name was mentioned as a possible option. However they were not available at the meeting to discuss if they would be able to help with such an event).

There were several general comments about testing.

1) Interop tends to be more of a marketing demo while other testing may be more of an engineering bakeoff.
2) Testing that isn't under non-disclosure isn't all that useful
3) Some amount of testing should be done over the internet using well known addresses.
4) Keeping a log (or web page) of the unclear issues as well as sending mail to the list will help in finding and correcting them.
5) We should probably have a test plan for both MIB related and security related items. Dave Perkins volunteered to help write one of these two plans.

With this in mind we are targeting a bakeoff test for sometime around the March IETF.

V. Discussion of Charter Revisions

Our current deliverables were completed 4 months early and it is time to decide what, if any, changes should be to the charter.

The overview document now has a target date of February 1998 for the first ID to be posted on the list, this would be similar to RFC1901. There was some discussion if 1901 will be replaced, the answer seems to be no, both will continue to be required.

There is also a desire for a v3 to v1/v2c coexistence spec similar to and possibly replacing 1908.

We discussed but did not reach consensus on a recommended status for V2C. This should be discussed further on the list.

Russ intends to identify volunteers to perform as editors for the docs shortly after Christmas (Dec 25) and then, in conjunction with the IESG, will start work on revising the charter.

This was the end of the items on the formal agenda.

VI. Other Items

We started a discussion of items that had been deferred pending resolution of the security issues. The issues brought up were: SMI issues that were previously posted, 64 bit integers, floating point (single & double precision), something better than GetBulk, and some sort of ACTION verb perhaps combining GET/SET into one operation.

The floating point data types may be handled via some sort of textual conventions rather than creating a new base type. However, we need to determine if the conventions should be done now as part of the v3 work or if they can wait until there is a MIB that needs them.

It was pointed out that we had looked at adding a better GetBulk and an action verb some time ago and decided against them. If things haven't changed we may not need to do anything for them now.

VII. Final Item

Russ wanted to give one more round of applause to the editors of our current set of documents.

Slides

Modular SNMP
SNMPv3 Agenda

Attendees List

go to list

Previous PageNext Page