[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