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.