Re: Final Announcement of Qualified Volunteers

[John C Klensin]

--On Tuesday, July 09, 2013 19:43 -0400 Donald Eastlake
 wrote:

> Hi John,
> 
> Excuse me for replying to just part of your message below:

No problem.
I found your explanation helpful.Two observations at the
risk of repeating myself

(1) I did not make a proposal.  I did point out that there were
other possibilities within the general bounds of the "no more
than two" rule.  Beyond that, about as far as I'm willing to go
is to say that different mechanisms (the current ordered list,
selecting a company down to two candidates, your square root of
V alternate suggestion, and maybe some other things) each have
advantages and disadvantages and, probably, each optimizes for
something different or deals with a different marginal case.  I
suspect that, most of the time, the differences in practice are
likely to be trivial (or smaller).   But I haven't even tried to
do the analyses in large part because I think they would be much
too speculative.

(2) In response to Brian, you wrote...

>> That said, the "not more than two from the same employer" rule
>> was written in anticipation of a theoretical problem; it seems
> 
> I think not. If I recall correctly, there was at least one
> noncom with three voting members with the same affiliation.
> While there was no particular evidence that these voting
> members were acting as other than individuals, the consensus
> was that it just smelled bad and so the limit of two ...

The "bad smell" issue is, IMO, far more important than any
discussions of whether people or organizations have misbehaved
or might misbehave in the future.  It is especially important
should we have another round of discussions about antitrust
policies because, for an SDO, the ability, even in principle,
for one organization or set of interests to dominate a body or
its leadership selection process can easily create a lawyer's
playground.  I don't think it would be wise to try to completely
eliminate that risk even if it were possible, but passing a
smell test is nonetheless important for multiple reasons.

best,
   john

Second Call for Volunteers to Serve on the ICANN Nominating Committee

[IAB Chair]

Please note that the deadline for volunteering is 19 July 2013.  Please pass 
this call for volunteer to anyone that might be interested.

Russ

= = = = = = = = = =

Dear Colleagues,

The IAB (on behalf of the IETF) has been asked to supply a member to the 2014 
ICANN Nominating Committee (NomCom) by 15 August 2013. We would therefore like 
to ask the community for volunteers to serve on the ICANN NomCom. If you are 
interested, please send a short e-mail to iab-chair at iab.org with a copy to 
execd at iab.org with your motivation and information concerning your 
familiarity with the IETF and ICANN.  The deadline for volunteering is 19 July 
2013.

The IAB will select from the available candidates, taking into account the 
familiarity with ICANN and the IETF, their roles, and their processes. The 
selected candidate will serve on the ICANN NomCom on personal title; however, 
we will be looking for a candidate who has an understanding of the interests of 
the technical community.

The ICANN NomCom process itself is governed by the ICANN bylaws; an abstract of 
the relevant articles can be found at http://nomcom.icann.org/bylaws.htm.  In 
addition, each NomCom determines a number of its own operational procedures, 
including the role of the NomCom in recruiting and selecting candidates.

The ICANN Nominating Committee typically meets in person at or around three 
consecutive ICANN meetings. The first of these meetings, when the 
committee is formally established, will be held  22-23 November 2013 following 
the Buenos Aires ICANN meeting on 17-21 November. The committee will next 
attend the "Spring" ICANN meeting, which in 2014 will be in Singapore on 23-27 
March 2014. Finally, the committee will meet during and after the "Summer" 
ICANN meeting in London on 22-26 June 2014 where the final slate of candidates 
for the ICANN Board, the GNSO, ccNSO,and ALAC will be agreed upon.

Candidates should be able to join monthly teleconferences (typically at UTC 
14:00), with the expectation that these teleconferences will held weekly during 
the candidate assessment process in May-June.

NOTE: ICANN does cover travel and hotel costs for a pre-determined number of 
days at each of the 3 consecutive ICANN meetings.

For more information about the ICANN NomCom see: http://nomcom.icann.org/.  If 
you are willing to be considered or would like to nominate someone for the 
position, please send an email to iab-chair at iab.org and execd at iab.org.

On behalf of the IAB,
Russ Housley
IAB Chair

Re: Final Announcement of Qualified Volunteers

[Dave Crocker]

On 7/9/2013 2:07 PM, Ted Lemon wrote:

On Jul 9, 2013, at 4:58 PM, Scott Brim  wrote:

Is the great majority of the wisdom in the IETF incorporated into
a few megacorporations?

(That might reflect market share, in which case, is it a problem?)


I don't know the answer to that question, but it's an interesting
question.   But the reason I reacted to John Klensin's message
earlier the way I did is that I think that the question of how biased
toward the company's goals a nomcom participant will be has a lot to
do with the individual candidate.


Yes it does, but unfortunately that is irrelevant.

The concept of conflict of interest is not concerned with whether an 
individual's behavior is problematic, but whether there is an inherent 
tension amongst different interests for the person.  In other words, 
it's about the situational potential, not personal integrity.


There are two ways to deal with conflict of interest.

The first is to prohibit it.  If a person has competing situational 
influences, they are excluded.


In many environments -- and especially ones with industry participants 
doing industry work, like a standards body -- it is not possible to 
create a 'neutral' situation.  So the alternative is to 'balance' things 
through diversity, ensuring that the situational forces pull in many 
different directions.  (Actually, this also means we ought to mean we 
limit the number of router vendors or MTA vendors or... in positions of 
control for individual committees.)




And large companies do seem to
tend to snap up long-time influential IETF participants, so indeed it
is likely that over time IETF knowledge will tend to concentrate in
one large company or another.


Trends towards industry concentration are a long-standing challenge.  To 
the extent that the IETF wishes to continue to be inclusive, diversity 
pressures means it needs to limit the /ability/ of the giants to dominate.


Again, it has nothing to do with the motives or style of any of the 
giants.  It has to due with a requirement that others are assured equal 
opportunity to participate and influence.


d/



--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: Final Announcement of Qualified Volunteers

[Dave Crocker]

On 7/9/2013 5:23 PM, l.w...@surrey.ac.uk wrote:

I do recall a case where both chairs of a WG belonged to a Major Organization.

World domination was thwarted, however, because the chairs couldn't actually
agree on anything; the organization was big enough that competing views
were widespread within it.

Much to the frustration of other members of the Major Organization.
And the members of the working group.

This suggests that we can't produce viable committees _anyway_.



As usual, what it suggests is that we think that individual 
counter-examples somehow refute basic, well-established principles.


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

RE: Final Announcement of Qualified Volunteers

[l.wood]

I do recall a case where both chairs of a WG belonged to a Major Organization.

World domination was thwarted, however, because the chairs couldn't actually
agree on anything; the organization was big enough that competing views
were widespread within it.

Much to the frustration of other members of the Major Organization.
And the members of the working group.

This suggests that we can't produce viable committees _anyway_.

Lloyd Wood
http://sat-net.com/L.Wood/



From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Dave Crocker 
[d...@dcrocker.net]
Sent: 09 July 2013 21:53
To: ietf@ietf.org
Cc: nomcom-chair-2...@ietf.org
Subject: Re: Final Announcement of Qualified Volunteers

> Should we consider changing it to "not more than one" in view
> of today's data?


On it's face, that sounds like an absolutely Draconian rule.

However stepping back a bit, it should prompt a simple question:  Is the
IETF so reliant on a tiny number of companies that we cannot produce
viable committees if we require each member of a committee to be
affiliated with a different company?

In other words, are we really incapable of requiring extensive corporate
diversity?


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: Final Announcement of Qualified Volunteers

[Donald Eastlake]

Hi Brian,

On Tue, Jul 9, 2013 at 4:40 PM, Brian E Carpenter
 wrote:
>> (2) Four companies account for 44.3% of the volunteers.
>
> OK, but what would X be in "Four companies account for X% of
> people eligible to volunteer"?
>
> That said, the "not more than two from the same employer" rule
> was written in anticipation of a theoretical problem; it seems

I think not. If I recall correctly, there was at least one noncom with
three voting members with the same affiliation. While there was no
particular evidence that these voting members were acting as other
than individuals, the consensus was that it just smelled bad and so
the limit of two per primary affiliation was adopted. (Also note that,
according to the records, the first two nomcoms had only 7 voting
members.)

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> that it was a good idea, but it does allow the following to become
> true: "Four companies account for 67% of the NomCom members."
>
> Should we consider changing it to "not more than one" in view
> of today's data?
>
> Regards
>Brian

Re: Final Announcement of Qualified Volunteers

[Donald Eastlake]

Hi John,

Excuse me for replying to just part of your message below:

On Tue, Jul 9, 2013 at 9:31 AM, John C Klensin  wrote:
>
>...
>
> (3) It is probably too late to even discuss it for this year
> (see below) but it occurs to me that, if one wanted to minimize
> the odds of organizations trying to game the nomcom selection
> process, it would be rational to do a two step draw, first
> randomly selecting two volunteers from any organization offering
> more than two and then including only those two in the final
> selection process.On the other hand, that would give you
> around 81 candidates for the final selection this year.  If

The current two nomcom member per sponsor limit is really pretty much
of an honor system by self declaration. The Nomcom chair has no need
to bindingly determine what affiliation every volunteer has. Only as
nomcom members are selected does the Nomcom chair have to even think
about this. I think that, as a result, there are probably at most a
handful of cases where the Nomcom chair has to worry about this at all
including ambiguous cases such as someone working for a subsidiary of
a company that sponsors someone already selected for noncom or
consultations that nominally work for a separate organization but are
X% funded for their IETF work by BigCompany for various values of X.
Any "two step" rule as you suggest will move affiliation from a tail
end check designed to be sure that the nomcom passes the smell test to
the heart of the selection process. I think the result would be a
mess.

However, if such a system were adopted, its not like an upfront
selection to 2 per sponsor is the only alternative to the current
unlimited pool from which the noncom is selected. Just to give an
example of an alternative rule, since you have to classify all
volunteers as to who their sponsor is, you could do initially a select
among the V volunteers from sponsor S limited to the square root of V
rounded up. That would seem like a more moderate intermediate course.

> running the final selection against order 140 people rather than
> order 81 causes the community to believe that it has a better
> sample, then that option probably would not be appropriate.  I
> am not, however, convinced that we would actually have consensus
> for minimizing those odds, nor about whether a company's ability
> to nearly guarantee that at least one of its employees will be
> on the Nomcom by providing a large fraction of the volunteers
> violates the provision of Section 4, bullet 16, of RFC 3777
> requiring "...unbiased if no one can influence its outcome in
> favor of a specific outcome".

In my opinion, those words, in the context of the previous sentence
which speaks of each volunteer being equally likely to be selected,
means influence in favor of a particular volunteer or the like.
(Although all volunteers are equally likely to be selected, the
selections are ordered and after two have been selected with the same
affiliate, subsequent selections with the same affiliation are
discarded and additional selection(s) made.)

> ...

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> best,
>john
>

Re: Final Announcement of Qualified Volunteers

[Douglas Otis]

On Jul 9, 2013, at 3:58 PM, Spencer Dawkins  
wrote:

> On 7/9/2013 8:59 AM, Scott Brim wrote:
>> The sample is better at 140 if individuals represent themselves, but not if 
>> they are swayed by their organizational affiliation, and organization is now 
>> a significant factor in what we can expect from volunteers -- not all, but 
>> even some of those from organizations where the volunteers are long time 
>> participants. I support this idea. I think the gain is greater than the 
>> loss, and it even fosters diversity. 
> 
> I don't have a lot of time to chat about this, but
> 
> - I agree with Scott that it matters what voting members are guided by 
> (organization, personal experience, intuition, flipping coins ...)
> - I suspect that it's not possible to predict what any 10 voting members 
> chosen at random will be guided by
> - I'm not sure we can even know what the 10 voting members *were* guided by, 
> unless the behavior is so bad that the advisor freaks out or the chair tells 
> us in the plenary Nomcom report
> 
> If people want to think about the Nomcom volunteer pool, it may be useful to 
> wonder about whether the perspective of voting members from more 
> organizations would help the Nomcom make better choices.
> 
> Of course, I'm not sure we can predict that, either :-)

Dear Spencer,

Precisely because it is impossible to judge motivations, the only way to ensure 
fairness is to ensure broad participation.  It seems unfortunate an 
organization dedicated to developing the Internet has not done more to ensure 
those obtaining remote access are not treated as second class participants.  
This should greatly increase the available talent.  The larger pool could be 
coupled with a meeting subscription to offset the loss of fees collected at 
meeting venues. 

To improve the experience, a flash based netbook coupled with the projector and 
PA could improve remote access into being much closer to a face-to-face 
experience worthy of fees requested.  Importantly, both face-to-face and remote 
participants should be able to obtain equal roles.  If the Internet is down, so 
is the meeting.  That may make venue selection more dependent upon the quality 
of the Internet availability.

Imagine real time translations made possible actually enhancing regional 
understanding.

Regards,
Douglas Otis

Re: Final Announcement of Qualified Volunteers

[Randy Bush]

Spencer Dawkins wrote:

> - I'm not sure we can even know what the 10 voting members *were*
>   guided by, unless the behavior is so bad that the advisor freaks out
>   or the chair tells us in the plenary Nomcom report

and Yoav Nir wrote:

> how much can a nomcom member (or a pair of them) do to advance a
> company's goals?

< reality check >

the ietf is no longer a collegiate collection of engineers, computer
scientists, and operators.  sad to say, we need to get past that fantasy
of the good old days.  and i would point out that traditional SDOs are
generally users trying to get multi-vendor interoperability and choice,
not vendors throwing weight proportional to market share.

but physics says we do this in an environment which is dominated by the
vendors being the ones who can afford the cost to have a strong presence
in the ietf, see .

and i believe that there is a real problem, not just fud and theory.

i *heard* (from reliable sources, plural, but not witnssed) that there
was a nomcom where company X said that an employee of X must be chosen
for the iesg or 
would ensue.

randy

Re: Final Announcement of Qualified Volunteers

[Spencer Dawkins]

On 7/9/2013 8:59 AM, Scott Brim wrote:
The sample is better at 140 if individuals represent themselves, but 
not if they are swayed by their organizational affiliation, and 
organization is now a significant factor in what we can expect from 
volunteers -- not all, but even some of those from organizations where 
the volunteers are long time participants. I support this idea. I 
think the gain is greater than the loss, and it even fosters diversity. 


I don't have a lot of time to chat about this, but

- I agree with Scott that it matters what voting members are guided by 
(organization, personal experience, intuition, flipping coins ...)
- I suspect that it's not possible to predict what any 10 voting members 
chosen at random will be guided by
- I'm not sure we can even know what the 10 voting members *were* guided 
by, unless the behavior is so bad that the advisor freaks out or the 
chair tells us in the plenary Nomcom report


If people want to think about the Nomcom volunteer pool, it may be 
useful to wonder about whether the perspective of voting members from 
more organizations would help the Nomcom make better choices.


Of course, I'm not sure we can predict that, either :-)

Spencer

RE: Final Announcement of Qualified Volunteers

[l.wood]

Ah, Allison actually misspelled it in setting her reply-to. So all replies 
would bounce.

Seriously guys, nom-com is the way to go to reduce this confusion. Needs a 
minus.

Lloyd Wood
http://sat-net.com/L.Wood/

On plus side, I didn't make the typo, only copied it and couldn't spot it. Go 
me!



From: Wood L  Dr (Electronic Eng)
Sent: 08 July 2013 08:55
To: l.w...@surrey.ac.uk; ietf@ietf.org; noncom-chair-2...@ietf.org
Subject: RE: Final Announcement of Qualified Volunteers

Gah. Am idiot misspelling it, sorry.

Lloyd Wood
http://sat-net.com/L.Wood/



From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of 
l.w...@surrey.ac.uk [l.w...@surrey.ac.uk]
Sent: 08 July 2013 08:38
To: ietf@ietf.org; noncom-chair-2...@ietf.org
Subject: RE: Final Announcement of Qualified Volunteers

Email to noncom-chair-2...@ietf.org appears to fail - bounce below.

Re: Gen-ART Telechat Review of draft-thornburgh-adobe-rtmfp-09

[Ben Campbell]

Thanks Michael, that note would completely resolve my concern, and change my 
review summary to "ready for publication".

Ben.

On Jul 9, 2013, at 5:03 PM, Michael Thornburgh  wrote:

> hi Ben.
> 
> your "like to see" is entirely reasonable, and the following text will be in 
> the next revision once my AD or Document Shepherd directs me to post it:
> 
>   Note to implementers: at the time of writing, the Cryptography
>   Profile used by the above mentioned Adobe products is not publicly
>   described by Adobe.  Implementers should investigate the availability
>   of documentation of that Cryptography Profile prior to implementing
>   RTMFP for the purpose of interoperation with the above mentioned
>   Adobe products.
> 
> thank you.
> 
> -michael thornburgh
> 
> 
>> From: Ben Campbell [mailto:b...@nostrum.com]
>> Sent: Tuesday, July 09, 2013 12:59 PM
>> 
>> I am the assigned Gen-ART reviewer for this draft. For background on 
>> Gen-ART, please see the FAQ at <
>> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Please wait for direction from your document shepherd or AD before posting a 
>> new version of the draft.
>> 
>> Document: draft-thornburgh-adobe-rtmfp-09
>> Reviewer: Ben Campbell
>> Review Date: 2013-07-09
>> IESG Telechat date: 2013-07-11
>> 
>> Summary: This draft is essentially ready for publication as an informational 
>> RFC. There is one issue
>> from my previous review and related discussion that I think is almost, but 
>> not completely handled. All
>> other concerns from my previous review have been addressed in this version.
>> 
>> Major issues:
>> 
>> There has been a fair amount of discussion about how this protocol requires 
>> a crypto profile to
>> interoperate, and no such profiles are included, or otherwise widely 
>> published. If this were a
>> standards track draft, I would argue for at least one mandatory-to-implement 
>> profile to be included or
>> referenced. But since this is intended as an informational RFC that simply 
>> describes what certain
>> products are doing, that's probably okay.  Furthermore, the author added a 
>> paragraph to the
>> introduction specifically calling out the issue, which I applaud.
>> 
>> But I'd like to see that paragraph go a bit further, and explicitly mention 
>> any such profile needed to
>> interoperate with the commercial products mentioned in the 2nd paragraph of 
>> section 1 has not been
>> made available at the time of RFC publication, and that implementors should 
>> investigate the
>> availability of such a profile prior to implementing this protocol for the 
>> purposes of interoperating
>> with those products.
>> 
>> Minor issues:
>> 
>> None.
>> 
>> Nits/editorial comments:
>> 
>> None.

RE: Gen-ART Telechat Review of draft-thornburgh-adobe-rtmfp-09

[Michael Thornburgh]

hi Ben.

your "like to see" is entirely reasonable, and the following text will be in 
the next revision once my AD or Document Shepherd directs me to post it:

   Note to implementers: at the time of writing, the Cryptography
   Profile used by the above mentioned Adobe products is not publicly
   described by Adobe.  Implementers should investigate the availability
   of documentation of that Cryptography Profile prior to implementing
   RTMFP for the purpose of interoperation with the above mentioned
   Adobe products.

thank you.

-michael thornburgh


> From: Ben Campbell [mailto:b...@nostrum.com]
> Sent: Tuesday, July 09, 2013 12:59 PM
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at <
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please wait for direction from your document shepherd or AD before posting a 
> new version of the draft.
> 
> Document: draft-thornburgh-adobe-rtmfp-09
> Reviewer: Ben Campbell
> Review Date: 2013-07-09
> IESG Telechat date: 2013-07-11
> 
> Summary: This draft is essentially ready for publication as an informational 
> RFC. There is one issue
> from my previous review and related discussion that I think is almost, but 
> not completely handled. All
> other concerns from my previous review have been addressed in this version.
> 
> Major issues:
> 
> There has been a fair amount of discussion about how this protocol requires a 
> crypto profile to
> interoperate, and no such profiles are included, or otherwise widely 
> published. If this were a
> standards track draft, I would argue for at least one mandatory-to-implement 
> profile to be included or
> referenced. But since this is intended as an informational RFC that simply 
> describes what certain
> products are doing, that's probably okay.  Furthermore, the author added a 
> paragraph to the
> introduction specifically calling out the issue, which I applaud.
> 
> But I'd like to see that paragraph go a bit further, and explicitly mention 
> any such profile needed to
> interoperate with the commercial products mentioned in the 2nd paragraph of 
> section 1 has not been
> made available at the time of RFC publication, and that implementors should 
> investigate the
> availability of such a profile prior to implementing this protocol for the 
> purposes of interoperating
> with those products.
> 
> Minor issues:
> 
> None.
> 
> Nits/editorial comments:
> 
> None.

Re: Final Announcement of Qualified Volunteers

[Douglas Otis]

On Jul 9, 2013, at 2:07 PM, Ted Lemon  wrote:

> On Jul 9, 2013, at 4:58 PM, Scott Brim  wrote:
>> Is the great majority of the wisdom in the IETF incorporated into a
>> few megacorporations?
>> 
>> (That might reflect market share, in which case, is it a problem?)
> 
> I don't know the answer to that question, but it's an interesting question.   
> But the reason I reacted to John Klensin's message earlier the way I did is 
> that I think that the question of how biased toward the company's goals a 
> nomcom participant will be has a lot to do with the individual candidate.   
> And large companies do seem to tend to snap up long-time influential IETF 
> participants, so indeed it is likely that over time IETF knowledge will tend 
> to concentrate in one large company or another.
> 
> That being the case, the current two-person rule could as easily be argued to 
> be damaging to the process as beneficial to it.   I'm not making a claim 
> either way, but I think that absent statistically valid data, this discussion 
> is completely theoretical.

Dear Ted,

From my experience, some projects have been thwarted through actions of a few 
companies.  The direction taken ended up being doomed which may have been the 
ultimate goal and potentially represents a real fairness issue IMHO.

Regards,
Douglas Otis  

Re: Final Announcement of Qualified Volunteers

[S Moonesamy]

At 06:49 09-07-2013, Ted Lemon wrote:
I find the presumption that IETF attendees employed by companies 
that send large number of attendees are robots to be somewhat 
distasteful.   It also doesn't match my experience.   I am sure that 
_some_ attendees from large companies are just as partisan as you 
fear, but some are not.   So I am not convinced that your proposal 
would have a good outcome.


I fixed the nomcom-chair-2013 email address as it does not make sense 
to send an email to an invalid address.


When designing a random selection a person has to ensure that the 
selection is such that the unbiased nature is publicly 
verifiable.  As John Klensin mentioned "four companies account for 
44.3% of the volunteers".  A similar question was raised by Sam 
Hartman previously.  When I looked at the affiliations over the years 
I noticed that two companies can easily get 40% of the vote.


The IETF works on the presumption of good faith.  Would a significant 
number of attendees from large companies adopt a partisan 
approach?  It's difficult for the public to determine that.  I'll 
change the question: does anyone believe that the average attendee 
from a large company will take a decision which is in the interest of 
the IETF Community even though that decision conflicts with what 
would be in the interest of the company?


That's not the better question though.  What is NomCom about?  The 
possible answers are not in the RFCs.


Anyway, the initial message was about having a broad pool and doing 
an unbiased selection from it.  The pool may have less people but it 
is broader in the sense that there would be people from all walks of 
the IETF.  I think that's what Jari Arkko might be referring to when 
he writes the word "inclusive".


Regards,
S. Moonesamy  

Re: Final Announcement of Qualified Volunteers

[Yoav Nir]

On Jul 10, 2013, at 12:07 AM, Ted Lemon 
 wrote:

> On Jul 9, 2013, at 4:58 PM, Scott Brim  wrote:
>> Is the great majority of the wisdom in the IETF incorporated into a
>> few megacorporations?
>> 
>> (That might reflect market share, in which case, is it a problem?)
> 
> I don't know the answer to that question, but it's an interesting question.   
> But the reason I reacted to John Klensin's message earlier the way I did is 
> that I think that the question of how biased toward the company's goals a 
> nomcom participant will be has a lot to do with the individual candidate.  

I think that before we discuss the extent of the bias, we should explore the 
question of whether such bias matters. Phrased as a question, how much can a 
nomcom member (or a pair of them) do to advance a company's goals? I've heard 
that nomcom members recuse themselves from discussions of candidates from their 
own company, so company X can't hope to get its employees appointed as ADs by 
stuffing the nomcom with other employees. Well, unless there's a huge back-room 
conspiracy among several such companies. 

Company X might have a bunch of technologies that they want to bring to the 
IETF to get them rubber-stamped as standards track RFCs, and they might want to 
see to it that ADs that will be trouble-makers don't get elected. That might 
even work (a single member is much more able to prevent someone being appointed 
than to cause someone to be appointed) But such proposals could be defeated in 
working groups and at IETF last call long before they even reach the IESG. I 
just don't see the benefit justifying the effort.

Yoav

Re: Final Announcement of Qualified Volunteers

[Ted Lemon]

On Jul 9, 2013, at 4:58 PM, Scott Brim  wrote:
> Is the great majority of the wisdom in the IETF incorporated into a
> few megacorporations?
> 
> (That might reflect market share, in which case, is it a problem?)

I don't know the answer to that question, but it's an interesting question.   
But the reason I reacted to John Klensin's message earlier the way I did is 
that I think that the question of how biased toward the company's goals a 
nomcom participant will be has a lot to do with the individual candidate.   And 
large companies do seem to tend to snap up long-time influential IETF 
participants, so indeed it is likely that over time IETF knowledge will tend to 
concentrate in one large company or another.

That being the case, the current two-person rule could as easily be argued to 
be damaging to the process as beneficial to it.   I'm not making a claim either 
way, but I think that absent statistically valid data, this discussion is 
completely theoretical.

Re: Final Announcement of Qualified Volunteers

[Scott Brim]

On Tue, Jul 9, 2013 at 4:53 PM, Dave Crocker  wrote:
>
>> Should we consider changing it to "not more than one" in view
>> of today's data?
>
>
>
> On it's face, that sounds like an absolutely Draconian rule.
>
> However stepping back a bit, it should prompt a simple question:  Is the
> IETF so reliant on a tiny number of companies that we cannot produce viable
> committees if we require each member of a committee to be affiliated with a
> different company?
>
> In other words, are we really incapable of requiring extensive corporate
> diversity?

Is the great majority of the wisdom in the IETF incorporated into a
few megacorporations?

(That might reflect market share, in which case, is it a problem?)

Re: Final Announcement of Qualified Volunteers

[Dave Crocker]

Should we consider changing it to "not more than one" in view
of today's data?



On it's face, that sounds like an absolutely Draconian rule.

However stepping back a bit, it should prompt a simple question:  Is the 
IETF so reliant on a tiny number of companies that we cannot produce 
viable committees if we require each member of a committee to be 
affiliated with a different company?


In other words, are we really incapable of requiring extensive corporate 
diversity?



d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: Final Announcement of Qualified Volunteers

[Brian E Carpenter]

> (2) Four companies account for 44.3% of the volunteers.

OK, but what would X be in "Four companies account for X% of
people eligible to volunteer"?

That said, the "not more than two from the same employer" rule
was written in anticipation of a theoretical problem; it seems
that it was a good idea, but it does allow the following to become
true: "Four companies account for 67% of the NomCom members."

Should we consider changing it to "not more than one" in view
of today's data?

Regards
   Brian

Gen-ART Telechat Review of draft-thornburgh-adobe-rtmfp-09

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at < 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
 
Please wait for direction from your document shepherd or AD before posting a 
new version of the draft.
 
Document: draft-thornburgh-adobe-rtmfp-09
Reviewer: Ben Campbell
Review Date: 2013-07-09
IESG Telechat date: 2013-07-11
 
Summary: This draft is essentially ready for publication as an informational 
RFC. There is one issue from my previous review and related discussion that I 
think is almost, but not completely handled. All other concerns from my 
previous review have been addressed in this version.
 
Major issues:
 
There has been a fair amount of discussion about how this protocol requires a 
crypto profile to interoperate, and no such profiles are included, or otherwise 
widely published. If this were a standards track draft, I would argue for at 
least one mandatory-to-implement profile to be included or referenced. But 
since this is intended as an informational RFC that simply describes what 
certain products are doing, that's probably okay.  Furthermore, the author 
added a paragraph to the introduction specifically calling out the issue, which 
I applaud. 

But I'd like to see that paragraph go a bit further, and explicitly mention any 
such profile needed to interoperate with the commercial products mentioned in 
the 2nd paragraph of section 1 has not been made available at the time of RFC 
publication, and that implementors should investigate the availability of such 
a profile prior to implementing this protocol for the purposes of 
interoperating with those products.

Minor issues:

None.

Nits/editorial comments:

None.

Re: Draft submission deadlines change

[Arturo Servin]

Thanks Alexa.

   
Best regards,
as
On 7/9/13 4:59 PM, Alexa Morris wrote:
> Arturo,
>
> The time is the same as usual (UTC 24:00) and it's posted online in the 
> Important Dates section here: 
> http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87. 
>
> Regards,
> Alexa
>
> On Jul 9, 2013, at 12:53 PM, Arturo Servin wrote:
>
>> Hello,
>>
>>I was checking the deadlines for submitting drafts. Clear it is
>> Monday 15th July but it does not say the time.
>>
>>
>> Thanks,
>> as
>>
>> On 7/3/13 2:17 AM, IETF Chair wrote:
>>> Please note that for IETF 87, there is only one deadline for draft 
>>> submission: Monday 15th July. Previously, there had been two different 
>>> deadlines, one for -00 and another one for other versions. The IESG has 
>>> decided to experiment with just one deadline for now to simplify the set of 
>>> deadlines and enable easier submission of new drafts. While we realise that 
>>> the change comes near the deadline, we hope that you find the extra time 
>>> useful.
>>>
>>> But please do note that working group chairs will continue to make smart 
>>> decisions about what topics are worthwhile for discussing in a session in 
>>> the upcoming meeting, and will also set their agendas in a timely manner 
>>> and create deadlines for their working groups that must be adhered to. The 
>>> earlier new drafts are submitted, the more time there is to talk about them 
>>> on the mailing lists and consider them for the session agendas. This is 
>>> particularly important for BoFs.
>>>
>>> Jari Arkko for the IESG
> --
> Alexa Morris / Executive Director / IETF
> 48377 Fremont Blvd., Suite 117, Fremont, CA  94538
> Phone: +1.510.492.4089 / Fax: +1.510.492.4001
> Email: amor...@amsl.com
>
> Managed by Association Management Solutions (AMS)
> Forum Management, Meeting and Event Planning
> www.amsl.com 
>

Re: Draft submission deadlines change

[Alexa Morris]

Arturo,

The time is the same as usual (UTC 24:00) and it's posted online in the 
Important Dates section here: 
http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87. 

Regards,
Alexa

On Jul 9, 2013, at 12:53 PM, Arturo Servin wrote:

> Hello,
> 
>I was checking the deadlines for submitting drafts. Clear it is
> Monday 15th July but it does not say the time.
> 
> 
> Thanks,
> as
> 
> On 7/3/13 2:17 AM, IETF Chair wrote:
>> Please note that for IETF 87, there is only one deadline for draft 
>> submission: Monday 15th July. Previously, there had been two different 
>> deadlines, one for -00 and another one for other versions. The IESG has 
>> decided to experiment with just one deadline for now to simplify the set of 
>> deadlines and enable easier submission of new drafts. While we realise that 
>> the change comes near the deadline, we hope that you find the extra time 
>> useful.
>> 
>> But please do note that working group chairs will continue to make smart 
>> decisions about what topics are worthwhile for discussing in a session in 
>> the upcoming meeting, and will also set their agendas in a timely manner and 
>> create deadlines for their working groups that must be adhered to. The 
>> earlier new drafts are submitted, the more time there is to talk about them 
>> on the mailing lists and consider them for the session agendas. This is 
>> particularly important for BoFs.
>> 
>> Jari Arkko for the IESG
> 

--
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amor...@amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com 

Re: Draft submission deadlines change

[Arturo Servin]

Hello,

I was checking the deadlines for submitting drafts. Clear it is
Monday 15th July but it does not say the time.

   
Thanks,
as

On 7/3/13 2:17 AM, IETF Chair wrote:
> Please note that for IETF 87, there is only one deadline for draft 
> submission: Monday 15th July. Previously, there had been two different 
> deadlines, one for -00 and another one for other versions. The IESG has 
> decided to experiment with just one deadline for now to simplify the set of 
> deadlines and enable easier submission of new drafts. While we realise that 
> the change comes near the deadline, we hope that you find the extra time 
> useful.
>
> But please do note that working group chairs will continue to make smart 
> decisions about what topics are worthwhile for discussing in a session in the 
> upcoming meeting, and will also set their agendas in a timely manner and 
> create deadlines for their working groups that must be adhered to. The 
> earlier new drafts are submitted, the more time there is to talk about them 
> on the mailing lists and consider them for the session agendas. This is 
> particularly important for BoFs.
>
> Jari Arkko for the IESG

Re: Final Announcement of Qualified Volunteers

[John C Klensin]

--On Tuesday, July 09, 2013 13:49 + Ted Lemon
 wrote:

> I find the presumption that IETF attendees employed by
> companies that send large number of attendees are robots to be
> somewhat distasteful.   It also doesn't match my experience.
> I am sure that _some_ attendees from large companies are just
> as partisan as you fear, but some are not.   So I am not
> convinced that your proposal would have a good outcome.

It was _not_ a proposal, merely an analysis of the numbers and
an exploration of alternatives.

I also didn't say "robots" or anything that could be reasonably
construed as robots.  I don't even have any experience that
would lead to expect that a company would expect any selected
Nomcom members to march in lockstep.

I do note that the "no more than two people with the same
primary affiliation" rule is part of RFC 3777 (BCP 10) and take
that as an indication that the community was unhappy with at
least the appearances of one company having more than 1/5 of
Nomcom voting membership.  That limit is not part of any
proposal I or, to my knowledge, others have made recently.  With
regard to that limit, my analysis is merely an exploration of
how the intent of that rule might best be satisfied.

I'd welcome a discussion of whether the analysis is correct or
not. You might reasonably believe that it is irrelevant.  But,
as far as disagreeing with a proposal or not, please wait until
someone makes one (fwiw, it won't be me).

john

Gen-ART review of draft-ietf-abfab-eapapplicability-04

[Black, David]

The -04 version of this draft resolves the minor issue noted in
the Gen-ART review of the -03 version.

There is a remaining editorial nit, in that the one use of
"non-network" in the -04 version would benefit from clarification.
I suggest the following text change to the start of the paragraph
that's split across pages 3 and 4 (change is to last line of excerpt):

OLD
   Operators need to carefully consider the security implications before
   relaxing these requirements.  One potentially serious attack exists
   when channel binding is not required and EAP authentication is
   introduced into an existing non-network service.

NEW
   Operators need to carefully consider the security implications before
   relaxing these requirements.  One potentially serious attack exists
   when channel binding is not required and EAP authentication is
   introduced into an existing service other than network access.

Thanks,
--David

> -Original Message-
> From: Black, David
> Sent: Monday, June 17, 2013 10:39 PM
> To: stefan.win...@restena.lu; jsalo...@cisco.com; General Area Review Team
> Cc: ietf@ietf.org; ab...@ietf.org; Black, David
> Subject: Gen-ART review of draft-ietf-abfab-eapapplicability-03
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> .
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-abfab-eapapplicability-03
> Reviewer: David L. Black
> Review Date: June 17, 2003
> IETF LC End Date: June 17, 2003
> 
> Summary:
> This draft is on the right track but has open issues, described in the review.
> 
> This draft updates the applicability statement for EAP to include usage
> for application layer access via EAP over GSSAPI.  Additional security
> requirements are introduced for environments in which EAP is used for
> that purpose.
> 
> I found one open issue, which is minor, and may be editorial
> 
> Major issues: None
> 
> Minor issues: One
> 
> The next to last paragraph on p.3 begins with this sentence:
> 
>For these reasons, channel binding MUST be implemented by peers, EAP
>servers and AAA servers in environments where EAP authentication is
>used to access application layer services.
> 
> It appear that this "MUST" requirement applies to all uses of EAP,
> including network access authentication, not just application layer access
> authentication.  If so, that's not immediately obvious from the text, and
> an additional sentence should be added to make this clearer.  If not,
> the above sentence needs to exclude network access authentication from
> that requirement.
> 
> Nits/editorial comments:
> 
> The same paragraph (p.3) continues with:
> 
>In addition, channel
>binding MUST default to being required by peers for non-network
>authentication.  If the EAP server is aware that authentication is
>for something other than a network service, it too MUST default to
>requiring channel binding.
> 
> What is meant by "non-network authentication" and "other than a network
> service"?  If those mean "other than for network access authentication"
> as the term "network access authentication" is used in section 1 and
> RFC 3748, that meaning should be clarified.
> 
> idnits 2.12.17 generated this comment:
> 
>   -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
>  have content which was first submitted before 10 November 2008.  If you
>  have contacted all the original authors and they are all willing to grant
>  the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
>  this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
>  (See the Legal Provisions document at
>  http://trustee.ietf.org/license-info for more information.)
> 
> idnits appears to be confused ;-).  The -00 version of this draft is from
> 2012,
> and this draft does not contain sufficient material from RFC 3748 that would
> raise that concern, so this comment should be ok to ignore.
> 
> Thanks,
> --David
> 
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> david.bl...@emc.com    Mobile: +1 (978) 394-7754
> 

Re: Final Announcement of Qualified Volunteers

[Scott Brim]

On Tue, Jul 9, 2013 at 9:31 AM, John C Klensin  wrote:
> if one wanted to minimize
> the odds of organizations trying to game the nomcom selection
> process, it would be rational to do a two step draw, first
> randomly selecting two volunteers from any organization offering
> more than two and then including only those two in the final
> selection process.On the other hand, that would give you
> around 81 candidates for the final selection this year.  If
> running the final selection against order 140 people rather than
> order 81 causes the community to believe that it has a better
> sample, then that option probably would not be appropriate.

The sample is better at 140 if individuals represent themselves, but
not if they are swayed by their organizational affiliation, and
organization is now a significant factor in what we can expect from
volunteers -- not all, but even some of those from organizations where
the volunteers are long time participants.  I support this idea.  I
think the gain is greater than the loss, and it even fosters
diversity.

Re: Final Announcement of Qualified Volunteers

[Ted Lemon]

I find the presumption that IETF attendees employed by companies that send 
large number of attendees are robots to be somewhat distasteful.   It also 
doesn't match my experience.   I am sure that _some_ attendees from large 
companies are just as partisan as you fear, but some are not.   So I am not 
convinced that your proposal would have a good outcome.

Re: Final Announcement of Qualified Volunteers

[John C Klensin]

--On Saturday, July 06, 2013 14:53 -0700 NomCom Chair 2013
 wrote:

> I am pleased to announce that we have 140 qualified
> individuals who  have generously volunteered to serve as
> voting members of this year's  Nomcom.

Allison,

Given my previous comment about statistical assertions, a quick
look at this list sheds some additional light on cross-sections
of the community.  

(1) While you have 140 people from whom to do a random draw, the
"no more than two volunteers with the same primary affiliation"
(RFC 3777, Section 4, Bullet17) rule means that the actual nomcom
pool is only 81 even though some of the people are indeterminate
(I've made some assumptions about company boundaries -- other
assumptions would yield very slightly different results).  That
number is obtained by listing the companies and then counting
any company with more that two volunteers as having only two.  

Neither the 140 number nor the 81 number is incorrect, they just
measure different things.

(2) Four companies account for 44.3% of the volunteers.  As
others have pointed out, while having a very large number of
volunteers cannot produce more than two Nomcom voting seats due
to that restriction, it can virtually guarantee (statistical
randomness notwithstanding) that one will end up with one or two
seats.  Specifically, if the people selected constitute a
cross-section of the volunteers, then more than 10% of the pool
(14 volunteers) would predict to at least one seat.  Two
companies exceed that number and a third is very close.
Randomness could make the actual numbers either better or worse,
but, if an organization's goal were to assure at least one seat,
that seems easily accomplished.  Of course, having lots of
volunteers doesn't imply that an organization was trying to
accomplish any such thing -- it could just have a lot of
public-spirited IETF participants and policies that allow people
to commit the time.

(3) It is probably too late to even discuss it for this year
(see below) but it occurs to me that, if one wanted to minimize
the odds of organizations trying to game the nomcom selection
process, it would be rational to do a two step draw, first
randomly selecting two volunteers from any organization offering
more than two and then including only those two in the final
selection process.On the other hand, that would give you
around 81 candidates for the final selection this year.  If
running the final selection against order 140 people rather than
order 81 causes the community to believe that it has a better
sample, then that option probably would not be appropriate.  I
am not, however, convinced that we would actually have consensus
for minimizing those odds, nor about whether a company's ability
to nearly guarantee that at least one of its employees will be
on the Nomcom by providing a large fraction of the volunteers
violates the provision of Section 4, bullet 16, of RFC 3777
requiring "...unbiased if no one can influence its outcome in
favor of a specific outcome".

Actually, if I read Bullet 16 correctly, the choice of methods
is up to you, with RFC 2777 (and 3797) being just examples. So,
in theory, you could make that change.  I wouldn't personally
recommend it, but you are the one who has personal
responsibility for things being fair and unbiased while this is
just a statistical exercise for me.

best,
   john