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

Elwyn Davies elwynd at nortelnetworks.com
Fri Feb 28 18:58:08 CET 2003


Hi, Brian.

Some thoughts below....

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian at hursley.ibm.com]
> Sent: 28 February 2003 11:07
> To: problem-statement at alvestrand.no
> 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.) 

I'll leave aside the matter of bias for a moment - we've now had both for
and against comments including from people within the IAB/IESG community,
but there is certainly no doubt that you are well qualified to offer an
opinion.

Whether the concentration of authority and influence is a root cause or a
symptom of something else can certainly be debated.  It might be appropriate
to reorder the section altogether, putting the main emphasis on the failure
of the organization to revamp its structures when it expanded beyond the
coping ability of the 'small IETF' mechanisms, together with some biasses in
the nomcom mechanism towards long service and stability.
> 
> > 
> >    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.
> 
Apart from this being a solution statement, it doesn't sufficiently clearly
put over the idea that the current arrangement doesn't have enough people
wielding the authority and influence. 'Too few' is certainly a judgement
call but if you believe it needs to delegate, then is that not a vindication
of this call? Anyway, in a sense all this paper is entirely about judgement
calls!  Your subsequent response to Ran indicated that you felt that fingers
were being pointed here:  That wasn't intended but maybe something like 'The
IESG is does not have enough members to effectively wield all the authority
that it has' might appear more neutral.

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

Again I think the alternative wording masks the problem point:  As is said
later, the problem is possibly that ADs appear fireproof because there is no
sanction short of the recall process, which may make participants reluctant
to challenge a decision which is not sufficiently obtuse to deserve the
recall process.
> 
> > 
> >    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...

I agree ... an earlier pre-draft had some less good words to this effect,
although we should be careful not to push all the blame onto the NOMCOM(s).

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

The lack of a formal hierarchy does make it extraordinarily difficult for
people to get involved unless they are quite extrovert - and I do think that
this happens - it is said in another way at the end of 2.6.
> 
> >    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.
>
That's a good way of putting it. 
> 
> >    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.

As I said above the whole section could be rearranged so that this is the
master topic.

> 
> >    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".)
The sentence was not necessarily intended to imply that the IESG as a whole
ever did this: For the purposes of this draft I don't know that we need to
go into this issue in a more detailed way - suffice it to say that 'black
balling' mechanisms are not desirable.

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

Clearly this feeds into the quality control discussion as well, but the
point is that authority is concentrated into the hands of a small subset of
the IESG in such a way that
it can frustrate the whole process by stopping progress rather than
providing positive input.

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

See last comment.  Both points are relevant.

> 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

We'll need a completely new title if the discussion order is altered.

Regards,
Elwyn

> 
>    Brian
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/problem-statement/attachments/20030228/c7099ab5/attachment.htm


More information about the Problem-statement mailing list