RE: draft-ietf-ccamp-tracereq-01.txt
"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Tue, 22 April 2003 15:54 UTC
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 22 Apr 2003 15:56:22 +0000
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155016A3652@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Ron Bonica <Ronald.P.Bonica@mci.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: RE: draft-ietf-ccamp-tracereq-01.txt
Date: Tue, 22 Apr 2003 17:54:57 +0200
MIME-Version: 1.0
Content-Type: text/plain
Some comments from my side inline > > -----Original Message----- > > From: Ron Bonica [mailto:Ronald.P.Bonica@mci.com] > > Sent: maandag 21 april 2003 20:55 > > To: Wijnen, Bert (Bert); Ccamp-wg (E-mail) > > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > > > > Bert, > > > > Sorry to have taken so long to respond. I have been away on > > vacation. > > No problem... we all need that once in a while (or so I think) > > 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. > > > > Should there be some text to this effect included in the draft? > > Might be a good idea... > > > 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? > > Well... remember I had a bot of trouble finding which of the numbered bullets needed some extra security or not... I guess that is what the commenting person may have meant with "burried". > > > 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. > > Great > > 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. Should I > > include some words the that effect in the document? > > So, although I guess many (nmost) of us understand that, adding some of that explantnion to the document may help (more novice) readers. > > > > > 4. justification of requirements might be nice. > > > > > > > This is interesting, but it could result in a much longer > > document. Wouldn't this distract the reader from the document's > > basic intent? > > Always difficult to say. I personally like for example RFC3216 format. > > In any event, I will spin a new version of the document as > > soon as there is some response to this message. > > Good. I hope to get responses soon. Others on the WG list, please do chime in if you have an opinion. Bert > > Ron > > >
- 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