NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Russ Mundy <mundy@tis.com>
Operations and Management Area Director(s):
Scott Bradner <sob@harvard.edu>
Michael O'Dell <mo@uu.net>
Deirdre Kostick <kostick@qsun.att.com>
Mike O'Dell <mo@uu.net>
General Discussion:snmpv3@tis.com
To Subscribe: snmpv3-request@tis.com
Archive: ftp://ftp.tis.com/pub/ietf/snmpv3
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 SpecificationGoals and Milestones:
Reported by: Jeff Johnson, Cisco SystemsApril 9, 1997 Evening Session
Russ Mundy, Working Group Chair, opened the session by introducing the O&M Area Directors John Curren and Mike O'Dell, as well as outgoing Area Director Scott Bradner. Since Mike has primary ownership of the Working Group, he gave a brief presentation.
Mike's point of view is that there is nearly a half-billion dollars worth of network elements that are managed via SNMP. There needs to be a mechanism to secure them. And since his company deploys such elements, he is a customer of our work.
Mike then commented on the name of the Working Group, SNMPv3. He pointed out that it could have been simply called SNMP "Yet Again." But by applying a number to it, SNMPv3, we're putting a stamp on it. This is it. The Working Group is being given one last chance to succeed, and we need to answer the following question: are we closer to the end, or further from the beginning? We need to get security resolved, and we must succeed; the community needs for us to succeed.
John Curren then briefly added that although he's been active in the IETF for over five years, it's always been outside of Network Management. However, he's had a chance to look in lately, and he's available as a resource for the Working Group. He stressed that we need to fix the state of network management. We need to have realistic expectations and produce something useful. We need something that is deployable; it doesn't have to be perfect. We need it quickly and it must be functional.
Scott Bradner then gave his very succinct analysis of the job of the Working Group. We have one mission, only one mission. We must make SNMP secure in a way that is useful for the people operating networks. We cannot deviate from that single narrow focus. Our only aim is security.
Russ then reviewed the agenda and the charter. He stressed that we are starting with the recommendation of the advisory team; we are not starting new work. He pointed out that the recommendation provides for both security models and security protocols that are replaceable. We want to leverage as much of the USEC and V2* work as is practical. We are planning on producing five specifications while avoiding changes to RFCs 1902-1907.
This last point caused a bit of discussion. Dave Perkins is concerned that other problems won't be addressed, and Andy Bierman specifically pointed out the need for Integer64 and Unsigned64 data types in the RMON2 Working Group. Mike O'Dell told the Working Group that if we have working group last call by the Munich IETF, then we'll tackle the other issues.
David Harrington then began an overview of the architecture proposed by the advisory team. The Trap Table in the Local Processing module was the immediate subject of discussion. Randy Presuhn pointed out that the DisMan Working Group is also looking at a trap destination table. He is concerned that there might be a duplication of effort, and further concerned that the final design contain the right stuff for both working groups. There was some discussion as to whether sending traps is a part of the Local Processing, or really part of applications. Steve Waldbusser noted that all SNMP transactions are initiated by applications except for one exception: agents sending traps. The model for notifications should be like every other transaction. It is generated by the application, outside of the protocol engine and traps should be dealt with as an exception in which the agent needs a mechanism for listing trap destinations, a statement with which several members of the working group concurred.
The question was then raised as to how informs fit into the model. Keith McCloghrie felt that traps and informs should be handled similarly. He asserted that it is agents that have the information, so it is agents that should be sending both traps and informs. Fred Baker asked Keith to confirm that he believes that agents should be capable of sending informs, despite language in RFC 1905 which states that informs are sent by management applications; Keith confirmed. It was pointed out that we need to be specific about what we mean by an "agent" versus a "management application" in the scope of the architecture.
Bob Stewart had a different spin on traps and informs. He feels that traps and informs are management activities, sent by management applications, to which Randy Presuhn observed that regardless of which "box" traps fall into, we must recognize that traps are different. Specifically, outgoing traps go through access control.
Jeff Case then opinioned that management emissions are at the response of management applications, and that application inputs come from many places. There is a need for stable storage to indicate where to send notifications, but applications can also have non-stable destinations.
There was consensus that the Working Group was rat holing on traps, so the question was raised if there were any problems, except for notifications, with the modular approach outlined by the advisory team.
Keith McCloghrie was curious just how tightly coupled the MPC and LP are, seeing as how the pdu version number refers to both. He wanted to know if these should be more modular with separate version numbers or whether they should be tightly coupled. Randy Presuhn further pointed out that version is even more overloaded because it also refers to SMI as well as LP model. Dave Perkins explained that using the version to refer to SMI is one of the problems with the current SNMP that he wants to fix but which are out of scope. Dave Fowler then observed that "management applications" are referenced throughout the documents, but that all aspects are considered implementation-dependent. This led to lots of discussion about what is an application. This discussion ate up the remaining meeting time.
April 10, 1997 Afternoon Session
Russ began by summarizing the previous evening's meeting. He then informed the Working Group that the Area Directors do not consider the initial schedule on the Working Group charter aggressive enough. It is their desire to be at Working Group last call by Munich.
David Harrington then began by reviewing what is in the boxes. There are three types of modules inside the snmp engine:
mpc: coordination sec: message-level security (authentication/privacy) lpm: accesses control, coordinate processing of pdu
Inside a system, there are some "functional thingies" that "use" the engine (the term "functional thingy" was coined in order to avoid some of the semantic baggage which is attached to the term "application," in particular, we want to be clear that these can be present on either a management station or a managed device).
David then explained that one of the problems with the proposal is separating the architecture from the SNMPv3 message format. In order to clarify the architecture, David drew up a slide showing potentially many MPCs, SECs and LPMs in an engine. Although the Working Group is specifically concerned with the SNMPv3 MPC, there can be multiple MPCs in an engine, such as an SNMPv1 or SNMPv2C MPC. Randy Presuhn was curious where the MPC recognition takes place. There is a demultiplexing which occurs when a message is received by the transport, but the exact location is implementation dependent. Randy was also curious if the MPC defines the binding to the LPM. The answer is that it depends on the LPM. If an SNMPv3 message is received, the MPC looks at the message's security model to see which security function to use, but there is only one SNMPv3 MPC and LPM. If, for example, an SNMPv1 message is received, the v1 MPC is hardwired to use the community security model, and the v1 LPM is used. But it was clarified that since RFC 1157 does not really specify a LPM, the v3 LPM could be used for SNMPv1 messages. In other words, the v3 LPM may be used for v1 messages, but it is not required to be used for them.
A discussion followed about where an MIB lives. Information is held in various places, and there is an interface between the LPM and the instrumentation. A MIB interface provides access control to the instrumentation. However, functional "thingys" can also access the instrumentation via other, non-SNMP mechanisms. It was further noted that the difference between MIBs and instrumentation is an agent issue, not an NMS issue. MIBs are the mechanism for accessing the instrumentation. It was asked if the Working Group plans on defining an API for accessing the information. The answer is no, it is just an architectural interface; realization of the interface is application-specific.
Keith McCloghrie voiced a concern that the working group is being too specific in specifying the interfaces between the modules in the architecture, that it is a slippery slope. Jeff Case concurred with this sentiment. We need to make sure we are specifying a service interface and not an application interface. The problem appears to be the term "interface." Many people equate it with API, but in this case it is not.
Following this discussion, David Harrington gave a quick description of the message flows through the architecture:
All was pretty quiet until we reached the trap flow. It is different from both generating a request and generating a trap in that the PDU goes through access control before being sent. Discussion began once again on the trap flow, but since the meeting time was over, it was squelched.
Russ then summarized the meeting. There are plans for up to six documents:
· V3 Message Processing & Control
The last of these may be combined into a single document.Finally, a new schedule was proposed:
This would allow a Working Group Last Call by Munich. There were many objections to this schedule, but the ADs stressed that we must meet this schedule. This was followed by much discussion on the possibility of achieving this goal, which really didn't go anywhere. Then the meeting was adjourned.
1. SNMP Advisory Team Results and Recommendations
2. SNMPv3 Working Group – Agenda
3. SNMPv3 Working Group – Charter Review