ietf
[Top] [All Lists]

Re: [RFC 3777 Update for Vacancies]

2012-10-26 11:25:36
At 11:39 AM 10/26/2012, John C Klensin wrote:
In principle, I have no problem with setting up a list of
repeated/ long-term non-feasance, non-appearance, or
non-responsiveness conditions that are treated as equivalent to
a more formal resignation unless the body of which that person
is a member votes to waive the rule (i.e., not accept the
resignation).    I actually think that would be completely
reasonable and that we probably should have established such
principles years ago even though I'd expect a lot of quibbling
about setting the thresholds for "repeated/ long-term".


This is exactly what I'd like to avoid.  No matter how we set the conditions, 
someone will argue - successfully - that the conditions are not met.  (For 
example, I attend one out of every 3 meetings for exactly 5 minutes - I 
obviously haven't abandoned the position, but I really have abrogated my 
responsibilities).  Etc etc etc etc etc... 

Or something will come up that the conditions just never anticipated (the 
current example springs to mind).


Let the bodies decide if the member is doing their job.  If 2/3 of them think 
no and they can convince 2/3 of the confirming body, then its time for him to 
go.  This handles pretty much any "emergency" condition I can think of and does 
it in only a little more than a month.  And note, that unlike a recall, there 
is no bar to being re-appointed by the Nomcom in the following term.

The recall process remains for the body of the IETF to be able to affect a 
removal with some amount of formalism.

I'm pretty much going to object to any condition based model that anyone 
proposes, because we're really bad at a) figuring out the complete list of all 
possible conditions that could ever happen, b) writing conditions that can be 
objectively evaluated, and c) figuring out how to decide when specific 
conditions are met (because of the lack of objective criteria).  In addition, 
people have been carping on the mailing list about how we need to be flexible - 
and condition lists by their very nature are not flexible.