Re: draft-sullivan-nomcom-chair-select-00

[Mary B <[e-mail]>]

My view would be that arm twisting would still be required in the case that
the volunteer pool doesn't have other experience that is deemed important.
 In my view it's the other experience in IETF that is far more important.

On Mon, Feb 14, 2022 at 9:47 AM Scott Bradner <[e-mail]> wrote:

> historically the ISOC CEO has had to twist arms rather tightly in some
> cases - taking out that option
> would seem a loss
>
> Scott
>
> > On Feb 14, 2022, at 9:40 AM, Joel M. Halpern <[e-mail]>
> wrote:
> >
> > I like the idea of trying to avoid "familiarity capture".
> > However, I have two problems with the text as written.
> >
> > The major problem I have is that it provides no  option for the ISOC
> President to go twist more arms if the set of volunteers is unacceptable.
> I realize that allowing such fallback weakens the above protection.  But
> the whole system only works if we assume good faith on the part of the ISOC
> president, so I do not think the loss is significant.
> >
> > As a lesser point, I would suggest changing the MUST have been a member
> of a  prior nomcom to a SHOULD (strongly) have been...  We have succeeded
> with nomcom chairs who had not served on prior nomcoms.
> >
> > Yours,
> > Joel
> >
> > On 2/14/2022 12:54 AM, Andrew Sullivan wrote:
> >> Dear colleagues,
> >> I write with my job hat on.  I'm employed by the Internet Society.
> >> Part of my job here is to select the NomCom Chair.  I've been
> >> uncomfortable about how that has worked in the past, and more than a
> >> year ago I said I'd write a new process.  I failed at that goal, but
> >> it's a new year so I've finally written this.  It's at
> >> https://datatracker.ietf.org/doc/draft-sullivan-nomcom-chair-select/.
> >> I am eagerly requesting feedback on that draft _for things under my
> >> control_.  The procedures in RFC 8713 give me a lot of latitude in how
> >> to deal with this appointment.  They give me no control whatsoever as
> >> to whether I _should_ be able to do this, who else should do it, and
> >> so on.  Feedback of the form "Here's how NomCom should work for real,"
> >> will be ignored, because they will not provide me guidance as to what
> >> I should do.
> >> Please also resist the temptation to tell me, "Tell someone else it's
> >> their thing and promise to follow what they promise."  If the IETF
> >> wants to modify RFC 8713, including removing my own role in this
> >> selection, I don't imagine a universe in which I'd work to work to
> >> foil that.  But similarly I am not willing to create an entirely new
> >> consultative body (or new job for an existing consultative body)
> >> without the community saying so.  This document is merely an outline
> >> of how I plan to execute my duties as they're already defined.
> >> I hope this will be a modest contribution to the IETF, and I look
> >> forward to your suggestions.
> >> _Please_ send me feedback directly and not copied to the list.  I
> >> won't be able to follow discussion about this on the list except
> >> sporadically, and I'm going to have to put this plan into action some
> >> time in the coming weeks.  Thanks very much.
> >> Best regards,
> >> A
> >
>
>