[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

EOS WG Minutes - Minneapolis


Here are the EOS minutes.  Please respond
with any needed corrections, additions, deletions, etc....

Due to the need to get the new WG rolling and to make sure
all the pertinent ideas are on record, I decided not to
over-simplify these minutes.



50th IETF (Minneapolis) Evolution Of SNMP (EOS) WG, 3/19/2001, 0900 CDT

Compiled by Robert Bohanek and Lauren Heintz.

Dale Francisco opened the meeting with general comments.

Glenn Waters followed with a requirements overview discussion
based on 'draft-ietf-eos-requirements-00.txt', which unfortunately
wasn't submitted to the IESG in time to be published before
the working group meeting.

EOS deliverables must conform to rfc2571, and any new work is not
intended as a replacement to existing frameworks.

Capabilities mechanism was discussed.  Consensus reached that this
does not need to advertise "base features" of an entity, though some
debate occurred about what "base features" are, and the short answer
seemed to be "whatever is in SNMPv3".  It may be this is a difference
between MUST vs SHOULD language.  It was observed by one member that
field implementations of SNMPv3 are spotty, and the assumption to add
stuff is that it means new PDU's.

OID Compression was discussed.  Dave Perkins suggested this was a
non-issue except perhaps when retrieving large amounts of information.
Clarification was sought from the audience about what specific problems
OID compression was trying to solve.  Bert Wijnen reminded all that the
EOS charter specifies the requirements and objectives, and that any
other items to be added, need to be added later, after the initial
goals have been met.

Efficient row creation was discussed.  Row creation semantics are
currently heavyweight.  This requirement is deemed to simplify the
burden on agents in dealing with configuration requests.  Do we do
this with a new PDU type?  Where does the WG want to go?

Efficient sub-tree deletion was discussed.  Joel Halpern observed that
sub-tree deletion is only one possible solution to an unstated or
poorly formed requirement.  If data synchronization is the actual
requirement, then let's say that instead.

Efficient Bulk Transfer was discussed.  A request was fielded for an
explanation of the difference between a single protocol operation and
a single "conceptual" operation.  Is it a Grand PDU that causes multiple
smaller PDU's?  This requirement is vague, it was suggested.  It was
conjectured the idea is to minimize the amount of work and have it
appear as if a single operation is at work.  One attendee
wondered if the operation needs to understand table boundaries, so
that you can get to the bottom of the table and quit?  Glenn Waters
added that, in general, the idea is to transfer large amounts of data
and figure out how to grab all, or a specified part of a table.  Dave
Perkins pointed out that when retrieving large information that
contains counters, you may have large differences in timestamps.  Does
the requirement need the data to be consistent?  One co-chair said
this was a reasonable thing to consider and that we should add that as
a requirement.  We need to discuss and get guidance on it.

Efficient set, efficient row operations, efficient row creation were
discussed. Someone asked if createAndGo (as opposed to createAndWait)
by itself meets this requirement.  What are we trying to solve?  Is
it to remove createAndWait?  There was another request for specificity
for the need of this requirement.

One attendee contended that in order to do away with createAndWait,
we'd need TCP in order to remove the packet size limitation that
originally motivated createAndWait.  Randall Atkinson
said if the goal is to remove createAndWait, we need to make that
explicit.  That would be a 5-6 year implementation curve.  A co-chair
cleared the air by saying that the goal is to create a new, simpler,
more powerful row status TC.  Can't make createAndWwait go away.  Dave
Harrington agreed that createAndWait is still needed.  A question was
raised whether the current RowStatus TC requires createAndWait to be
supported?  There were differing opinions.

Jeff Case observed that we were mixing layers in our discussion.  For
future MIBS, a new RowStatus TC does not need createAndWait.  It could
be called RowStatusLite, at least for purposes of discussion.  It is a
MIB issue, not a protocol issue.  More concerns were raised that some
future table designs and/or implementations would not be able to
support RowStatusLite, but consensus seemed to indicate that was not
problematic.  The new TC would have to be explicit with this regard,
and indicate you may have to in some cases support large PDUs in order
to support RowStatusLite.  That's the penalty you pay to get the

Bert Wijnen again homilized, as he would have to do so many times in
the next few hours, that the EOS charter describes the issues we need
to discuss.  Someone offered the idea that any WG can consider a TC,
but cannot mandate that it be used from then on.

Glenn finished up the requirements overview and turned the floor over
to Jeff Case to talk about OID Compression issues:

Jeff's slides are available at

Jeff contends that we need a third rev of protocol operations, much in
the same way that the SNMP MIB and SMI have been rev'ed several times
with much needed improvements.

No special problem handling the new PDU types; there's an "unknown PDU"
handler now, sq would work fine under SNMPv3.  It is an engine to engine

Gordon Bowman asked how we would set compression for one PDU type
but not another?  Which of the things are we talking about are not
engine specific?  Row creation would be MIB specific.  Jeff Case
answered that it depends on what solutions we come up with.
Agent implementation strategy should be transparent.

Wes Hardaker suggested that two different aspects to capabilities need
to be considered: Master agents need to advertise protocol-related
capabilities whilst subagents need to advertise MIB specific
capabilities.  A mechanism is needed to ensure that occurs properly.

Jeff discussed multiple approaches to OID compression and suppression
ranging from entire message/pdu compression to applying
transformations to parts of the PDU contents.

If all objects are part of the same row, then we can dispense with
instance OIDs, using either an explicit naming scheme (using single
numbers to indicate the column number of each varbind), or an implicit
scheme in which the position of the varbind in the list corresponds to
its column number.

More research into compression and suppression is needed.  They may
have independent applications and suppression may even eliminate need
for compression.

Sandra McCleod of SNMP Research will be performing some performance
studies on these different approaches to see which does indeed work
better.  Andy Bierman pointed out that the instance part of the OID
is significant and that we have the problem of operations affecting
multiple MIB groups, such that multiple sup/compressed OID anchors
are needed in the op, as needed.  Andy was rewarded with a shiny new
dime because his comment was a perfect segue to the next slide.
Andy was observed suspiciously testing the coin with his teeth.

Randy Presuhn pondered the implications of creating new PDU types.
But since the VACM table in rfc2575 is sorted based on read, write and
notify operations, it was felt a new PDU would fit well in those
categories, thereby indicating that VACM probably would not be

Another attendee made a plea to adhere to simple solutions and to try
to combine solutions such as bulk transfer and OID sup/compression
where possible.

Jeff Case stated a requirement for subtree deletion was questionable.
Seems like a MIB thing, not a protocol thing.  Must maintain
statelessness and not become jailed during Packet Loss.  Jeff Case
acted out the "go to jail" phenomenon where connection oriented data
transfers may be severely interrupted in lossy networks and have to
start over.

A suggestion was raised that connection mgmt is a viable solution in
cases for bulk retrieval when the net is working well.  A dissenting
opinion suggested that what works when the net is good must also work
when the net is bad.  This opinion was seconded by another who
enjoined with yet another call for simplicity.

David Perkins then presented his proposal for a getCols
capability. Slides (not sure if same as presented) available at

getCols allows the requester to specify particular columnar objects
to retrieve for every row.  The advantage of this is that some
information (configuration, state) changes rarely and is a waste
to retrieve on every poll.

He outlined the problems with getNext and getBulk (e.g. too many
operations, holes, overshoots, low packing factor) and suggested a bulk
transfer mechanism is needed only when the table contains huge amounts
of data.  His initially proposed getCols PDU can "fit" into existing
PDU structures much in the same way that getBulk "fits" into a getNext

Some questions arose about how getCols knows when to "stop"
retrieving.  David indicated a "stop" parameter would be included in
the PDU, the details of which need to be worked out.

Someone wondered if the OID compression/suppression work might
preclude the need for getCols, and David responded that the WG would
have to determine if that is the case.  Randy Presuhn also suggested
that a "tail" function might be desirable -- to be able to retrieve
only that part of a steadily increasing table (e.g. a logging or
history table) that had been added since the last retrieval or from
a specified instance.  Another voice asked whether getCols
allowed for filtering of rows from the indicated slice.  The answer
to this latter question was that getCols as presented does not filter,
though some more discussion abounded concerning whether such a filter
operated on the instance info or the object values, as well as the
parameters getCols would need to support such filtering capabilities.
It was also asked whether getCols was meant to retrieve only "dirty"
row data or all data within the specified slice, and the answer was
"all data" and that MIBs should always be designed anyway to anticipate
the kinds of getCols slice retrievals most often needed so that added
complexity (in the form of filters and dirty row skipping) is not

Dale Francisco now requested general comments:

Concerns were raised over whether EOS and SMING WGs had overlapping
efforts.  A specific question was asked regarding extended data types
and kerberos and RADIUS issues.  Randall pleaded not to entangle Radius
and SNMPv3 security issues.  Just depend on SNMPv3.

Dan Romascanu suggested we don't need bigger data types, according to
former lessons learned as the etherMIB WG chair, to which objections
were raised to add Gauge64 and other types.  Jeff Case countered that
signed fixed-point int64 support was needed.

Bert again echoed the mantra that it is OK to consider such things for
the future, but probably not until EOS completes initial charter.  We
may have charter enhanced with things later on that fall off SMING
charter.  SNMPv3 WG considering whether we need to extend more
security models, but such issues are not part of EOS WG either.

Randy Presuhn pointed out that the EOS WG may define new PDU types,
and since SNMP uses a CHOICE SYNTAX in rfc1905, syntax defs in rfc1905
must be cloned and new choices added.  This may be problematic.

Glenn commenced with closing remarks: Many related issues have
been identified in the charter items, so we may need to merge some
of the documents, as needed.  Also need to come to consensus on choices
of desired approaches.  Need first drafts by April 20th to IETF editor
so we can have discussions on the list.  Dale observed that some
discussion was necessary as a precursor to getting the documents ready.

Bert encouraged the editors to sign-on to the April 20th milestone,
and no objections were heard.