Section 2.4 of draft-ietf-problem-statement-00.txt

James Kempf kempf at docomolabs-usa.com
Fri Feb 28 10:09:46 CET 2003


Process question to chairs: is the intent that we achieve concensus on what the
problems are for this draft, or is the draft supposed to reflect the diversity
of opinion about the problems as input to the solution procedure?

            jak

----- Original Message -----
From: "Brian E Carpenter" <brian at hursley.ibm.com>
To: <problem-statement at alvestrand.no>
Sent: Friday, February 28, 2003 3:06 AM
Subject: Section 2.4 of draft-ietf-problem-statement-00.txt


> > 2.4 Authority and Influence in the IETF are concentrated in too few
> >     hands
>
> I think this heading, and the whole section, is somewhat off base.
> If anything, it's describing a symptom, or a set of consequences
> of other problems. The whole text of this section is in my view
> a somewhat biased view of the facts. (My qualifications for making
> this judgement: 8 years inside the IAB black helicopter, closely
> watching the IESG, with my arm being twisted every two years to
> prvent me jumping out, until I succeeded last year. Plus co-chairing
> a WG that has been hung up for 2 years getting its last 2 documents out.)
>
> >
> >    It appears that both authority and influence in the IETF are
> >    concentrated in too few hands, and those with authority (primarily
> >    the Internet Engineering Steering Group (IESG))
>
> The objective fact is that about 10 years ago, the IETF decided to remove
> authority from the IAB, and give it to the IESG. The above phrase is a
> judgement call by saying "too few". Rewrite:
>
>     Authority in the IETF is explicitly concentrated in the hands
>     of the Internet Engineering Steering Group (IESG) rather
>     than being delegated.
>
>
>
> >    ...are insufficiently
> >    accountable for some of their actions.
>
> Again, "insufficiently" is very much a judgement call. Try
>
>     Although the appeal process has been exercised a number of
>     times, there has never been a member recall, so in practice
>     Area Directors are rarely sanctioned.
>
> >
> >    The IETF appears to have created a 'ruling class' system which tends
> >    to re-select the same leaders from a limited pool of people who have
> >    proved competent and committed in the past.
>
> I think this should be preceded by
>
>     Successive IETF Nominating Committees have chosen to give heavy
>     weight to continuity of IESG and IAB membership. Thus, the IETF appears...
>
> >    Members of this 'ruling
> >    class' tend to talk mainly to each other and former members of the
> >    'ruling class'.
>
> I dispute "mainly" - where is the evidence? Speaking personally, it's
> a pleasure to work with newer arrivals in the IETF. I think this
> sentence should be deleted, unless you have objective evidence.
>
> >    Newcomers to the organization and others outside the
> >    'ruling class' are reluctant to challenge the apparent authority of
> >    the extended 'ruling class' during debates and consequently influence
> >    remains concentrated in a relatively small group of people.
>
> Again, I'd like to see the evidence (I don't see this on multi6, to
> take one example). In any case, this is a statement about society
> in general, not about the IETF. It's always been people who are
> willing to make fools of themselves in public who have reached
> prominence. Try this
>
>      As in any organization, newcomers and outsiders are reluctant
>      to challenge the apparent authority of the extended 'ruling class'
>      during debates. Only newcomers with the courage to intervene
>      assertively and in public can influence outcomes.
>
>
> >    This
> >    reluctance may also be exacerbated if participants come from a
> >    different cultural background than the dominant one.
>
> 100% true.
>
> >
> >    The management and technical review processes currently in place were
> >    adequate for the older, smaller organization, but are apparently not
> >    scalable to the current size of the organization. The reliance of the
> >    existing process on the small number of people who have authority in
> >    the IETF both slows up the process
>
> Agreed. But it's a bit of a change of topic - maybe needs a subheading.
>
> >    and limits the number of formally
> >    recognized 'preferred' positions within the IETF, thereby limiting
> >    the (intangible) rewards for participants.
>
> Another change of topic. I suspect that too many issues are getting
> mixed up here.
>
> >    This can lead to useful
> >    and effective participants leaving because they cannot obtain any
> >    recognition (the only currency the IETF has to pay participants),
> >    which they use to fuel their own enthusiasm and help justify their
> >    continued attendance at IETF meetings to cost constrained employers.
>
> Actually, this is contradictory. If they leave for this reason, they are
> *not* useful and effective. They are *potentially* useful and effective.
> So I think the problem here is that the current IETF environment does
> not cultivate newcomers unless they are assertive as well as competent.
> This is a problem, but I'm not sure it belongs in this section.
>
> >
> >    The current IESG processes allow one (or two) people to block or veto
> >    the work put together and approved by the many in a Working Group,
>
> This is a very biased way to state it. Try
>
>     The IESG, being the final authority, applies the final quality control
>     to documents that have been put together and approved by many in a Working
>     Group. In some cases, this results in one (or two) people applying a
>     block or veto to others' work.
>
>
> >    possibly without good reason being given.
>
> Is there evidence of the IESG blocking stuff without giving reasons?
> (Note: I said "IESG" not "an AD".)
>
> >    This can happen in two
> >    ways:
> >
> >    o  IESG members who fail to put work on the IESG agenda. The
> >       'responsible Area Director (AD)' for a WG can hold up progress in
> >       the WG indefinitely, with no way for the WG to bypass the AD short
> >       of using the formal appeal or recall processes, both of which
> >       signal such a desperate breakdown in relations that, in practice,
> >       no WG has ever attempted to use them to overcome this sort of
> >       unreasonable delay.
>
> I think this is a valid observation. But it seems very detailed to be
> in Section 2 rather than the Appendix. I think it should be reduced
> to a summary line here.
>
> >
> >    o  Documents can be blocked by one AD tabling a 'DISCUSS' issue
>
> s/delayed/blocked/
>
> >       regarding a document.  Although a mechanism exists whereby the
> >       whole IESG can override a single AD's DISCUSS, any two ADs can
> >       block a piece of work indefinitely.
>
> Yes, but why is this relevant here? Surely it is connected to the issue
> of quality control in earlier stages in the process. The issue is that
> due to lousy early quality control, the IESG is not simply acting as
> a back stop but as the routine, regular quality control agent. I don't
> see how it is relevant to the issue 2.4 claims to address.
>
> >
> >    Apart from the frustration that this can cause inside the
> >    organization, and the perception of disunity from outside the
> >    organization, work which has been properly authorized as being within
> >    scope of the IETF and properly quality checked during development
> >    should almost never come up against such a blockage.
>
> Exactly. So it isn't an issue of concentration of authority. It's an
> issue of failure much earlier in the process than IESG review. I think this
> issue does not belong at all in 2.4.
>
> With all that said, let me propose a new title for this section, as
> well as the rewrites and deletions suggested above:
>
> 2.4. Authority and Influence in the IETF are insufficiently delegated
>
>    Brian
>



More information about the Problem-statement mailing list