Does the IETF use the protocols it designs ?
Do these incompetent Working Groups you refer to use IPv6 ?
Jim Fleming
http://www.unir.com
Mars 128n 128e
http://www.unir.com/images/architech.gif
http://www.unir.com/images/address.gif
http://www.unir.com/images/headers.gif
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp
http://www.ietf.org/mail-archive/ietf/Current/msg12213.html
http://www.ietf.org/mail-archive/ietf/Current/msg12223.html
----- Original Message -----
From: "Keith Moore" <[EMAIL PROTECTED]>
To: "Marshall T. Rose" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Einar Stefferud" <[EMAIL PROTECTED]>; "Marshall Rose"
<[EMAIL PROTECTED]>
Sent: Monday, June 25, 2001 3:06 PM
Subject: Re: I am *NOT* a believer in the democratic process.
> > perhaps, as noted earlier, the turning point was when wg's were
> > chartered to do requirements documents instead of protocol
> > documents. perhaps the problem is even earlier...
>
> in my experience, one reason that a WG is chartered to do only a
requirements
> document (there are others *) is that the WG appears to lack basic
competence,
> but there isn't the political will to entirely block creation of the
group.
> so the group is allowed to do a requirements document in the hope that
doing so
> will give the group more clue. sometimes it even works, but quite often
the
> group ends up creating an immensely complex mess.
>
> so the chartering of groups to do requirements documents may be a symptom
> of the problem rather than the problem itself. but it probably does
correleate
> in time with the "turning point".
>
> Keith
>
> * another reason is that the group's work needs to satisfy such a diverse
set of
> interests that the only way to get everyone on the same page is for the
group
> to jointly write such a document.
>
> p.s. I wish we'd stop calling them requirements documents, because we tend
> to treat them as if they were carved in stone rather than merely an
exercise
> in getting everyone to agree on a problem definition. "design goals" is
much better.
>
