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

RE: RowStatus versus RowState




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

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

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

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

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

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

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

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

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

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

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

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

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

>      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