Subject: Comments on problem statement

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 5 Jul 2003 06:30:16 -0700

1.1

   These failures are just those that afflict many small organizations
   trying to make the transition from a small organization which can be
   run informally and where essentially all participants fully share the
   aims, values and motivations of the leadership,

That is NOT the issue, the problem has nothing to do with shared values,
this statement contains exactly the type of arrogant assumption that has
poisoned relationships between the establishment and the proletariat.

When there is a problem with the proletariat refusing to be led blindly the
establishment complain sniffily about 'lack of shared values' - thus putting
themselves up on a pedestal.

Can't you folk see how insulting this attitude is?

The PROBLEM is a well known one that there is a functional limit of about
150 people for informally organized groups. It is a basic limitation of the
human brain, it simply does not have enough RAM to maintain knowledge of
relationships amongst bigger groups.

2.2

This section should address the fact that IETF documents are poorly
formatted in a fixed width font making them VERY hard to read. They look
like a second rate piece of work and many engineers will avoid IETF process
for that reason alone.

This is yet another example of the establishment having its own way without
listening to the membership. Suggest change and you get Dilbert's PHB wet
blanket proceedure.

Also the section should address the fact that many of the engineering
criteria that the IETF thinks it is applying don't actually exist. Case in
point is the ubiquitous reference to 'end-to-end' security. This is actually
a conflation of several pieces of work. Search for an actual definition of
what the doctrine means and you will not find a single coherent statement.
The end-to-end paper itself barely mentions security.

If you read the RFC describing the IAB security workshop which is the
nearest thing to a coherent IETF statement on security you will find it
bears little relation to the received wisdom that is often rammed down the
throats of WGs by people who in most cases are NOT security specialists.

2.6 The IETF Management Structure is not Matched to the Current Size and
    Complexity of the IETF

IT could well be that the ROLE of the IETF management structure is not
matched to the current size and scope. The management structure is
considerably larger than OASIS which at this point is managing an equivalent
number of active specifications.

If the management does less the problem is reduced. To do less the
management have to relinquish control over the process outcome.

I fail to see the fearful penalties that the IESG believe will attend a
faulty spec. In my experience completely broken specs don't make it to
production. There is plenty of brokeness that went into the Web but that
almost always happened as a result of someone deliberately circumventing the
process completely.

---

From: Scott W Brim <[email-masked]>
Date: Sat, 5 Jul 2003 10:51:52 -0400

> Can't you folk see how insulting this attitude is?

http://www.shirky.com/writings/group_enemy.html

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 06 Jul 2003 17:28:41 +0200

"Hallam-Baker, Phillip" wrote:
...
> like a second rate piece of work and many engineers will avoid IETF process

Well, I'm currently working both in the IETF (one fixed width font) and
in the GGF (as many variable fonts as you want). I find IETF documents
substantially easier to deal with. They are much smaller, which is an
immense advantage when you are on the road or on a lousy hotel wireless
network. They are much easier to discuss on mailing lists by trivial cut 
and paste. Even the diagrams can easily be cut, pasted, and updated. 

Against this is is the lack of italics or shading to distinguish symbols
and examples from text; that is certainly an advantage in GGF documents.

There may be some arguments for having the final product look pretty,
by use of multiple fonts and artistic diagrams. But in my experience,
using these techniques in documents under development is a problem
in itself.

    Brian

---

From: Melinda Shore <[email-masked]>
Date: Sun, 06 Jul 2003 12:47:21 -0400

> and paste. Even the diagrams can easily be cut, pasted, and updated. 

This line of discussion has, as we've seen repeatedly,
extraordinarily high likelihood of becoming very
unproductive very quickly.  If there's a real problem here
aside from differences in personal preference, let's put
some text to it and move on, otherwise let's just move on.

Melinda

---

From: "James Kempf" <[email-masked]>
Date: Mon, 7 Jul 2003 07:48:12 +0200

IMHO, the font's don't make a big difference.

One thing that does is the inability to do good graphics. It is extremely
difficult, almost impossible, to include graphs of data in IETF documents.
This makes it very hard to present data derived from experiments as
underlying support for a particular engineering approach to a protocol
design. I think this might help to re-enforce the tendency in IETF for
people's opinions on technical matters to be more important than
experimental data. Also, good quality graphics of system designs are
difficult to do with ASCII, ASCII drawing packages not widthstanding. Though
the correlation is somewhat more problemantic, I wonder if this doesn't
contribute some to the tendency in IETF to avoid looking at the larger scale
system aspects of a particular problem, and concentrate more on the point
protocol aspects.  The premise here is that the difficulty in communicating
the result has a tendency to supress the conversation.

For a good example of both these effects, see the IKEv2 draft. While reading
the draft, I found myself looking for some graphs of data to support the
redesign of IKE, and some good system diagrams explaining the underlying
system and protocol flows in all the cases that are discussed in the text.
The few ASCII diagrams in the document are utterly inadequate, IMHO, for
conveying the complexity that the protocol is trying to capture.

            jak