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

Re: RowStatus versus RowState


"Ayers, Mike" wrote:
> > From: Lauren Heintz [mailto:lheintz@cisco.com]
> > As you noted, a list of POTENTIAL and sometimes CONFLICTING rowops
> > requirements was posted a few weeks ago along with a request
> > for comments.  So far very few, if any, comments have been received.
>         Checking back, I see that my response was dropped.  I've had some
> trouble with that on this list, which I believe may now be fixed.
> Repost:
> > From: Steve Moulton [mailto:moulton@snmp.com]
> > 1.  PDUs containing row operation data will be as efficient
> > as possible
> >     on the wire.
>         I don't like this.  Not only is it common sense to make efficient
> PDUs, but it seems like this as a requirement will only be useful for
> deciding between competing proposals, and I don't think it is wise to decide
> a priori that efficiency is the most important consideration.
> > 2.  PDUs containing row operation data will be as efficient
> > as possible
> >     on the subagent wire.
>         This is the same problem as #1, possibly worse.  This should be
> excised.  Other considerations, such as compatibility with existing
> protocols, are more important here.
> > 3.  Use of PDUs containing row operation data SHOULD NOT require
> >     existing instrumentation methods to be rewritten in order to
> >     assure basic functionality of the operations.  However, to
> >     obtain the efficiency and simplicity gains that row operations
> >     enables, method routines and dispatchers MAY require modification.
> >
> >     Proxies must be able to unambiguously translate rowOp requests into
> >     conventional SNMP requests.
>         "Modification"  MUST not mean "incompatible".
> > 4.  If a tradeoff must be made, then ease of transition to an EOS
> >     network is more important than efficiency on the wire.  (Note
> >     that this requirement does not preclude modification of
> >     master agent/subagent communication protocols, message processing
> >     code, or dispatcher code.)
>         Is this deliberately in conflict with #1 & #2?

#1 and #2 said "...efficient as possible..." so this is just
saying that it would be OK to lose a small bit of efficiency
if it meant we could obtain an easier transition strategy.

> > 5.  If a tradeoff must be made, then efficiency on the wire
> >     may involve a more complex message processing subsystem and
> >     dispatcher within the SNMP engine [RFC2571], while
> >     allowing for (but not mandating) simplified method routine code
> >     with respect to set processing.
>         I can't even make sense of this one.

I *think* this means increasing complexity of certain
NMS/agent subsystems may be OK if it results in more efficient
on-wire PDUs.

> > 6.  Information in SET requests containing row operation data
> >     should have a well defined (lexicographical) ordering within MIB
> >     groups. That is to say, in table row SETs, the atomic objects
> >     MUST be lexicographically ordered.  (This requirement is
> >     designed to simplify SET processing on complicated requests with
> >     interrelated objects).
>         Change MUST to MAY.  Specifically, OID suppression by relative index
> specification will not have its efficiency impacted by this requirement, and
> so this would become a restriction with no benefit in that case.

I think if you change to MAY, then you MAY as well not
specify this requirement.  My impression is that unless you
specify strict ordering, then no potential benefit is possible.

> > 7a.  RowOp requests MUST support creation, deletion and modification
> >      semantics as in draft-ietf-eos-snmp-rowops-00.txt.  (Whether
> >      these operations are specified as new PDUs is not
> >      considered in this question.)
>         This says nothing, unless you think that it is a real possibility
> that the designers would forget about creating, deleting, or changing rows
> (they won't).

It says that we MUST define (support is the wrong word) CreateRow,
EditRow, blah, blah, requests, because those requests are defined in the
draft v0.
Whether an impl supports them is a different story.

> > 7b.  Row creation and modification shall be accomplished with
> >      the existing SET operation.  Row deletion shell be
> >      accomplished with either a RowStatus object, or with
> >      a simplified RowStatus-like object that expresses
> >      a combination of rowState semantics (NotReady,
> >      NotInService and Active) with the ability to suspend or
> > delete a row.
>         Likewise.
> > 8a.  PDUs containing row operation data shall use the same PDUs
> >      as currently defined.  Row deletion shell be
> >      accomplished with either a RowStatus object, or with
> >      a simplified RowStatus-like object that expresses
> >      a combination of rowState semantics (NotReady,
> > NotInService and Active)
> >      with the ability to suspend or delete a row.  (Note that
> >      getBulk or getCols is a separate issue).
> >
> > 8b.  New PDUs shall be created to support row operations.
>         How about:
> 8.      Row operations MUST be able to be performed with existing PDUs.
>         New PDUs may be created for row operations if they will
>         measureably improve performance of row operations.
> > 9a.  RowOp requests MUST use existing PDU
> >      and varbind structures (even if this
> >      leads to less than optimal efficiency
> >      and/or makes it harder to write/execute
> >      agent code).
> >
> > 9b.  Row operations requests may use aggregate variable binding
> >      structures to express row operation semantics.
>         Huh?  This smells like the #8 twins in different jackets.

One big question is do we use existing PDUs and data structures
to their best effect, or do we define new ones?  What considerations
compell us to define new ones (i.e. efficiency?  elegance?).  Is it
worth the pain to define new ones, and what pains would we experience?

For example, I surmise that the current draft does not obsolete existing
utility functions, though adding a new varbind aggregate type
might do that.  It's unclear whether new aggregate structures or PDUs
result in more efficent PDUs than the current draft.

> > 10a. RowStatus-like objects MUST not be required
> >      for rowOp requests to be supported.  In other
> >      words, a new TC (e.g. RowState) needs to be
> >      provided that separates the notions of
> >      row-state and row-fate.  Row-fate is left to protocol
> >      operations.
> >
> > 10b. Either RowStatus or RowState-like objects may be used
> >      to control row-state and row-fate.  The choice is governed
> >      by the MIB designer's requirements.
> >
> > 10c. Either RowStatus or RowState+fate (NotReady, NotInService and
> >      Active, plus ability to set Suspend and Delete)
> >      may be used to control row-state and row-fate.  The
> > choice is governed
> >      by the MIB designer's requirements.   Additional protocol
> >      operations are not required.
>         If we are to choose between these three, the choice is between
> copping out, copping out, and copping out.  Why would we bother to adress
> the issue of rows and deliberately ignore the part that's been causing an
> increasing amount of difficulty?  I think that we MUST incorporate state and
> fate into a single TC - first, it's not that difficult; second, it would be
> of great benefit to the community at large; third, we don't need more of
> these bizzare row management paradigms created.

So, you argue to maintain RowStatus, drop RowState and the new rowOp
request formats?  If so, then what do you perceive the benefits
of rowOps?  If not, then maybe we have a disconnect.

> > 11.  RowOp requests MUST support random reads
> >      for scalar and table objects concurrently
> >      and in addition to row-oriented operations.
> >      This would, for example, allow sysUpTime
> >      to be polled along with other row-oriented data.
> >      (This does not imply that protocol operations, i.e., SET
> >      and GET, may be combined in a single request).
>         This is a requirement not to prohibit scalar operations in the event
> of new PDUs, yes?


> > 12.  RowOp requests MUST support a GetCols-type
> >      of request (as opposed to not at all, or instead
> >      supporting it in the BULK document).
>         Huh?  Ever heard of get-bulk?  What's the difference between that
> and a "GetCols-type request"?  Also, why must columns be handled as row
> operations?  That doesn't even make much sense, really...

I think the GetBulkRow request sort of serves as a GetCols.
Whichever way you name it, they both retrieve data from multiple
rows and multiple columns.  GetBulkRow allows you to pull data
from very specific table sections or entire tables.  I think I've
pretty much heard we have consensus to define a GetBulkRow request,
the question is whether the current draft gets close.

> > 13   Agents supporting PDUs containing row operation data must support
> >      a GetBulk-type operation which corrects problems in the current
> >      GetBulk operator (specifically, column holes and
> >      termination conditions).  (Column holes are addressed
> >      using row objects; termination conditions will require
> >      additional operands).
>         Please explain this clearly.  What are "column holes" and why are
> they a problem?  What is the issue with termination conditions?

GetBulkRow specifies starting and ending rows between which
(inclusive) data may be retrieved.  GetCols
I believe only specify starting row(s).  When you 
do a GetBulk(colA, colB) on a sparse table, the response
data is not always collatted very nicely and the NMS has to
sift through the data to find out which objects in which rows
were retrieved (or not).  I hope I summarized that well enough to
suffice!!  GetBulkRow (I think) avoids this problem because the
response data is pre-collated on a row-by-row basis.

> > 14.  RowOp request design MUST use OID suppression
> >      techniques (see the current rowOps draft as an
> >      example) so as to achieve the desired level of
> >      efficiency.
>         Let's keep row operations and data compression separate, please.  We
> know data compression is coming - let it be done in its own space.

I think we have consensus that rowOps should use OID suppression
techniques (i.e. pack data efficiently).  I also
gather OID compression is out of scope (as you suggest below).

> > 15.  RowOp request design MUST support OID compression
> >      techniques (see the eos OID compression draft)
> >      so as to achieve the desired level of efficiency.
>         Likewise.
> > 16.  RowOp requests MUST support explicit
> >      naming of column/scalar objects.  Though
> >      this may increase the size of PDUs, this
> >      may also decrease protocol exchange errors.
>         Please explain.  Currently, all objects must be explicitly named.

That's right.  The question is, do we allow ops such
as explicit:GetRow(row1, OID-1, OID-2) or implicit:GetRow(row1,

The explicit form requires larger PDUs because you have to at least
include the column descriptors in the request.  The implicit form
uses, perhaps, positional associations to allow us to keep OIDs
shorter.  Current draft specifies explicit naming.

> > 17.  RowOp requests MUST support implicit
> >      naming of column/scalar objects.  This
> >      may allow smaller PDUs at the POSSIBLE
> >      expense in some rare situations that protocol
> >      exchange errors may occur.
>         Again, let's keep data compression issues out of this.
> > 18a. New AgentX PDU-types MUST NOT be needed
> >      to support RowOps, though existing ones MAY
> >      be tweaked.
> >
> > 18b  To take full advantage of the new simplified row operations
> >      made possible by this work, additional master agent/subagent
> >      communication PDUs MAY be required.
>         No tweaking.  AgentX is moving for standardization, and if we can
> meet #3, then no tweaking is needed.

Current draft would break current AgentX if an impl were required
to implement CreateRow, DeleteRow or GetBulkRow (but maybe not
EditRow, GetRow, GetNextRow).
> > 19.  If RowOps can be made more efficient
> >      at the expense of requiring a few more
> >      subagent registration operations and/or
> >      slightly more complex VACM configs (etc),
> >      this is an acceptable tradeoff.
>         This is too vague to mean anything.  Let's look at the proposals and
> decide the tradeoffs then.
> > 20.  RowOp requests must allow application-level error codes
> > to be returned.
>         If this means what I think it means, then it is bad.  SNMP is for
> management information, and its error codes should refer only to the ability
> to manipulate that information.  Application level error codes should be
> managed information, not protocol data.

Noted.  Others disagree I believe.  Current draft attempts
to support a rudimentary extended error capability.

> > 21.  RowOp SET requests must also behave as a GET (after the SET).
>         An interesting idea, but we should consider it before we mandate it.
> Do we want this?

Current draft attempts to support this (i.e. three-phase sets).
Three-phase sets MAY indeed contribute to fewer protocol
exchanges and thus further serves to justify rowOps in the first place.

> >      Items 20 and 21 may be out of scope of our charter.
>         I hope so.
> > 22.  RowOp requests MUST allow for new
> >      data types to be supported in an easy
> >      manner.
> >
> >      This item may be out of the scope of our charter, since it
> >      an SMI issue.
>         May?  Duh!  Anyway, it's already met.  That's why we use ASN.1!
> /|/|ike