> -----Original Message-----
> From: Dave Shield [mailto:D.T.Shield@csc.liv.ac.uk]
> Sent: Friday, August 02, 2002 18:00
> To: firstname.lastname@example.org
> Subject: 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?
No. It was more of a discussion point probing the boundaries of what is evolutionary and what is revolutionary. The WG (and the ADs) will evaluate proposals based on the overall spirit of what the charter is attempting to accomplish.
> 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.
Great discussion and I also see that Jeurgen agrees with you. I hope that a proposal can get written up -- strawman or otherwise -- in Internet draft format by September 15.
By the way, we have one proposal on the table at the moment. It Wes Hardaker's draft: draft-hardaker-eos-oops-00.txt. In the WG meeting there appeared to be a moderate level of interest in this work so far. If you like what you see in Wes's draft maybe another avenue you could follow is to help out Wes.