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

Re: RFC 1905 Section 4.2.5


Juergen (and possibly with Frank) wrote an I-D a couple of years
back with a proposal for an SNMP remote operation (a new PDU type),
and provided SMI extensions to support it.

Nothing was done with it, mainly because it was before the EOS WG
was started. However, it had some problems due to
running over a connectionless transport with a limited
max message size, which were:
1) a response could be dropped (even though the operation was
   performed), and if a retry was done, the operation could be
   repeated. This could cause problems. For example, allocate
   a new instance of a resource and return the identification
   for the instance. A drop of the response results in an
   instance being allocated that is not known. There are
   other types of problems due to the non-repeatability
   of operations.
2) an operation could take longer to be performed than the
   retry timeout of the manager. The manager would then
   retry the operation, even though it was in progress.
   The problems are similar to #1 above.
3) If an operation can take a long time, then there should be
   a mechanism to abort it. I don't remember this being 
   included in the proposal.
4) what happens when the response will not fix in the max
   message size. Do you tell the manager that the operation
   was performed, but the results cannot be provided?
Note that running over a connection oriented transport "fixes"
some problems, but also creates additional problems. The one that
many people miss is when an operation is performed successfully,
but the connection is broken before the manager receives it.
The resulting situation is the same as #1 above!

At 03:46 PM 8/29/2001 -0500, you wrote:

>Another solution would be to have user defined objects classified with
>accessible-for-response (like accessible-for-notify).  The protocol would
>need to be relaxed to allow these new objects to be passed back along with
>a Response PDU.


>In reality, if DisplayString is chosen for the
>parameter and the error string is delimited then one could say as many
>errors as can fit into the string.  Applications cannot do anything with
>this text beyond displaying or storing the error.  The error is more for a
>user than for an application.  I would rather deal with this type of
>problems with a MIB variable, table, column, or trap but it is not possible
>without correlation problems.  Hence the protocol support.

Having results that can only be interpreted by a human is
a non-starter. For example, what language do you return text?

>Sidney Antommarchi
>VXi - Systems Engineering

/david t. perkins