[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ordering constraints / procedures
Hi Ed,
The purpose of the requirements gathering phase is to identify the
individual requirements.
In many cases, two requirements may overlap, yet be subtly different.
If we assume that only one requirement needs to be mentioned, we don't
really identify both requirements properly; there is an implicit
assumption that the secondary requirement is understood. The one
requirement that is mentioned may end up being eliminated because the
direct requirement is determined to not be in scope or whatever. But
then the secondary requirement also gets eliminated, and it may do so
without people realizing it because the secondary requirement is not
explicitly mentioned.
At this stage, I believe we need to be brainstorming the list of
requirements, not trying to merge them together. We should do that after
we explore the underlying assumptions that people think are covered by a
listed requirement. Uncovering those assumptions is the hard part, and
that's why we are trying to collect the justifications for the listed
requirements, or have additional requirements spelled out.
I don't think anybody "owns" a requirement - the WG owns the
requirements. We do need input about what people think each requirement
means, and I consider it important that you make us aware of your
assumptions about the requirements. Better now than later.
dbh
Edward P Luwish wrote:
>
> 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
--
---
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