Subject: RE: Requirements and solutions

From: Shahram Davari <[email-masked]>
Date: Tue, 19 Nov 2002 10:14:50 -0800

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

> -----Original Message-----
> 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,
> 
> 	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: "Daniel O. Awduche" <[email-masked]>
Date: Tue, 19 Nov 2002 13:51:37 -0500

Shahram,

This issue can be trivially resolved through an applicability statement.

The applicability statement may outline pertinent requirements 
concerning a particular deployment context, and indicate if and
how the target specifications address the requirements.

Cheers,
/Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram
Davari
Sent: Tuesday, November 19, 2002 1:15 PM
To: 'Gray, Eric'; [email-masked]'
Subject: RE: Requirements and solutions 

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.

Yours,
-Shahram

> in parallel and the results compared in an applicability document.  
> This is quite reasonable.
> 
> 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
> 
> 
> > 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
> > 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.