Subject: RE: Adjusting the Nomcom process

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 5 Sep 2006 12:44:17 -0700

> From: John C Klensin [mailto:[email-masked]] 

> --On Tuesday, September 05, 2006 3:10 PM -0400 Keith Moore 
> <[email-masked]> wrote:

> One thing to watch out for in these proposals is that the 
> Nomcom now has the ability to brainstorm, conclude that 
> person X would be a better candidate for a particular 
> position than any of the already-suggested candidates, and 
> then go out an start twisting X's arm.  The idea is 
> particularly important if the Nomcom has an idea that 
> involves reaching outside the usual cluster of suspects or 
> even outside the collection of usual and recent IETF 
> participants.  In theory, the Nomcom can reach that 
> conclusion and start the process at a fairly late stage, 
> e.g., after the close of the formal call for nominations/ 
> recommendations.

I agree that such a mechanism can be useful. I suspect though that the reason it has not been used as much recently is the introduction of term limits and the fact that the effective vacancies are known in advance.

> While it is probably not impossible to reconcile it with 
> public lists of candidates, reconciling the two might require 
> some effort.  How about a specific proposal, folks?  You and 
> Dave clearly know how to do that, even if some others who 
> make a lot of postings to this list don't seem to.

I don't agree that this is necessary.

In a public election system it is open to any group to decide that they don't like the candidates on offer and to propose an additional candidate. There is in general an advantage to declaring a candidacy as early as possible, particularly if you are a strong candidate. 

The key is simply to ensure that the close of nominations is not unreasonably early.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 6 Sep 2006 10:21:23 -0700

> From: Ned Freed [mailto:[email-masked]] 

> > Brian E Carpenter wrote:
> > > This isn't a call for bureaucracy, but for precision. As 
> this year's 
> > > glitch shows, extreme precision is needed in the rules.
> 
> 
> > Interesting.  What it showed me is that we cannot anticipate every 
> > contingency.
> 
> Dave, I'm sorry, but it didn't show that at all. The specific 
> problem that arose here WAS anticipated and analyzed and the 
> correct thing to do in this case WAS determined and 
> documented. See RFC 3797 section 5.1 for specifics.

There were two problems and very few security analyses anticipate more than one failure simultaneously. Reducing the number of critical assets, i.e. removing the dependence on the list order, significantly reduces the scope for unexpected interactions.