Subject: Qualifying for NomCom

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Apr 2016 15:11:45 -0300

Yes, this again.

I've refreshed RFC7437bis in the datatracker since we're effectively
between active NomCom periods, so now's a good time to take another look at
this.

For those that didn't follow along last time, the big showstopper for this
draft as I have it now had to do with updating the criteria for qualifying
to serve on the NomCom.  The current draft says:

(1) To qualify, one must have attended three of the last five in-person
meetings, as it's been for a long time now.

(2) This is regularly criticized as selecting for attendees with the
support and budget to travel to the meetings, and possibly excludes people
who make substantial or numerous IETF contributions but participate
remotely more than in person.

We made previous attempts on this list to come up with new criteria given
(2) above, but weren't successful at coming to consensus, so I took them
back out, leaving the text that's there now.  The previous thread:
https://mailarchive.ietf.org/arch/msg/ietf/QHwG1KrQDBK9u0wsfALjPSre-pw

I'd like to take another run at this before the next NomCom really gets
going.  One suggestion I was given here at IETF 95 is to come up with some
system that's worth trying, and not over-engineer it to protect against
gaming or other abuses until such time as such abuse is evident.  It might,
for example, be sufficient defense to empower the NomCom Chair or the IETF
Chair (or both) with a "panic button", making them able to declare that
selection criteria will fall back to what we have now if it looks like the
proposed new qualification system is likely to yield an inappropriate set
of selecting NomCom members.

Comments welcome.

-MSK

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Apr 2016 15:13:12 -0300

What do you mean by "coming to consensus?"

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Apr 2016 15:17:56 -0300

> What do you mean by "coming to consensus?"

There was no clear agreement on a new set of qualifying criteria, and the
discussion faded out.

-MSK

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Apr 2016 15:19:42 -0300

Right.   So that's not what "consensus" means.   Suggest you reread RFC
7282.   It's not normative, but I think it's helpful to reread when you
feel that you have failed to find consensus.   It contains some good advice
about getting to consensus.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Apr 2016 15:35:17 -0300

> about getting to consensus.

Well let's see...

"Lack of disagreement is more important than agreement..."  check.  There
was disagreement with the proposals, and no better ones presented available.

"Rough consensus is achieved when all issues are addressed, but not
necessarily accommodated..." check.  I wasn't able to even address the
concerns raised, because they were valid, and again there were no solid
remedies proposed.

etc.

On the other hand, I realize now that previous thread went on longer than I
remembered, and there was a proposal that we (I, probably) construct an
RFC3933-style process experiment and let that run for a while.  If it works
well, we can codify it by adding it to RFC7437bis.  So I'll do that.  If
anyone wants to volunteer to collaborate on it, please contact me directly.

-MSK

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Apr 2016 16:52:47 -0400

Murray S. Kucherawy <[email-masked]> wrote:
    >> Right. So that's not what "consensus" means. Suggest you reread
    >> RFC 7282. It's not normative, but I think it's helpful to reread
    >> when you feel that you have failed to find consensus. It contains
    >> some good advice about getting to consensus.

    > "Lack of disagreement is more important than agreement..." check.
    > There was disagreement with the proposals, and no better ones
    > presented available.

    > concerns raised, because they were valid, and again there were no
    > solid remedies proposed.

I concur with Murray: there were objections which remained open and
uncontested.

    > On the other hand, I realize now that previous thread went on longer
    > than I remembered, and there was a proposal that we (I, probably)
    > construct an RFC3933-style process experiment and let that run for a
    > while. If it works well, we can codify it by adding it to RFC7437bis.
    > So I'll do that. If anyone wants to volunteer to collaborate on it,
    > please contact me directly.

Yes, let's do that!

It would awesome if we could say definitely that the new rules
contribute to more volunteers before we actually use them.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 7 Apr 2016 22:58:04 +0200

I liked the suggestion of a process experiment where the Nomcom chair
could accept a volunteer that did not qualify under the current rules,
based on his/her own judgment, possibly with a challenge period (we
already have a challenge period in the procedure).

Once we have a few tens of examples of people who want to serve and the
community doesn't mind being allowed to serve, we can start seeing if we
can find rules that cover them.

Harald

On 04/07/2016 08:11 PM, Murray S. Kucherawy wrote:
> between active NomCom periods, so now's a good time to take another
> look at this.
>
> For those that didn't follow along last time, the big showstopper for
> this draft as I have it now had to do with updating the criteria for
> qualifying to serve on the NomCom.  The current draft says:
>
> (1) To qualify, one must have attended three of the last five
> in-person meetings, as it's been for a long time now.
>
> support and budget to travel to the meetings, and possibly excludes
> people who make substantial or numerous IETF contributions but
> participate remotely more than in person.
>
> We made previous attempts on this list to come up with new criteria
> given (2) above, but weren't successful at coming to consensus, so I
> took them back out, leaving the text that's there now.  The previous
> thread:
> I'd like to take another run at this before the next NomCom really
> gets going.  One suggestion I was given here at IETF 95 is to come up
> with some system that's worth trying, and not over-engineer it to
> protect against gaming or other abuses until such time as such abuse
> is evident.  It might, for example, be sufficient defense to empower
> the NomCom Chair or the IETF Chair (or both) with a "panic button",
> making them able to declare that selection criteria will fall back to
> what we have now if it looks like the proposed new qualification
> system is likely to yield an inappropriate set of selecting NomCom
> members.
>
> Comments welcome.
>
> -MSK

-- 
Surveillance is pervasive. Go Dark.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Apr 2016 09:09:40 +1200

On 08/04/2016 08:52, Michael Richardson wrote:
...
> contribute to more volunteers before we actually use them.

That's not quite how RFC3933 works. You'd *actually* run the experimental
procedure for (say) one cycle, with automatic reversion to RFC7437 unless
RFC7437bis was approved. I think it's a good idea. A one-year experiment
affects ~half the IESG and IAB seats so is highly unlikely to lead to
disaster.

   Brian

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Apr 2016 18:21:07 -0300

How's this look for starters?

http://blackops.org/~msk/draft-kucherawy-nomcom-procexp.txt

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 7 Apr 2016 23:57:16 +0200

On 04/07/2016 11:21 PM, Murray S. Kucherawy wrote:
> <http://blackops.org/%7Emsk/draft-kucherawy-nomcom-procexp.txt>
>
> On Thu, Apr 7, 2016 at 6:09 PM, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
>

Two suggestions:

- Scope objections and aborts to the time between the announcement of
the final list of volunteers and the selection of the comittee. This
closes the loophole that the powers-that-be can look at the selected
nomcom, say "we don't like this group", and force a re-selection by
spuriously objecting.

- The timing says "This experiment is defined to last for one year,
starting and ending with the constitution of the next NomCom after this
document is approved and published." - this is neither determinate nor
grammatical, I think - in particular, it starts and ends at the same time.

I suggest "This experiment is defined to start with the first call for
volunteers after IESG approval of this document, and ends with the
selection of the nomcom from that volunteer pool. Evaluation of the
experiment will be done after the selection process of the formed nomcom
completes."

Otherwise - go for it!

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Thu, 7 Apr 2016 22:06:11 +0000

Looks pretty good.

There's a fourth possible outcome: we've gathered enough information from the experiment that we know what we want to do and don't need to re-run another experiment in order to revise 7437.

Tony

From: ietf <[email-masked]<mailto:[email-masked]>> on behalf of "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 7, 2016 at 5:21 PM
To: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>
Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>, ietf <[email-masked]<mailto:[email-masked]>>
Subject: Re: Qualifying for NomCom

On Thu, Apr 7, 2016 at 6:09 PM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
On 08/04/2016 08:52, Michael Richardson wrote:
...

   Brian

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Apr 2016 19:08:26 -0300

On Thu, Apr 7, 2016 at 6:57 PM, Harald Alvestrand <[email-masked]>
wrote:

> - Scope objections and aborts to the time between the announcement of the
> final list of volunteers and the selection of the comittee. This closes the
> loophole that the powers-that-be can look at the selected nomcom, say "we
> don't like this group", and force a re-selection by spuriously objecting.
>

OK.

> grammatical, I think - in particular, it starts and ends at the same time.

The NomCom is no longer constituted when it dissolves, which is what I
meant by that.  But I can be more explicit.

> experiment will be done after the selection process of the formed nomcom

We might be splitting hairs, but to my mind, the experiment continues
beyond the seating of the NomCom, because that NomCom was formed under the
terms of the experiment; so the experiment truly ends when that NomCom
completes its obligations and dissolves.

> Otherwise - go for it!

I'll fold the above in.  Any other feedback?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Apr 2016 19:09:19 -0300

On Thu, Apr 7, 2016 at 7:06 PM, HANSEN, TONY L <[email-masked]> wrote:

>
> There's a fourth possible outcome: we've gathered enough information from
> the experiment that we know what we want to do and don't need to re-run
> another experiment in order to revise 7437.
>

Isn't that the same as the first outcome?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Apr 2016 19:55:49 -0300

On Thu, Apr 7, 2016 at 7:20 PM, HANSEN, TONY L <[email-masked]> wrote:

> No, outcome 1 says to use the criteria in section 2 directly as specified
> there. Outcome 4 lets us twiddle it.
>

Wouldn't we want to repeat the experiment with the twiddling before making
it part of the BCP?  That's outcome 2.

-MSK

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Thu, 7 Apr 2016 22:20:51 +0000

No, outcome 1 says to use the criteria in section 2 directly as specified there. Outcome 4 lets us twiddle it.

Tony

From: "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 7, 2016 at 6:09 PM
To: Tony Hansen <[email-masked]<mailto:[email-masked]>>
Cc: ietf <[email-masked]<mailto:[email-masked]>>
Subject: Re: Qualifying for NomCom

On Thu, Apr 7, 2016 at 7:06 PM, HANSEN, TONY L <[email-masked]<mailto:[email-masked]>> wrote:

-MSK

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Fri, 8 Apr 2016 02:27:51 +0000

I don't know. It seems like it depends on the outcome of the experiment as to what the next step should be. It may be obvious at that point what the answer should be, but not what was specified in section 2. I don't want us to be overly constrained in our choices.

There's actually another choice that is not specified: it was a mistake to do this experiment and that the rules should remain the same as they are now and not change.

Here's my formulation of the 4 choices:

*) We learned enough to say that no change need to be made to the current rules.
*) We learned some things and need to run another experiment with different parameters.
*) We learned enough to know what the change to the current rules is that needs to be made, either
-) as specified in section 2 or
-) some other formulation.

Tony

Date: Thursday, April 7, 2016 at 6:55 PM

On Thu, Apr 7, 2016 at 7:20 PM, HANSEN, TONY L <[email-masked]<mailto:[email-masked]>> wrote:
No, outcome 1 says to use the criteria in section 2 directly as specified there. Outcome 4 lets us twiddle it.

Wouldn't we want to repeat the experiment with the twiddling before making it part of the BCP?  That's outcome 2.

-MSK

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Apr 2016 07:41:12 -0300

ISTM that regardless of how the questions are phrased, this experiment is rigged to succeed. 

Because of the confidentiality requirements, all the information we are likely to get will be from a report by the NomCom chair, and even that is going to be sanitized to such a degree that it won’t tell us anything.

So anything short of the NomCom appointing 7 marketing types to the IESG who will promptly replace all WG chairs with supermodels to “improve the image of the IETF” is going to be considered a failure of this experiment. The overwhelmingly most likely outcome is “We ran the experiment, nothing horrible happened, no issue with extending this forever”. Besides, the work of the NomCom cannot be evaluated when they complete their work. We have to evaluate them by what their appointees do, and that’s a couple of more years in the future.

Yoav

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 8 Apr 2016 07:54:59 -0300

On Fri, Apr 8, 2016 at 7:41 AM, Yoav Nir <[email-masked]> wrote:

> [...]

Do you have any suggestions?

-MSK

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Apr 2016 09:59:45 -0400

> http://blackops.org/~msk/draft-kucherawy-nomcom-procexp.txt

okay, this is very very open.
As a 3933 experiment, I think we can do this.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Apr 2016 10:00:58 -0400

So, we'll know by August if the experiment resulted in more volunteers.

My only concern is that we decide it was ineffective in getting more diverse
volunteers,  and stop; but it might have needed more than 1 year to socialize
the ideas out there.

A result might also be: the new rules cause no harm and should be kept until
such time we have more data.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Apr 2016 11:06:51 -0300

There are some issues here.   First, who can challenge a nomcom volunteer's
elegibility?   Second, what process is followed if their eligibility is
challenged?   This actually seems a lot harder than some of the other
proposals that were put forth, which simply extended eligibility of the
same type to more IETF participants, rather than creating two classes of
IETF participants.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 08 Apr 2016 15:19:10 +0000

On Fri, Apr 8, 2016, 11:08 Ted Lemon <[email-masked]> wrote:

> There are some issues here.   First, who can challenge a nomcom
> volunteer's elegibility?
>

Anyone, I think. RFC7437 talks about it.

  Second, what process is followed if their eligibility is challenged?

I think that's unspecified; the Chair just has to resolve the issue
somehow.

  This actually seems a lot harder than some of the other proposals that
> were put forth, which simply extended eligibility of the same type to more
> IETF participants, rather than creating two classes of IETF participants.
>

Anything more specific seems to create a lot of burden for the a chair who
has to manually vet every applicant in terms of their contributions (which,
I bet, I'd at least as painful as determining consensus on something), and
it can introduce bias. Putting that burden on the community instead seems a
better approach.

-MSK

---

From: Lucy Lynch <[email-masked]>
Date: Fri, 8 Apr 2016 15:21:40 +0000 (UTC)

> same type to more IETF participants, rather than creating two classes of

Thanks Ted -

As the incoming NomCom chair I have some concerns about how exercising 
judgment can scale to possible requests. The current selection and vetting 
process already includes a lot of steps and processing - if you want to 
add a layer here I'd like to feel confident that this was something the 
community really wanted and that the proposed vetting wouldn't leave those 
executing exposed to second guessing after the fact.

- Lucy