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

[Ron Bonica <[e-mail]>]

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.