Subject: RE: Adjusting the Nomcom process

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 6 Sep 2006 14:08:06 -0700

One simple fix here would be to publish the list on IETF announce BEFORE it goes to the secretariat and to ONLY use that list regardless of whether people are excluded or not.

This still leaves the question of what to do if people were left off the list and need to be added in. 

Another safeguard that can be put in place here is to date the choice of random seeds a fixed time after the list is posted. If the nomcon is appointed late well though, it does not matter. 

> -----Original Message-----
> From: Ned Freed [mailto:[email-masked]] 
> Sent: Wednesday, September 06, 2006 4:10 PM
> To: Eliot Lear
> Cc: Ned Freed; IETF Discussion
> Subject: Re: Adjusting the Nomcom process
> 
> > Ned,
> > > 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.
> 
> > I don't know how many ways I can say this, but 5.1 is irrelevant to 
> > the problem I was concerned about, which is having the pool 
> come out 
> > at the same time as the results.  That allows for mischief in many 
> > ways (not that I'm accusing anyone of that).  Under the 
> circumstances 
> > I *still* believe that the chair did the correct thing, and 
> that his 
> > doing so has ensured the integrity of the process.
> 
> First of all, as others have suggested, the problem with the 
> proximity of the list and result publication can be addressed 
> trivially by having the secretariat provide the list they 
> received for vetting purposes as well as the result they 
> handed back. Maybe I missed a response from you on this, but 
> AFAIK you have yet to explain why this simple action wouldn't 
> deal with your concerns, both in the present situation and 
> should a similar situation ever arise in the future. (in fact 
> I think you said that this would resolve the issue for you, 
> this time around at least.) In any case, I felt this solution 
> to your issue was so simple and obvious that there was no 
> need to comment on it further.
> 
> Second, I have yet to hear an explanation from you as to how 
> the community can be confident that the process wasn't gamed 
> in the fashion I have previously described. AFAIK you have 
> failed to rebut this argument, and until you do I have to say 
> I regard something that's I see no way to check as many times 
> more serious than something that can be checked quite easily.
> 
> In short, I think you concerns are 180% out of sync with reality here.
> 
> 				Ned
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 06 Sep 2006 19:29:03 -0400

On Wednesday, September 06, 2006 02:08:06 PM -0700 "Hallam-Baker, Phillip" 
<[email-masked]> wrote:

> One simple fix here would be to publish the list on IETF announce BEFORE
> it goes to the secretariat and to ONLY use that list regardless of
> whether people are excluded or not.

I like that approach; it's straightforward and easy to analyze.

> list and need to be added in.

Yes; that's a hard one.  The most common/likely failures can be handled by 
publishing the list twice, and allowing anyone to add their name at any 
time prior to the second publication.  Anyone who wants to be sure they are 
added will submit their name before the first publication, and check to 
insure they are listed.

However, that doesn't prevent a person from being excluded due to malicious 
interference or unusual communication problems.  One possible answer would 
be to allow multiple entities to publish lists of volunteers (say, the 
Nomcom chair, the IETF secretariat, and the ISOC President), and use the 
union of the publisheere is a strong IETF consensus that<br />
&gt;our specs need to support universal interoperability.<br />
<br />
Oouhaou!<br />
<br />
are:<br />
- functionally _equivalent_<br />
- interchangeable<br />
- universal interoperability<br />
supposed to be the same concept?<br />
At the same layers?<br />
jfc<br />
<br />

<img src="http://i.msgtag.com/alrthAFic/ui/zFom/CB/jxr/xEzD/qDuCDzDC.gif" alt=" " border="0" id="MSGTAGImage"/></body>
</html>

------MTvmdmdirvweethigbxrcraqpuexvqmute--

--===============0776770849==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============0776770849==--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 06 Sep 2006 19:29:03 -0400

However, that doesn't prevent a person from being excluded due to malicious 
interference or unusual communication problems.  One possible answer would 
be to allow multiple entities to publish lists of volunteers (say, the 
Nomcom chair, the IETF secretariat, and the ISOC President), and use the 
union of the published lists (which any party can easily compute).  Under 
this model, volunteers would normally be expected to submit their names as 
usual to the Nomcom chair, but if they are then omitted from the first 
list, would submit again to all three sources.

Once this is done, the selection process consists of computing the union of 
the published lists, sorting according to a canonical order, and applying 
RFC3797 until enough candidates have been selected.

> Another safeguard that can be put in place here is to date the choice of
> random seeds a fixed time after the list is posted.

What purpose would this requirement serve?

-- Jeff

d lists (which any party can easily compute).  Under 
this model, volunteers would normally be expected to submit their names as 
usual to the Nomcom chair, but if they are then omitted from the first 
list, would submit again to all three sources.

Once this is done, the selection process consists of computing the union of 
the published lists, sorting according to a canonical order, and applying 
RFC3797 until enough candidates have been selected.

> Another safeguard that can be put in place here is to date the choice of
> random seeds a fixed time after the list is posted.

What purpose would this requirement serve?

-- Jeff

---

From: Ralph Droms <[email-masked]>
Date: Wed, 06 Sep 2006 22:23:41 -0400

Perhaps we could avoid similar delays in generating the final list of
volunteers in the future:

 Secretariat generates a list of eligible volunteers as early as possible
  (As far as I know, eligibility data is available well before call for
   volunteers is posted)
 List is used to verify volunteers when offer to volunteer is received
 Volunteer can contest eligibility
 List of volunteers is ready as soon as volunteer period closes

Seems like this process would lend itself well to automation; I can imagine
a web tool that accepts offers to volunteer, checks eligibility against list
from the Secretariat and gives immediate feedback to ineligible volunteers.

- Ralph

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 07 Sep 2006 07:17:09 +0100

>from the Secretariat and gives immediate feedback to ineligible volunteers.

The nomcom pool is in my view very much at the low water mark So an
extension to Ralph's idea would be for the Secretatiat to send a direct
mail to all those who are  eligable to say that they are eligable for this
 important task and invite them to volunteer by clicking a hyperlink in
the mail. The mail should probably include a note from the Nomcom
chair etc.

- Stewart

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Sep 2006 09:32:55 +0300 (EEST)

> the mail. The mail should probably include a note from the Nomcom

I said this in the past, but IMHO the job description of a NOMCOM 
member would need to change if we wanted more people to be involved. 
I think most folks would rather do something else than commit to a 5+ 
hour/wk schedule for a number of months.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings