Re: ordering constraints / procedures

[Edward P Luwish <eluwish@qwest.com>]

In my opinion the distinction is whether or not an operation depends on the
result of an earlier operation.

Simple ordering constraints can be satisfied by the manager issuing a single
request containing all the required varbinds, letting the agent impose the
required order and error/consistency checking.  In other words the
constraints are relevant only when varbinds are issued in separate requests,
where the agent may produce side effects before "realizing" that a required
parameter is missing or erroneous.

A procedure can not be performed that way since the manager would have to
examine the response before issuing a subsequent (separate) request.

Ed

Juergen Schoenwaelder wrote:

> >>>>> Robert Story writes:
>
> Robert> 1) SMIng must provide a mechanism to formally express ordering
> Robert> constraints.
>
> Robert> 2) SMIng should support a mechanism to formally define
> Robert> procedures that are used by managers when interacting with an
> Robert> agent.
>
> Robert> Can someone explain if there is a difference between these
> Robert> two? If they are the same, I vote that the "ordering
> Robert> constraints" name is clearer than "procedures."
>
> The concept of procedures came out of some discussions about
> methods. Right now, people implement methods with a couple of writable
> objects, some status objects that report the status of the invoked
> "method", and some result/error objects. To use these objects, the
> manager has to follow certain procedures such as:
>
> (1) create/set the following set of objects
> (2) poll the following objects until the method is complete
> (3) retrieve some objects which carry result/error information
> (4) do some cleanup set operations
>
> In other words, procedures probably go somewhat further than just
> ordering constraints (but frankly, I also do not know what ordering
> constraints includes and what not).
>
> Disclaimer: I am just trying to clarify where these requirements came
> from and what they mean. This should not be read as a statement that I
> support these ideas or not.
>
> /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/>