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

["Wijnen, Bert (Bert)" <[e-mail]>]

Looks good to me. Pls submit to internet-drafts.
And I will pick it up for IESG agenda again.

Did the WG members check it too?

Thanks,
Bert 

> -----Original Message-----
> From: Ron Bonica [mailto:[e-mail]]
> Sent: dinsdag 13 mei 2003 4:20
> To: Wijnen, Bert (Bert); [e-mail]
> Subject: RE: draft-ietf-ccamp-tracereq-01.txt
> 
> 
> Bert,
> 
>   Here is the ping that you requested.
> 
>          Ron
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]On
> > Behalf Of Wijnen, Bert (Bert)
> > Sent: Monday, April 28, 2003 11:54 PM
> > To: Ron Bonica; [e-mail]; [e-mail]
> > Subject: RE: draft-ietf-ccamp-tracereq-01.txt
> > 
> > 
> > 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:[e-mail]]
> > > Sent: maandag 28 april 2003 18:58
> > > To: [e-mail]; [e-mail]
> > > 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: [e-mail] 
> [mailto:[e-mail]]On
> > > > Behalf Of Ron Bonica
> > > > Sent: Monday, April 21, 2003 5:51 PM
> > > > To: [e-mail]; [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: [e-mail] 
> [mailto:[e-mail]]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.
> > > >
> > > >
> > > >
> > > 
> > 
>