RE: draft-ietf-ccamp-tracereq-01.txt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Thjanks Ron, I am checking with the people who raised the issues.

Thanks,
Bert 

> -----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.
> 
> 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?
> 
> > 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. Should I
> include some words
> the that effect in the document?
> 
> 
> > 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?
> 
> In any event, I will spin a new version of the document as 
> soon as there is
> some response to this message.
> 
>                                                        Ron
>