NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 03-Feb-00
Chair(s):
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:
Done |
|
Post first SNMPv3 Internet-Draft, Modules and Interface Definitions. |
Done |
|
Working Group meeting at Memphis IETF to discuss SNMPv3 recommended approach, discuss Working Group Charter and the plan for completion. |
Done |
|
Post revised SNMPv3 Modules and Interface Definitions Internet-Drafts. |
Done |
|
Post initial SNMPv3 Message Processing and Control Module Internet-Draft. |
Done |
|
Post initial SNMPv3 Security Model Module Internet-Draft. |
Done |
|
Finalize SNMPV3 Modules and Interface Definitions Internet-Draft and review other I-Ds at Munich IETF. |
Done |
|
Post revised SNMPv3 Local Processing Module Internet-Draft. |
Done |
|
Post revised SNMPv3 Security Model Module Internet-Draft. |
Done |
|
Post revised SNMPv3 Message Processing and Control Module Internet-Draft. |
Done |
|
Post initial SNMPv3 Proxy Specification Internet-Draft. |
Done |
|
Submit SNMPv3 Modules and Interface Definitions to IESG for consideration as a Proposed Standard. |
Done |
|
All SNMPv3 specifications submitted to IESG for consideration as Proposed Standards. |
Jul 98 |
|
Testing of interoperability between independent implementations of SNMPv3 core specifications. |
Jul 98 |
|
Post the initial Internet Draft of the Intro document. |
Aug 98 |
|
Post initial Internet Drafts for updating the SNMPv3 core specifications. |
Aug 98 |
|
Post initial version of the Coexistence document as an Internet-Draft. |
Aug 98 |
|
SNMPv3 Working Group Meeting at 42nd IETF. |
Sep 98 |
|
Post revised version of the Intro document Internet-Draft. |
Sep 98 |
|
Post revised version of the Coexistence document as an Internet-Draft. |
Oct 98 |
|
Complete Working Group actions on revisions to core specifications and forward documents to the IESG for consideration as Draft Standard RFCs. |
Internet-Drafts:
· Version 2 of the Protocol Operations for the Simple Network Management Protocol
· Transport Mappings for the Simple Network Management Protocol
· Management Information Base for the Simple Network Management Protocol
Request For Comments:
RFC |
Status |
Title |
RFC2576 |
PS |
Coexistence between SNMP versions |
RFC2573 |
DS |
SNMPv3 Applications |
RFC2574 |
DS |
User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) |
RFC2575 |
DS |
View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) |
RFC2570 |
Introduction to Version 3 of the Internet standard Network Management Framework | |
RFC2571 |
DS |
An Architecture for Describing SNMP Management Frameworks |
RFC2572 |
DS |
Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) |
SNMPv3 Working Group
Recorded by Jeff Case
47th IETF
Adelaide Australia
Wednesday March 29, 2000
Welcome by Russ Mundy.
Introduction of new co-chair, David Harrington, Enterasys.
Agenda Bashing -- no changes from agenda published on mailing list.
Acknowledgement of Published RFC Updates.
The publication of two documents since the 46th IETF was announced:
- Coexistence and transition document (RFC 2776), Proposed Standard.
- Diffie-Helman USM Key Management extensions (RFC 2786), Experimental.
The next topic was the discussion of updated versions of RFCs 1905-1907 in the interest of advancing them from Draft to Full Standard status.
Randy Presuhn made a presentation on the very few remaining open issues with respect to the drafts which had been issued before the meeting:
draft-ietf-snmpv3-update-mib-01.txt
draft-ietf-snmpv3-update-transmap-01.txt
draft-ietf-snmpv3-update-proto-01.txt
RFC 1905 bis: there are no known outstanding open issues
RFC 1906 bis: there are two related open issues related to rfc1157 domain
The issue can be researched by looking at
ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1906/issue1906-06.html
The -01 document leaves the text largely unchanged. However, there were at least two comments on the mailing list that the text should be made more clear or the rfc1157 domain should be deprecated.
None of the people who raised objections to the text found in the -01 draft were present and the objections were posted after most of those present at the meeting had left home, both of which made discussion somewhat difficult.
Keith McCloghrie encouraged the group to come to some closure at the meeting. Randy Bush said that we could not make any final decisions today -- that everything must be decided on the list.
The group did take a straw-man vote among those present to get a sense of the working group. There was no objection to advancing the text as published in the -01 draft.
The final decision on this issue was deferred to the mailing list.
RFC 1907 bis: there is one set of related open issues related to the internationalization of character strings and UTF-8, specifically related to the MIB objects sysDescr, sysName, sysContact, and sysORDescr.
The issue can be researched by looking at
ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1907/issue1907-18.html
Jeff Case argued against the change, reiterating what he had posted to the list. He suggested that we have 3 basic choices (really 2):
1. leave these objects as they are in RFC 1907, but create additional objects that contain localized variations of objects such as sysName and sysContact, etc
2. make the changes as proposed in the -01 draft
3. do neither -- but expect to get the document thrown backin our faces when it reaches the IESG -- not recommended
Jeff stated his strong preference for option (1) and explained why he thought that options (2) and (3) were unworkable.
Bert Wijnen pointed out the need for this change as proposed in the -01 draft (He spoke in favor of option 2). Bert said we have made similar changes before (Entity MIB).
Randy Presuhn stated his preference for the text in the -01 draft (He spoke in favor of option 1).
Mike St. Johns: This violates the SMI. Use duplicate objects. (He spoke in favor of option 1).
Ran Atkinson: Use duplicate objects. (He spoke in favor of option 1).
Participants were encouraged make sure their positions had been posted to the mailing list.
A suggestion was made to take a straw poll.
After much time and flagellating, we got through the poll.
Q1: Retain DisplayString object semantics as found in RFC 1907
(i.e., part of option 1)
sense of the room is yes
Q2: Create new UTF objects in parallel
(i.e., part of option 1)
(the question did not distinguish between in parallel in the same draft or in a separate draft)
sense of the room is yes
Q3: Deprecate existing objects
consensus is no
Q4: Change semantics on objects to UTF8
(i.e., part of option 2)
sense of the room is no
It was again observed the the Entity MIB WG has already acted in a way that too the opposite approach to the above conclusions.
Bert observed that we cannot add objects to the MIB and advance. Others observed that the information module containing the new objects need not be in the same document.
The consensus of the room was for option 1, but based on Randy Bush's earlier input, we were unable to come to a conclusion. Correspondingly, the issue was deferred to the list for the final decision.
The next topic was SNMPv3 Deployment Reports
Russ Mundy, co-chair reported on four sets of deployment experience he has become aware of.
Small testbed at NAI labs
Verio - Carl Kalbfleish
SNMP Research
MG-Soft Reports Significant v3 Product Sales to "Users"
He called on Carl Kalbfleish, Verio, who reported on the limited work done to date in his test lab environment.
Others were invited to make reports of their experiences.
Ran Atkinson reported on the DOCSIS cable modem standard. Testing is happening in the lab against cable modem products. Testing is occuring with agent products built using products from two of the leading toolkit vendors.
One vendor indicated that he knows of others in the room that have SNMPv3 successfully implemented (and deployed) but continue to be shy about coming forward and reporting on it. It is somewhat unknown why these people do not want to make their reports public.
Deployment experience should be sent to snmpv3@lists.tislabs.com or Russ Mundy or Dave Harrington.
It was suggested that people may want to be on the lookout for a large United States Postal Service (USPS) Request for Proposals (RFP) which is rumored to contain a large SNMPv3 component.
The next topic was SNMPv3 Q & A Document Discussion: David Harrington
Dave Harrington had proposed on the list that we create a question and answer document.
So far, he has received only a few comments on the proposal.
The purpose of the Internet Draft would be to cover the following:
- Frequently Asked Questions
- What does SNMPv3 Do?
- Alternatives to SNMPv3
- Implementation Concerns
- Deployment Concerns
- Recommended Practices
This document would be similar in some ways to the document from the IAB on the case for IPv6.
He wants to be try to answer some of the questions people ask when they go to deploy or implement SNMPv3.
- Costs/Benefits. Feasibility Analysis. Resource Planning.
- Resure[sic]/Integration Studies. Buy/Develop Decision.
- How does SNMPv3 benefit my customer? What features can I sell my customer?
- Alternatives. Why not SNMPv2c, Ipsec, WEBM...
- Implementation concerns - code space, etc
- Deployment concerns. How hard is it to manage? More operators?
- Interoperability.
- Co-existence with other management v1, v2c, cli, radius, cops, cmip, tmn
- Recommended Practices. Once there is a view based control mechanism? How do you use it? Routing configuration verses sysContact. Security Parameters.
- A/C statements, sysORTable (to determine the capabilities of devices). As release notes
See Dave's presentation slides for additional detailed subpoints -- sorry, but we were unable to keep up here.
Dave is looking for looking for volunteers to each write small portions of the document.
The next topic was Promoting SNMPv3
New/Updated Implementations were discussed. SNMPv3 is now shipping in RedHat Linux and FreeBSD.
Find information on Juergen's Web site:
http://www.ibr.cs.tu-bs.de/projects/snmpv3
There is an interest in identifying organizations requiring and buying SNMPv3 and other promotional ideas.
IWL has offered to host additional interoperability testing if there is sufficient interest.
Bert (with AD hat on): promotional activities that smack of marketing should happen outside the IETF.
Randy Presuhn: should document the experience with WinSNMP and snmp++ to support SNMPv3. There was some question about how complete those works are.
Dave Perkins: is getting questions from cable modem customers about how to use SNMPv3. He has SNMPv3, but has not turned it on, because he does not have sufficient printed information.
Straw poll: do we want to do interoperability testing? No strong support. Steve Waldbusser: thinks that we are past the time where interoperability testing is either necessary or useful - may be counterproductive by sending the wrong message - indicating the technology is less mature than it is.
Bert: sees no need for interoperability testing for promotion.
Randy Bush sees no strong need for additional interoperability testing.
The next topic was Discussion of Related Items
Several potential additional Working Group items were identified and discussed. One question articulated by Co-chair Mundy is:
What additional information and specifications that would encourage greater deployment and use of SNMPv3?
Several additional security components were discussed in this light:
- Diffie-Helman USM Key Management extensions on standards track
- Triple-DES protection from disclosure
- Kerberos
There was no strong interest at this time in bringing new work into the Working Group with respect to additional security modules
Jeff Case suggested that it might reduce barriers to adoption and deployment if we invite an expert speaker to come to a future meeting and present tutorial information on the impact of recent changes in export control regulations.
Next, there was an attempt to gauge interest in new work items to be considered either in this Working Group, or a new one. A large number of possible work items were presented:
- Recommended Practices
- Views for Common MIB Objects
- read-only versus read-write
- routing configuration versus sysContact
- Security Parameters (USM, VACM)
- Usefulness of A/C Statement
- Management Extensions for SNMPv3 Applications
- Bulk Transfer
- OID Compression
- Operations on PDUs
- New (High Capacity) Datatypes
- New SMI
- Complete Information Modeling
Moving topics from ongoing IRTF work to new IETF work
A total of eleven work areas were presented. A straw poll was taken on several of these topics.
- bulk transfer
sense of the room was in favor of looking at working on it
- OID compression
sense of the room was in favor of looking at working on it
- operations and pdus
sense of the room was in favor of looking at working on it
The room became somewhat restless, in part, because attendees were being asked to take a position on questions they did not fully understand.
At this point, Ran observed that we need to stop enhancing, fixing, and extending and leave things stable so the market can catch up.
Randy Bush responded: we cannot remain static -- we have had pressure for some changes building for some time ... therefore we must pick the items for our future work lists *_very_* carefully.
The opinions were expressed that our next work items need to
- incorporate management features, not merely more security
- address long-standing issues
- produce solutions compatible with snmpv3
- be clearly focused projects
At this point David Harrington got his laptop working again which allowed him to project his presentation.
Proposed Phase 1
- efficient data transfer
- bulk transfer
- improved table retrieval
- OID compression / suppression
Proposed Phase 2
- new data types and operators
- need to the understand problem
Proposed Phase N
- Non engineering ready
- Focus not well understood
- Not sure which wg should handle these
- May be IRTF efforts
There was no attempt to propose that all work be done here.
Projects that should be reviewed in other places including DISMAN Remote intelligence
Standardized script language: DISMAN or SNMPCONF
The meeting concluded when we ran out of time at 5:30 pm.
Respectfully submitted,
Jeff Case
(Thanks also to Carl Kalbfleisch who provided a second set of notes which
helped in the "hurried" places.)
Agenda
Remaining Issues for RFC 1905, 1906, and 1907 updates