The MPLS WG Archive

[Monique Morrow <mmorrow@cisco.com>]

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
>
>
> > -----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.
> >