Re: Draft EOS minutes

RE: Draft EOS minutesI am a new subscriber of this list so I would like to greet
everybody.

>   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.

Could anyone explain to me why filling the holes is so useful? In a few
documents I have read it was stated that "manager applications have problems
with putting data in the right order". I personally do not think there is such a
problem at all. Perhaps a more serious thing is that row data may come from
different "time instants", so a row may be unsynchronized. Moreover, a row that
existed during the first get-type operation, which returned a part of its data,
might disappear later, so it may provide partial obsolete data. On the other
hand, are SNMP agents required to treat a single get/get-bulk etc. operation as
atomic?

Leaving holes as they are allows to limit the amount of data that need to be
sent. I am not any strong supporter of the holes, but it seems that there is a
general agreement about that they should be fixed. The original explanation
(problems with putting data in the right order) is a bit funny - can't
programmers do that? Implementation of a procedure for table retrieval using
GetNext/GetBulk with correct holes (and endOfMibView errors) handling is
relatively easy. If this is the main reason, perhaps it is not worth doing. If
there are other reasons (e.g. to minimize the "unsynchronized data" effects),
perhaps the statements in the drafts should be made clearer?

>   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.

A possibility to provide options for a single get-type operation is to use a
virtual table for this purpose and treat the index part of a table variable OID
as the data used to specify how this request should be handled (a fake get
operation on a table, used for providing an index with operation-related data).
For example, this could be used to negotiate OID compression and/or the places
in a MIB where get-bulk should stop - this would allow to get rid of the
"overshoot" problem. Quite tricky, but feasible.

Best regards,

Marek