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