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

Re: Thoughts on the various EOS proposals


Very useful comments.
A few responses inline.

Thanks, Lauren

Dave Shield wrote:

> It struck me that a number of the proposals seemed to be covering
> similar ground, but that very little attempt had been mag}z?^?f0$J:I$I%)$IJI$RI$I%)$IJI$RI$I%)$IJI$RI$I%)$IJI$RI$I%)$IJI$RI$I%)$IJI$RI$I%)$IJI$RI$@WGֿ3_|btk_~OK$
j.AXV_m]o)^cD>VV=ҿ?zjYV=ҿ?zjLJI$I%)$IJI$RI$I%)$INoL|iը}Zq6שvgƟZկg}z?^?f0$J:I$I%)$IJI$RI$I%)Wn#kt^~X@/,h8q6^EƦQFSISv?i% NBů?[Wounq'#737^VMXZ9A,iebdn׿&3.VU;lppǸ<21eE^,0pmce_eh aims and structure of the working group charter and requirements.

The RowOps draft directly attempts to provide a tangible solution
to some of the charter items, and the requirements have not
yet been defined.  However, which specific charter "aims" do you
think the RowOps draft violate?

The requirements so far provided were meant as a survey of sorts,
and in fact some of them may conflict.  As I have posted earlier,
in the absence of specific feedback from the list, the RowOps draft
tries to "pick" a set of requirements so as to provide a "this is
how it might look if we did it this way" approach.  Some so-called
"requirements" therefore, are satisfied and some not.  Also, as I
the compliancy column (which supposes to indicate whether a given req'
consensus) also differs from my own of the consensus and what I
provided in the RowOps draft.
>   I'd like to consider some of these specific aims individually.
> OID compression
> ---------------
>   There have been five proposals for OID compression - OID prefix
> compression, OID delta compression, the table-based compression from
> the GetCols draft, and two forms of compression (or "inheritance")
> in the RowOps draft.
>   The first two are fundamentally similar - OPC is conceptually
> simpler, while ODC handles single-row OIDs more efficiently.
>   The GetCols compression is specific to this particular operation,
> and can't be used as a general-purpose OID compression mechanism.
> It also _requires_ the manager to save state - the compression is
> not self contained within the PDU.
>   The RowOps name-level inheritance is similarly restricted to a
> subset of PDUs (the new operations defined in that document), and
> only handles exact matches.  I believe that either of the first two
> OID compression techniques could handle this equally efficiently,
> with the added flexibility of covering other situations as well.
>   The RowOps prefix-level inheritance is a very specific form of
> compression, which could potentially be useful in a wider context.
> But again, the dedicated OID compression approaches can probably
> handle this more powerfully, without being restricted to these
> particular PDU operations.

Although confusing at first glance, I think it is good to be in
a position to have to look at these different approaches.  In the
beginning, we had no idea what aproach would yield the greatest
benefits, so we intentionally chose to look at compression AND
suppression and make up our collective minds later.  Regarding the
RowOps draft, my own take is that the compression and suppression
each would work better in different scenarios -- but I haven't
verified that with quantitative research as of yet.

Nevertheless, I also would like to see a consistent
approach as long as it is effective in most typical

I also would like to point out that a method of
compression/suppression might impinge on other
requirements.  For example, one of the strengths
of the RowOps suppression method is that it
allows transition benefits for an approach where
new requests (e.g. CreateRow, DeleteRow) are also
desired.  OID compression, as defined, I think would
hurt the ability to satisfy this "proposed" requirement.

> Row Operations
> --------------
> Turning to the general idea of row operations - I actually see
> this as two distinct sub-problems:
>   - how to specify a row aggregation
>         (which table, index and subset of columns), and
>   - what operations are supported on such an aggregation.
> I'd suggest that these be considered separately.
> Row Aggregation
> ---------------
> There have been two forms of row aggregation proposed - the RowOps
> RowIdentifier mechanism, and the Appendix of the OPC document.
> The RowIdentifier uses a sequence of existing varbinds to encode the
> row aggregation information - the first holding the table and instance
> information, followed by the individual columns (one per varbind).
>   The OPC Appendix proposal uses a single varbind, with a new value
> structure to hold this list of columns.  Coming in to this topic cold,
> this second approach seemed much simpler to understand, being a
> logical extension to the current, familiar mechanisms.  By comparison
> the RowIdentifier mechanism felt much more convoluted and hard to follow.
>   Yet I don't recall seeing any discussion of the OPC aggregation
> syntax on the list.  Is there a fundamental problem with extending the
> definition of a VarBind in the way proposed?

I agree the RowOps method is a bit harder to follow and seems
convoluted.  However, I believe it might be actually easier
to implement and demands less impact on existing code libraries.
Also, the RowOp approach does not require duplicate VACM rules or
duplicate subagent registrations.  The issue of duplicate
subagent registrations, in particular, would immediately
cause some vendor's subagents to become unusable as is.
Hope I'm not mis-characterizing any other aproach here!

So, I see this as an issue of whether we choose an incremental
(RowOps draft) vs BigBang (OPC appendix) method.  Personally,
I would hope we evaluate each known approach and see if
we can find a solution that embraces the best of all worlds.
The RowOps draft was indeed intended to help provide grist
for this debate, and was never intended to be a final solution.
Due to lack of list feedback, we had assumed providing something
tangible would inspire debate.

> Row Operations
> --------------
>   Of the six new PDU operations proposed in the RowOps document,
> three (EditRow, GetRow, and GetNextRow) appear to be exact analogies
> of existing requests, one (GetBulkRow) is more-or-less a version of
> the GetCols suggestion, and two (CreateRow, and DeleteRow) are new.
>   The RowOps document explicitly states that row aggregation can
> only be used with the new operations.  It seems to me that if the row
> aggregation mechanism was designed such that it could be clearly
> distinguished from traditional 'singleton' VarBinds, then perhaps
> this restriction could be lifted.  Having two PDUs (e.g. GET and
> GetRow) with similar behaviour, but operating on different types
> of data, seems unnecessarily complex.
> Bulk Operations
> ---------------
> The two Bulk data proposals appear to be addressing very different
> aims.  I believe the out-of-band approach is intended for use in
> high- to very-high volume scenarios, where pure-SNMP may simply not
> scale.
>   The GetCols proposal (with or without compression) feels a much
> more general-purpose approach.  As such, they are not mutually
> incompatible, and it almost feels inappropriate to compare them
> directly.  Perhaps more useful would be to compare the functional
> behaviour of GetCols and GetBulkRow, to see if there are features
> of one that could be usefully included in the other.
> OK - I've probably trodden on a number of toes by now.  Now it's
> time to tell me why I'm talking nonsense.
> Dave