Re: Draft EOS minutes

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

> Could anyone explain to me why filling the holes is so useful?

It's certainly not *necessary* (except for a few particular situations,
such as the Row Aggregation operations).  But it's potentially useful,
if only because it may (in some circumstances) simplify the processing
at either end.

For example, if a management app issues a (conventional) request

		GetNext colA colB colF

it might get the response

		colA.1  colB.2  colF.1

If it wants to process the related entries for row 1,  it's got to
check every varbind to see if the index is 1 or not - and either discard
the one(s) it's not interested in, or save them for later processing.


If instead it could issue a request

		GetNext[fillHoles]  colA colB colF

then it would get the response

		colA.1  colB.1=noSuchInstance  colF.1

So there's no requirement to check the index values - they're all
guaranteed to refer to the same row.  And this varbind list can be
used immediately to retrieve the next row, without worrying about
getting things back into line again.


>                                                                 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.....
> Leaving holes as they are allows to limit the amount of data that need to be
> sent.


Then don't make use  of this particular capability.  The whole idea of the
capability negotiation proposal is that the manager can *choose* which
features to make use of.   If it's happy to handle holes (and the resulting
potential for mixed-row data), then it's free to do so.
  If it prefers to guarantee that the response will refer to a single row
(at the cost of some padding in the response PDU), then such a feature
would allow this to be possible too.



DP> The elimination of holes is for the following reasons:
DP> 1) it allows a much for efficient agent implementation.

> Ok, but in this case the holes could be removed from a response
> before it is sent (or am I missing anything?).

  But that's extra work at the agent end.  A typical MIB table implementation
may well retrieve all the information for a particular row in one go (e.g.
via a system call, or reading/parsing a line from a file).
  Processing a GetNext[fillHoles] request could be handled immediately.
If a particular column didn't exist for that row, the agent could supply
the noSuchInstance exception straight away.
  With a conventional GetNext request, the agent would have to re-invoke
the data retrieval mechanisms to obtain the next entry for that particular
column (having isolated it from all the other related varbinds for which
it does have a value).   That's potentially quite a bit of work, for
something that the original manager may not be interested in anyway.

  OK - the agent has to be able to handle this (for continued support of
traditional GetNext/Bulk operations).  But it's not much extra code to
support this new functionality.   In the Net-SNMP-based implementation I
developed last week, it took literally *ONE* new line of code to do this.
  (Recognising that this facility was required took a bit more work,
admittedly - but adding the basic functionality was trivial)

Dave