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

Re: Draft EOS minutes




> There was general discussion about whether we should be working on
> evolutionary change or revolutionary change.

  Was any sort of consensus reached on this issue?

Most of the proposals that have received a significant amount of
attention over the last couple of years have felt to me to be
"revolutionary" rather than "evolutionary" (e.g. RowOps & OOPS).
This surprises me, as there have been a number of evolutionary
suggestions put forward that would seem to offer a reasonable
improvement in functionality for relatively little effort.

> Glenn plans to announce to the list that new proposals should be
> submitted by Sept 15 and if none are submitted then the WG should
> seriously consider shutting down due to lack of interest.

  OK - Stealing shamelessly from the proposals already on the table,
I'd suggest the following:

  a)  OID Delta Compression
	(as per draft-irtf-nmrg-snmp-compression)

  (possibly with a distinct tag type for "non-compressed" OIDs, as
   suggested for OID Prefix Compression - draft-ietf-eos-oidcompression)
  This proved very easy to implement - it only took me a weekend to
  add support for both compression algorithms to the net-snmp code.


  b)  Filling holes in tables
	using either 'noSuchInstance' or a new Exception value

  This has been suggested in a number of the current proposals
  (GetCols, Row Aggregation, OOPS), and would potentially be
  useful with the existing GetNext/GetBulk operators as well.
    I'm currently discussing adopting an adaptation of this
  for the net-snmp agent anyway - just to simplify the normal
  GetNext/Bulk operation.


  c)  Non-wrapping of columns
	either as a separate protocol operation (GetCols)
	or as an extension of existing ones (GetBulk and ?GetNext)

  Again, potentially very simple to implement - since wrapping to
  the next column has typically to be handled specially anyway.


Note that I've deliberately phrased these in terms of functionality
rather than protocol operations, as all three could potentially
be applied to existing protocol operations as well.
  Similarly I've listed them separately, since they are distinct
ideas, and could easily be applied individually or in combination.
And none of these would preclude the adoption of more wide-reaching
additions to the protocol later.


  The other thing that would be necessary is some sort of mechanism
for negotiating the use of such enhancements.  Reporting which
enhancements are available could be handled via a suitable MIB, but
requesting the use of an individual facility is a harder problem.
  Ideally, we should develop a flexible mechanism that could also
accomodate subsequent enhancements.  That might indicate something
based on tag types and/or "control" varbinds, rather than distinct
PDU types (which wouldn't really scale very well).  I've got some
ideas about various possibilities, and will try to put together a
fuller proposal, if there's any interest in this sort of approach.


Dave