RE: draft-ietf-ccamp-tracereq-01.txt
"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Tue, 29 April 2003 03:54 UTC
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 29 Apr 2003 03:57:18 +0000
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155017C0D1A@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Ron Bonica <Ronald.P.Bonica@mci.com>, ccamp@ops.ietf.org, bwijnen@lucent.com
Subject: RE: draft-ietf-ccamp-tracereq-01.txt
Date: Tue, 29 Apr 2003 05:54:22 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Thanks... busy with other things now. Will check early next week. Pls ping me if I do not answer by say Wed next week. Thanks, Bert > -----Original Message----- > From: Ron Bonica [mailto:Ronald.P.Bonica@mci.com] > Sent: maandag 28 april 2003 18:58 > To: ccamp@ops.ietf.org; bwijnen@lucent.com > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > Bert, > > I have spun a new version of draft-ietf-ccamp-tracereq. It is > available at > http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-02.txt. > Please take a > look. > > If you think that this version addresses the IESG concerns, I > will post send > it to the draft editor. > > Ron > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Ron Bonica > > Sent: Monday, April 21, 2003 5:51 PM > > To: ccamp@ops.ietf.org; bwijnen@lucent.com > > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > > > > Bert, > > > > Sorry to have taken so long to respond. I have been away on > vacation. > > > > Comments inline..... > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of Wijnen, Bert (Bert) > > > Sent: Wednesday, April 16, 2003 9:30 AM > > > To: Ccamp-wg (E-mail) > > > Subject: FW: draft-ietf-ccamp-tracereq-01.txt > > > > > > > > > Please consider these comments and let me know if they > > > wrrant some additional text in the ID. > > > > > > Thanks, > > > Bert > > > > > > >***** o Tracing Requirements for Generic Tunnels (None) > > > > <draft-ietf-ccamp-tracereq-01.txt> > > > > Token: Wijnen, Bert > > > > Note: New revision Addresses comments. > > > > Now on IESG agenda for April 17th > > > > Responsible: Bert > > > > > > 1. this document looks like it might be the union of all the > > > "i want it to do <foo>" requests. an important part of > > > requirements documents is knowing what to not require. > > > do they have any? > > > > This document specifies requirements for a new protocol. It > specifies > > requirements, primarily, by detailing the required capabilities of > > applications that will use this protocol. The application > may implement > > some subset of those capabilities. It may also implement a > superset of > > the required capabilities. However, protocol designers are > not required > > to consider the additional capabilities when designing the protocol. > > > > I can add some text to this effect. > > > > > 2. i am concerned about the security stuff that they've buried in > > > their requirements. nothing definite. it seems unwieldy. but > > > then, so many security things do... > > > > Can you be more specific? Is there any particular requirement that > > you feel cannot be implemented? > > > > > 3. section 4.1 and 4.2 seem to be worded with a particular > > > implementation in mind. requirements documents ought not > > > specify solutions (eg, 4.2 talks about udp, why can't i use > > > icmp?) > > > > Section 4 provides a few protocol requirements, stated as such. In > > particular, Section 4.1 states that the new protocol will consist of > > probes and responses, and that each probe/response pair will reveal > > information regarding a network hop. (In this respect, the > new protocol > > will resemble TRACEROUTE). > > > > Had I remembered to include an application requirement to > support partial > > traces through broken paths, this requirement would have > made much more > > sense! > > I will fix this. > > > > Section 4.2 requires that the protocol be implemented over > UDP. I included > > this > > section primarily to rule out implmentations that were _not_ > > acceptable. For > > example, > > ICMP should not be used, because carrying MPLS information > over ICMP would > > constitute > > a layer violation. TCP should not be used, because this would > > conflict with > > the protocol's > > requirement for statelessness. Tunnel specific mechanisms > should not be > > used, because > > this would conflict with the requirement for generality. > > > > This leaves UDP and IP as the two most resonable candidates. > > > > I can add some words indicating how we arrived at this decision. > > > > > 4. justification of requirements might be nice. > > > > > > > I can add a sentence or two after each requirement. > > > > > > >
- RE: draft-ietf-ccamp-tracereq-01.txt Wijnen, Bert (Bert)
- RE: draft-ietf-ccamp-tracereq-01.txt Ron Bonica
- RE: draft-ietf-ccamp-tracereq-01.txt Wijnen, Bert (Bert)
- RE: draft-ietf-ccamp-tracereq-01.txt Wijnen, Bert (Bert)
- RE: draft-ietf-ccamp-tracereq-01.txt Ron Bonica
- RE: draft-ietf-ccamp-tracereq-01.txt Wijnen, Bert (Bert)
- FW: draft-ietf-ccamp-tracereq-01.txt Wijnen, Bert (Bert)
- RE: draft-ietf-ccamp-tracereq-01.txt Wijnen, Bert (Bert)
- RE: draft-ietf-ccamp-tracereq-01.txt Ron Bonica