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

proposed row ops requirements


Greetings, all,

To clarify the eventual contents of the row operations draft, the
following proposed requirements have been proposed for discussion.
Note that these proposed requirements are not intended to be 
consistent per se, and are a basis for discussion, not a
prescriptive list of requirements.


1.  PDUs containing row operation data will be as efficient as possible 
    on the wire.

2.  PDUs containing row operation data will be as efficient as possible
    on the subagent wire.

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.  

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

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

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

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.

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.

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.

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.

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).
   
12.  RowOp requests MUST support a GetCols-type
     of request (as opposed to not at all, or instead
     supporting it in the BULK document).

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

15.  RowOp request design MUST support OID compression
     techniques (see the eos OID compression draft)
     so as to achieve the desired level of efficiency.
 
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.

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.

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.

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.

20.  RowOp requests must allow application-level error codes to be returned.

21.  RowOp SET requests must also behave as a GET (after the SET).

     Items 20 and 21 may be out of scope of our charter.

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.

This list may be exhausting, but is by no means exhaustive.  Please
submit additional requirement, bearing in minds the limits set
by our initial charter.

 
 A URL for the rowOps Internet-Draft is:
 http://www.ietf.org/internet-drafts/draft-ietf-eos-snmp-rowops-00.txt
 
 
 A URL for the OID compression Internet-Draft is:
 http://www.ietf.org/internet-drafts/draft-ietf-eos-oidcompression-00.txt


Respectfully,

Lauren Heinz 
Steve Moulton


---
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
moulton@snmp.com     Knoxville, TN 37920-9716 USA  http://www.snmp.com