NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 05-Mar-99
Chair(s):
Russ Mundy <mundy@tis.com>
Operations and Management Area Director(s):
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>
Operations and Management Area Advisor:
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Mailing Lists:
General Discussion:snmpv3@lists.tislabs.com
To Subscribe: snmpv3-request@lists.tislabs.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 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:
· User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
· Introduction to Version 3 of the Internet standard Network Management Framework
· View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
· An Architecture for Describing SNMP Management Frameworks
· Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
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 SNMPv3 Working Group
Minneapolis IETF
Friday, 19 March 1999, 9:00 AM
Minutes: - Bob Stewart, edits: - Russ Mundy
The chair, Russ Mundy called the meeting to order and began with mutual self congratulations on the IESG approval of our core documents for Draft Standard and the introduction document for Informational. The documents are in the hands of the RFC Editor, waiting to be issued.
We reviewed the published agenda and made no changes. These minutes follow that agenda.
Rob Frye gave a presentation on the coexistence document. His slides, available from the IETF proceedings, contain the bulk of his points. The following points received his particular emphasis or group discussion.
The major remaining issue was Counter64 behavior for SNMPv1, with the following major points.
A general mechanism for data type extensibility is out of scope.
Rob overviewed the problem and available options.
Rob explained the editors' proposed solution but noted it had a serious problem of requiring proper error handling in old, existing application code.
Rob then confirmed the following points of consensus regarding an acceptible solution:
- It should cover multilingual systems.
- It should cover proxy.
- It should be for direct access or proxy. This is a strong should since the major difficulty is regarding proxy for an SNMPv1 application to an SNMPv2c/SNMPv3 agent, which is considered a minor situation.
- Get, GetNext, and Set should operate the same direct or proxy if practical.
- Notifications should operate the same direct or proxy if practical.
- In general SNMPv1 applications can handle OPAQUE objects but do not drill into object contents.
- NetworkAddress as an index is a problem but of little concern as the only standard MIB where it appears is a deprecated section of MIB II. The coexistence documenet will say that this is covered simply by including a constant 1 as an index field in front of an OCTET STRING network address.
- We should not address general extensibility of data types.
During this discussion there was a suggestion from the floor (from Bob Stewart) on how to handle the one sticky case for the preferred solution of treating Counter64 as not in view. We then discussed that suggestion.
The problem is when an SNMPv1 application sends a GetNext request through a proxy to an SNMPv2 or higher version agent and the proxy gets back a Counter64. In that case the proxy must iterate the request with the agent until it gets past the Counter64, a potentially long, messy, expensive process.
The proposed solution is to tell network administrators who see this problem to solve the inefficiency by defining for that application's community a view that does not contain the Counter64, making it truly not in view via access control, thus keeping the necessary iteration within the agent.
In addition to this, a proxy that does iterate should push the last subidentifier of the offending object to its maximum value to avoid useless iterations, then re-request all data.
The editors accepted this proposal, to be added as implementation and deployment notes. In addition the editors' proposal to return genErr was changed to noSuchName and we decided to follow standard not-in-view procedure and drop notifications going out as SNMPv1 but coming in with Counter64.
We then moved on to what needs to be updated in RFCs 1905, 1906, and 1907 for them to go to full Internet Standard.
They need some clarifications and an editorial pass. They will not be open for general changes. The goal is to go from Draft Standard to full Standard. We need to adjust terminology similar to what was done for SMPv2. This should be pervasive if not too painful or otherwise a front-end paragraph.
Changes need to be clean, clear, and simple.
Randy Presuhn, Dave Perkins, and Keith McCloghrie volunteered on the spot. Others provided a maybe, and the need is to be mentioned on the mailing list.
The next major point was the need for an applicability statement. Russ reported that Scott Bradner says our present documents are sufficient in that regard. There was some sentiment that we might need something along the line of what it means to implement SNMPv3, but we decided to wait and see.
We then discussed wether we needed other major documents on deployment or implementation.
- A deployment document would capture what deployment strategies and techniques were intended and expected by the designers. It should include the view of the operations people. We decided we couldn't do that now but perhaps some of us could work with the early deployers.
- As to an implementation document, we noted that there are now plenty of implementations without one and that it would be hard to find time for the working group to develop one. The working group consensus was that this item should be dropped as a working group item, perhaps leaving it to The Simple Times.
The next agenda item was the work schedule. The coexistence document will tentatively have a new draft by 30 April. The update team for the old RFCs will provide a sense of the problem by 26 April.
Next on the agenda was a charter update. This will be done after the update team's report, with Russ providing an early pass to the Area Directors.
We then had an informational presentation from Ken Hornstein on his Kerberos for SNMPv3 security research project. He indicated this was an interesting experiment. It's a big change from SNMP's traditional independence from other protocols but has some benefits. We decided to revisit this approach after further research work. There was a question about how it would apply with AgentX.
As a final note, Bob Stewart reported that Cisco is now shipping SNMPv3 in IOS and we issued a general call for people to send product ship reports to Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de> for inclusion on his SNMPv3 web site and for The Simple Times.