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

Re: proposed row ops requirements



Very nice!  Thanks Sharon
Lauren

Sharon Chisholm wrote:
> 
> hi
> 
> I've taken the liberty of drafting a compliance matrix for the
> row operations requirements that Steve sent around last month.
> 
> Disclaimers:
> - I've ordered the matrix by type of requirement, as appose to
>   by the original requirements numbers.
> - I made up the initial compliances so we could start the
>   discussion somewhere.
> - I also left out some of the original requirements since they
>   felt more like solutions than requirements to me.
> - I'm just trying to progress the discussion.  Unless told
>   otherwise, I assume Steve or Lauren are still maintaining the
>   requirements/compliance list.
> 
> ----
> 
> Yes - There is rough consensus this is a requirement
> Maybe - There is some belief that this is a requirement
> No - There is rough consensus that this is not a requirement.
> 
> ---------------------------------------------------------------
> General Term      | Specific Item    | Number     | Compliance |
> ---------------------------------------------------------------
> Efficient         |bits-on-wire      | R1         | Yes        |
>                   |subagent-wire     | R2         | No         |
> ---------------------------------------------------------------
> Simpler           |Force Ordering    | R6         | Yes        |
>                   | One PDU          |            | Yes        |
>                   | No RowStatus     | R10a       | Yes        |
> ---------------------------------------------------------------
> Co-existence      | Transparency     | R32        | Yes        |
>                   | Proxy conversion | R3-2       | Maybe      |
> ---------------------------------------------------------------
> Operation Support | Create Row       | R7a        | Yes        |
>                   | Delete Row       | R7a        | Yes        |
>                   | Change Row       | R7a        | Yes        |
>                   | Suspend Row      | R8a        | Maybe      |
>                   | Get Row          | R7a        | Yes        |
>                   | Get Next Row     |            | Yes        |
>                   | Get Bulk Row     |            | Maybe      |
>                   | Get Scalars      | R11        | Maybe      |
>                   | Get Next Scalars |            | Maybe      |
>                   | Get Bulk Scalars |            | Maybe      |
>                   | Change Scalars   |            | Maybe      |
> ---------------------------------------------------------------
> Error Handling    | Improve          | R20        | Yes        |
> ---------------------------------------------------------------
> Transitioning     | Easy for Systems | R3-1, R9a  | Maybe      |
>                   | Easy for AgentX  | R18a       | No         |
> ---------------------------------------------------------------
> Holes             | Fill in Reply    | R13        | Yes        |
>                   | Allow in Request | R16,R17    | Yes        |
> ---------------------------------------------------------------
> Set return values |                  | R21        | No         |
> ---------------------------------------------------------------
> New Data Structure| Support          | R22        | Maybe      |
> ---------------------------------------------------------------
> 
> The following seem more like solutions than requirements:
>   R4, R5, R7b, R8b, R9b, R12, R14, R15, R18b, R19,
> 
> Requirements not in original list:
> 
> 23. Support of EOS row operations must be transparent to managers
>     wishing to communicate with the system using base SNMPv3
> 
> Sharon
> 
> -----Original Message-----
> From: Steve Moulton [mailto:moulton@snmp.com]
> Sent: Thursday, May 24, 2001 10:34 AM
> To: eos@ops.ietf.org
> Subject: 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