[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
again and allowing for agreeing to dis-agree :)
why is it that "seeing the requirements, concise, sustainable
and justifiable" is something you need to do before the doc
becomes a wg doc, not as an outcome of a wg discussion. it seems
like you are putting constraints on becoming a wg doc, almost
as if it were a wg last call
David Allan wrote:
> I guess you didn't read all the emails. I raised a number of concerns
> and somewhere in all this noise had a useful and productive dialog going
> with Ron which suggested (to me at least) most were on their way to
> resolution in the next version of the draft. Which then IMHO would be a
> reasonable starting point for a WG document.
> As this is a requirements document, I'm a little confused as to how it
> consistutes a proposal against which solutions that can do more should
> be evaluated. There seems to be a blurring of requirements and the
> candidate solution set in this discussion which should be irrelevant in
> discussing a requirements document.
> I'm simply interested in seeing the requirements, concise, sustainable
> and justifiable.
> > -----Original Message-----
> > From: Eric Rosen [mailto:email@example.com]
> > Sent: Thursday, February 28, 2002 9:59 AM
> > To: Shahram Davari
> > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; firstname.lastname@example.org
> > Subject: Re: draft-bonica-tunneltrace-02
> > Shahram> It has serious security, complexity, backward
> > compatibility and
> > Shahram> layer violation issues.
> > Tom> Can you elaborate on what you think these are?
> > Shahram> Please refer to previous emails by me and David
> > Allan. Most of them
> > Shahram> are listed there.
> > I'm sorry, but as far as I can tell, those previous mails
> > simply say that
> > (a) the proposed solution doesn't do some things that
> > you think are
> > valuable, and (b) the proposed solution doesn't fit well
> > into some ITU
> > architecture.
> > The second of these points is completely irrelevant.
> > The first is
> > irrelevant too, unless there is a reasonable alternative
> > proposed which does
> > more, or if the current proposal doe so little that SPs
> > don't think it
> > worthwhile. The MPLS OAM stuff you've been pushing is
> > not a reasonable
> > alternative of this sort because (a) it is MPLS-specific,
> > and (b) it is
> > already crystal clear that it will not be accepted in the
> > IETF. And it's
> > pretty clear that a number of SPs do think that what the
> > current proposal
> > does is worthwhile.
> > If you can actually cite specific security issues with
> > the proposal, it
> > would be valuable to know about them.
> > Suggestions for reducing complexity would also be valuable,
> > if you have any
> > specific suggestions in that area.
> > I don't understand what the backwards compatibility issue is,
> > as there is no
> > previous version to be compatible with.
> > If you think there are layer violation issues, then what you
> > need to do is
> > exhibit the particular set of specific problems that will
> > arise in practice
> > as a result of those violations. If you cannot do this
> > without referencing
> > some arcane ITU architecture document, then the natural
> > conclusion is that
> > the problem is with that architecture's layering model,
> > not with the
> > proposal.
Utfors Research, Architecture and Future Lab (URAX)
Box 525, 169 29 Solna
Office +46 8 5270 2000
Office direct +46 8 5270 5038
Mobile +46 70 848 5038