Tracing Requirements for Generic Tunnels
draft-ietf-ccamp-tracereq-05

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: vrijdag 4 april 2003 17:45
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