[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
In general (i.e. not specific to this document)
- When the document is about a work item and deliverable that
is in the current WG charter, then the WG chairs try to get
consensus on which document or documents are to be used for
delivering on that work item
- When the document addresses work that is not in the current
WG charter, then the WG chairs can still try to figure out
if the WG has consensus that such work SHOULD be done by
the WG, but the WG chairs will need to get in discussion
with ADs to try and arrange for charter update.
- ADs will be very reluctant if the WG has not performed well
according to current charter and milestones.
- When ADs accept the new work as reasonable, they will have
to defend a charter change to IESG and IAB, and if they
all agree, then WG charter gets changed, and we're back at
step 1 above.
Hope thsi explains the process (for those who did not already know)
> -----Original Message-----
> From: Loa Andersson [mailto:email@example.com]
> Sent: Wednesday, February 20, 2002 5:31 PM
> To: David Allan
> Cc: Ron Bonica; firstname.lastname@example.org
> Subject: Re: draft-bonica-tunneltrace-02
> 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.
> 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 email@example.com
> WWW www.utfors.se