12 problems

[john.loughney at nokia.com]

Brian,

Some comments and contrarian thoughts on selected issues in-line.  
Some of the issues I agree with, but I supply alternate viewpoints
that I have heard discussed.

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

Things may take more time, but there may still be some management issues
lurking that slow down the progress.  Some study would be helpful to
find out what are the bottlenecks in the process.  I think that the
ID-tracker may provide some stats.

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

How widespread is this?  This is somewhat apocryphal in my 
opinion.  There may be some cases of groups wanting a rubber-stamp,
but I don't think it is all that widespread.
 
> 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.

I do think that there is a real complaint that the RFC review process
has become much more stringent, without documentent justification.
Rules on extensibility of certain protocols (SIP, Diameter for example) 
are much tighter than on their predicesor protocols (like RADIUS).  This
produces additional IESG & RFC-Editor workload - which slows down the
process.  A more stringent review may be needed, but I don't remember
that we, as a community, have decided that this is a good thing.
 
> 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.

Is this true still. A few years back, it seemed that this was true,
but now the meetings are less crowded.