Re: I-D Action: draft-rsalz-termlimits-00.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Well, I am not convinced. *Guidance* to NomCom along these lines
would be a fine idea, but a firm rule, IMHO, would over-constrain
an already constrained solution.

Regards
   Brian

On 21-Oct-21 09:29, John C Klensin wrote:
> 
> 
> --On Thursday, October 21, 2021 08:32 +1300 Brian E Carpenter
> <brian.e.carpenter@xxxxxxxxx> wrote:
> 
>> Well, this is a bad idea that was repeatedly rejected in the
>> past.
> 
> Brian, I believe that hard limits were rejected in the past for
> two reasons:
> 
> (i) There will certainly be specific cases for which they are
> the wrong answer.  We can imagine many such cases.
> 
> (ii) There has been at least a suspicion in the community that
> the IESG is opposed to anything that would put additional
> constraints on incumbents (e.g., themselves).
> 
>> Why? Because it's always hard to fill all the positions, and
>> this would make it harder.
> 
> I suggest there is a different way to look at that.  If we have
> a position that cannot be filled by someone able, willing,
> competent, and with adequate time and resources, a Nomcom would
> be doing the community a big favor by not filling it and thereby
> forcing a review of whether we need that position, whether the
> role that position is supposed to satisfy is correctly defined
> for needs at the time or whether some reorganization would serve
> us better, whether our ambitions for what should be done are
> realistic, and so on.  Probably the same principle should apply
> when there is only one candidate whom the Nomcom (or other
> appointing body) would not consider acceptable if there were any
> other choices.
> 
> As a specific example that has come up before, if there is an
> area with two ADs and one of those slots cannot be filled, it
> should trigger a review of whether that area can get by on one
> AD, whether we need the Area at all any more (so that the remain
> AD should be charged with winding it down), whether some of the
> WGs in the Area should be trimmed, and whether the IESG is in
> need of a reorganization.  
> 
> Moving forward with a least-bad candidate because it was hard to
> recruit people may help patch a problem but I suggest it is bad
> for the IETF in the long term.
> 
> And that suggests there is actually value in term limits:  if we
> know, a year in advance, that a position will be open, it allows
> far more time to think about candidates, twist arms, line up
> resources, etc.,  and even whether some of the above thinking
> about the organization or the Area or the IETF would be in
> order.  in addition, telling organizations who support
> Nomcom-selected people during their terms that it for a maximum
> of two such terms might make it easier to get agreement than if
> it is a potential lifetime commitment (assuming, of course, that
> organizations are not supporting people for those positions
> because of a belief that having people in them brings prestige,
> credibility, or power to the company).
> 
>  
>> If someone is incompetent, NomCom will not reappoint them even
>> once, let alone twice.
>>
>> We all agree that ossification is unwelcome, but artificial
>> turnover is not the way to avoid that.
> 
> I think we have seen people who have ossified in place but who
> are then selected for an additional term before retiring or
> being forced out.  I agree that rigid term limits are not the
> right solution, but hoping the Nomcom will figure it out may not
> be the optimal solution either.
> 
> Finally, the "one term out" rule in Rich's proposal ensures
> rotation, not retirement, and there is a difference.  Even a
> person who has done a great job might benefit from some time in
> the community between terms... and the community would almost
> certainly benefit from the more recent and closer to bottom-up
> perspective on what it takes to get work done in the IETF.
> 
>    best,
>     john
> 




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux