Re: One week left to object

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

 



John,

As far as I know, the general proposals are to leave those selected as
voting NomCom members who confirm they still want to serve on the
NomCom. Some new random source would be used to scramble the remainder
of the volunteer list so it just randomizes who would be selected
"next" rather than continuing down the list with the initial random
ordering.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@xxxxxxxxx

On Mon, Aug 22, 2022 at 10:22 PM John C Klensin <john-ietf@xxxxxxx> wrote:
>
> --On Monday, August 22, 2022 19:35 -0500 Pete Resnick
> <resnick=40episteme.net@xxxxxxxxxxxxxx> wrote:
>
> > On 16 Aug 2022, at 22:41, Michael Richardson wrote:
> >
> >> Michael StJohns <mstjohns@xxxxxxxxxxx> wrote:
> >>     > On 8/16/2022 5:35 PM, Michael Richardson wrote:
> >>     >> Eric Rescorla <ekr@xxxxxxxx> wrote: >> qualified
> >>     >> volunteer.
> >> They have
> >>     >> no control over who they could >> transfer to, their
> >>     >> only
> >> choice is to
> >>     >> transfer or not.
> >>     >>
> >>     >> > Correct, but they get to look at the next person on
> >>     >> > the list.
> >>     >>
> >>     >> Given the two from one org limit, what's the attack
> >>     >> here?
> >>
> >>     > DId you already forget what happened last time
> >>     > around?  E.g.
> >> I'm the
> >>     > second member from a company, and the 11th person is
> >>     > the third
> >> member.
> >>     > I decline to serve, the other guy picks it up and the
> >>     > company
> >> doesn't
> >>     > lose a slot.
> >>
> >> I'm still actually lost.
> >> The company still has only two people, right?
> >> It's just not the same two people.  How is it a win?
> >> Why would 11th person be more or less honest than you?
> >
> > If the any of the two people picked from the company is an
> > inexperienced and non-influential member of the community and
> > #11 on the list is a very experienced and influential member,
> > the three can decide who has the best skills to influence the
> > NomCom to pick the candidates of their choice. The company
> > loads the volunteer pool in order to maximize the odds that
> > *someone* in the company gets chosen, and if lucky (with
> > enough people in the list the odds are high), that #11 on the
> > list is a person from the same company and then they get to
> > choose which of the three will serve on the NomCom.
> >
> > The key is that nobody should be able to influence the makeup
> > of the NomCom other than removing themselves.
>
> Pete,
>
> I see an opposite way to game the system and no good solutions
> (or none better than what Rich (and Andrew) have decided it is
> best to do).   Suppose someone (either selected or not) takes a
> look at the overall composition of the proposed Nomcom --
> particular people as well as companies represented -- and
> decides they don't like it, e.g., that some agenda that they are
> interested in pushing is not sufficiently represented.   If they
> are on the list and the plan is to repeat the randomization and
> draw, all they have to do to get a complete new draw is to
> decline to serve.    Will that improve things in the direction
> of a Nomcom composition that would make them happy?  No way to
> guess.  But, if they are already upset about the composition on
> one draw, the odds that a second draw will make things even
> worse (from their perspective) are probably fairly low.
>
> And, if they are not part of the Nomcom on the initial draw, all
> they need to do is to persuade someone who is part of the draw
> to say "so sorry, I'm not going to serve".
>
> The "if someone declines, start over" model could also lend
> itself to a DoS attack.   Suppose there were a company who had
> decided that the IETF had outlived its usefulness and was
> willing to put resources into killing it off.  They would make
> sure a sufficient number of people (whose behavior they could
> control) were part of the pool to just about guarantee that one
> or more of them would be selected as part of the initial draw.
> Then one of those people would decline to serve, forcing a
> second draw (going back to selection of new randomness sources,
> etc.).  The second draw would then require a challenge period.
> Assuming at least one of "their" people were selected that time,
> they could decline to serve, forcing a third draw, etc.  As
> Rich, IIR, more or less pointed out, those processes are
> time-consuming.  It would not take too many iterations
> (especially if there were a basis for throwing in one or more
> appeals) to push actual seating of a Nomcom that could start
> considering candidates far enough into the year to make their
> doing a competent job nearly impossible or at least so
> time-consuming as to encourage others to decline to serve.
>
> If we are worried about the selection process being gamed, it
> seems to me to be at least as useful to concentrate on the
> situations in which people volunteer to serve, are selected, and
> then decline (noting that Rich's process of going down the list
> turned up two more such people and, of course, we cannot know
> their reasons).    Can we create disincentives to people ending
> up in that position?  For the scenario you outline of a selected
> person stepping down to allow a more effective person from the
> same organization a seat, we could change the rule such that, if
> a company got to two (or more) members and one of them stepped
> down, any further possible Nomcom members from that company were
> excluded as the Chair went down the list.   One could make that
> even more harsh by deciding that, if anyone were selected and
> stepped down, no one else from their organization could be
> selected.   That way, someone stepping down would cost the
> company any possibility of having two employees (or even one) on
> the Nomcom rather than working to their advantage.
>
> best,
>    john
>




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

  Powered by Linux