12 problems

[Brian E Carpenter]

john.loughney at nokia.com wrote:
> 
> 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.

Indeed. We need to look into it.

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

At the peak of the Internet "boom" there was definitely more of this.
I hesitate to call out recent examples by name, since that is flame
fodder, but the phenomenon still exists. Whether we should change
anything as a result is another question.

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

It's certainly true the the IESG, aided and abetted by the IAB, has
been getting more stringent. Haven't noticed any wave of objection to
this in plenary sessions or any NomCom recalls as a result... but it
does seem that some open discussion would be appropriate.

    Brian