[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



One of the concerns I always see with Requirements documents is
that it can get bogged down in loooonnggg discussions/delays
before any real work starts.
So... if it is OK with you... I'd rather just approve it as
informational. However, I can send this to author and see
what he has to say (he is on vacation this week however).

Thanks,
Bert 

> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: dinsdag 15 april 2003 22:22
> To: iesg
> Subject: draft-ietf-ccamp-tracereq-01.txt
> 
> 
> serious quibbles maybe, not a discuss
> 
> randy
> 
> 
> 
> From: ops-dir
> To: Randy Bush <randy@psg.com>,ops directorate <ops-dir@ops.ietf.org>
> Subject: draft-ietf-ccamp-tracereq-01.txt
> Date: Mon, 14 Apr 2003 17:07:35 -0400
> 
> At 09:23 PM 4/11/2003 -0400, Randy Bush wrote:
> 
> 
> >*****  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?
> 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...
> 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?)
> 4. justification of requirements might be nice.
> 
> however, given that requirements documents are ignored
> by the world (except for the corporate head-patters),
> this document could say sdlkhj n3poiytjhsdfgn and the
> world would not care.
>