Editor's Note: These minutes have not been edited. Minutes of the IETF 38 SNMPv3 Working Group Reported by Jeff Johnson, cisco Systems 09Apr97 Evening Session Working Group Chair Russ Mundy 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 are 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. And we need it quickly, and it must be functional. Scott Bradner then gave his very succint 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 specificly 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 was 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 similiarly. 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. Specificially, outgoing traps go thru 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 concensus 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. 10Apr97 Afternoon Session Russ began by summarizing the previous evening's meeting. He then informed the working group that the initial schedule on the working group charter was not considered agressive enough by the Area Directors. It is their desire to be at workig 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" which "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 pontentially many MPCs, SECs and LPMs in an engine. Although the working group is specificially 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 recoginition 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 an 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. There was then a discussion about where does the MIB live. 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, and 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, and 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: o generate request_msg o receive request_msg o generate response_msg o receive response_msg o generate trap 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 6 documents: o Architecture o V3 Message Processing & Control o V3 USEC Security Model o V3 Local Processing o V3 Notifications o V3 Proxy The last of these may be combined into a single document. Finally, a new schedule was proposed May 9 next id May 19 week interim meeting Jun 13 next id Jun 23 week interim meeting Jul 14 last call versions Aug 11 week munich ietf 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 ajourned.