Re: IETF Diversity

[Noel Chiappa]

> From: Doug Barton 

> their work has been ignored and/or shouted down since it doesn't fit
> the narrative.

The usual fate of those who care more about the data than the herd-meme of the
moment. For a good example of this in action, those who are unfamiliar with
the work of Barbara McClintock should try looking her up. (She actually
stopped publishing because the reception given to her work was so negative.)

(In honour of the thread, I have carefully picked a female example. Is that
being sensitive, or patronizing? Left as an exercise for the reader...)

Noel

Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03

[Sam Hartman]

I'm fine with this text.
Either with eap-lower-layer as a MUST or the more complex version.

Re: Reducing Internet Latency Workshop

[Mirja Kühlewind]

Hi Matt,

I currently writing a position paper but I'm travel tomorrow and over the 
weekend and am not sure if I will be able to finish the paper today. Is it 
maybe possible to submit the paper a couple days later?

Mirja


On Friday 14 June 2013 10:42:43 Matthew Ford wrote:
> Possibly of interest. (Short) Position paper deadline is 23rd June.
>
> Regards,
> Mat
>
> Workshop on Reducing Internet Latency
> =
> 25 - 26 September 2013
> London, England
>
> Latency tends to have been sacrificed in favour of headline bandwidth in
> the way the Internet has been built. This two-day invitation-only workshop
> aims to galvanise action to fix that. All layers of the stack are in scope.
> Latency is an increasingly important topic for networking researchers and
> Internet practitioners alike. Data from Google, Microsoft, Amazon and
> others indicate that latency increases for interactive Web applications
> result in less usage and less revenue from sales or advertising income.
> Whether trying to provide platforms for Web applications, high-frequency
> stock trading, multi-player online gaming or 'cloud' services of any kind,
> latency is a critical factor in determining end-user satisfaction and the
> success of products in the marketplace. Consequently, latency and variation
> in latency are key performance metrics for services these days.
>
> But latency reduction is not just about increasing revenues for big
> business. Matt Mullenweg of WordPress motivates work on latency reduction
> well when he says, "My theory here is when an interface is faster, you feel
> good. And ultimately what that comes down to is you feel in control. The
> [application] isn’t controlling me, I’m controlling it. Ultimately that
> feeling of control translates to happiness in everyone. In order to
> increase the happiness in the world, we all have to keep working on this."
>
> Invitations to attend the workshop will depend on receipt of a position
> paper. In a spirit of co- ordination across the industry, submissions are
> encouraged from developers and network operators as well as the research
> and standards communities.
>
> A wide range of latency related topics are in scope including, but not
> limited to: - surveys of latency across all layers
> - analyses of sources of latency and severity/variability
> - the cost of latency problems to society and the economy, or the value of
> fixing it - principles for latency reduction across the stack
> - solutions to reduce latency, including cross-layer
> - deployment considerations for latency reducing technology
> - benchmarking, accreditation, measurement and market comparison practices
>
> Submissions
> ---
> This is an invitation-only workshop. Prospective participants must submit
> short (up to 2 pages) position papers outlining their views on a specific
> aspect of the overall scope. The emphasis here is on relevance and brevity
> - you do not need to write a lot of text, just demonstrate that you have
> thought about the problem space and have something interesting to say on
> the topic.
>
> Please send position papers in PDF format to: late...@isoc.org
>
> Participant numbers will be limited to focus on discussion and identifying
> actions rather than slideware. Accepted position papers will be made
> public. A report on the workshop will be published after participants have
> agreed the content. Therefore, it will be possible to state views during
> the workshop without them being publicly attributed.
>
> Important Dates
> ---
> Position paper submission deadline: 23 June 2013
> Paper acceptance notification: 28 June 2013
> Workshop dates: 9am, Wednesday 25th – 5pm, Thursday 26th September 2013
>
> Program committee
> -
> Mat Ford, Internet Society, co-chair
> Bob Briscoe, BT, co-chair
> Gorry Fairhurst, University of Aberdeen
> Arvind Jain, Google
> Jason Livingood, Comcast
> Andrew McGregor, Google
>
> Workshop venue and other details
> 
> Venue: Hilton London Paddington Hotel, 146 Praed Street, LONDON W2 1EE, UK
> Registration fee: There is no registration fee for the workshop.
> Recommended accommodation: Hilton London Paddington, registration link will
> be supplied to accepted participants.
>
> The workshop is sponsored by the Internet Society, the RITE project, Simula
> Research Labs and the TimeIn project. The Internet Society will host a
> workshop dinner on the Wednesday evening.

Re: IETF Diversity

[Scott Brim]

On Thu, Jun 20, 2013 at 3:12 AM, Noel Chiappa wrote:

> > From: Doug Barton 
>
> > their work has been ignored and/or shouted down since it doesn't fit
> > the narrative.
>
> The usual fate of those who care more about the data than the herd-meme of
> the
> moment. For a good example of this in action, those who are unfamiliar with
> the work of Barbara McClintock should try looking her up. (She actually
> stopped publishing because the reception given to her work was so
> negative.)
>

But she won huge praise in the end, which says something ultimately good
about the process of science, that it can overcome the shortcomings of its
practitioners.


> (In honour of the thread, I have carefully picked a female example. Is that
> being sensitive, or patronizing?


Yes.

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[Olafur Gudmundsson]

On Jun 19, 2013, at 9:29 AM, joel jaeggli  wrote:

> Given that this document was revved twice and had it's requested status 
> change during IETF last call in response to discussion criticism and new 
> contribution I am going to rerun the last call.


I reviewed this version and I think this is a fine document that I support. 
In particular the document goes out of its way to address the issues raised in 
prior 
IETF last call to the extent possible. 
The document is going to be the specification of two DNS RRtypes that have been 
allocated via expert review, we (DNS community) want to encore
that any such allocations be published as RFC's for future references. 

This document is not a product of any working group.

Olafur (DNSEXT co-chair) 

JOSE Virtual Interim 6/17 mixup

[Sean Turner]

There was an intent to have a virtual meeting of the JOSE WG on 
2013-06-17.  The announcement never made it to the IETF announce list. 
Because of this that virtual meeting is considered a design team meeting 
and not an official virtual interim meeting.  As such, all output is 
subject to approval, rejection or modification by the WG as a whole. 
The minutes of that design team have been posted here:


http://www.ietf.org/proceedings/interim/2013/06/17/jose/minutes/minutes-interim-2013-jose-2

Note that the next virtual interim was properly announced:
http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=12075&tid=1371735805

spt

Re: Is the IETF is an international organization? (was: IETF Diversity)

[Mark Nottingham]

Keep in mind that you're talking to an organisation that believes that 
Vancouver qualifies as "Asia."


On 19/06/2013, at 12:07 PM, SM  wrote:

> Hi Aaron,
> At 11:40 19-06-2013, Aaron Yi DING wrote:
>> Relating to the statement above(I assume Phillip is addressing the US 
>> Academia), not quite sure are we still discussing the same topic?
>> sorry, I am bit confused ..  since IETF is an international organization.
> 
> I changed the subject line as I am as confused as to whether the IETF is an 
> international organization.
> 
> There was a mention of "First the Civil Rights act, then Selma...  ;)".  I 
> assume that the act is an Act for the United States of America.  Harvard was 
> also mentioned.  I did a quick search and I found out that "Harvard 
> University is an American private Ivy League research university".
> 
> Regards,
> -sm 

--
Mark Nottingham   http://www.mnot.net/

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[John C Klensin]

Olafur,

Based on reviewing the current draft and the handling of my
objections and other of others to the prior ones, I agree that
the document is ready for publication.  

However, I feel a need to comment on one of your observations
below because it seems to lie at the core of why this particular
document took up so much IETF list time and correspondence.
Most of that could have been avoided, IMO, and I think there is
something to be learned from it to which I hope you, the DNSEXT
WG, and Ted (as responsible AD) will pay attention.


--On Thursday, June 20, 2013 09:39 -0400 Olafur Gudmundsson
 wrote:

> The document is going to be the specification of two DNS
> RRtypes that have been allocated via expert review, we (DNS
> community) want to encore that any such allocations be
> published as RFC's for future references. 

The IETF has historically had strong opinions about change
control, consensus, and the nature of recommendations.
Personally, I hope those opinions will continue and, if
anything, get stronger.

It seems to me that it is reasonable to say "we want a
lightweight registration procedure that imposes few if any
requirements on allocating an RR TYPE" or you can say "want to
ensure RFC publication" but that you don't get to say both at
once, especially when Standards Track or the IETF Stream are
involved.  If you (and DNSECT) want the very lightweight
registration procedure, then you should reasonably expect to
make sure that any documents are clearly informational (in
content and category) and to take your chances about
publication: Informational in either the IETF Stream or the
Independent Submission Stream could result in a "no" answer or,
more likely, requirements to justify the design decisions behind
the RRTYPEs as a condition of publication.  You can't "ensure"
anything because the relevant groups really do get to evaluate
both document quality and appropriateness for use.

By contrast, if the WG really does "want to ensure..." then it
would be appropriate to change the registration procedure so
that the I-Ds are posted and RFC publication is agreed to before
the RRTYPEs are registered so everyone can be sure that the two
match.That could be coupled with some sort of provisional
arrangement while document review is in progress, if the WG
thought that was necessary.   Howver the bottom line, IMO, is
that, if you want RFCs and want those RFCs to accurately
describe an RRTYPE and there is going to be open review during
the RFC development process, you can't have lightweight
registration and then insist that an RFC be published to
match... at least IMO and, if the discussions of the recent Last
Calls are indicative, a significant part of the the community
may share that view.

So some review of the DNSEXT-specified procedures and
expectations may be in order.

regards,
   john

RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03

[Black, David]

I think this is ok, but my email client isn't distinguishing the new vs. old 
text.

If it's just changes to produce this new bullet, I have a small edit:

o Channel binding MUST be used for all application authentication.
The EAP server MUST either require that the correct EAP lower-layer
attribute or another attribute indicating the purpose of the authentication
be present in the channel binding data for application authentication.

"MUST either require that" --> "MUST require that either"

Thanks,
--David

From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com]
Sent: Wednesday, June 19, 2013 7:23 PM
To: Black, David
Cc: stefan.win...@restena.lu; General Area Review Team; ab...@ietf.org; 
ietf@ietf.org
Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03

Thanks for the text,  some revision to address
On Jun 18, 2013, at 12:34 PM, "Black, David" 
mailto:david.bl...@emc.com>> wrote:


[Joe] Good points, the text can be more specific:

"In environments where EAP is used for purposes other than network access
authentication all EAP servers MUST enforce channel bindings.  For application
authentication, the EAP server MUST require that the correct EAP lower-layer
attribute be present in the channel binding data.   For network access
authentication, the EAP server MUST require that if channel bindings are
present they MUST contain the correct EAP lower-layer attribute.   All network
access EAP peer implementations SHOULD use channel bindings including the EAP
lower-layer attribute to explicitly identify the reason for authentication.
Any new usage of EAP MUST use channel bindings including the EAP lower-layer
attribute to prevent confusion with network access usage. "

This is looking good, modulo Sam's comment on EAP lower-layer vs. something
else that I'll leave to you and he to sort out.  I have a suggested rewrite,
mostly to clarify MUST vs. SHOULD requirements for support vs. usage, and
to reformat into a structured bullet list of requirements (this is not
intended to change any requirements from what you wrote):

"In environments where EAP is used for purposes other than network access
authentication:

o All EAP servers and all application access EAP peers MUST
support channel bindings.  All network access EAP peers
SHOULD support channel bindings.

o Channel binding MUST be used for all application authentication.
The EAP server MUST require that the correct EAP lower-layer
attribute be present in the channel binding data for
application authentication.


o Channel binding MUST be used for all application authentication.

The EAP server MUST either require that the correct EAP lower-layer

attribute or another attribute indicating the purpose of the authentication
be present in the channel binding data for application authentication.



o Channel binding SHOULD be used for all network access authentication,
and when channel binding data is present, the EAP server MUST
require that it contain the correct EAP lower-layer attribute
to explicitly identify the reason for authentication.

o Any new usage of EAP MUST use channel bindings including the
EAP lower-layer attribute to prevent confusion with network
access usage.

Thanks,
--David



-Original Message-
From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com]
Sent: Tuesday, June 18, 2013 1:47 PM
To: Black, David
Cc: stefan.win...@restena.lu; General Area 
Review Team; ab...@ietf.org;
ietf@ietf.org
Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03



I think we could state this a bit better as something like:

"In environments where EAP is used for applications authentication and network
access authentication all EAP servers MUST understand channel bindings and
require that application bindings MUST be present in application
authentication and that application bindings MUST be absent in network
authentication.   All network access EAP peer implementations SHOULD support
channel binding to explicitly identify the reason for authentication.  Any new
usage of EAP MUST support channel bindings to prevent confusion with network
access usage. "

That text is an improvement, and it's headed in the same direction as Sam's
comment - "application bindings MUST be present in application authentication"
is a "MUST use" requirement, not just a "MUST implement" requirement.

OTOH, I'm not clear on what "application bindings" means, as that term's not
in the current draft.  Specifically, I'm a bit unclear on "application bindings
MUST be absent in network authentication" - does that mean that channel
binding must be absent, or that channel binding is optional, but if channel
binding is present, it MUST NOT be an "application binding", whatever that
is?



[Joe] Good points, the text can be more specific:

"In environments where EAP is used for purposes other than network access
authentication all EAP servers 

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[Andrew Sullivan]

On Thu, Jun 20, 2013 at 11:17:16AM -0400, John C Klensin wrote:
 
> So some review of the DNSEXT-specified procedures and
> expectations may be in order.

I encourage you, then, to organize the BOF session that will spin up
the WG to achieve this.  DNSEXT is only still alive because our last
document hasn't been published.

But more generally, as a practical matter it is better that people
register their stuff with us than that they don't.  We have, in the
wild, a used EDNS0 option code that is all over the Internet.  It is
undocumented, and the code point isn't actually registered.  That
state of affairs is surely worse than that the IETF didn't get to
provide good advice to authors.  DNSEXT already tried to be the DNS
cops, and has failed miserably, partly because of the usual
get-off-my-lawn crowd and partly because people unfamiliar with the
IETF find its procedures a little arcane.

My view is that we need to be more pragmatic.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

NOMCOM 2013 - UPDATE of validated volunteers list so far

[NomCom Chair 2013]

Below is the current validated list of volunteers for Nomcom
2013.  If your name has a *, I'm waiting for a message back
from you.

Big thanks to everyone who has volunteered!

Now what are the rest of you waiting for?

We still need quite a few to get up to 200 volunteers.
Please reply and volunteer - include in the email: your
First Name, Last Name, email addresses you've used in the
last few years in registering for IETF meetings, preferred
email address, primary affiliation, and a contact phone
number for use if you're selected.

Thanks, 

Allison Mankin
Nomcom 2013 Chair


1 John Scudder
2 Stephen Hanna
3 Wassim Haddad
4 Russ White
5 Stephan Wenger
6 ZHAO Yi
7 Eric Gray
8 Steve Kent
9 Toerless Eckert
10 Alia Atlas
11 Victor Kuarsingh
12 Yizhou LI
13 Gonzalo Salgueiro
14 Gang CHEN
15 Ning KONG
16 Marcelo Bagnulo
17 SHEN Shuo 沈烁 (Sean)
18 Fernando Gont
19 Glen Zorn
20 Reinaldo Penno
21 Klaas Wierenga
22 Pascal Thubert
23 Mehmet Ersue
24 Ole Troan
25 Jouni Korhonen
26 Giles Heron
27 Gunter Van de Velde
28 Arturo Servin
29 Eric Vyncke
30 Cullen Jennings
31 Tina Tsou
32 Dhruv Dhody
33 Hongyu LI (Julio)
34 Scott Mansfield
35 John Drake
36 Andrew McLachlan
37 Derek Atkins
38 Suhas Nandakumar
39 Eric Rescorla
40 Karen Seo
41 Stig Venaas
42 Stan Ratliff
43 Ignas Bagdonas
44 Peter Yee
45 Donald Eastlake
46 ZHOU Qian (Cathy)
47 Sam Hartman
48 Lixia Zhang
49 Teemu Savolainen
50 Alvaro Retana
51 Terry Manderson
52 Bill VerSteeg
53 Melinda Shore
54 IJsbrand Wijnands
55 Karen O'Donoghue
56 Benson Schliesser
57 Ari Keränen
58 Fangwei HU
59 Mach CHEN
60 Hui Deng
61 LIU Dapeng
62 Jaap Akkerhuis
63 Magnus Westerlund
64 Zehn CAO
65 Zaheduzzaman Sarker
66 Bhumip Khasnabish
67 Andrew Chi
68 Thomas Nadeau
69 Steven C (Craig) Whilte
70 Orit Levin
71 Sam Aldrin
72 Paul Ebersman
73 Christopher Liljenstolpe
74 Uma Chunduri
75 Suresh Krishnan
76 Varun Singh
77 Ron Bonica
78 Bill (William) Manning
79 Radia Perlman
80 Daniele Ceccarelli
81 Deborah Brungard
82 Kostas Pentikousis
83 Gregory Mirsky
84 Dave Sinicrope
85 Thomas Walsh
86 Zhaohui (Jeffrey) ZHANG
87 Xian ZHANG
88 Mark Townsley
89 Hannes Gredler
90 Brian Trammell
91 Carlos Martinez
92 Peter Koch
93 Daniel Migault
94 Yi (Aaron) Ding
95 Michael Richardson
96 Sohel Khan
97 John Bradley
98 Huaimo Chen
99 Matthew Campagna
100 Keith Drage
101 Chris Bowers
102 Jakob Heitz
103 Tomofumi Okubo
104 Emil Ivov
105 Timothy B. Terriberry
106 JIANG Yuanlong
107 Luigi Iannone
108 Damien Saucez
109 Lou Berger
110 Yana Stamcheva
111 Ondřej Surý
112 Marcin Pilarski
113 Michael StJohns
114 Wes George
115 Christian O'Flaherty
116 Uwe Rauschenbach
117 Olafur Gudmundsson
118 Shwetha Subray Bhandari*
119 Tobias Gondrom
120 Christer Holmberg
121 Susan Hares
122 Kiran Kumar Chittimaneni
123 Donald Fedyk
124 Stephen Botzko*
125 Li Xue*
126 John Sauer*

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[Doug Barton]

On 06/20/2013 09:36 AM, Andrew Sullivan wrote:

On Thu, Jun 20, 2013 at 11:17:16AM -0400, John C Klensin wrote:


So some review of the DNSEXT-specified procedures and
expectations may be in order.


I encourage you, then, to organize the BOF session that will spin up
the WG to achieve this.  DNSEXT is only still alive because our last
document hasn't been published.

But more generally, as a practical matter it is better that people
register their stuff with us than that they don't.  We have, in the
wild, a used EDNS0 option code that is all over the Internet.  It is
undocumented, and the code point isn't actually registered.  That
state of affairs is surely worse than that the IETF didn't get to
provide good advice to authors.  DNSEXT already tried to be the DNS
cops, and has failed miserably, partly because of the usual
get-off-my-lawn crowd and partly because people unfamiliar with the
IETF find its procedures a little arcane.

My view is that we need to be more pragmatic.


I agree with at least a little of what each of Olafur, John, and Andrew 
have said; but I think there's a middle ground between "throw the doors 
wide open" and "everything we have tried before didn't work." At least I 
hope there is.


Perhaps we could have a non-WG mailing list so that people could submit 
proposals for review prior to the expert review process. Even some of 
the "get off my lawn" crowd offered good suggestions for this EUI case 
(make 1 record with a size field rather than 2 records) that could have 
made this whole process a lot smoother.


Doug

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[Ted Lemon]

On Jun 20, 2013, at 1:04 PM, Doug Barton  wrote:
> Perhaps we could have a non-WG mailing list so that people could submit 
> proposals for review prior to the expert review process. Even some of the 
> "get off my lawn" crowd offered good suggestions for this EUI case (make 1 
> record with a size field rather than 2 records) that could have made this 
> whole process a lot smoother.

You mean like "namedroppers"?

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[joel jaeggli]

On 6/20/13 10:04 AM, Doug Barton wrote:


I agree with at least a little of what each of Olafur, John, and 
Andrew have said; but I think there's a middle ground between "throw 
the doors wide open" and "everything we have tried before didn't 
work." At least I hope there is.


Well recall that we still have DNSOP, which along with the dnsext 
mailing list once the wg is closed is probably a reasonable place to 
get/look for feedback.
Perhaps we could have a non-WG mailing list so that people could 
submit proposals for review prior to the expert review process. Even 
some of the "get off my lawn" crowd offered good suggestions for this 
EUI case (make 1 record with a size field rather than 2 records) that 
could have made this whole process a lot smoother.
My impression of the outcome of the procedure change for the registry is 
the wg didn't feel that there should be any particular obstacle  beyond 
expert review for registration. It is possible that reasonable people 
should disagree on the application of given rr-types and that they 
should be registered anyway.


In 30 years we've allocated ~120 rrtypes most of which we don't use   
anymore.


Doug

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[Andrew Sullivan]

On Thu, Jun 20, 2013 at 10:04:54AM -0700, Doug Barton wrote:

> Perhaps we could have a non-WG mailing list so that people could
> submit proposals for review prior to the expert review process.

The WG list isn't going away with the WG.  The list is explicitly
called out as a good place to try out proposals, so people can in fact
do that today.

Best,

A
-- 
Andrew Sullivan
a...@anvilwalrusden.com

namedroppers (wasRe: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard)

[Andrew Sullivan]

On Thu, Jun 20, 2013 at 05:10:20PM +, Ted Lemon wrote:
> You mean like "namedroppers"?

If only we still had that list.  Alas, it was the victim of politics.
Perhaps Randy Bush will bring it back to life.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[Doug Barton]

On 06/20/2013 10:27 AM, Andrew Sullivan wrote:

On Thu, Jun 20, 2013 at 10:04:54AM -0700, Doug Barton wrote:


Perhaps we could have a non-WG mailing list so that people could
submit proposals for review prior to the expert review process.


The WG list isn't going away with the WG.  The list is explicitly
called out as a good place to try out proposals, so people can in fact
do that today.


I would argue that a fresh start here might be appropriate, although I 
wouldn't argue it strongly, and wouldn't object to using dnsext@ if that 
was the consensus.

Re: Conclusions on South American IETF Meeting

[Arturo Servin]

Thank you Bob and the IAOC for taking the time to analize the
possiblities of a meeting outside North America, Europe and Asia.

Independently of the result, I think it had been a good opportunity
for many of us to take advantage of the momentum and to initiate some
actions to promote the IETF.

Regards,
as


On 6/21/13 1:00 AM, The IAOC wrote:
> The IAOC would like to thank all the people who commented on the IETF
> list and responded to the survey. It was very helpful to the IAOC in
> identifying issues and interest.
>
> As of 17 June 2013, the survey had 656 responses. This was more 
> responses than for any other survey we have done, and is more than 
> half of the number of people who usually attend an IETF meeting.
>
> Of the unfiltered data, 72.3% said they would very likely or likely 
> attend a meeting in Buenos Aires. 13.3% said unlikely or very 
> unlikely. Of these 17.1% have not attended an IETF meeting and 38.7% 
> are not on a committee, WG chair, I-D author, or full time student. In 
> this group 169 people (25.7%) were from South America, Latin America, 
> or the Caribbean. The unfiltered survey results can be found at:
>
> http://iaoc.ietf.org/documents/SurveySummary_Unfiltered_06172013.pdf
>
> Applying a filter of only looking at the most active participants 
> (that is, IESG, IAB, IAOC, NomCom members, WG chairs, and I-D authors) 
> the Likely and Very Likely is 71.8% indicated they will attend, and 
> 13.8% said they were unlikely or very unlikely. In this group 26 
> people (7.0%) were from South America, Latin America, or the 
> Caribbean. Also, this group of the most active participants was Likely 
> or Very Likely to attend London at 85.9% (higher than South America) 
> and Yokohama at 68.4% (lower than South America). The filtered survey 
> results can be found at:
>
> http://iaoc.ietf.org/documents/SurveySummary_Active_06172013-1.pdf
>
> Based on these survey results, we conclude there would be good 
> attendance at a meeting in Buenos Aires overall, good attendance from 
> people in the region, and that most active participants will attend. 
> Active participants would attend at similar rates to their attendance 
> at other IETF meetings. From this viewpoint, holding a meeting in 
> Buenos Aires appears to be similar holding it in other locations 
> around the world.
>
> The results from the survey by itself do not mean we should have an 
> IETF meeting in Buenos Aires, but it does eliminate several reasons 
> why we should not have a meeting there.
>
> The harder questions as discussed on the IETF list relate to if we 
> should have a meeting in Buenos Aires.
>
> The first part of this relates to whether having a single meeting in 
> South America will increase IETF participation from that region and 
> increase the diversity in the IETF. This was discussed a lot on the 
> IETF list. We agree that a single meeting isn't sufficient. We have 
> been talking with the Internet Society (ISOC) about programs and 
> events that could be held in the region leading up to and following an 
> IETF meeting in the region. They said that ISOC is planning to hold a 
> series of events and programs in South America. This would include:
>
>   - Increasing the IETF Fellows and policy makers from the region
>   - Local meetings about IETF technologies
>   - Local meetings about Internet deployment approaches
>   - Local meetings with general information on how the IETF works and 
>  how to participate
>
> The more detailed plan we received from ISOC can be found at:
>
>  
> http://iaoc.ietf.org/documents/ISOC%20Activities%20supporting%20IETF%20in%20LAC.pdf
>
> The IAOC thinks that scheduling an IETF meeting in Beunos Aires and 
> announcing a series of events will increase the participation from 
> this region and may improve the IETF's cultural diversity.
>
> The other general questions raised on the list are why should we do 
> this and will having a meeting in South America really help with the 
> issues we see relating to advancing the IETF in political and 
> international circles. Some people expressed skepticism that this 
> would really help. We don't think we can prove this factually, it is a 
> judgment call to a large extent, but we think the combination of the 
> IETF meeting and the ISOC events in the region will help.
>
> The IAOC will proceed with planning a single meeting in Buenos Aires 
> based on what we have heard from the community, the survey, and our 
> discussions with ISOC regarding organizing events in South America. We 
> will also continue to track attendance from participants in all 
> regions.
>
> We thank you for providing feedback on the IETF list and for 
> responding to the survey.
>
> Bob Hinden
> IAOC Chair

Re: Conclusions on South American IETF Meeting

[Carlos M. Martinez]

+1!

On 6/20/13 3:13 PM, Arturo Servin wrote:
> 
> Thank you Bob and the IAOC for taking the time to analize the
> possiblities of a meeting outside North America, Europe and Asia.
> 
> Independently of the result, I think it had been a good opportunity
> for many of us to take advantage of the momentum and to initiate some
> actions to promote the IETF.
> 
> Regards,
> as
> 
> 
> On 6/21/13 1:00 AM, The IAOC wrote:
>> The IAOC would like to thank all the people who commented on the IETF
>> list and responded to the survey. It was very helpful to the IAOC in
>> identifying issues and interest.
>>
>> As of 17 June 2013, the survey had 656 responses. This was more 
>> responses than for any other survey we have done, and is more than 
>> half of the number of people who usually attend an IETF meeting.
>>
>> Of the unfiltered data, 72.3% said they would very likely or likely 
>> attend a meeting in Buenos Aires. 13.3% said unlikely or very 
>> unlikely. Of these 17.1% have not attended an IETF meeting and 38.7% 
>> are not on a committee, WG chair, I-D author, or full time student. In 
>> this group 169 people (25.7%) were from South America, Latin America, 
>> or the Caribbean. The unfiltered survey results can be found at:
>>
>> http://iaoc.ietf.org/documents/SurveySummary_Unfiltered_06172013.pdf
>>
>> Applying a filter of only looking at the most active participants 
>> (that is, IESG, IAB, IAOC, NomCom members, WG chairs, and I-D authors) 
>> the Likely and Very Likely is 71.8% indicated they will attend, and 
>> 13.8% said they were unlikely or very unlikely. In this group 26 
>> people (7.0%) were from South America, Latin America, or the 
>> Caribbean. Also, this group of the most active participants was Likely 
>> or Very Likely to attend London at 85.9% (higher than South America) 
>> and Yokohama at 68.4% (lower than South America). The filtered survey 
>> results can be found at:
>>
>> http://iaoc.ietf.org/documents/SurveySummary_Active_06172013-1.pdf
>>
>> Based on these survey results, we conclude there would be good 
>> attendance at a meeting in Buenos Aires overall, good attendance from 
>> people in the region, and that most active participants will attend. 
>> Active participants would attend at similar rates to their attendance 
>> at other IETF meetings. From this viewpoint, holding a meeting in 
>> Buenos Aires appears to be similar holding it in other locations 
>> around the world.
>>
>> The results from the survey by itself do not mean we should have an 
>> IETF meeting in Buenos Aires, but it does eliminate several reasons 
>> why we should not have a meeting there.
>>
>> The harder questions as discussed on the IETF list relate to if we 
>> should have a meeting in Buenos Aires.
>>
>> The first part of this relates to whether having a single meeting in 
>> South America will increase IETF participation from that region and 
>> increase the diversity in the IETF. This was discussed a lot on the 
>> IETF list. We agree that a single meeting isn't sufficient. We have 
>> been talking with the Internet Society (ISOC) about programs and 
>> events that could be held in the region leading up to and following an 
>> IETF meeting in the region. They said that ISOC is planning to hold a 
>> series of events and programs in South America. This would include:
>>
>>   - Increasing the IETF Fellows and policy makers from the region
>>   - Local meetings about IETF technologies
>>   - Local meetings about Internet deployment approaches
>>   - Local meetings with general information on how the IETF works and 
>>  how to participate
>>
>> The more detailed plan we received from ISOC can be found at:
>>
>>  
>> http://iaoc.ietf.org/documents/ISOC%20Activities%20supporting%20IETF%20in%20LAC.pdf
>>
>> The IAOC thinks that scheduling an IETF meeting in Beunos Aires and 
>> announcing a series of events will increase the participation from 
>> this region and may improve the IETF's cultural diversity.
>>
>> The other general questions raised on the list are why should we do 
>> this and will having a meeting in South America really help with the 
>> issues we see relating to advancing the IETF in political and 
>> international circles. Some people expressed skepticism that this 
>> would really help. We don't think we can prove this factually, it is a 
>> judgment call to a large extent, but we think the combination of the 
>> IETF meeting and the ISOC events in the region will help.
>>
>> The IAOC will proceed with planning a single meeting in Buenos Aires 
>> based on what we have heard from the community, the survey, and our 
>> discussions with ISOC regarding organizing events in South America. We 
>> will also continue to track attendance from participants in all 
>> regions.
>>
>> We thank you for providing feedback on the IETF list and for 
>> responding to the survey.
>>
>> Bob Hinden
>> IAOC Chair
> 

Re: Is the IETF is an international organization? (was: IETF Diversity)

[SM]

At 08:02 20-06-2013, Mark Nottingham wrote:
Keep in mind that you're talking to an organisation that believes 
that Vancouver qualifies as "Asia."


That should be added to the Tao. :-)

At 08:24 20-06-2013, John C Klensin wrote:

Political convenience and expedience trumps geographical reality
every time :-)


The question I would ask is how many continents are there.

Regards,
-sm 

IAOC Website Updated

[IETF Administrative Director]

One of the IAOC goals for 2013 was to update the IAOC website to improve
consistency, organization, linkage, and ease of use.

I am pleased to announce that the IAOC site has been updated and is available 
now for your use at .

On the home page see a video of an Overview of the IAOC given by Chair Bob
Hinden in Orlando that includes a discussion of venue selection and IETF 
finances.  Also on the home page are recent announcements, as well as reports
from IANA, the RFC Editor, the IETF Chair, the NomCom Chair, and more.

The navigation bar makes it easy to find financial statements, minutes,
meeting sponsorship opportunities, and much more.

We hope you find this helpful, the IAOC as more transparent, and of course we
welcome your feedback.

Ray
IETF Administrative Director

PS:  Going to IETF 87 in Berlin?  The IAOC will be doing another overview
session there, Sunday July 28 at 3:00 PM.  Hope to see you there!

Policy makers (was: Conclusions on South American IETF Meeting)

[SM]

At 11:00 20-06-2013, The IAOC wrote:

series of events and programs in South America. This would include:

  - Increasing the IETF Fellows and policy makers from the region


I don't see any policy makers reviewing 
Internet-Drafts.  I don't see any policy makers 
writing IETF RFCs.  Policy makers do not usually 
participate in IETF discussions.


During the diversity discussions it has been 
pointed out that it would be useful if there were 
more network operators and people who can write 
code participating in the IETF.  What the IAB 
seems to be have recommended instead is to 
increase the number of policy makers attending IETF meetings.


I am reminded of a sentence from Patrik 
Fältström: "And to some degree there might be 
parties that see the lack of progress as a good 
thing...".  I hope that the IAB is not one of 
these parties as it might be seen as using the 
IETF for its political convenience.


Regards,
-sm 

Re: namedroppers (wasRe: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard)

[Randy Bush]

>> You mean like "namedroppers"?
> If only we still had that list.

any reports of its death are from questionable sources

> it was the victim of politics.

like much of life

randy

Re: Is the IETF is an international organization? (was: IETF Diversity)

[Fred Baker (fred)]

On Jun 20, 2013, at 11:26 AM, SM  wrote:

> At 08:02 20-06-2013, Mark Nottingham wrote:
>> Keep in mind that you're talking to an organisation that believes that 
>> Vancouver qualifies as "Asia."
> 
> That should be added to the Tao. :-)
> 
> At 08:24 20-06-2013, John C Klensin wrote:
>> Political convenience and expedience trumps geographical reality
>> every time :-)
> 
> The question I would ask is how many continents are there.

One. The rest are islands. Asia, by the way, is a peninsula sticking out from 
Europe.

Now that we've cleared that up...

Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Ben Campbell]

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-thornburgh-adobe-rtmfp-07
Reviewer: Ben Campbell
Review Date:  2013-06-20
IETF LC End Date: 2013-06-25

Summary: This draft is almost ready for publication as an informational RFC. 
However, I have some concerns about the purpose and intended status of the 
document that I think should be considered prior to publication.


Note: This is an informational draft that describes what I understand to be an 
existing protocol as implemented by commercial products. Therefore, this review 
does not attempt to evaluate the protocol itself. I assume the protocol is what 
it is, and it is not up to the IETF to agree or disagree with it.

*** Major issues:

-- Why does this need to be published as an IETF stream RFC?  If I understand 
correctly, this documents an existing protocol as implemented by commercial 
products. I agree with Martin's comment that there is value in publishing this 
sort of thing, but I applaud the Adobe and the author for publishing it so 
other implementations can interoperate with their products. But that could have 
done that in an independent stream document, or even in an Adobe published 
document. (Perhaps even in a prettier format ;-)  )  If we publish this as an 
IETF stream document, then I think it needs stronger clarification that it is 
not an IETF consensus doc than just its informational status.

Along those lines:

-- Is this document the authoritative specification? (I suspect not.) 
Who owns change control? I assume that to be Adobe and/or the authors. What 
expectation do readers of this draft have that it represents the current 
version of RTMFP at any point in time?

-- Under what circumstances would one desire to implement this? I can 
infer that from the introduction, but it would be nice to see some sort of 
applicability statement making it explicitly clear that this is not an IETF 
protocol, and that one would implement it in order to interoperate with certain 
Adobe products. I know that some of this may be implied by the fact that this 
is informational rather than standards track. But I don't expect readers who 
are not IETF insiders to understand that subtlety without some explicit words 
to that effect. In particular, it would be good to clarify the difference 
between this and the many "not quite accepted as standards track by some 
working group" nature of a number of our informational RFCs that describe 
protocols.

That all being said, this is overall a well written document. The rest of my 
comments are mostly pedantic nits.

*** Minor issues:

-- section 1.2: 

I find the use of "MUST ONLY" confusing. I gather it means "you are _allowed_ 
to do X only under certain conditions" rather than "you are _required_ to do X 
under certain conditions." If correct, I think the words "MAY ONLY" would be 
more clear. If not, then I think the construct would be better handled using 
existing 2119 language.

-- section 3.2:

Do I understand correctly that all endpoints are expected to be able to present 
certificates? Do you find that common in the field? I realize the nature of the 
certs will depend on the security profiles.

-- sections 3.2 and 5

Do I assume correctly that endpoints need a common crypto profile to 
communicate? Is there a repository where one might find crypto profile 
documentation? Is there a commonly implemented one to which this draft could 
refer?

-- section 3.2: "Multiple endpoints SHOULD NOT have the same identity."

Why not MUST? Will things not break if two endpoints do have the same identity?

-- "Authenticity MAY comprise verifying an issuer signature chain in a public 
key infrastructure"

Is that really normative, or just an observation of fact?

-- " Canonical Endpoint Discriminators for distinct identities SHOULD be 
distinct."

What if they are not? Do things break? It might be worth making this a MUST, or 
adding some additional guidance about what might happen if the SHOULD is 
violated.

-- "A comparison function MAY comprise performing a lexicographic ordering..."

Is that really normative, or just an example of something one might do?

-- "A test SHOULD comprise testing whether the certificates are identical."

What if it doesn't? Also, what constitutes "identical"? All fields match 
values? Bitwise match?  Is it simply including the same identity or identities? 
Maybe an identity function provided by the crypto profile?

-- 3.5, last paragraph:

Can you offer guidance on reasonable buffer size and number ranges?

-- 3.5.1.1.1, 3rd paragraph:

What are the consequences of having a tag with less than 8 bytes of length? Is 
the SHOULD reasonable here?

-- 3.5.1.1.1 throughout, and following sections:

Does the upper case AND have special meaning?

-- 3.5.1.

Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[John C Klensin]

--On Thursday, June 20, 2013 12:36 -0400 Andrew Sullivan
 wrote:

> On Thu, Jun 20, 2013 at 11:17:16AM -0400, John C Klensin wrote:
>  
>> So some review of the DNSEXT-specified procedures and
>> expectations may be in order.
>...
> But more generally, as a practical matter it is better that
> people register their stuff with us than that they don't.  We
> have, in the wild, a used EDNS0 option code that is all over
> the Internet.  It is undocumented, and the code point isn't
> actually registered.  That state of affairs is surely worse
> than that the IETF didn't get to provide good advice to
> authors.  DNSEXT already tried to be the DNS cops, and has
> failed miserably, partly because of the usual get-off-my-lawn
> crowd and partly because people unfamiliar with the IETF find
> its procedures a little arcane.
> 
> My view is that we need to be more pragmatic.

Andrew,

Just to be clear, I completely agree.  I thought that should
have been clear from the context of my note (context that you
omitted above).  I think that what I have referred to as the
lightweight registration procedure is just fine.  What I have
objected to since the first time a Last Call on the present
document was initiated is any assertion that, because something
is registered, it is entitled to be documented in the RFC
Series.   I object even more strongly to any implication that
such a registered RRTYPE should be accepted as a Standards Track
document without any further review because it is registered
already.

I thought that issue had been settled for this document by
reclassifying its intended status to Informational and
clarifying the relationship of the RRTYPEs to other
consideration, particularly privacy ones.  IMO, that
clarification along makes it worth publishing as an RFC, but the
notion of entitlement was, I thought, put to rest.

Consequently, I was mildly astonished when Olafur's comment
(which included the information that he is co-chair of DNSEXT)
included "...we (DNS community) want to encore [sic] that any
such allocations be published as RFC's for future references".  

So, once again and in short sentences:

(1) The present registration procedure does nothing to ensure
any such thing.

(2) There is nothing else in either IETF or RFC Editor
procedures that ensures RFC publication.  If a document
describing an already-registered RRTYPE is submitted and some AD
wants to sponsor it for publication as an individual submission
and puts it into a Last Call on that basis, the community may
pick at it, insist on changes, or even reach consensus that it
should not be published.

(3) I think the above is fine.  If someone (else) thinks that
RFC publication should be "ensured" for any RRTYPE allocation,
then they need to persuade whomever needs to be persuaded to
modify the registration procedure.   I would, personally, oppose
that change if it eliminated the possibility of quick,
lightweight, registrations but my opinion probably doesn't count
for much relative to the "DNS community" for which Olafur and/or
you are speaking.

best,
john

Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Barry Leiba]

>
> -- Why does this need to be published as an IETF stream RFC?  If I
> understand correctly, this documents an existing protocol as implemented by
> commercial products. I agree with Martin's comment that there is value in
> publishing this sort of thing, but I applaud the Adobe and the author for
> publishing it so other implementations can interoperate with their
> products. But that could have done that in an independent stream document,
> or even in an Adobe published document. (Perhaps even in a prettier format
> ;-)  )  If we publish this as an IETF stream document, then I think it
> needs stronger clarification that it is not an IETF consensus doc than just
> its informational status.


 FWIW, the IESG has discussed this in the context of other documents, and
is looking at boilerplate that does not say that the document is a "product
of the IETF", and makes it clear that the content is not a matter of IETF
consensus.  If that sort of boilerplate was used, do you think that would
be sufficient?

Barry

Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[John C Klensin]

--On Thursday, June 20, 2013 22:14 -0400 Barry Leiba
 wrote:

>  FWIW, the IESG has discussed this in the context of other
> documents, and is looking at boilerplate that does not say
> that the document is a "product of the IETF", and makes it
> clear that the content is not a matter of IETF consensus.  If
> that sort of boilerplate was used, do you think that would be
> sufficient?

FWIW, many IETF Stream Info documents definitely are "matters of
IETF consensus", even more so when those documents are the
consequence of a WG request to publish.   IMO, if a document
really isn't an IETf product in any way and has no relationship
to IETF consensus, it would be far more reasonable for ADs to
simply decline to sponsor it --leaving the document to the
Independent Submission Editor or outside the RFC Series-- rather
than trying to diddle around with boilerplate... especially
since we know that people rarely pay attention to stock
boilerplate.

The option of sponsoring individual submission informational
documents is one that the community granted the IESG in order to
give you folks a reasonable way to deal with circumstances that
were more or less unusual.  You don't need to use it.

   john

p.s. I started a much more detailed response to Ben, but I think
the essence of it is above.  IMO, a discussion that amounts to
whether or not an AD used bad judgment by choosing to sponsor an
individual Informational submission (or whether ADs should have
that power at all) should not become part of evaluating a
particular document's appropriateness.

Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Ben Campbell]

On Jun 20, 2013, at 9:14 PM, Barry Leiba  wrote:

> -- Why does this need to be published as an IETF stream RFC?  If I understand 
> correctly, this documents an existing protocol as implemented by commercial 
> products. I agree with Martin's comment that there is value in publishing 
> this sort of thing, but I applaud the Adobe and the author for publishing it 
> so other implementations can interoperate with their products. But that could 
> have done that in an independent stream document, or even in an Adobe 
> published document. (Perhaps even in a prettier format ;-)  )  If we publish 
> this as an IETF stream document, then I think it needs stronger clarification 
> that it is not an IETF consensus doc than just its informational status.
> 
>  FWIW, the IESG has discussed this in the context of other documents, and is 
> looking at boilerplate that does not say that the document is a "product of 
> the IETF", and makes it clear that the content is not a matter of IETF 
> consensus.  If that sort of boilerplate was used, do you think that would be 
> sufficient?
> 

I think that would help, depending on the specific language. My concerns about 
change control, authoritative specs, etc might still apply depending on the 
boilerplate details.

Thanks!

Ben.

Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Ben Campbell]

On Jun 20, 2013, at 10:12 PM, John C Klensin  wrote:

> p.s. I started a much more detailed response to Ben, but I think
> the essence of it is above.  IMO, a discussion that amounts to
> whether or not an AD used bad judgment by choosing to sponsor an
> individual Informational submission (or whether ADs should have
> that power at all) should not become part of evaluating a
> particular document's appropriateness.

I certainly didn't mean this to be a discussion of AD judgement. I suspect this 
would not be the first time the IETF has published an informational RFC that 
describes a non-IETF protocol, so there's probably precedent for doing so. It 
might be worth discussing whether that's a good precedent.

I also recognize that the authors have done a _lot_ of work on this draft, so 
this entire discussion is probably a bit unfair to them. I actually do hope it 
gets published somewhere.

Thanks!

Ben.

Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of 164 messages in the last 7 days.
 
script run at: Fri Jun 21 00:53:02 EDT 2013
 
Messages   |  Bytes| Who
+--++--+
  7.93% |   13 |  6.46% |83622 | stpe...@stpeter.im
  6.10% |   10 |  5.81% |75305 | do...@dougbarton.us
  4.88% |8 |  3.91% |50591 | melinda.sh...@gmail.com
  4.27% |7 |  4.48% |58056 | john-i...@jck.com
  3.05% |5 |  4.91% |63546 | david.bl...@emc.com
  3.05% |5 |  3.70% |47900 | hal...@gmail.com
  3.05% |5 |  3.37% |43652 | yd...@cs.helsinki.fi
  3.66% |6 |  2.68% |34743 | d...@dcrocker.net
  2.44% |4 |  3.47% |44982 | jsalo...@cisco.com
  2.44% |4 |  2.11% |27359 | s...@resistor.net
  2.44% |4 |  2.03% |26268 | ted.le...@nominum.com
  2.44% |4 |  2.01% |26016 | joe...@bogus.com
  2.44% |4 |  1.95% |25313 | jari.ar...@piuha.net
  1.83% |3 |  2.27% |29410 | morrowc.li...@gmail.com
  1.83% |3 |  2.01% |25980 | abdussalambar...@gmail.com
  1.83% |3 |  1.83% |23694 | p...@frobbit.se
  1.83% |3 |  1.79% |23217 | b...@nostrum.com
  1.83% |3 |  1.56% |20167 | y...@checkpoint.com
  1.83% |3 |  1.49% |19314 | war...@kumari.net
  1.22% |2 |  2.05% |26509 | ed.le...@neustar.biz
  1.83% |3 |  1.42% |18361 | hartm...@painless-security.com
  1.83% |3 |  1.24% |16039 | a...@anvilwalrusden.com
  1.83% |3 |  1.23% |15972 | paul.hoff...@vpnc.org
  0.61% |1 |  2.41% |31232 | rjspa...@nostrum.com
  1.83% |3 |  1.14% |14763 | ra...@psg.com
  1.22% |2 |  1.68% |21721 | suresh.krish...@ericsson.com
  0.61% |1 |  2.27% |29379 | magnus.westerl...@ericsson.com
  1.22% |2 |  1.42% |18391 | doug.mtv...@gmail.com
  1.22% |2 |  1.40% |18104 | arturo.ser...@gmail.com
  1.22% |2 |  1.36% |17556 | nar...@us.ibm.com
  1.22% |2 |  1.35% |17460 | carlosm3...@gmail.com
  1.22% |2 |  1.27% |16497 | kathleen.moria...@emc.com
  1.22% |2 |  1.19% |15475 | f...@cisco.com
  1.22% |2 |  1.02% |13166 | br...@innovationslab.net
  1.22% |2 |  0.86% |11137 | aser...@lacnic.net
  1.22% |2 |  0.70% | 9102 | j...@mercury.lcs.mit.edu
  0.61% |1 |  1.10% |14193 | daedu...@btconnect.com
  0.61% |1 |  0.85% |10959 | presn...@qti.qualcomm.com
  0.61% |1 |  0.83% |10754 | d...@cridland.net
  0.61% |1 |  0.81% |10541 | shollenb...@verisign.com
  0.61% |1 |  0.78% |10037 | chris.dearl...@baesystems.com
  0.61% |1 |  0.74% | 9635 | t...@ecs.soton.ac.uk
  0.61% |1 |  0.73% | 9392 | mirja.kuehlew...@ikr.uni-stuttgart.de
  0.61% |1 |  0.68% | 8857 | f...@isoc.org
  0.61% |1 |  0.66% | 8528 | me...@globetel.com.ph
  0.61% |1 |  0.61% | 7937 | barryle...@computer.org
  0.61% |1 |  0.59% | 7633 | hsan...@isdg.net
  0.61% |1 |  0.59% | 7614 | scott.b...@gmail.com
  0.61% |1 |  0.57% | 7422 | droma...@avaya.com
  0.61% |1 |  0.57% | 7367 | brian.e.carpen...@gmail.com
  0.61% |1 |  0.55% | 7182 | hous...@vigilsec.com
  0.61% |1 |  0.54% | 7035 | nomcom-chair-2...@ietf.org
  0.61% |1 |  0.53% | 6804 | adr...@olddog.co.uk
  0.61% |1 |  0.52% | 6786 | jab...@hopcount.ca
  0.61% |1 |  0.51% | 6609 | ma...@isc.org
  0.61% |1 |  0.51% | 6549 | jo...@taugh.com
  0.61% |1 |  0.50% | 6442 | randy_pres...@mindspring.com
  0.61% |1 |  0.48% | 6250 | mehmet.er...@nsn.com
  0.61% |1 |  0.47% | 6147 | m...@mnot.net
  0.61% |1 |  0.46% | 5925 | turn...@ieca.com
  0.61% |1 |  0.45% | 5781 | jo...@iecc.com
  0.61% |1 |  0.44% | 5733 | stephen.farr...@cs.tcd.ie
  0.61% |1 |  0.44% | 5640 | o...@ogud.com
  0.61% |1 |  0.43% | 5549 | c...@tzi.org
  0.61% |1 |  0.41% | 5339 | d...@xpasc.com
  0.61% |1 |  0.40% | 5241 | d...@virtualized.org
  0.61% |1 |  0.40% | 5212 | i...@ietf.org
+--++--+
100.00% |  164 |100.00% |  1295092 | Total