[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: email@example.com [mailto:firstname.lastname@example.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.
> > 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.
> > Ron