12 problems

[Brian E Carpenter]

This longish note is actually cut and pasted from a note I sent
to the IAB and IESG almost exactly two years ago: my view of
a set of IETF problems at that time. But I haven't seen much reason
to change the list.

To conform with this proto-WG's proto-charter, I've deleted my
recommendations for action. So this is my input to the problem
collection process. I apologise for the opinionated tone, but
it didn't seem worth editing the text for neutrality at this stage.

    Brian

ISSUE 1: Too Slow
-----------------

We hear assertions from 3rd parties that the IETF is too slow
(ironically, the same complaint we used to make about ITU and ISO).
This is cited as a major reason for doing work in a closed
vendor consortium.

The fact is that today it typically takes 18 months for a
document to progress from a -00 draft to a Proposed Standard RFC,
up from 6 months in 1993.

In that period the IETF has tripled in active participants, more
than doubled the number of WGs, and its demography has changed 
dramatically. Its ouput (measured in RFCs) has at least tripled.
Some slowing down seems inevitable, but a factor three is slightly
worrying.

However, we can't accept any solution to this perceived problem that
threatens openness and the rough consensus process. That's how we get
good engineering results *and* a level playing field. With more people
involved than 7 years ago, it just takes more time.

ISSUE 2: Lack of focus
----------------------

Another reason we see all these XYZ Forums popping up
and bringing us half-baked specifications to rubber stamp
is that much of the industry sees the IETF as unfocussed
and unwilling to solve *their* particular problem. Indeed
the IETF has been bad at identifying what other organisations
think of as "architecture" and triggering coordinated work
to solve a specific industry problem. The IETF's strength
tend to be in piece parts; in fact that is how we handle
the complexity of the total architectural problem - by
interoperable small pieces adhering to general design principles.

ISSUE 3: IESG is too picky
--------------------------

We hear complaints from vendors, closed industry forums, and WGs
that the IESG is too picky (won't charter my WG, won't approve my
RFC, etc.).

[Comment] Mainly, this proves that the IESG is doing its job.

ISSUE 4: IESG is opaque or arbitary; IAB is opaque
--------------------------------------------------

Those outside the charmed circle do have this impression. Having sat
in on IESG calls for 5 years, I have enormous respect for the IESG's
fairness and I know why things sometimes appear to be black holed.
But it definitely can be frustrating from the outside.

The IAB, although it is not a hurdle for document approvals, is
also somewhat opaque to outsiders.

ISSUE 5: Too many steps in IETF process
---------------------------------------

Actually we haven't heard this much from 3rd parties but we
know that the Internet mainly runs on Proposed Standards.
There is also confusion between Internet-Draft and Draft Standard.
On the other hand, there are solid reasons for the 3 steps
on the standards track (progressing from solid design through proven
interoperability to mature deployment).

ISSUE 6: RFC abuse by marketroids
---------------------------------

We mention this because it keeps coming up, but whenever we
discuss it the conclusion seems to be that however we name
our documents, marketroids will find a way to abuse them,
as in "Conforms to IETF Really Stupid Idea #17". And all
proposals for a revised naming scheme rathole, always.

ISSUE 7: Herding cats
---------------------

Without intending to be the least bit critical of anyone,
we clearly are imposing a crippling workload on a "volunteer"
organization. 

The NomCom already requires nominees to give an assurance that
their employer will allow them enough time to attend to their
IETF duties. But we don't do this in any formal way for
WG chairs and document authors.

ISSUE 8: meetings too big, too many newcomers & tourists
--------------------------------------------------------

The meetings are close to impossible to fit into hotel facailities,
and almost certainly violate fire regulations every time. Some
sessions are so crowded that vital participants can't get in without
extreme prejudice. Technical discussion is diluted by sociological
effects. Yet we must retain the open-access nature of the IETF.

ISSUE 9: the operator disconnect 
--------------------------------

Operators now perceive the IETF as not understanding or 
particularly caring about their concerns. So in general
we don't hear enough from them.

ISSUE 10: Root of all evil
--------------------------

The Internet Society has just [during 2000] created "Platinum" 
membership whereby companies can designate funds in support
of standards work, and this has proved that companies *are* willing
to support the IETF with cash. But they will presumably expect
output as a result. [2003 comment: Money has got substantially
tighter over the last 2 years. We can realistically expect
funding difficulties.]

ISSUE 11: IAB and IESG spend precious time on political sludge
--------------------------------------------------------------

Analysis: obvious. But like it or not, choices made in the
IETF change the available policy options, and bad policy
decisions can damage the technology. So we have to be
engaged.

ISSUE 12: Risk of micro-management
----------------------------------

Does the IAB attempt to micro-manage IESG issues? Does the IESG
attempt to micro-manage AD issues? And do ADs attempt to micro-manage
WG Chair issues? 

---