Comments on problem statement

[spencer at mcsr-labs.org]

Dear Phillip,

I'm on the problem statement editor team, but am speaking
only for myself...

And thank you for your comments on the draft - we wish we
had more comments.

Spencer

----- Original Message ----- 
From: "Hallam-Baker, Phillip" <pbaker at verisign.com>
To: <problem-statement at alvestrand.no>
Sent: Saturday, July 05, 2003 8:30 AM
Subject: Comments on problem statement


> 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?
>

Speaking only for myself - I wasn't trying to insult anyone. I believe this
text came from discussions about the expanded scope of IETF work
during the 1990s, in several areas where we were absorbing new
groups of participants who had not previously been active in developing
protocols for the Internet.

The influx of telecom participants, the influx of WWW participants
(we even had an HTML working group for a while!), and the influx
of wireless participants are the types of things I was thinking about.
This wasn't to say that any of these folks weren't smart - they were
often smart about things that didn't overlap a lot with what IETF
was doing in the early 1990s. Not just an IETF issue - My boss at Fujitsu
told me that's why he hired me in 2000.

"Please send text." There are more people on the editor team who think
they are newbies than think they are oldies. Dave Crocker's lowest-
numbered RFC is 351, but that's about 1800 lower than the average
for the editor team. We're not trying to insult the proletariat,
we think they include us...

> 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.

I would agree with this, and in my spare time, I'm trying to remember times
when we've scaled anything without inserting levels of hiearchy. So far,
without success. Please send text that does not require the over-decimation 
of the IETF to 150 participants!

>
>
> 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.

I hope this is an overstatement, but even if it's not, XML2RFC has been
very useful for me, and seems like a step in the right direction. If you
don't like the way ftp://ftp.rfc-editor.org/in-notes/rfc2629.txt looks,
maybe Marshall Rose didn't, either - at least, he generated
http://xml.resource.org/public/rfc/html/rfc2629.html
from the same input file. I would like to see us spending
more time talking about what specifications should look like, but starting
with XML is one way that lets us stop talking about the universality of 
pure text and start talking about what is actually useful in a
specification - because we can always generate an RFC that looks
(way too much?) like ftp://ftp.rfc-editor.org/in-notes/rfc1.txt...

If I understand the COACH BoF agenda and scope, this is probably a more
appropriate topic there, as we move into solution space...

>

[deleted down to]

>
>
> 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.
>

My impression (please correct me if I'm wrong) is that we started out
worrying that a faulty congestion control or routing specification might 
result in a disaster, but in recent years, the worry has been that faulty 
specifications take years, if not decades, to disappear (see the "web 
server releases never disappear" discussions in the late 1990s, for 
example). So I'm not sure we still have an overwhelming "fear" - but we 
act a lot like we did when we had such a fear.

My opinions only, of course.

Spencer

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .