Loa:
I thought the first criteria (somthing we should do) was met when somthing appeared in a WG charter and milestones ;-).
As for the second, I'll agree to disagree. I've provided my suggestions as to changes that should be made before IMO the document is a good enough starting point. Others should offer their opinions.
cheers
Dave
> -----Original Message-----
> From: Loa Andersson [mailto:loa.andersson@utfors.se]
> Sent: Wednesday, February 20, 2002 11:31 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: Ron Bonica; ccamp@ops.ietf.org
> Subject: Re: draft-bonica-tunneltrace-02
>
>
> All,
>
> a more IETF (possibly ccamp) philosophical question. What do
> we do when we accept a document as a WG document. In my mind
> it is a step taken when we realise that this is something that
> the WG group should do and the document is a good enough starting
> point for doing this work.
>
> Even if I agreed with all of Dave's comments it is my 2 c's
> that both the criteria above are met and that we should progress
> the doc as a WG document.
>
> There will be a couple of iterations where the comments will be
> addressed and possibly be worked into the final req doc.
>
>
> /Loa
>
> David Allan wrote:
>
> > Ron:
> >
> > I have a number of comments on the draft.
> >
> > Clarifications:
> >
> > The discussion of traceroute in section 5, 2nd para. Are you really
> > saying that
> > traceroute only reveals the current layer/level and reveals
> no knowledge
> > of nesting of
> > lower layer/level tunnels or the relationship of the
> current level to
> > higher levels?
> > It doesn't clearly come out.
> >
> > Comments on application requirements (numbers correspond to the
> > requirement):
> >
> > 1) I think a broader discussion of some of the security
> issues needs to
> > be raised. First by
> > whatever means a trace request needs to be able to be
> instantiated at a
> > tunnel end
> > point. Second, as a result of initiating a trace, any node in the
> > network may be required to
> > generate a response to the tracing application. Therefore
> the tracing
> > application is required
> > to promiscuously accept responses. A mechanism is required to
> > authoritatively associate
> > responses with requests and discard spurious messages.
> Further such a
> > mechanism should not be
> > able to be leveraged for denial of service attacks (e.g.
> spurious trace
> > responses forcing lots
> > of cryptography, defense against replay attacks etc.).
> >
> > 2) Any interface? I think any routable interface (mind you
> this is where
> > separating out routing
> > limitations into a separate section reduces the clarity). I
> think there
> > is a separate stipulation that
> > there is no representation as to the number of protocol
> exchanges it
> > takes to perform a trace
> > (other than permitting the trace originator to perform some
> measure of
> > flow control by the protocol
> > being designed to bound the number of responses a transaction will
> > elicit; ideally 1 to 1, this also
> > has DOS implications similar to ICMP smurf type attacks whereby the
> > responses to a single
> > message can be unbounded). You actually bring this up
> obliquely in the
> > protocol requirements, but IMHO it
> > should be expressed less prescriptively.
> >
> > 3) Is third party really a special case? Can I not instantiate an
> > in-line trace using management
> > protocols etc. and pull back the results.
> >
> > 4) the application "displays" tunnels (editorial nit)? are
> we really
> > discussing how much information the
> > application collects and reports on. The alternative
> interpretation is
> > that the same amount of
> > information is always collected, and somehow filtered
> during presentation.
> >
> > 4) When you say "single hop" or "in detail", are you really
> saying "this
> > layer" or "constituent
> > lower layer components"? It could use clarification.
> >
> > 5) Are you sure the collected information includes round
> trip delay?
> > It's not clear to me
> > whether this is some pre-existing chunk of information just lying
> > around, or where the trace
> > transaction is expected to measure RTT on the fly for every hop and
> > provide current view.
> >
> > 6) I think are more accurate statement is support any tunneling
> > technology that is used between
> > IP endpoints. Otherwise this is not a sustainable requirement. I am
> > concerned, for example, that
> > any intervening L2 or layer 2 and a half skewers the model. (e.g..
> > IP/PPP/L2TP, you can only
> > reveal the PPP end points, or if you look at L2TP tunnel
> switches, you
> > appear to be SOL)
> >
> > 7) This is the "detail" referred to earlier? Seems this one
> is subject
> > to the routing
> > requirements reported later. Might be easier simply to
> introduce that
> > limitation here.
> >
> > 8) Is the expectation that the quality of information
> obtained from a
> > control plane trace and a
> > forwarding plane be comparable? Can you clarify what you mean by a
> > control plane trace? I can see augmenting
> > signalling protocols to faciliate this (e.g. LSP query
> I-D), but that
> > does not fit into this discussion.
> >
> > 10) This seems to be overlapping with a solution framework.
> >
> > 11) Any intention of aligning TTL models with the
> terminology emerging
> > elsewhere (pipe or uniform
> > models?).
> >
> > 13) Don't quite grok the motivation. I plead ignorance ;-)
> >
> > The protocol requirements section is actually rather
> prescriptive. There
> > are specific requirements
> > in there that end up as either application limitations or
> part of an
> > applicability statement (e.g. routing
> > requirements) or design guidelines. The rest shouldn't be
> in this document.
> >
> > IMHO at the present time the document is not quite ready
> for "prime time".
> >
> > my two cents
> > Dave
> >
>
>
> --
> 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
>
>
>