Re: ordering constraints / procedures

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

I don't have any requirements to add - I think we have more than enough already.

I probably shouldn't have jumped into the fray so quickly without looking at the
history of the requirements - it's possible with ANY requirement that a solution
to one can in fact satisfy another, and in retrospect one forgets why two or more
specifications were ever raised in the first place.

I gave a possible interpretation of how the two might differ, since there did not
seem to be a response from the authors of the requirements.

I strongly suspect that whatever solution we develop for "procedures" will also
cover "ordering constraints", so it probably doesn't matter if we drop one of them
- I'd vote to drop "procedures" since it's not as specific (and impressive
sounding) as "ordering constraints".  In any case, I am not interested in owning
either of the requirements, which could happen if I write another word on the
subject...

Keep up the good work - when something comes up that's near and dear to me I'll
jump back in!

Ed

David Harrington wrote:

> Hi all,
>
> It appears that there are a number of interpretations of "ordering
> constraints" and "procedures".
>
> If you feel that the feature, as per your interpretation, is a
> requirement, be sure to submit in the proper format for inclusion in the
> requirements list.
>
> If it determined to be a duplicate interpretation, it can be removed
> later. If it is determined after the cutoff that your interpretation is
> different than the interpretation which is already posted, it may be
> difficult to get it added to the requirements later. Identifying all
> these little underlying assumptions, and identifying the real
> requirements, is part of the reason why we are going through gathering
> and posting the proposed requirements.
>
> Dave Durham, I suggest an additional field in the proposals - the name
> of the person proposing and/or justifying the requirement, so we can ask
> for further clarification if needed.
>
> dbh
>
> Edward P Luwish wrote:
> >
> > 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/>
>
> --
> ---
> David Harrington            Network Management Standards Architect
> dbh@enterasys.com           Office of the CTO
> +1 603 337 2614 - voice     Enterasys Networks
> +1 603 332 1524 - fax       Rochester NH, USA