|
Re: On revising 3777 as in draft-klensin-recall-rev-00
2005-11-15 12:25:06
Hi John,
Your notes are convincing to me. In effect, you are saying that if
the IESG and IAB members cannot function well together, let's hear
about it before the nomcom cycle. I missed the sentence "The
petition and its signatories must be announced to the IETF community"
in my earlier reading of RFC 3777.
With that condition in place, draft-klensin-recall-rev-00 looks ok to
me. Thanks.
regards,
Lakshminath
At 09:30 AM 11/15/2005, John C Klensin wrote:
--On Monday, 14 November, 2005 15:57 -0800 Lakshminath Dondeti
<ldondeti(_at_)qualcomm(_dot_)com> wrote:
> To give some context:
>
> 3777 says that Recall petitions must be signed by 20 people
> who are eligible to be a nomcom voting member.
>
> draft-klensin-recall-rev-00 suggests that this rule
> "inadvertently" disqualifies sitting IAB and IESG members and
> proposes to allow them to sign Recall petitions.
>
> Inadvertent as it may be, I think that the
> nomcom-qualification is a perfectly fine rule, and sets a
> higher-bar for the recall process than the new proposal. A
> quick count of the number of IAB and IESG seats we have
> available reveals that IAB and IESG members may get into
> brawls (they go to yearly retreats without us commoners around
> to watch them, and gods only know what happens there! :-)) and
> may choose to initiate a recall process on one or more of the
> them without having to explain what's wrong until the recall
> committee is formed. As it stands today, 3777 forces recall
> initiators to find 20 ordinary folks :-), no more than 2 from
> a single affiliation and convince them that a certain IAB/IESG
> member needs to be replaced before her/his term is up, to
> start the recall process.
Well, I don't want to get very far into the "10 versus 20"
argument, about which I have no strong opinion, but let me cite
some history and disagree with the above...
First, remember that, before 3777 was adopted and published in
June 2004 with this "20 signature" rule to prevent denial of
service attacks, we had RFCs 2727, 2282, and 2027, going back to
October 1996. In each of those versions, the number of people
needed to initiate a recall procedure was ... uh, one. And
the qualification for that one was not "nomcom eligible" or any
other attendance criterion. RFC 2727 uses the interesting and
highly restrictive term "Anyone" (Section 5 (1)).
During the period in which we had the extreme vunerability to
DoS attacks that initiation of a recall by "anyone" suggests,
the number of recall attempts that reached the ISOC President
was, hmm, zero. The number of recall attempts that reached the
ISOC President since 3777 was published has also been zero. So,
if our goal is to tune the number of people required to prevent
DoS attacks based on our experience with such attacks, one
signature is more than adequate. Personally, I think that is
too few, but I don't know how to pick a good number. I didn't
propose to change the number in RFC 3777, not because I'm
convinced that 20 is the right number, but because I can't come
up with a good theory as to why any particular different number
is the right one.
However, with regard to the IAB/ IESG members, if the two bodies
are not capable of functioning effectively as groups, then the
whole community suffers. Your position, as I understand it,
essentially has the implication that, if they stop functioning
and have a nice brawl instead, the community should not find out
about that until, at least, the next nomcom cycle. That
impresses me as backwards. If the IESG or IAB is unable to
function due to the personality issues you essentially posit
then the nomcom process has already failed to do the part of its
job that I've sometimes described as picking only those people
who play reasonably well with other children. If the IAB or
IESG is not functioning effectively, and the problem is being
caused (in the opinion of IAB and IESG members) by a small
number of individuals, that situation should be, IMO, exposed to
the community as early and clearly as possible. Let's let the
IESG or IAB members who are most impacted by misbehavior be the
ones who initiate the recalls. Let's not promote leadership by
rumor and conspiracy as they try to collect signatures for
something they can't sign. And let's not create a situation in
which we invite so much frustration within those bodies that
people quit, or decline to seek reappointment, because they feel
unable to cope with a bad actor.
Also note that your concern that someone, perhaps some IAB or
IESG members, "may choose to initiate a recall process on one or
more of the them without having to explain what's wrong until
the recall
committee is formed." does not seem correct to me. Under the
RFC 3777 provisions,
The petition must include a statement of justification
for the recall and all relevant and appropriate
supporting documentation.
and
The petition and its signatories must be announced to
the IETF community.
That doesn't make the nature of the complaint very secret.
Indeed, it is much more open than the nomcom process in which
complaints against the behavior of a particular incumbent are
not public and we rely on the nomcom to investigate, in
sufficient secrecy that complaints can, in principle, just be
ignored, the truth of the matter. As was pointed out in a later
note, the nomcom has occasionally returned people to the IAB or
IESG who were already seriously disfunctional internally.
The bottom line is that the recall process has never been
abused. It is the community's last-resort protection against
someone who becomes abusive, relying of the difficulty of the
recall process as protection against any community action
against bad behavior. And, if there are problems within the IAB
or IESG (or some other relevant body) that are serious enough
for people to start contemplating recalls, it is better than the
community find out about that as swiftly and clearly as
possible, without our erecting barriers that we don't need.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|