Subject: RE: Requirements and solutions

From: "Gray, Eric" <[email-masked]>
Date: Tue, 19 Nov 2002 11:20:08 -0500

Shahram,

	We need to be a little less retentive about terms,
documents and ordering.

	A lot of the time in the IETF, work starts without 
a formal requirements document.  This is because some set
of people - nearly always including authors and often
including several others as well - believe they understand
the requirements well enough without formally documenting
them.  In many cases, a requirements statement of a sort 
is included in the draft abstract and/or introduction.

	Lately, there is a lot of preoccupation with the
need for formality.  A point I believe was made today is
that it is possible for a requirements document to proceed
in parallel and the results compared in an applicability
document.  This is quite reasonable.  

	While some people said something to the effect that -
in the event that they don't match up well - a mismatch is
an indication of failure on the part of the original draft
authors to develop something useful.  I think one could go
further and argue that the mismatch may be an indication
of future work that may be needed for subsequent versions
of the work already done.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> -----Original Message-----
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Tuesday, November 19, 2002 11:02 AM
> To: [email-masked]'
> Subject: Requirements and solutions
> 
> Hi,
> 
> I am very much troubled by a comment raised in MPLS meeting, that
> in the future the order of first requirements and then solution would
> quite often change and that hopefully it would not require any
> modification
> to the already approved solution.
> 
> This may be acceptable in occasional cases (may be MPLS-ping
> is one of those cases), but I am not sure it is a good idea
> to make this as a general rule.
> 
> 
> Thanks,
> Shahram
> 
> PS- Please not that my comment is not against MPLS-ping, rather about
> procedures.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 19 Nov 2002 13:31:23 -0500

>of the work already done.

         I totally agree.    Many people much smarter than
us have tried  to produce the grandest, most perfect solutions
from the start and failed.  IMHO, a mismatch is a reason to just
iterate  again to evolve the solution.

         --Tom

>[email-masked]

Success is relative; the more success, the more relatives. -Anonymous

---

From: Monique Morrow <[email-masked]>
Date: Tue, 19 Nov 2002 19:40:38 +0100

Shahram,

I believe that we are all striving for a balance between pragmatism and 
architectural perfectionism -  the former being dictated by immediate 
customer needs.

Kireeti has suggested that we run due diligence of these requirements 
against the proposed solution --- something that is reasonable and can be 
done in parallel IMHO.
Customers want solutions now not later and certainly, we can dialogue on 
evolving these requirements to the short-term, mid-term and long-term 
proposed implementations as these develop.

Looking forward to a prolific collaborative effort Shahram -

Best regards,

Monique

>Eric,
>
>As I said in my email, this is not a rule that is written in stone
>(like ten commandments). But I think it should be the general practice.
>
>I understand that in some cases, solution is developed without formal
>requirements. But I am wondering whether a follow up requirements RFC
>makes sense in those cases.
>
>Yours,
>-Shahram
>
>
> > From: Gray, Eric [mailto:[email-masked]]
> > Sent: Tuesday, November 19, 2002 11:20 AM
> > To: Shahram Davari; [email-masked]'
> > Subject: RE: Requirements and solutions
> >
> >
> > Shahram,
> >

---

From: Shahram Davari <[email-masked]>
Date: Tue, 19 Nov 2002 11:02:33 -0800

Monique,

I totally agree with you that customers need should be taken
to account first. And I have no problem with MPLS-ping or the
requirements doc. 

I understand the urgency, but to get a response in the meeting that
people should get used to this kind of process, and expect more to
happen in the future was a bit surprising to me.

Thanks,
-Shahram

> From: Monique Morrow [mailto:[email-masked]]
> Sent: Tuesday, November 19, 2002 1:41 PM
> To: Shahram Davari
> Cc: 'Gray, Eric'; [email-masked]'

---

From: [email-masked]
Date: Tue, 19 Nov 2002 22:27:33 -0000

There is a balance to be struck between the effort/time-spent
capturing/agreeing requirements and the effort/time-spent defining
solutions.  Common sense really.  However, there are set of functional
attributes that all network technologies require.....and fault-management is
amongst one of the most basic no-brainers.  So having said that, if we
cannot point to where the defects are identified/documented/specified (wrt
to entry/exit criteria and consequent actions.....which IMO ought to be the
starting point) then I think we are in a pretty poor shape to be making any
statements about trying to achieve perfection.

BTW - sometimes its not looking for solutions to the problems caused by
technology X that is the answer, the real answer maybe that technology X
itself is the problem.  However, this is far harder to recognise/accept and
deal with for many reasons.

regards, Neil 

> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: 19 November 2002 18:31
> To: Gray, Eric
> Cc: 'Shahram Davari'; [email-masked]'

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 19 Nov 2002 20:21:56 -0500

>makes sense in those cases.

         As we discussed during the meeting, LSP ping was designed
to be flexible and EVOLUTIONARY, so yes, if we need to fix
something that we discover is wrong, we can fix it incrementally
later.   For now, I think that LSP ping is a tool that is quite useful to
solve the problems it was designed to solve. If we discover later
that it needs some patching, it was designed to handle this.

         --Tom

---

From: Shahram Davari <[email-masked]>
Date: Thu, 21 Nov 2002 12:59:28 -0800

Hi Kireeti,

Thanks for your clarifications. Perhaps I misundertood your comments in the meeting.
I fully agree with your assertions below.

-Shahram

-----Original Message-----
From: Kireeti Kompella
To: Shahram Davari
Cc: [email-masked]'
Sent: 02-11-21 ?AEA 12:54
Subject: Re: Requirements and solutions 

Hi Shahram,

modification
> to the already approved solution.

There was no such statement made -- at least, that was not my intent.
However, since there is this confusion, let me clarify my statement.

If a requirements doc is worked on prior to, or simultaneously with,
a solutions document, then it makes absolute sense that the solutions
doc wait on the reqts doc.

In the case of LSP ping, however, a solution document has been around
for quite a while, in fact, as a *WG* document and has matured quite
a bit.  This document clearly (a) is useful (good consensus on that);
(b) meets at least some of the requirements; and (c) is extensible.

As I said at the meeting, I fully support reviewing the solutions doc
(once it's progressed) as part of the reqts doc, and adding extensions
as deemed useful or necessary, deprecating TLVs if needed.  But we do
need to move forward; and real experience would nicely complement the
requirements document.

Now that I've explained, let me say that I was very troubled by your
request: there are no reqts docs for (a) MPLS, (b) RSVP-TE, (c) LDP,
etc.  What if someone were to say, let's make them all informational
while we write the reqts docs and evaluate them?

I lie.  I wasn't at all troubled :-)

Your question really should be addressed to the ADs, or the IESG:
should every solutions doc be accompanied by a reqts doc?  If not
(and I dearly hope not), perhaps when a solutions doc becomes a
WG doc, the WG and/or chairs adjudicate whether a reqts doc is
needed.  That way, a late-breaking reqts doc doesn't stall an
in-flight soln doc.

Kireeti.