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

Re: proposed row ops requirements




>>>>> Steve Moulton writes:

Steve> 7a.  RowOp requests MUST support creation, deletion and
Steve> modification semantics as in draft-ietf-eos-snmp-rowops-00.txt.
Steve> (Whether these operations are specified as new PDUs is not
Steve> considered in this question.)

I could not figure out what the EditRow semantics in
draft-ietf-eos-snmp-rowops-00.txt really are since the elements of
procedure are just empty. So I can't say whether I agree or disagree.

Steve> 8a.  PDUs containing row operation data shall use the same PDUs
Steve> as currently defined.  Row deletion shell be accomplished with
Steve> either a RowStatus object, or with a simplified RowStatus-like
Steve> object that expresses a combination of rowState semantics
Steve> (NotReady, NotInService and Active) with the ability to suspend
Steve> or delete a row.  (Note that getBulk or getCols is a separate
Steve> issue).

Steve> 8b.  New PDUs shall be created to support row operations.

These two seem to contradict themself. I think we need new PDUs and so
I tend to disagree with the first sentence in 8a.

Steve> 9a.  RowOp requests MUST use existing PDU and varbind
Steve> structures (even if this leads to less than optimal efficiency
Steve> and/or makes it harder to write/execute agent code).

Steve> 9b.  Row operations requests may use aggregate variable binding
Steve> structures to express row operation semantics.

I think we should try very hard to stay with the existing PDU and
varbind formats unless changing them gives real benefits.

(I think we can actually stay with the PDU format, but we might need
to do some additions to the varbind definition.)

Steve> 16.  RowOp requests MUST support explicit naming of
Steve> column/scalar objects.  Though this may increase the size of
Steve> PDUs, this may also decrease protocol exchange errors.

Steve> 17.  RowOp requests MUST support implicit naming of
Steve> column/scalar objects.  This may allow smaller PDUs at the
Steve> POSSIBLE expense in some rare situations that protocol exchange
Steve> errors may occur.

Explicit naming probably makes it easier for the receiver to detect
bogus data and to discard it. However, I have also seen agents
returning correct data with broken OIDs - so in these cases, explicit
naming just created protocol exchange errors. I guess I would not
over-estimate the benefits of explicit. And in the case of a GetCols
operation, I would prefer to have more data in the payload in order to
reduce overall latency.

Steve> 18a. New AgentX PDU-types MUST NOT be needed to support RowOps,
Steve> though existing ones MAY be tweaked.

Steve> 18b To take full advantage of the new simplified row operations
Steve> made possible by this work, additional master agent/subagent
Steve> communication PDUs MAY be required.

I believe that we need to get in the longer term real benefits from
row operations on the agent implementation side. To achieve this, 
we AgentX must be extended to pass the added value down to the
instrumentation. Otherwise, we don't gain much.

Question: What happens if I implement a command responder which
supports all row new operations plus the RFC 1905 operations without
the set operation? The motivation for doing this is that sets on
arbitrary combinations of objects is way to expensive. If we have row
operations, then I could get away with doing sets on arbitrary
objects. Well, I could allow sets on those objects that map to row
operations. Does it make sense to allow for this, e.g. by returning a
suitable error code on all sets that do not map to row operations?

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

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

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

If an EditRow operation is in the charter, then 20 and 21 are within
the charter as well since you have to provide answers for this anyway.

Steve> 22.  RowOp requests MUST allow for new data types to be
Steve> supported in an easy manner.

Steve>      This item may be out of the scope of our charter, since it
Steve> an SMI issue.

It is an SMI and SNMP issue. We need to align the work in SMIng and
EOS here. Right now, the SMIng proposal wraps new data types in Opaque
values - since this is all we can do. If there were native support for
new data types in the protocol revision, then we could take advantage
of this.

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

I believe there is another important issue which always impacts SNMP
design decisions: The message size constraints we assume. RFC 1906
says that 484 is all you can bet on. Current practice these days seem
to be 1500 bytes in many implementations. SNMP over TCP says
conforming implementations must support at least 8K. I think it is
important to note whether 484 is still the hard limit or whether it is
acceptable to have new row operations that would not work in general
with 484 bytes on many existing tables (but might work with 1500 bytes
or 8K).

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>