I was hoping to get some email indicating that participants in our
interoperability testing had set up another application on their PC to be
the trap receiver, and that's
why the Test Suite did not receive the trap. If this *is* the case for
your implementation, please send me private email so we can confirm.
Traps were discussed at the SNMPv3 Working Group in Memphis. (Minutes
included below.) My interpretation of this discussion is that there is
likely to be some agreement on standardizing the trap mechanism in agents
in the near future within the IETF.
I was also asked how other MIBs handle traps. The UPS MIB specifies traps
and these are handled in a very similar way to the Printer MIB. The UPS
MIB working group has not done any interoperability testing, thus far.
Also, having polled the SNMP experts, the general consensus is that it
takes about ten lines of code to generate a trap from an agent. Some of
you have said that "traps are too hard to do". I assumed that meant too
hard to code. Obviously that cannot be the case. I need to hear from you
publicly or privately, why they are hard.
Based on all the facts right now, I would have to recommend that all the
references
about traps be removed from the RFC, and that the Printer MIB WG decides to
defer
specifying traps for printers until a standardized mechanism for traps is
defined.
----------
> From: Jeffrey T. Johnson <jjohnson@cisco.com>
> To: minutes@ietf.org
> Cc: snmpv3@tis.com
> Subject: Minutes of the SNMPv3 Working Group, IETF 38, Memphis
> Date: Thursday, April 17, 1997 11:35 AM
>
> 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.
>
>