The MPLS WG Archive

["Daniel O. Awduche" <awduche@isocore.com>]

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: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Shahram
Davari
Sent: Tuesday, November 19, 2002 1:15 PM
To: 'Gray, Eric'; 'mpls@uu.net'
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.

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:egray@celoxnetworks.com]
> Sent: Tuesday, November 19, 2002 11:20 AM
> To: Shahram Davari; 'mpls@uu.net'
> 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.
> egray@celoxnetworks.com
> 508 305 7214
> 
> 
> > -----Original Message-----
> > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> > Sent: Tuesday, November 19, 2002 11:02 AM
> > To: 'mpls@uu.net'
> > 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.
>