[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD review for: draft-ietf-ccamp-tracereq-00.txt
Bert,
I have corrected these problems and submitted an updated version of the
draft. Until the draft editor processes it, the updated version can be found
at www.bonica.org/docs/draft-ietf-ccamp-tracereq-01.txt
Ron
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Wijnen, Bert (Bert)
> Sent: Friday, April 04, 2003 10:46 AM
> To: Ccamp-wg (E-mail)
> Subject: AD review for: draft-ietf-ccamp-tracereq-00.txt
>
>
> Sorry for the dealy. Here we go.
>
> - The status of memo and abstract should NOT be numbered,
> see draft-rfc-editor-rfc2223bis-04.txt
> - I wonder why section 3 and the reference to RFC2119
> is present. You do NOT use any of those terms... or am I
> missing something?
> - In the abstract, I do not see the word "tunnel" at all.
> Is that not something to be described? The title and
> the rest of the document seem to make it clear that
> tracing of tunnels needs special consideration and
> features
> - first bullet section 6.
> Is the priviledge (i.e. security token) also not imporant
> for bullet 9??
> - bullet 3 sect 6.
> Is it worth to point to RFC2925, that allows for such a
> function for traditional traceroute?
> - Sect 7.4
> Mmm... section title is "Maintaining State" and it explains
> or prescribes that the protocol should be "stateless".
> Maybe title should be "Stateless Requirement" ??
> - Security considerations: I assume it is also a requirement to
> prevent replay attacks?
> - I am surprised with the reference to RFC2026. It will go away
> when this turns into an RFC. Maybe your boilerplate should
> use just RFC 2026 instead of [RFC-2026]
> - You have reference to RFC-2637 in the references section,
> But I do not see it anywhere in the text.
> It might actually be good to refence all of the tunneling
> protocols that you mention.
> - I wonder why there is a reference to RFC2434? It is not
> cited in the text anywhere.
>
> Bert
>
>
> Thanks,
> Bert
>