Loa:
I guess my concern is fairly simple. There is an element of reverse engineering of requirements from a specific solution (GTTP) embodied in this document. That to me somewhat disqualifies it as a reasonable starting point for a WG activity regardless of one's opinions of GTTP and the intent to fix problems associated with traceroute.
Some of my comments were in the spirit of removing self fulfilling prophecy from the requirements as IMHO they were not sustainable except to justify a specific solution. That's not necessarily a healthy approach.
cheers
Dave
> -----Original Message-----
> From: Loa Andersson [mailto:loa.andersson@utfors.se]
> Sent: Thursday, February 28, 2002 10:32 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: erosen@cisco.com; Shahram Davari; 'Randy Bush'; Cuevas, Enrique G,
> ALASO; ccamp@ops.ietf.org
> Subject: Re: draft-bonica-tunneltrace-02
>
>
> Dave,
>
> 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
>
> /Loa
>
>
>
> David Allan wrote:
>
> > Eric:
> >
> > 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.
> >
> > cheers
> > Dave
> >
> >
> >
> > > -----Original Message-----
> > > From: Eric Rosen [mailto:erosen@cisco.com]
> > > Sent: Thursday, February 28, 2002 9:59 AM
> > > To: Shahram Davari
> > > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.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.
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
> --
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URAX)
> Utfors AB
> Råsundavägen 12
> Box 525, 169 29 Solna
> Office +46 8 5270 2000
> Office direct +46 8 5270 5038
> Mobile +46 70 848 5038
> Email loa.andersson@utfors.se
> WWW www.utfors.se
>
>