Subject: Consolidating BCP 10 (Operation of the NomCom)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 3 Sep 2014 23:09:34 -0700

Colleagues,

As part of my work with NomCom '14, I'm preparing a revision of RFC3777
that incorporates all of the updates made to it subsequent to its
publication ten years ago.  This would roll all of the documents making up
the NomCom's definition and procedures into one place.

The draft is available here:

https://datatracker.ietf.org/doc/draft-kucherawy-rfc3777bis/

It is at present nothing more than a republishing of RFC3777 verbatim, with
some slight organization adjustments that come along with conversion to
xml2rfc (RFC3777 was done in nroff), and all of the changes made by the
other documents that currently comprise BCP 10 have been incorporated.
There have been no other substantive content changes made.

My plan is to keep it that way for this go-around.  Then, if the community
would like to actually crack open the document and revisit some of the
content, that would be a second project (for which I would probably
volunteer to act as editor).

Comments welcome.

-MSK, hatless

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Sep 2014 01:49:07 +0300

Murray,

> https://datatracker.ietf.org/doc/draft-kucherawy-rfc3777bis/

Thank you very much for writing this.

I have reviewed the draft, with the main goal of checking that the material from 3777 and other RFCs all came through. This was a bit tough, given the amount of source RFCs and text re-organisation.

Here’s the plain comparison to the RFC http://tools.ietf.org/rfcdiff?url2=draft-kucherawy-rfc3777bis-00.txt 

To ease my comparison, I also made a collection-of-RFCs vs. your draft comparison: http://www.arkko.com/ietf/gen/draft-kucherawy-rfc3777bis-00-from-rfc-3777-and-updates.diff.html I changed some of the formatting and aligned section numbering. Still, formatting changes result in the diff highlighting some changes when there are no changes. And I didn’t apply the changes from RFC 5078, but they are easy to see in Appendix C.

Overall, I am very happy with draft and did not spot any big issues. In particular, I did not find anything that you had missed or incorrectly copied. I did have a couple of comments, however:

Section 5.12 seems to have text that relates to pre-RFC5680 situation:

   The consultations are permitted to include names of nominees, if all
   parties to the consultation agree to observe the same confidentiality
   rules as the nominating committee itself.

Shouldn’t this be changed? Or am I missing something?

Section 3, item 3:

   One-half of each of the then current IESG and IAB positions is
   selected to be reviewed each year.

Strictly speaking, exactly half of the IESG is never selected, with 15 members. Or at least I hope you are not selecting half of the chair every year :-) You do note the odd number of members exception later in the text, but it still felt weird. I’d just say “approximately half” consistently under this item. There is a similar occurrence under the next item as well.

Finally, I do think having one source for the most recent version of RFC 3777 and its updates is very useful. I’d like to encourage reviews of this draft, as we do want to make sure all the details are right.

Jari

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 12 Sep 2014 16:15:14 -0700

On Fri, Sep 12, 2014 at 3:49 PM, Jari Arkko <[email-masked]> wrote:

> To ease my comparison, I also made a collection-of-RFCs vs. your draft
> comparison:
> http://www.arkko.com/ietf/gen/draft-kucherawy-rfc3777bis-00-from-rfc-3777-and-updates.diff.html
> I changed some of the formatting and aligned section numbering. Still,
> formatting changes result in the diff highlighting some changes when there
> are no changes. And I didn’t apply the changes from RFC 5078, but they are
> easy to see in Appendix C.
>

Wow, thanks for taking the time to do that.  I had a feeling I'd be asked,
and I was dreading the task.  :-)

>
> Overall, I am very happy with draft and did not spot any big issues. In
> particular, I did not find anything that you had missed or incorrectly
> copied. I did have a couple of comments, however:
>
> Strictly speaking, exactly half of the IESG is never selected, with 15
> members. Or at least I hope you are not selecting half of the chair every
> year :-) You do note the odd number of members exception later in the text,
> but it still felt weird. I’d just say “approximately half” consistently
> under this item. There is a similar occurrence under the next item as well.
>

Thanks, I'll review both of these this weekend and post an update or at
least a reply.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 12 Sep 2014 16:51:02 -0700

Jari.

> Shouldn’t this be changed? Or am I missing something?

As I read this, "consultations" refers to meetings between a NomCom member
and a community member that might have comments about specific candidates,
not a list or short list of eligible candidates.  Unless I've misunderstood
RFC5680, there's been no change to the confidentiality of those
conversations, so that paragraph stands correct as-is.

What did you have in mind here?

-MSK

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 12 Sep 2014 20:35:18 -0500

Hi, Murray,

On 09/04/2014 01:09 AM, Murray S. Kucherawy wrote:
> Colleagues,
>
> As part of my work with NomCom '14, I'm preparing a revision of 
> RFC3777 that incorporates all of the updates made to it subsequent to 
> its publication ten years ago.  This would roll all of the documents 
> making up the NomCom's definition and procedures into one place.
>
> It is at present nothing more than a republishing of RFC3777 verbatim, 
> with some slight organization adjustments that come along with 
> conversion to xml2rfc (RFC3777 was done in nroff), and all of the 
> changes made by the other documents that currently comprise BCP 10 
> have been incorporated.  There have been no other substantive content 
> changes made.
>
> My plan is to keep it that way for this go-around. Then, if the 
> community would like to actually crack open the document and revisit 
> some of the content, that would be a second project (for which I would 
> probably volunteer to act as editor).
>
> Comments welcome.

Thank you for doing this work. It looks good. I know that wasn't easy 
because every word matters :-)

I have some comments you may wish to consider.

--

This isn't text you changed in this revision, but it jumped out at me 
for the first time.

3.2.  Nominating Committee Principal Functions

    The principal functions of the nominating committee are to review
    each open IESG, IAB, and IAOC position and to nominate either its
                                               ^^ ^^^^^^^^
    incumbent or a superior candidate.

That text hasn't changed since http://tools.ietf.org/html/rfc2027 in 
October 1996.

I've always tried to use "nominee" to describe Nomcom inputs, and 
"candidate" to describe Nomcom outputs. That's the way I read the 
definitions, anyway.

The previous section correctly calls what Nomcom is doing "selection of 
candidates", as in

3.1.  Completion Due

(deleted down to)

    The annual process is comprised of three major components as follows:

    1.  The selection and organization of the nominating committee
        members.

    2.  The selection of candidates by the nominating committee.
            ^^^^^^^^^ ^^ ^^^^^^^^^^
    3.  The confirmation of the candidates.

I know this is supposed to be as small a revision as possible, but if 
the two descriptions really do conflict, and you don't want to preserve 
the conflict, I'd suggest "to select either its incumbent or a superior 
nominee as the candidate".

--

3.7.1.  Positions To Be Reviewed

deleted down to

    The IESG, IAB, and IAOC are responsible for providing summary of the
                                              "summaries" ^^^^^^^
    expertise desired of the candidates selected for their respective
    open positions to the Executive Director.  The summaries are provided
    to the nominating committee for its consideration.

--

4.13.  Open Positions

    The Chair (or the IETF Executive Director, if no Chair has been named
    four weeks after the first IETF meeting of the year) obtains the list
    of positions to be reviewed and announces it along with a
    solicitation for names of volunteers from the IETF community willing
    to serve on the nominating committee.

    If the IETF Executive Director issues the solicitation for
    volunteers, the IETF Executive Director must also collect responses
    to the solicitation and provide the names of volunteers to the
    incoming nominating committee Chair when the incoming nominating
    committee Chair is named.

 >   At the Chair's request, the IETF Secretariat may perform other
 >   clerical support tasks, as long as the task being performed does not
 >   require nominating committee Chair judgment, in the nominating
 >   committee Chair's opinion, and as long as the community is
 >   appropriately notified that this request is being made.  This request
 >   may come from the incoming nominating committee Chair (if one has
 >   been selected for this nominating committee cycle) or the previous
 >   nominating committee Chair (if the search for an incoming nominating
 >   committee Chair is still underway).

I was probably the one who put this paragraph where it is, but on 
reflection, it really has nothing to do with the rest of the section. 
Maybe move it to its own section about "Other Duties Performed by the 
IETF Secretariat"?

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 12 Sep 2014 20:47:16 -0500

On 09/12/2014 06:51 PM, Murray S. Kucherawy wrote:
> Jari.
>
> On Fri, Sep 12, 2014 at 3:49 PM, Jari Arkko <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
> As I read this, "consultations" refers to meetings between a NomCom 
> member and a community member that might have comments about specific 
> candidates, not a list or short list of eligible candidates.  Unless 
> I've misunderstood RFC5680, there's been no change to the 
> confidentiality of those conversations, so that paragraph stands 
> correct as-is.

I'm not Jari, of course, but I think Jari's point is that of course the 
consultations can include the names if they've already been disclosed as 
part of a call for feedback. So I agree that it's weird.

I usually forget that sending a list of nominees for feedback is a may, 
not a must:

    The nominating committee may disclose a list of names of nominees who
    are willing to be considered for positions under review to the
    community, in order to obtain feedback from the community on these
    nominees.

So any particular Nomcom may not have disclosed its list.

Perhaps it would be useful for this text to say "Even if the nominating 
committee has not previously disclosed a list of nominees, the 
consultations can include these names".

Does that help?

Spencer

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Sep 2014 10:03:29 +0300

On 13 Sep 2014, at 02:51, Murray S. Kucherawy <[email-masked]> wrote:

> As I read this, "consultations" refers to meetings between a NomCom member and a community member that might have comments about specific candidates, not a list or short list of eligible candidates.  Unless I've misunderstood RFC5680, there's been no change to the confidentiality of those conversations, so that paragraph stands correct as-is.
> 

Indeed, RFC 5680 changed only the list to be open, not the feedback that people send.

I guess I had some trouble understanding what the text specifically says. Your read of the meaning is fine, inline with RFC 5860 and exactly what should happen. 

But it was not so clear to me. The consultations might also refer to the general desired expertise question which text preceding this text talks about. In that case names of candidates shouldn’t even come to the picture. 

The way I read the paragraph is that it talks about what we used to do: send list of names to some selected set of community members, and get back feedback.  If this is the correct reading, then maybe the text should change. But perhaps my point is that the text can be read in different ways.

But maybe I’m the only one getting confused, and if so, that’s fine. I don’t know if we want to make any clarifications (even editorial) in this republication of the BCP, but if I were to write the text from scratch today, I’d say:

   The consultations are permitted to include names of nominees, if all
   parties to the consultation agree to observe the same confidentiality
   rules as the nominating committee itself, or the names are public as
   discussed in Section 3.6. Feedback on individual nominees should
   always be confidential.

Jari

---

From: Michael StJohns <[email-masked]>
Date: Sat, 13 Sep 2014 14:46:53 -0400

At 02:09 AM 9/4/2014, Murray S. Kucherawy wrote:
>Colleagues,
>
>As part of my work with NomCom '14, I'm preparing a revision of RFC3777 that incorporates all of the updates made to it subsequent to its publication ten years ago.Â  This would roll all of the documents making up the NomCom's definition and procedures into one place.
>
><https://datatracker.ietf.org/doc/draft-kucherawy-rfc3777bis/>https://datatracker.ietf.org/doc/draft-kucherawy-rfc3777bis/
>
>It is at present nothing more than a republishing of RFC3777 verbatim, with some slight organization adjustments that come along with conversion to xml2rfc (RFC3777 was done in nroff), and all of the changes made by the other documents that currently comprise BCP 10 have been incorporated.Â  There have been no other substantive content changes made.
>
>My plan is to keep it that way for this go-around.Â  

Hi Murray - 

Until I read the "for this go around" sentence, I was actually hoping someone was opening this up for a comprehensive revision.

Here's what I think needs to happen (prior to the next IETF nomcom selection):

1) Update 3777 to merge in the various changes that have been posted. (this rev)
2) Add text to fix the revealed-broken recall process
3) Add text to fill out what constitutes a vacancy.  E.g. 
    a) Vacancy by term completion
    b) Vacancy by resignation
    c) Vacancy by death or incapacity
    d) Vacancy by recall
    e) Vacancy by expulsion 
4) Add text to fix disconnects between what the Nomcom and the confirming bodies believe to be true with respect to:
   a) what is and is not confidential about a candidate with respect to the confirming body
   b) what MUST be provided to the confirming bodies
   c) what MAY be provided
   d) what must be provided to the nomcom by the confirming body on rejection of candidates (my take, simply the fact of rejection)
   e) that the rejection of a candidate is NOT a failure of process.
5) [This one is one of my hot buttons, but is somewhat controversial.  It's based  in part on my belief that the "we all participate as individuals, rather than members of company" trope is no longer even minimally true, especially for more recent participants.] Rework the Nomcom selection process to minimize the statistical affects of one or more companies each comprising large portions of the Nomcom volunteer pool. [Statistically,  if a company has 30% of the volunteers, they have an 85% chance of having 2 nomcom members, a 97% chance of having at least 1].

Item's 2, 3 and 4 are fixes  for events (failures of process) that have happened since the publication of 3777.

With respect to 5 - the text in 3777 is that the selection process should be fair - which is defined to mean:  "A method is fair if each eligible volunteer is equally likely to be selected."  That definition is already broken in that we cap the number of nomcom members from any given company at 2 - which means that anyone in a large company already has a lesser chance of selection then that represented by his portion of the volunteer pool. I think we benefit from diversity of opinion, and even more from diversity of experience. I'm concerned that the Nomcom has been at times rather over populated with large company representatives with a related narrowing of the experience pool. 

>Then, if the community would like to actually crack open the document and revisit some of the content, that would be a second project (for which I would probably volunteer to act as editor).

See above.  I don't think you actually gain anything by splitting this into two stages as the text from the roll up revision is going to need to change; going through the process - twice - to move revisions to RFC seems to be to be a waste of effort.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Sep 2014 08:23:13 +1200

On 13/09/2014 19:03, Jari Arkko wrote:
...
>    discussed in Section 3.6. Feedback on individual nominees should

I'm all for this clarification. I don't believe it's a change in intent,
so it's fine as part of a clean-up pass.

Maybe s/should/must/ in the last sentence.

   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 13 Sep 2014 19:20:42 -0400

It may (or may not) make sense to examine all of the issues you list.
It seems to me the next thing to certain that the work will not even be 
completed by the time the next nomcom is seated.

Might it make sense to follow the original proposal first, and just ge 
the current procedures as understood documented in one place.  And make 
sure that is correct, before embarking on changes?

Yours,
Joel

On 9/13/14, 2:46 PM, Michael StJohns wrote:
>> its publication ten years ago.Â  This would roll all of the documents
>> have been incorporated.Â  There have been no other substantive content
>> changes made.
>>
> Until I read the "for this go around" sentence, I was actually hoping
> someone was opening this up for a comprehensive revision.
>
> 4) Add text to fix disconnects between what the Nomcom and the
> confirming bodies believe to be true with respect to:
>     d) what must be provided to the nomcom by the confirming body on
> rejection of candidates (my take, simply the fact of rejection)
> 5) [This one is one of my hot buttons, but is somewhat controversial.
> It's based  in part on my belief that the "we all participate as
> individuals, rather than members of company" trope is no longer even
> minimally true, especially for more recent participants.] Rework the
> Nomcom selection process to minimize the statistical affects of one or
> more companies each comprising large portions of the Nomcom volunteer
> pool. [Statistically,  if a company has 30% of the volunteers, they have
> an 85% chance of having 2 nomcom members, a 97% chance of having at
> least 1].
>
>
> With respect to 5 - the text in 3777 is that the selection process
> should be fair - which is defined to mean:  "
>
> A method is fair if
> each eligible volunteer is equally likely to be selected."
> That definition is already broken in that we cap the number of nomcom
> members from any given company at 2 - which means that anyone in a large
> company already has a lesser chance of selection then that represented by
> his portion of the volunteer pool.
>
> I think we benefit from diversity of opinion, and even more from
> diversity of experience. I'm concerned that the Nomcom has been at times
> rather over populated with large company representatives with a related
> narrowing of the experience pool.
>
>
>> Then, if the community would like to actually crack open the document
>> and revisit some of the content, that would be a second project (for
>> which I would probably volunteer to act as editor).
>
> See above.  I don't think you actually gain anything by splitting this
> into two stages as the text from the roll up revision is going to need
> to change; going through the process - twice - to move revisions to RFC
> seems to be to be a waste of effort.
>
> Mike
>
>
>
>
>> Comments welcome.
>>
>> -MSK, hatless
>

---

From: Michael StJohns <[email-masked]>
Date: Sat, 13 Sep 2014 20:06:44 -0400

At 07:20 PM 9/13/2014, Joel M. Halpern wrote:
>It seems to me the next thing to certain that the work will not even be completed by the time the next nomcom is seated.
>
>Might it make sense to follow the original proposal first, and just ge the current procedures as understood documented in one place.  And make sure that is correct, before embarking on changes?

As far as I understand, Murray is proposing "no change in effective behavior" in the first pass, so whether or not we manage to get an RFC through before the next nomcom or not, the publication of a simply updated 3777 is really nothing more than clean up without any change in effect to the current Nomcom, nor in the behavior of any follow-on Nomcom.  

Given that there's a real cost (can you say Last Call?) to the community as a whole for each and every RFC action, I'm underwhelmed at the idea of opening up 3777 without making a commitment to actually address its warts.

That's a long winded way of saying no.  If there were a pressing need for the current Nomcom, I'd suggest they use the "operational discretion" portion of the document.  If there were a well understood set of changes that have been incorporated in practice, but not in documentation, I *might* say yes.  Neither of these appear to apply - hence, "No".

To be blunt, we're already... *sigh* splitting nits about the meaning of certain sections, words, word combinations, etc.  I'd really rather not go through that more than once every 5 years or so.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 13 Sep 2014 20:01:27 -0700

On Sat, Sep 13, 2014 at 1:23 PM, Brian E Carpenter <
[email-masked]> wrote:

> > But maybe I’m the only one getting confused, and if so, that’s fine. I
> don’t know if we want to make any clarifications (even editorial) in this
> republication of the BCP, but if I were to write the text from scratch
> today, I’d say:
> >

That all sounds good to me.  I'll do it in -01.

Thanks!

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 13 Sep 2014 22:09:46 -0700

On Sat, Sep 13, 2014 at 5:06 PM, Michael StJohns <[email-masked]>
wrote:

> As far as I understand, Murray is proposing "no change in effective
> behavior" in the first pass, so whether or not we manage to get an RFC
> through before the next nomcom or not, the publication of a simply updated
> 3777 is really nothing more than clean up without any change in effect to
> the current Nomcom, nor in the behavior of any follow-on Nomcom.
>

Correct, that's the intent.

> Given that there's a real cost (can you say Last Call?) to the community
> as a whole for each and every RFC action, I'm underwhelmed at the idea of
> opening up 3777 without making a commitment to actually address its warts.
>

On the other hand, isn't the cost of an IETF Last Call on what amounts to
consolidation of already-approved documents, and nothing else, a fair bit
less than the real cost of a typical IETF Last Call on new, updated, or
otherwise not-yet-approved work?  Given the no changes constraint, the Last
Call reviewers only need to confirm that the consolidation was done
correctly and the result is still understandable.  There's nothing new to
debate here.

> That's a long winded way of saying no.  If there were a pressing need for
> the current Nomcom, I'd suggest they use the "operational discretion"
> portion of the document.  If there were a well understood set of changes
> that have been incorporated in practice, but not in documentation, I
> *might* say yes.  Neither of these appear to apply - hence, "No".
>

I'm on the current NomCom (and was on the last one too), and I think it
would be reasonable for me to say that both of them sure thought it would
be nice to have had this work done ahead of time.  I wouldn't say it's a
pressing need, but if one NomCom after the next seems to have the same
sentiment, then it's probably work that's due or even past due.

> To be blunt, we're already... *sigh* splitting nits about the meaning of
> certain sections, words, word combinations, etc.  I'd really rather not go
> through that more than once every 5 years or so.
>

By that reasoning, it's time, since RFC3777 is more than ten years old and
all but one of the applied updates are at least five years old.  I suggest
that doing this first will make it easier to do the follow-on work you're
suggesting, especially since a diff to this document (when published), and
thus to the true current practice, will be very easy to generate.

-MSK

---

From: Michael StJohns <[email-masked]>
Date: Sun, 14 Sep 2014 17:12:38 -0400

At 01:09 AM 9/14/2014, Murray S. Kucherawy wrote:
>On Sat, Sep 13, 2014 at 5:06 PM, Michael StJohns <<mailto:[email-masked]>[email-masked]> wrote:
>Â 
>On the other hand, isn't the cost of an IETF Last Call on what amounts to consolidation of already-approved documents, and nothing else, a fair bit less than the real cost of a typical IETF Last Call on new, updated, or otherwise not-yet-approved work?Â  Given the no changes constraint, the Last Call reviewers only need to confirm that the consolidation was done correctly and the result is still understandable.Â  There's nothing new to debate here.

Have you see an IETF Last Call (humorous rhetorical question)?  More seriously, I appreciate your optimism, but empirical evidence  (e.g. the 5 or 6 messages with language changes for your draft, as well as every other Last Call in recent history) would suggest that the chances of getting this through last call without pain are slender if not non-existent.

>Â 
>That's a long winded way of saying no.Â  If there were a pressing need for the current Nomcom, I'd suggest they use the "operational discretion" portion of the document.Â  If there were a well understood set of changes that have been incorporated in practice, but not in documentation, I *might* say yes.Â  Neither of these appear to apply - hence, "No".
>
>
>I'm on the current NomCom (and was on the last one too), and I think it would be reasonable for me to say that both of them sure thought it would be nice to have had this work done ahead of time.Â  I wouldn't say it's a pressing need, but if one NomCom after the next seems to have the same sentiment, then it's probably work that's due or even past due.

Instead, let me suggest you do the above - but to a specific ID stage.  Let the/a Nomcom adopt the operations section of a specific ID as part of their 3777 permitted operational discretion.   That deals with the Nomcom's particular problems without the need to deal with the RFC process.

It also leaves the clock ticking as each ID expires after 6 months.  That will ensure that instead of just saying "its good enough" we have incentive to go ahead and fix the issues that have occurred.

>Â 
>To be blunt, we're already... *sigh* splitting nits about the meaning of certain sections, words, word combinations, etc.Â  I'd really rather not go through that more than once every 5 years or so.
>
>
>By that reasoning, it's time, since RFC3777 is more than ten years old and all but one of the applied updates are at least five years old.Â  I suggest that doing this first will make it easier to do the follow-on work you're suggesting, especially since a diff to this document (when published), and thus to the true current practice, will be very easy to generate.

We didn't open up 3777 to add the interim fixes because it was "too hard".  If we're not going to open 3777 up for substantive changes, then I see no reason to publish what is nothing more than a cosmetic reworking of existing and documented practice.    It's work for the editor, but more than that its work for the RFC staff, for the IESG, for the IAOC and for the IAB (yup - all have to sign off on it).

Instead, let's do it the right way.  Get the Chairs (IAB, IETF and IAOC) to appoint a design team in the general area and provide a page or two of things they think need to be fixed.  Solicit the community for any other issues.  Draft the first public version of the document to be feature complete for those issues and have text for each approach to solving each identified problem. 

>-MSK

I do understand the desire to take small bites - I just think you're trying to solve your first problem (Nomcom process) the wrong way.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Sep 2014 15:26:22 -0700

On 9/14/2014 2:12 PM, Michael StJohns wrote:
>> On the other hand, isn't the cost of an IETF Last Call on what amounts
>> to consolidation of already-approved documents, and nothing else, a
>> fair bit less than the real cost of a typical IETF Last Call on new,
>> updated, or otherwise not-yet-approved work?Â  Given the no changes
>> constraint, the Last Call reviewers only need to confirm that the
>> consolidation was done correctly and the result is still
>> understandable.Â  There's nothing new to debate here.
> 
> Have you see an IETF Last Call (humorous rhetorical question)?  More
> seriously, I appreciate your optimism, but empirical evidence 

Sadly, Mike is being pragmatically accurate in his concern/prediction.

> Instead, let me suggest you do the above - but to a specific ID stage. 
> Let the/a Nomcom adopt the operations section of a specific ID as part
> of their 3777 permitted operational discretion.   That deals with the
> Nomcom's particular problems without the need to deal with the RFC process.

This seems both useful and efficient.  Sometimes we do allow that
combination in the IETF.

In formal terms, it lets the Nomcom be the sole deciding group for its
own use of a consolidation version, while letting the full IETF
community then pursue corrections and enhancements.

> I do understand the desire to take small bites - I just think you're
> trying to solve your first problem (Nomcom process) the wrong way.

Within a group that has better working processes, the small-bites model
works well.  However as much as we might wish the IETF qualifies, it
doesn't.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Sep 2014 08:39:20 -0400

Michael StJohns <[email-masked]> wrote:
    >> the current procedures as understood documented in one place.  And
    >> make sure that is correct, before embarking on changes?

    > through before the next nomcom or not, the publication of a simply
    > updated 3777 is really nothing more than clean up without any change in
    > effect to the current Nomcom, nor in the behavior of any follow-on
    > Nomcom.

The idea was a clean up, no significant changes.

For instance, it turns out that you have to read very carefully to determine
that the IRTF chair is not eligible for nomcom, because the IRTF chair
is an ex-officio member of the IAB, and IAB members, including ex-officio
are not eligible.  It would be nice to include that conclusion explicitely.
I think that text about that should be included, and I'll propose some to
Murray.

On the other hand, it appears that both ISOC and AMSL (secretariat) employees
are nomcom eligible.  It's not clear that they should be; changing that
would require some additional thinking, and I would not propose any change.

    > That's a long winded way of saying no.  If there were a pressing need
    > for the current Nomcom, I'd suggest they use the "operational
    > discretion" portion of the document.  If there were a well understood
    > set of changes that have been incorporated in practice, but not in
    > documentation, I *might* say yes.  Neither of these appear to apply -
    > hence, "No".

The risk is a failure to pass on enough oral tradition from one nomcom chair
to another;  this results in proceedural mistakes due to mis-reading.  Being
consistent to what we wrote down is pretty important in my opinion.

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Sep 2014 00:11:11 +0300

FWIW, my opinion is that Murray and Michael R have got it right. Having a stable basis is a good thing to have for any real updates, and a good project management practice. As a datapoint, it took me a while to understand the different changed pieces and their effects, even with Murray’s document already pointing to the updates.

And I am optimistic about completing last calls, particularly when their scope is cleaning up / editorial. The substantive changes last calls then again may take longer - and perhaps rightly so. I do think Michael S’s list is a good project to complete as well, however.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Sep 2014 00:32:59 +0300

Michael,

Your list is good and worth working on. Thank you!

I do have some comments and questions though.

> 2) Add text to fix the revealed-broken recall process

Remind me what this is about.

>     c) Vacancy by death or incapacity

Seems reasonable. What are you thinking of under e)?

>    e) that the rejection of a candidate is NOT a failure of process.

Agree about e). It can be that the confirming body simply has more information. And I understand that items a) through d) have been a source of discussion between nomcom and the confirming bodies in some cases. However, I am wondering if we can specify useful, general rules about what must be provided. Is there a working practice that we believe could be taken on?

> 5) [This one is one of my hot buttons, but is somewhat controversial.  It's based  in part on my belief that the "we all participate as individuals, rather than members of company" trope is no long…

I do think the IETF still has a lot of individual opinion and “best for the internet” flavour in it. But we all are coloured by our affiliations and other associations. Some to smaller, some to greater extent. Not sure we should label the recent participants in this respect any more than others. 

In any case, I agree with your point about needing to shield the nomcom for over-extended influence from any particular party. The question is of course if there’s anything we can do about it. Do you have a suggestion?

Reading on…

> With respect to 5 - the text in 3777 is that the selection process should be fair - which is defined to mean:  "
> A method is fair if
> I think we benefit from diversity of opinion, and even more from diversity of experience. I'm concerned that the Nomcom has been at times rather over populated with large company representatives with a related narrowing of the experience pool. 

I’d argue that 2 out of 10 is not necessarily a big problem. But are you concerned about that, or are you concerned there might be cases where closely associated entities can circumvent the limit of 2, or are you concerned that the nomcom volunteers to a too large extent consists of commercial vendors?

There might be ways to tackle some of these issues, but the solutions are different depending on which problem you want to address.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Sep 2014 09:45:28 +1200

Jari,

On 16/09/2014 09:32, Jari Arkko wrote:
...
> I’d argue that 2 out of 10 is not necessarily a big problem. But are you concerned about that, or are you concerned there might be cases where closely associated entities can circumvent the limit o…

The worst case, which is not a fantasy, is that 5 large companies encourage
their staff to volunteer, so we end up with 5 pairs of large-company
staff and nobody from the rest of the community. But (as Mike seems to
imply) if we put in rules to make this impossible, we'd be even further
from "each eligible volunteer is equally likely to be selected."
So this does need clarity of intent, one way or the other.

   Brian

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Sep 2014 14:46:25 -0700

> So this does need clarity of intent, one way or the other.

Make it max 1 per company.

Real and substantial diversity is essential.

If we cannot get an adequate nomcom on that basis, we've got bigger
problems and nomcom selection isn't the place to try to solve it.

d/

---

From: Mary Barnes <[email-masked]>
Date: Mon, 15 Sep 2014 16:56:19 -0500

> problems and nomcom selection isn't the place to try to solve it.

[MB] I totally agree with Dave.  I think that also helps in that people
that are from bigger companies often have the most people that are willing
and more importantly able to fill the positions. Thus, this also reduces
the potential appearance of bias in terms of voting members favoring
nominees from their own companies. [/MB]

---

From: Doug Barton <[email-masked]>
Date: Mon, 15 Sep 2014 15:18:52 -0700

On 9/15/14 2:56 PM, Mary Barnes wrote:
>
>
> On Mon, Sep 15, 2014 at 4:46 PM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> that are from bigger companies often have the most people that are
> willing and more importantly able to fill the positions. Thus, this also
> reduces the potential appearance of bias in terms of voting members
> favoring nominees from their own companies. [/MB]

Are y'all talking about the input to the nomcom process, or the output? 
I don't see anything wrong with more than one candidate per company 
putting their name in the hat, but it's probably reasonable to limit the 
number of qualified applicants that go into the final selection process.

OTOH, how do you define "a company" in this scenario? Take any of the 
large multinationals .... is it fair to eliminate a candidate because 
there is another qualified candidate who happens to work at the same 
"company," even though they are in different business units, different 
states, different countries, or even different continents?

I totally agree with the need to avoid capture of the IETF leadership, 
but the problem is a lot harder to solve than you might think. It may be 
worthwhile for our folks who are interested in this topic to have a chat 
with the ICANN folks about policies and methodology that are in place 
there, as avoiding industry capture has been an important part of their 
working process since day 1, and a lot of thought has gone into it.

Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Sep 2014 10:29:16 +1200

> Make it max 1 per company.

So how would you modify the assertion in quotes, which is
already untrue with the 2 per company rule?

> Real and substantial diversity is essential.

Agreed. That wasn't my point, though.

   Brian

---

From: Mary Barnes <[email-masked]>
Date: Mon, 15 Sep 2014 17:55:11 -0500

On Mon, Sep 15, 2014 at 5:18 PM, Doug Barton <[email-masked]> wrote:

> Are y'all talking about the input to the nomcom process, or the output? I
> don't see anything wrong with more than one candidate per company putting
> their name in the hat, but it's probably reasonable to limit the number of
> qualified applicants that go into the final selection process.
>
[MB] We're talking about the selection of volunteers to serve as voting
members on the nomcom.  It's a random selection. The current process is
that if a 3rd volunteer is on the list of 10, the last one selected is
dropped and then whoever ended up in position 11 of the random selection
would become a voting member.  [/MB]

> large multinationals .... is it fair to eliminate a candidate because there
> is another qualified candidate who happens to work at the same "company,"
> even though they are in different business units, different states,
> different countries, or even different continents?
>
[MB] Yes, it is a challenge, but it's something we deal with already and
again, we're talking about selection of voting members of the nomcom and
not leadership appointments. At this point, it's entirely up to the nomcom
how many appointees from each company are selected - e.g., some nomcoms
decide that the IESG should have at most 2 people from the same company.
Others have decided 3 is okay. [/MB]

>
> I totally agree with the need to avoid capture of the IETF leadership, but
> the problem is a lot harder to solve than you might think. It may be

[MB] I think most of us know how hard the problem is to solve. It's been
plaguing nomcom for years - see
http://tools.ietf.org/html/draft-barnes-nomcom-report-2009-00.  The reality
is that large companies can afford to have large numbers of people
participate and attend IETF meetings (and thus qualify as voting members of
nomcom) as well as the ability to fund an employee to do nearly full time
work in leadership positions at the IETF. It's my understanding is that
ICANN solves this problem somewhat by providing coverage of travel expenses
for some of the appointments. That's a big deal for independent
consultants.
[/MB]

---

From: Michael StJohns <[email-masked]>
Date: Mon, 15 Sep 2014 22:44:25 -0400

Hi Jari - Thanks for the leading questions.  I'll comment below, but also I've posted http://datatracker.ietf.org/doc/draft-stjohns-alt-3777bis/ which provides suggested text for most of the items I listed below.  I wrote this a while back, but decided there wasn't sufficient interest to open up 3777.  The document is mostly complete - I think I still had to rework the timeline to comply with the interim changes documents.

>Remind me what this is about.

This was related to the painful process we started to implement to resolve the IAOC issue.  Basically, even at the beginning of the process we started finding problems (e.g. petitioner's couldn't serve on the recall committee turned out to have some warts).  I looked at the process as described in 3777 and realized that it would take most of 2 months to complete the process and concluded that a long drawn out process was bad for the IETF.  That led to the text in the above document to shorten various process related actions (selection of the recall committee comes from last nomcom volunteer list as a suggestion).

>Seems reasonable. What are you thinking of under e)?

See the document, basically any member (except the IETF chair) is subject to explusion by a 2/3 vote of the member of their body.  I added a confirmation step requiring 2/3 agreement by the related confirming body - but thinking about it, that may not be appropriate.  Generally, even elected bodies have a way to remove members that are disruptive, or are in violation of law or general standards of behavior.

The IETF chair exception is that he/she is chair of all the actions of the IETF, not just the IESG as a body.  Recall is still available and more appropriate.

>Agree about e). It can be that the confirming body simply has more information. And I understand that items a) through d) have been a source of discussion between nomcom and the confirming bodies in…

I added  text to the document based on my experiences on both sides of the issue - as a Nomcom chair, past chair and member and as an IAB member.  

In the final analysis, the confirming body, if it fails to get the information it wants/needs, generally has no alternative but to reject the candidate.  Setting expectations on both sides of the information exchange *prior* to getting to that point I think would resolve most of the issues.  I *really* hope to never see this go to mediation again.

>In any case, I agree with your point about needing to shield the nomcom for over-extended influence from any particular party. The question is of course if there’s anything we can do about it. Do yo…

Yup - text in the above document.  Basically, a two stage process.  Stage 1 draws from a pool of company tokens, where a given company has no more than 10% of the pool.  Stage 2 does a draw for each company selected in stage 1 from the pool of volunteers from that company.  The math works out to be about 33%/33%/33% of a given company having 0, 1 or 2 members of the Nomcom.

I did consider the "select only 1 nomcom member from a company" approach (suggested in another message on this thread), but all that does is make it statistically certain (>95%)for any company with about 28% of the nomcom pool to have a member on the nomcom.  I'd really like to remove that certainty.

The approach above is documented as an alternate process in the appendix of the document - like I said, its going to be somewhat controversial to find a workable process.  

>I’d argue that 2 out of 10 is not necessarily a big problem. But are you concerned about that, or are you concerned there might be cases where closely associated entities can circumvent the limit of…

Mostly I think the latter.  As a matter of pragmatism, the folks we select for the various IESG/IAB/IAOC positions are mostly going to be those with good support from their companies.  That's still going to trend towards selecting people from large companies.  Even if we reduce the influence of large companies on the selection process, that's not going to change for things like the IESG, but at least we remove one leg of trends that tend to oligarchical organization behavior.  

There are a lot of ways to muck with the process if you have the "power" of being on the nomcom concentrated in a few large organizations.  While I'm definitely unaware of any horse trading (you select my guy for the Lust Area director and I'll vote for your guy for the Glutton Area director) [I almost used real areas, but realized that could be taken badly....], I'd rather minimize the opportunities for external attacks on our process by reducing the attack surface.

>There might be ways to tackle some of these issues, but the solutions are different depending on which problem you want to address.

Yup.  Have fun reading.  

By the way, the document adds a number of items meant to constrain the process so it completes.  The words "reasonable time" are used way too often IMHO, and there are no good rules for what happens if one of the actors fails to act.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 16 Sep 2014 00:55:56 -0400

>Mostly I think the latter.  As a matter of pragmatism, the folks we select for the various IESG/IAB/IAOC positions are mostly going to be those with good support from their companies.  That's still…

I think I was asleep when writing the above  - instead:

Mostly I think its about too large a representation by large organizations, regardless of their individual foci of commercial, educational, international or state goals.   As a matter of pragmatism, the folks we select for our leadership positions tend to come from large organizations, simply due to the level of support necessary for a participant to be successful in an IETF leadership position.  Changing the selection process for the composition of the Nomcom is realistically NOT going to change that tendency.  What modification of the selection process should do is reduce one of the enablers for oligarchical organizational behavior - specifically like selecting like.  

Mike

---

From: Melinda Shore <[email-masked]>
Date: Mon, 15 Sep 2014 21:35:05 -0800

On 9/15/14 8:55 PM, Michael StJohns wrote:
> Mostly I think its about too large a representation by large
> organizations, regardless of their individual foci of commercial,
> educational, international or state goals.   As a matter of
> pragmatism, the folks we select for our leadership positions tend to
> come from large organizations, simply due to the level of support
> necessary for a participant to be successful in an IETF leadership
> position.  Changing the selection process for the composition of the
> Nomcom is realistically NOT going to change that tendency.  What
> modification of the selection process should do is reduce one of the
> enablers for oligarchical organizational behavior - specifically like
> selecting like.

I think that's correct, and addressing it requires more structural
changes than we're likely to be able to implement any time soon.
But.  I do think there's value in having leadership come from companies
competing with each other, if we're limited to having the leadership
come from large vendors.  It's not only because it helps diffuse
influence, but also because they can be very different organizationally,
and that can be useful (different decision-making and management styles,
for example).

Melinda

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 16 Sep 2014 08:55:43 -0400

> This was related to the painful process we started to implement to resolve the IAOC issue.  Basically, even at the beginning of the process we started finding problems (e.g. petitioner's couldn't s…

I started the only recall process, it started in October and ran into November meeting. 
One of the issues I ran into was “who is nomcom eligible” this is important when a process spans an IETF meeting,  i.e. can someone gain/loose nomcom 
eligibility during the meeting. 
Having people that sign recall petition excluded from the recall committee is double edged sword, it may motivate people to either sign (in order to avoid serving) or refuse to server in the hope of being picked for committee.
I think the suggestion that last set of Nomcom volunteers be used as a group to select from is a good one, but that again gets into the the issue of who is nomcom eligibility 
at the time of appointment. 

The whole set of rules as to who works for the same company are difficult at best to manage, I would like to see them clarified to be 
	- “affiliation at last IETF meeting attended”, 
	- “affiliation on the date of action. 
I had to rule out a person who told me confidentially that they were interviewing a company X which already had max people signing the recall, just to avoid possible 
problem that down the road. 

There is no time limit to collect recall signatures. One month seems reasonable time frame for failing a recall petition. 

On a different note, appointing nomcom in current process depends on having a chair.
Appointing a chair frequently is difficult due to the time commitment that the chair must make. 
I would seriously advocate that we remove from the chair as much work as possible, 
for example anyone can run the selection process.
We can possibly create a position of Nomcom Selector who’s only role is to run the selection process on time during April and May each year.
The same person would be expected to run the selection process if there is need at later times. 
An alternate is to have the secretariat run this process, as there is no magic other than selecting the 
seeds for the program. 

	Olafur

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Sep 2014 10:36:02 -0400

I like Dave's suggestion i.e., reduce the per-company NOMcom appointment
limit to 1 from 2.

It's not a perfect solution, but it's clear, simple to implement, and
the intent is obvious.

Steve

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 16 Sep 2014 16:39:10 +0200

+1

Bert

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 16 Sep 2014 15:21:22 +0000

same here

Mehmet 

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of ext Bert Wijnen (IETF)
> Sent: Tuesday, September 16, 2014 4:39 PM
> To: Stephen Kent; [email-masked]; Brian E Carpenter; Jari Arkko
> Cc: ietf
> Subject: Re: Substantial nomcom procedure updates (Was: Re: Consolidating BCP
> 10 (Operation of the NomCom))
> 
> +1
> 
> Bert
>

---

From: Allison Mankin <[email-masked]>
Date: Tue, 16 Sep 2014 12:16:21 -0400

I support making this change as well.

Someone asked "what is an affiliation"?  Nomcom has already dealt with this
issue in practice; if a person is unclear about their affiliation in
volunteering for the nomcom, they are asked for information before they are
added to the volunteer pool.

Allison (from the perspective of chairing Nomcom last year)

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 16 Sep 2014 17:40:04 +0100

> So this does need clarity of intent, one way or the other.
It would be useful to run the stats to see how close we have ever come 
to that. The affiliations are not on the site so it's difficult to do a 
quick check. My recollection is that we have never seen worse than 2+2, 
and that does not happen every year.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 16 Sep 2014 17:49:43 +0100

On 15/09/2014 23:55, Mary Barnes wrote:
> The reality is that large companies can afford to have large numbers 
> of people participate and attend IETF meetings (and thus qualify as 
> voting members of nomcom) as well as the ability to fund an employee 
> to do nearly full time work in leadership positions at the IETF.

This is becoming less true, particularly the latter statement about I* 
funding. There is a significant transition going on in our industry both 
in terms of the perceived  importance of the IETF vs other forums and 
discretionary funding available to support senior staff on activities 
other than direct product creation.

- Stewart

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Sep 2014 12:53:28 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> I’d argue that 2 out of 10 is not necessarily a big problem. But are
    >> you concerned about that, or are you concerned there might be cases
    >> where closely associated entities can circumvent the limit of 2, or
    >> are you concerned that the nomcom volunteers to a too large extent
    >> consists of commercial vendors?
    >>

    > The worst case, which is not a fantasy, is that 5 large companies
    > encourage their staff to volunteer, so we end up with 5 pairs of
    > large-company staff and nobody from the rest of the community. But (as
    > Mike seems to imply) if we put in rules to make this impossible, we'd
    > be even further from "each eligible volunteer is equally likely to be
    > selected."  So this does need clarity of intent, one way or the other.

I think that we have a happy medium right now.

I want to note that there is a surprising lack of volunteers from a number of
large companies.  I would deeply like to have a social scientist compare
IETF registration listed affliations vs nomcom affliations over the years,
and also contrast that with past/future I*, WG chair, and document author lists.

This should also be an input to diversity design team: different
organizations and different people value IETF participation differently,  and
in some cases if we want a diversity of people from a diversity of
organizations, we need to be aware of what those internal rewards (or lack
of) are. [my observation is specifically that if you want gender diversity,
it's easier to find it in larger organizations than smaller ones, but the
incentives to participate in IETF may be very perverse in large organizations]

---

From: Dave Crocker <[email-masked]>
Date: Tue, 16 Sep 2014 09:54:14 -0700

> and that does not happen every year.

I'll suggest that past statistics aren't all that relevant.  The issue
is the sampling model and its potential for problematic outcomes.

A design that permits 5 companies to /ever/ fully populate the Nomcom is
a flawed design.

d/

ps. It's worth applying that same analysis approach to questions of
competence.  No matter how bright or well-intentioned everyone might be,
would Nomcom be competent if all of its members only met the minimum
selection criteria and, for example, /no/ member of Nomcom had /any/
experience actually participating in a working group, writing any RFCs,
or chairing any WGs?  The current rules permit that outcome.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 16 Sep 2014 12:57:31 -0400

At 12:40 PM 9/16/2014, Stewart Bryant wrote:
>It would be useful to run the stats to see how close we have ever come to that. The affiliations are not on the site so it's difficult to do a quick check. My recollection is that we have never seen worse than 2+2, and that does not happen every year.

What I remember (without going back and checking) is something like 2+2+1 or 2+2+1+1 happening multiple times.  What might actually be more interesting is looking at say the last 15 years  or so of Nomcom membership and understanding what the long term trend of representation is.  Unfortunately, we don't seem to have that information all in one place. 

Mike

---

From: Doug Barton <[email-masked]>
Date: Tue, 16 Sep 2014 10:02:52 -0700

On 9/15/14 3:55 PM, Mary Barnes wrote:
>
>
> On Mon, Sep 15, 2014 at 5:18 PM, Doug Barton <[email-masked]
> <mailto:[email-masked]>> wrote:

>     Are y'all talking about the input to the nomcom process, or the
>     output? I don't see anything wrong with more than one candidate per
>     company putting their name in the hat, but it's probably reasonable
>     to limit the number of qualified applicants that go into the final
>     selection process.
>

Ok, so you're talking about the output.

>     OTOH, how do you define "a company" in this scenario? Take any of
>     the large multinationals .... is it fair to eliminate a candidate
>     because there is another qualified candidate who happens to work at
>     the same "company," even though they are in different business
>     units, different states, different countries, or even different
>     continents?
>
> not leadership appointments.

It is equally, if not in fact more important to avoid capture of the 
nomcom itself.

> At this point, it's entirely up to the
> nomcom how many appointees from each company are selected - e.g., some
> nomcoms decide that the IESG should have at most 2 people from the same
> company. Others have decided 3 is okay. [/MB]

... and I think the point that I (and others) are trying to make here is 
that perhaps it should not be up to the nomcom.

>     I totally agree with the need to avoid capture of the IETF
>     leadership, but the problem is a lot harder to solve than you might
>     think. It may be worthwhile for our folks who are interested in this
>     topic to have a chat with the ICANN folks about policies and
>     methodology that are in place there, as avoiding industry capture
>     has been an important part of their working process since day 1, and
>     a lot of thought has gone into it.
>
> http://tools.ietf.org/html/draft-barnes-nomcom-report-2009-00.  The
> reality is that large companies can afford to have large numbers of
> people participate and attend IETF meetings (and thus qualify as voting
> members of nomcom) as well as the ability to fund an employee to do
> nearly full time work in leadership positions at the IETF. It's my
> understanding is that ICANN solves this problem somewhat by providing
> coverage of travel expenses for some of the appointments. That's a big
> deal for independent consultants.
> [/MB]

That's exactly the kind of NIH response I was hoping I wouldn't see. It 
would be arrogant in the extreme to assume both that we're totally aware 
of all of the problems, and that we know how every other organization 
that faces similar problems solves them. Opening a dialog with ICANN on 
this topic can only have benefits to both organizations, at the risk of 
a very small amount of wasted time if nothing useful surfaces. I'm sure 
that there are other groups out there who it would be worth engaging on 
this topic, but personally I'm only familiar with ICANN's efforts.

Doug

---

From: Mary Barnes <[email-masked]>
Date: Tue, 16 Sep 2014 12:37:51 -0500

On Tue, Sep 16, 2014 at 12:02 PM, Doug Barton <[email-masked]> wrote:

> would be arrogant in the extreme to assume both that we're totally aware of
> all of the problems, and that we know how every other organization that
> faces similar problems solves them. Opening a dialog with ICANN on this
> topic can only have benefits to both organizations, at the risk of a very
> small amount of wasted time if nothing useful surfaces. I'm sure that there
> are other groups out there who it would be worth engaging on this topic,
> but personally I'm only familiar with ICANN's efforts.

[MB] One final comment since the thread has now reached the typical
personal attack/mis-interpret what the other person said without
considering that one may have mis-understood mode.  Please consider that
some people actually don't write emails with anything intended to be read
between the lines.

My statement was in no way an NIH response. I stated factually that the
issues being discussed are well known and they are challenging.  I also
noted that ICANN solved part of the problem covering travel expenses.  In
no way did I make any statement with regards to whether we ought to talk to
ICANN.  My statement was a response to the fact that you stated the problem
was a lot harder to solve than we thought and a simple statement about how
ICANN solved part of the problem.

BTW, did you read the document for which I provided a link?  It fairly
clearly explains some of the issues that are quite relevant to this thread.
 If haven't read the document then, you ought check Jari Arkko's FB page.
 He has a posting today that's quite relevant in that case. [/MB]

---

From: Michael StJohns <[email-masked]>
Date: Tue, 16 Sep 2014 13:44:09 -0400

>It's not a perfect solution, but it's clear, simple to implement, and

As I said, I did take a look at that approach, and it is *better* than the current process for some value of *better".  But it still has the characteristic that by overloading the volunteer pool, a company can pretty much guarantee its representation on the Nomcom.

The formula is basically  "P = 1-(1-n)^10"  where P is the probability of having a member and "n" is the proportion the company has of the volunteer pool.   E.g. A company with 15% of the volunteer pool has an 80% chance of having a member of the nomcom.

Turning the formula around to how many volunteers you need to get a specific result, you get "n = 1-ROOT (1-P, 10)"

So to have a 95% chance of having a member, you need about a 26% share of the Nomcom volunteer pool.

If you cap the share of the volunteer pool (by doing the two stage selection process I mentioned or something similar), you can set the numbers any way you want.  For example, if you cap the share at 10%, and you're selecting at max one member per company, a company has about a 65% chance of having a member.  If you use the same 10% cap on the pool, but allow a max of two nomcom members, a company has about a 33% chance of no member, 33% chance of 1 and 33% chance of two.

I'm not sure what the right numbers are, but I would like to set things up so that overloading the nomcom pool is no longer a viable strategy (or at least has a lower payoff).

Changing the cap to 1 member will reduce, but not eliminate,  over representation of large companies on the Nomcom.  If the change is made, then year to year  2-4 companies will provide about 30% (guesstimate based on what I remember of past volunteer pools) of the nomcom members; down from what I would guess is currently close to 50%.  The question is whether that number is still too high or not?

Later, Mike

Note:  This is all binomial distribution probability stuff.  In excel, the probability pulling exactly N black balls (nomcom positions) out of Y pulls (10 nomcom slots) given a P percentage of black balls (nomcom volunteers) in the pool is =BINOMDIST (N, Y, P, FALSE).  When you're doing Y pulls, and you cap successes at N, then the result is the sum of N to Y of that function (e.g. the probability of pulling at least 2 black balls is the sum of the probabilities of pulling 2, 3, 4...10 black balls).

I used that to play around with various scenarios.

For instance, assume that 4 companies collectively have a 50% share of the volunteer pool and that each individual company is capped at 1 member.  The numbers work out to about an 82% chance the companies will share 4 members,  a 12% chance of 3, 5% of 2 and 1% of 1.  That goes to looking at the nomcom representation on a longer term basis than year to year.  If the cap is 2 (as it has been in years past), that gives you a 27% chance of 0-3members, a 20% chance of 4,  a 25% chance of 5, a 20% chance of 6, 12% chance of 7 and a 5.5% chance of 8.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 16 Sep 2014 13:52:50 -0400

>A design that permits 5 companies to /ever/ fully populate the Nomcom is

Actually, it's worse than that.  The number is 3 companies to get 6 slots.  At that point, those three companies control the outcome of the Nomcom.  Of course, being too obvious will result in interesting backlash.

>or chairing any WGs?  The current rules permit that outcome.

Yup.  I considered this as well, and then reasoned that if you capped the pool proportion (the input to the selection process) rather than (or in addition to) the output you might get companies not doing the "everybody volunteer" thing and instead actually having people volunteer who have a track record of interaction with the IETF.

Mike

---

From: Doug Barton <[email-masked]>
Date: Tue, 16 Sep 2014 10:58:36 -0700

On 9/16/14 10:37 AM, Mary Barnes wrote:
> noted that ICANN solved part of the problem covering travel expenses.
>   In no way did I make any statement with regards to whether we ought to
> talk to ICANN.

You also made no statement about your intention to contact ICANN and 
open a dialog with them. What you did do was attempt to demonstrate your 
thorough knowledge of the topic, as well as your familiarity with 
ICANN's solutions; which to me sounds like justification for NOT 
contacting them. Sounds pretty NIH'y to me, but I would be happy to be 
proven wrong.

So rather than accusing me of an ad hominem attack (which, FWIW, is also 
a form of ad hominem attack), why not simply address the question 
directly? Will you contact ICANN to open up a dialog, and if not, why not?

Doug

---

From: Mary Barnes <[email-masked]>
Date: Tue, 16 Sep 2014 13:25:56 -0500

On Tue, Sep 16, 2014 at 12:58 PM, Doug Barton <[email-masked]> wrote:

> You also made no statement about your intention to contact ICANN and open
> a dialog with them.

[MB] Which means I made NO statement whatsover one way or the other.  I
provided you with no information upon which you ought to have drawn the
conclusions you did.  I am a very literal person and my not saying
something means that I did not say something.  You presumed something based
upon the fact that I did not explicitly say something.
[/MB]

> What you did do was attempt to demonstrate your thorough knowledge of the
> topic, as well as your familiarity with ICANN's solutions; which to me
> sounds like justification for NOT contacting them. Sounds pretty NIH'y to
> me, but I would be happy to be proven wrong.

[MB] I provided a concrete example of the fact that we have been plagued
with this problem for a while and that as Nomcom chair it struck me as an
important issue back in 2009. We discussed this at the March IETF in
Anaheim in 2010.  Careful note, that since you did not reply one way or the
other as to whether you read my Nomcom report, I'm going to make the crazy
assumption that I DON'T KNOW the answer to that question based on your
response.

I made a single, factual statement about how ICANN solved "part" of the
problem.  I in no way intended that statement to mean that I thought there
was thus no need to talk to ICANN.
[/MB]

>
> So rather than accusing me of an ad hominem attack (which, FWIW, is also a
> form of ad hominem attack), why not simply address the question directly?
> Will you contact ICANN to open up a dialog, and if not, why not?

[MB] Simple answer. I will not personally contact ICANN.  I think the
suggestion is not at all a bad idea, but right now I don't have the time
nor is anyone paying me for any of the work I am currently doing in IETF.
 I'm not that nice of a person.

Yet again, I thought I was providing some helpful, relevant information on
a IETF discussion and my *intent* was totally misconstrued with assumptions
being made and suggestions that I was being "arrogant to the extreme",
which is a tad amusing if you really knew me.    And, yes, I totally agree
that my response was an attack of sort, but the ABSOLUTE one thing I have
learned being a women in IETF is that unless I do that I am NOT listened to
all.  So, in my experience, it's still better to be heard than totally
ignored!  This, of course, gets us to the very serious problem with IETF
culture (as evidenced by virtually all IETF discussion threads), which is
the hostile environment. Unfortunately to work in IETF one often has to
change what one considers to be civil behavior in order to defend oneself
when one has been mis-understood.  In certain cultures, that's acceptable,
but it's certainly a terrible way for IETF to operate.

Honestly, if you wanted to be constructive, why did you just not share what
*you* happen to know about ICANN's efforts?

[/MB]

---

From: Doug Barton <[email-masked]>
Date: Tue, 16 Sep 2014 12:00:12 -0700

On 9/16/14 11:25 AM, Mary Barnes wrote:
> [MB] Simple answer. I will not personally contact ICANN.

Thanks. Unfortunate, but I appreciate your honesty.

Is anyone else involved in the 3777bis process willing to take this up 
as a task?

> Honestly, if you wanted to be constructive, why did you just not share
> what *you* happen to know about ICANN's efforts?

For two reasons, of roughly equal importance. My information is several 
years out of date, and I have no desire to be entangled in the 3777bis 
discussion any more than absolutely necessary. :)

Doug

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Sep 2014 17:31:26 -0400

Given that we are talking about dynamics of people, controlling the 
outcome of the nomcom process with 6 folks, even if those 6 folks were 
actually to cooperate, is very dependent upon who they are, who the 
other 4 are, who the liaisons and chair are, etc.

Rumor claims that on occaison two people who did not even have a vote 
had more influence than any sitting members.  I believe practice has 
changed to reduce that particular problem.

I do grant that consistent excessive representation from large 
corporations could be a problem.  If we want to re-open 3777 for 
substantive change, I can live with a change to 1 person per 
corporation.  I think that the potential benefits from such would 
probably out-weight the drawbacks.

However, it is not at all clear to me that the benefits of reopening 
3777 for substantive change outweigh the VERY large costs of such an 
activity.

As an example of the complications, we would presumably have to discuss 
your alternative selection process proposal.  Which would involve 
looking at the perverse incentives on the corporations to control their 
participation in the pool, and to self-select who they want to see 
standing.  Ouch.

And from experiences we all have been through, I would stronglye xpect 
even more complex and difficult discussions if we open the document up 
to substantive changes.

Yours,
Joel

On 9/16/14, 1:52 PM, Michael StJohns wrote:
...

---

From: Dave Crocker <[email-masked]>
Date: Tue, 16 Sep 2014 14:46:23 -0700

> even more complex and difficult discussions if we open the document up

Taken on its face, this appears to be an argument for never making any
changes to any aspect of IETF infrastructure.

The pain level of getting anything in the IETF's infrastructure to be
changed is high enough to make that argument plausible, but of course it
isn't -- or rather, it must not be -- acceptable.

So the question is whether the problems of concern are serious enough to
warrant the very likely (nay, certain) pain?

Or perhaps the question to ask is what specific problems, dangers,
benefits, etc., do folk consider worth working to prevent or ensure?

d/

---

From: Melinda Shore <[email-masked]>
Date: Tue, 16 Sep 2014 14:03:57 -0800

> benefits, etc., do folk consider worth working to prevent or ensure?

That's what I've been wondering, as well.  It sounds like some
nomcom chairs have identified some ambiguities that could use
clarification and some minor policy tweaks (well, I would put
the reduction in the number of nomcom members per company in
the "minor" category; others might not), but I haven't seen
anyone propose a major overhaul.  Is there something that's
likely to be controversial?

Melinda

---

From: Mary Barnes <[email-masked]>
Date: Tue, 16 Sep 2014 17:08:47 -0500

A few comments below [MB].

On Tue, Sep 16, 2014 at 4:31 PM, Joel M. Halpern <[email-masked]>
wrote:

> actually to cooperate, is very dependent upon who they are, who the other 4
> are, who the liaisons and chair are, etc.
>
> Rumor claims that on occaison two people who did not even have a vote had
> more influence than any sitting members.  I believe practice has changed to
> reduce that particular problem.
>
[MB] I believe so.   I will note that I personally think one of the
advantages of the current process is that there are  number of things that
were intentionally unspecified to allow the nomcom to decide a process they
found most effective.  For example, each nomcom can choose whether
non-voting members sit in on interviews.  As well, the chair has some
leeway in terms of what decisions they make about the process versus what
they allow the voting members to decide.  I think that's important to allow
for flexibility in the management style of the nomcom chair as well as the
level of experience of the voting members with a process of this nature.
 For example,  if you have a lot of experienced voting members and a chair
that had never served on a nomcom, then likely there's a lot of benefit in
engaging the voting members in a lot of the process discussions.  Thus, I
would be concerned about making the process too prescriptive.  I think this
aligns with Joel's first point.
[/MB]

> substantive change, I can live with a change to 1 person per corporation.
> I think that the potential benefits from such would probably out-weight the
> drawbacks.
>
[MB] I agree.  I think it could be helpful (and I'm not seeing how it would
be harmful, but maybe I'm missing something) to limit the voting members to
1 per affiliation. One question I have though is whether the affiliation of
the Nomcom chair is considered.  Personally, I think it ought to.  I think
there is the potential for bias, for example if you have a voting member
having the same affiliation as a nomcom chair, in particular if any of the
nominees for the appointments also have the same affiliation.  Although,
that would dramatically reduce your pool of potential nomcom chairs, which
is already pretty sparse.  So, it's probably a bad idea despite maybe
having a good intention.  I'm throwing this out basically, so this is
considered now rather than later IF we are going to update the process.
[/MB]

>
> However, it is not at all clear to me that the benefits of reopening 3777
> for substantive change outweigh the VERY large costs of such an activity.
>
> your alternative selection process proposal.  Which would involve looking
> at the perverse incentives on the corporations to control their
[MB] Personally, I'm not quite so concerned about this.  I possibly didn't
read the proposal closely enough to see how different it is from the
current. But, with the current you run the algorithm to produce 15 names
and then you drop the 3rd in the list if it's in the top 10 and then pick
#11 and so on.  Obviously, the algorithm would need to change to perhaps
produce a longer, ordered list.  But, I don't see that as a problem.
 Although, perhaps I've missed how the algorithm might have changed in the
past several years?
[/MB]

> even more complex and difficult discussions if we open the document up to
> substantive changes.
>
[MB] I pretty much agree with Joel. I personally think an incremental
change process (e.g., like was done for open list) is the only way we could
keep this from becoming a task that is unlikely to complete in a reasonable
timeframe.  The Nomcom process is challenging enough that changing too many
things at once has the potential for really poor outcomes, in particular,
it means people could be spending way more time trying to understand a new
process as opposed to evaluating community feedback and making selections.
Again, in my experience doing the latter in a timely manner is challenging
enough as is.
[/MB]

>> Actually, it's worse than that.  The number is 3 companies to get 6
>> slots.  At that point, those three companies control the outcome of the
>> Nomcom.  Of course, being too obvious will result in interesting backlash.
>>
>>
>>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Sep 2014 18:17:48 -0400

No, it is not an argument for not making any changes.  It is, 
unfortunately, an argument that any time we look at changing our 
process, we really have to look at the potential benefit and the costs 
of trying to make the changes.

I agree that a priori there are times when we need to fix the processes. 
  Sometimes even situations where we realize that major processes need 
major overhauls.

My personal read as a participant in this process and debate is that the 
benefit of the changes I have seen requested does not rise to meet the 
costs of making that level of change.  It may be possible to scope the 
effort so as to make some improvements, without incurring the full 
costs.  I don't currently see any way. But then, I could easily be 
missing something.  And others almost certainly see the values differently.

Yours,
Joel

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Sep 2014 17:59:46 -0500

> isn't -- or rather, it must not be -- acceptable.

It's a feature.  It's difficult enough that we'd have a damned good
reason to undertake any changes.

> warrant the very likely (nay, certain) pain?

Exactly.

Nico
--

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Sep 2014 11:13:20 +1200

> changes to any aspect of IETF infrastructure.

Which I'm pretty sure is not what Joel meant.

I'd rather see a rapid IETF Last Call on draft-kucherawy-rfc3777bis-01,
which is intentionally a no-op in terms of process changes. It could
easily be expedited as an RFC before the next IETF, if anybody cares
that much. Then we can have a managed discussion of the issues and
proposals that Mike has raised, which deserve debate.

   Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 16 Sep 2014 18:26:36 -0500

For what it's worth, http://www.rfc-editor.org/info/rfc5078 (the first
revision to RFC 3777) was Informational, just tuning the non-normative
timeline to name stuff that hadn't been accommodated, such as

   o  A few common practices are not accounted for in the Appendix B
      timeline [RFC3777].  For example, it is common to allow a week for
      notifying unsuccessful nominees before the formal announcement is
      made.  This is not included in the timeline.

I believe I'm quoting Russ Housley, Gen AD at the time, correctly as saying
"if we can't agree on that one, we can't agree on anything".

After that was approved, we made more significant, but still incremental,
updates to normative text.

So, perhaps draft-kucherawy-rfc3777bis-01 is the bait we stake out this
time, to see what happens to the least controversial proposal possible?
("stuff we've already agreed to, once")

Spencer

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 16 Sep 2014 16:28:28 -0700

> proposals that Mike has raised, which deserve debate.

For what it's worth, the RFC Editor turnaround has been around a month
lately, at least for documents going through working groups for which I'm
co-chair.  Unless there are strings pulled, a four-week last call, a
telechat cycle, and a month in the editor queue won't fit between now and
Honolulu.

But I also expect it would be a very lightweight Last Call, and would make
follow-on evolution of the BCP easier.

-MSK

---

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Sep 2014 15:23:56 +0300

Doug,

First and most important: Mary kindly provided information. Please do not assume that she has opinions that she did not express.

Then back to the substantial topic: Many of us have understanding of a number of other organisations, and what kinds of differences they have to IETF. Including the fundamental mode of the operation, compensation structures, financing, and so on.

The IETF, along with many other successful standards organisations, is based on voluntary adoption of our standards. When we make good, timely standards that people care about, there will be participants that want to observe, contribute, and even manage the production of these standards. If we do not, they do not. As simple as that. Personal opinion is that we’ve succeeded in doing things that interest the industry in the last few years, but that is something that we need to repeat every month going forward as well. And there is room for improvement. And it still is a big challenge to recruit leadership, nomcom members, etc. We should be grateful for the excellent teams we have...

And we should be aware of the implications of different modes of operation. If you run an organisation where people have to care a lot in order to participate, the good thing is that you’ll create a forcing function to work on useful things. The bad side of that is that it may create too much focus on things that are in commercial world only. And as Stewart noted, lean corporations may focus only on products, not on other things as much. The situations are different in other modes. For instance, in paid board model you might encounter situations where the organisation starts to be self-selecting, or you would get different people applying than you would otherwise. Which might of course be good or bad. In any case, it is not immediately clear to me that even if we had a bigger funding source, paying our board members would immediately solve all our issues. Many of our participants are not limited through getting food for the family, but rather through opportunity costs of using them either for IETF work or for creating some new products in their companies.

Anyway, what are your experiences and suggestions in this topic, Doug? Do you have suggested models to follow?

Jari

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 17 Sep 2014 15:55:30 +0200

On Monday, September 15, 2014, Doug Barton wrote:

>> encourage
>>     > staff and nobody from the rest of the community.
>
>
That is bad selection output.

> But (as Mike seems to
Max 1 per company per country.

>>     Real and substantial diversity is essential.
Agree

>> favoring nominees from their own companies. [/MB]
 Yes

> Are y'all talking about the input to the nomcom process, or the output?

It is process. But output should be determined by community.

> different countries, or even different continents?

Only different country is reasonable to have more with same company. We
need more of countries people involved in the process. That is diversity in
country but not company. However, there should be metric for diversity
measure to select output with more diversity quality per person.

> working process since day 1, and a lot of thought has gone into it.

 Do you have a reference that we can check with?

AB

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 17 Sep 2014 15:05:13 +0100

> Max 1 per company per country.
Why?

The economy is global, companies are global.

Surely it should be one company, one stock price, one quota of Nomcom 
members.

Stewart

---

From: Loa Andersson <[email-masked]>
Date: Wed, 17 Sep 2014 16:52:14 +0200

Folks,

> Surely it should be one company, one stock price, one quota of Nomcom

While I agree that "country" is a bad idea, I can#t but reflect on that
it is not that long ago that we decided on "two per company" has really
anything changed since then?

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Michael StJohns <[email-masked]>
Date: Wed, 17 Sep 2014 12:53:15 -0400

>anything changed since then?

"not that long ago" => 10+ years or about 35% of the lifetime of the IETF ago.  I forget when the process constructively changed, but it was definitely in place for the 2004 nomcom selection (publication date of 3777).

And yes, things have changed.

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 17 Sep 2014 13:18:42 -0400

Oh just increase the size of the NomCon and the issues go away.

I suggest expanding it to 100 members.

I am totally serious here and fully aware of the consequences. The
IETF thinks that it has adopted a perfect and unique approach to
governance. Well so did the many other organizations that have tried
similar. And if you watch what has happened to those organizations
over time it is what has happened in the IETF.

The original mechanism for choosing leaders was that they were the
ARPA program managers. Then as the IETF emerged as a distinct entity
and people started to worry about things such as getting insurance,
process started to emerge. The original process was a hermetic closed
politburo operating in secret which is actually a very common form of
organization in communities that consider themselves to be very open.

The failure modes can be quite spectacular. The old UK left had a
series of faction splits due to Gerry Healy (now deceased) engaging in
the behavior Jimmy Saville was accused of after his demise and several
UK celebs have been sentenced to prison terms for recently. There is
currently a similar scandal emerging in the skepticism/atheism
community. What brought down the old IETF cabal was the Kobe carve up.

Since then the NOMCON has been gradually reformed. And at each step
everyone tells me that the reforms I propose are utterly unacceptable
and impossible and ten years later they do them anyway and there are
no problems.

There once was a time when the idea of people knowing which posts were
open was considered unacceptable. The assumption was that any AD
willing to be reappointed would be. The idea of an expectation of a
two consecutive term limit was an innovation. Eventually it was
accepted that the world would not come to an end if the names of
nominees being considered were made public. And this had the predicted
and intended effect of turning the nomination process into one where
the NOMCON solicited input from the IETF at large.

At the moment the process is reasonably effective in avoiding really
bad appointments. But it is also pretty good at excluding
troublemakers and wildcards. And you need those sort of people every
so often to shake things up. Being selected by ten people whose names
were picked out of a hat guarantees that no AD, IAB or IETF chair can
ever claim a mandate to change anything in the organization.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Sep 2014 21:21:28 +0300

> I suggest expanding it to 100 members.

So, spend 10 times as many cycles on making the same decision? Would CFRG consider a curve that was 10 times slower than the ones they are considering right now?

We can barely get enough NomCom candidates right now. If volunteering all but guarantees that you’re going to have to spend half of the November meeting talking to people about other people, I don’t think we’d get as many volunteers as we do.

> ever claim a mandate to change anything in the organization.

Some ADs make trouble anyway, but the biggest thing affecting the choice of AD is that they have to be funded by somebody else to work full time at the IETF. If we had the IETF two hundred years ago, we might get gentlemen (in the old sense of the word). Since these days the idle rich prefer to work in charity rather than in managing standards organizations, we get people with funding from corporations, government agencies, and the occasional academic, and the people who decide to fund them don’t hire wildcards for the job.

That won't change even if we forgo the NomCom entirely and select ADs by a true test of merit such as a bridge tournament or memorizing the most episodes of Star Trek.

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 17 Sep 2014 14:41:48 -0400

> So, spend 10 times as many cycles on making the same decision? Would CFRG consider a curve that was 10 times slower than the ones they are considering right now?

No, increase the work load to the point where such discussions are no
longer feasible and they won't happen. Increasing the size of the
NOMCON would reduce the length of the discussions.

> Some ADs make trouble anyway,

Not enough.

My concern was more the IAB though. Having ten people who all think
the same way is pointless, nine of them are wasting their time.

> That won't change even if we forgo the NomCom entirely and select ADs by a true test of merit such as a bridge tournament or memorizing the most episodes of Star Trek.

You are thinking in terms of cabals. The next step after NOMCON isn't
going to be either a bridge tournament or a Star Trek trivia contest.
It will be an open vote process with the same qualifications as for
the NOMCON.

Again, I am basing my prediction on observing how other organizations
with a closed appointment structure have fared over time. The most
common outcome is that the organization dies by attrition and is
replaced by another. But some organizations do manage to survive and
they do so by gradually opening up the system and making it more
democratic. The only exception to this rule are religious
organizations.

Changes will come when a series of incompetent NOMCONs make choices
that the organization can't accept. The diversity issue looks to be
the most likely flash point.

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 17 Sep 2014 21:59:13 +0200

> The economy is global, companies are global.
The aim was diversity for nomcom.  The country factor is not important if
the nomcom members are global persons (or have multinationalities). Each
member volunteering will not have same effort as others, because it depends
on their home/work location even if they are in same job/company. I
recommend making that effort an equal volunteering cost, so we can have
a global IETF effort per nomcom work per member. It may attract more
interest in the rule per country.

People in our community are identified by countries/nationality, and even
if companies are global but they still have locations, they have to follow
their offices location country's market/industry/policy. Each company has
head offices which are located some where that has the biggest market and
their board members indicate its global representation. Yes IETF has no
location and is global (different than the global companies, because it
is locationless and profitless), but its selected nomcom members
may/should give us some indication of such global consideration.

AB