Allison Mankin | 2 Mar 18:06 2015

TSVDIR LC review: <draft-ietf-bfcpbis-rfc4582bis-13.txt> (The Binary Floor Control Protocol (BFCP)) to Proposed Standard>

[Put into template form and forwarded for the TSVDIR reviewer, Gorry Fairhurst, to expedite while he is traveling]

Please resolve these comments along with any other Last Call comments you may receive.

Document:  draft-ietf-6man-resilient-rs-04.txt
Reviewer: Gorry Fairhurst
Review Date: 2015-03-01
IETF LC End Date: 2015-03-05
IESG Telechat date: ---

Summary: This draft is not ready for publication as a standards track RFC.  

This document defines a control protocol that may be used over TCP or UDP.
The major change between this document and its predecessor RFC4528 is stated to be:

Main purpose of this work was to revise the specification to support BFCP over an unreliable transport (Section 16.1)

The use of UDP raises a number of issues that need to be considered when
used in environments that may experience congestion, long delay, or
limited capacity. Further work appears to be needed to address these
concerns. Citing RFC 5405 as normative (rather than informational) may be
good, and some of the guidance from this BCP suggests protocol issues that
should be examined and justified or amended. Notable concerns are the lack of
support for RTT estimation, and the way in which fragmentation is handled.

There is mention of potential support for SCTP, however the statement on
SCTP appears to need updating.

The intro states:
"BFCP has been designed so that it can be used in low-
bandwidth environments" - there are specific low-bandwidth
concerns when UDP is used. See below.

Section 3.4: Congestion Control
I do not understand how congestion-control is performed on the media flow.
Is it the responsibility of each audio stream to independently react to
congestion? If it is, it would be useful to state this here.

Section 5: Protocol:
"If a floor control server receives a
message with an unsupported version field value, and the extensions
in this document is supported, the receiving server MUST send an
Error message with parameter value 12 (Unsupported Version) to
indicate this. "
- What happens in the case where the receiving server does not support the
extensions in this document? Does it silently discard?

Section 5:

What is the security model when TLS/DTLS is not used? - has the protocol
protection from off-path attacks, and how is this provided?

What is the privacy model when TLS/DTLS is not used?  - Does the protocol
expose the identity of participants to others on the network?

"Res: At this point, the 3 bits"
- This may be better written as perhaps: Res: In version 1 and 2 of the
protocol, the 3 bits".

- Please specify here what a receiver should do with an undefined primitive value!

Payload Length:
- What happens when using a datagram format if the datagram length (e.g.
UDP-Length) is less or more than the value specified within the BFCP?

Conference ID:
- Is the Conference ID randomised to provide protection to mitigate the
chance of off-path data insertion attacks? Note that in section 6.2.4,
symmetric port numbers (src,dst) are recommended, and hence the a random
ephemeral port does not offer protection from off-path attacks in the case
where TLS/DTLS is not used.

Fragment Length:
- What happens if the datagram length (e.g. UDP-Length) is less or more
than the value specified within the BFCP?

Section 6.1: CC:
"if a TCP
connection cannot deliver a BFCP message and times out or receives an
ICMP port unreachable message mid-connection, the TCP connection
SHOULD be reestablished."
- I think this needs more specification. How many times will the TCP
connection be retried in succession? While it seems OK for a session to be
restarted because of a delivery failure, this seems like a
congestion-control problem if it is unconditionally resumed with no
control of the number of attempts, and no requirement to back-off after
repeated failures.

Section 6.2.1: Retransmission interval:
"The default initial interval MUST be set to 500ms "
- The protocol appears to fail systematically  when the actual path RTT is
greater than 500ms. The sender needs not only to expand the timer each
retransmission, but needs to avoid the possibility that every message is
duplicated when the path RTT is greater than 500mS. A simple solution is
for the sender learn the actual RTT and increase the default timer when
this is greater than 500 mS? This seems like a protocol flaw. See RFC 5405
on the need to back-off timers, based on RTT.

Section 6.2.2:
How does the receiving endpoint verify that the ICMP message was from the
corresponding endpoint, is there any field in the protocol header that
could be used to reduce the chance of off-path attacks?

Section 6.2.2:
This section could usefully also refer to RFC 5405.

Section 6.2.3:
"BFCP entities should consider the MTU size"
- This isn't capitalised as "SHOULD", was that intended? I'm unclear what
the intention is here, especially when discussing PMTU-D.

"and MAY run MTU discovery, such as [20][21][22], for this purpose."
- Presumably this is "Path" MTU Discovery.
- The ID does not explain how this is done. Could it be done using dummy
messages (e.g. padded out with unused options?) or some other method to
probe the path? The current text simply does not explain how PMTUD  or
PLPMTUD is implemented, It needs to specify how to generate a "big" packet
and how to handle retransmission.

Congestion Control:
The protocol appears to say it sends a single datagram per RTT, but
actually fragmentation may result in multiple fragments per RTT. This
amplifies the congestion control risk. There appears to be no limit set to
the number of fragments that may be created, and each are presumably sent
as a burst - and all retransmitted if there is a single loss. This could
introduce a significant risk of congestion collapse, if this happens for
multiple consecutive messages.

Timers T1 and T2 are set to a static value by configuration. While the
values suggested may be reasonable default minimum values, these two
values should be increased when a path has a larger RTT to avoid the
protocol replicating all data (see RFC 5405). The current specification
can increase congestion for long RTT paths, and needs to be updated to
reflect paths discovered to have a larger RTT.

B.1.1.6.  SCTP
"It would be quite straight forward to specify a BFCP binding for SCTP
[28], and then tunnel SCTP over UDP in the use case described in
Appendix B.1.  SCTP is gaining some momentum currently.  There is ongoing
discussion in the RTCWeb WG regarding this approach. However, this
approach for tunneling over UDP was not mature enough  when considered and
not even fully specified."
- it seems this dismisses SCTP support, yet this text appears out of date
and needs  to be updated to reflect RFC 6951, and possibly
Richard Shockey | 1 Mar 23:35 2015

Money is the answer? Hum..

>>> The rough consensus process is actually quite good at resisting gaming
>>> by BigEvil Corporation; see sections 6 and 7 of RFC 7282.
>> Again: my concern isn't gaming of consensus, nor do I believe
>> corporations who sponsor their employees' IETF work are evil.  My
>> concern is diversity within the IETF and within the larger sphere of
>> Internet governance.
>Those are two entirely different questions. As far as the IETF goes,
>we need to attract and welcome top class engineers who have the
>capacity *as individuals* to join the technical meritocracy. As far
>as "the larger sphere of Internet governance" goes, the more time
>passes, the less idea I have of what that means or why it matters.

The reality is long term IETF participation is becoming a career limiting
move for a certain class of Internet Engineering professional.  Sadly we
don¹t do stock options. The more bureaucratic we become the more we start
to look like ah .. <cough> Geneva.

As far as the internet governance issue .. Well there are some folks in
the US that have some very definite ideas about that. We¹ll see when the
the latest rockem sockem action packed Report and Order from the FCC looks

Can you define ³fair and reasonable² so what is ³reasonable network

Coming to a laser printer near you in a couple of weeks. Film at 11 (EST)

>And I remind you that this thread started around the question of how
>can we fund a model with more emphasis on remote participation and
>less emphasis on face-to-face meetings. It's a sad fact that without
>money at the level of a few $M per year, we can't fund any model at all.

HummŠ ³Money is the answer, what is the question?"  I seem to have heard
that proposition before.

The obvious answer is for ISOC on behalf of the IETF to take over ICANN
once and for all. 

They certainly have more money than they know what to do with so it seems
logical. We certainly know what to do with it.

Cookies (especially gluten free cookies) and ice cream could be free!
Given ICANN's free cash flow we might be able to add shrimp bowls.


Phillip Hallam-Baker | 27 Feb 15:44 2015

Thinking laterally

Thinking of the remote participant fee. As someone whose travel restrictions prevent attending in certain parts of the world:

* I have no problem paying a fee but I am not the decision maker
* Paying a fee is better for my CFO
* Not paying a fee is even better for my CFO unless we get something for it

One thing I really would like more of as a remote attendee is video of the sessions. That is something worth paying for and it is something that we should have adequate technology base for. If video streaming sessions really is more than plugging in a camera... we is still doin it wrong.

So kicking in $100 a session for video is a no-brainer. Can make this an advance payment thing. The video is only guaranteed if at least one person drops the $100 though and the list of 'sponsors' of the video is only published after the ability to sign up closes.

If someone wants to add video after the fact they pay a full conference fee per session.
Roy T. Fielding | 27 Feb 01:52 2015

Re: Interim meetings - changing the way we work

On Feb 26, 2015, at 3:13 PM, Brian E Carpenter wrote:
> On 27/02/2015 11:34, Lou Berger wrote:
>> On 2/26/2015 5:23 PM, Thomas D. Nadeau wrote:
>>> Those subteams go off on their own for weeks at a time and iterate as needed. And they work without all of
the overhead of a formal meeting. They may or may not discuss progress on the list until issues come up.
>> There's nothing wrong/out of process with this. The key process
>> requirement is that they do review & discuss changes with the WG at some
>> point (which sometimes *is* sometimes a challenge to ensure that it
>> happens), and certainly no later than when the changes are published. 
> And *any* decision taken that way, right down to the choice to use binary
> arithmetic, may be challenged and changed by the WG as a whole, and for
> that matter by the IETF as a whole when it gets to Last Call.

FWIW, that certainly wasn't the case for HTTP/2.  The IETF is currently
very flexible in how chairs are allowed to apply its processes.


Ted Lemon | 26 Feb 23:11 2015

Re: Interim meetings - changing the way we work

On Feb 26, 2015, at 3:47 PM, Joel M. Halpern <jmh <at>> wrote:
> But I have seen nothing in our procedures, or even in emails from ADs to the wg-chairs list, or to the IETF
list, indicating that our leadership expects chairs to live up to this standard.
> Yes, careful analysis suggests that this is really implicit in our current rules.  But it is not happening.

I think this is true, and we should do something about it.

Thomas D. Nadeau | 26 Feb 22:21 2015

Re: Interim meetings - changing the way we work

> On Feb 26, 2015:4:16 PM, at 4:16 PM, Brian E Carpenter <brian.e.carpenter <at>> wrote:
> On 27/02/2015 09:08, Thomas D. Nadeau wrote:
>>> On Feb 26, 2015:2:42 PM, at 2:42 PM, Benson Schliesser <bensons <at>> wrote:
>>> Nico Williams wrote:
>>>> Yes, but a record that a concall or other interim meeting took place,
>>>> and who attended, even if there are incomplete or missing minutes, is
>>>> important for IPR reasons.  Ensuring that such meetings are NOTE WELL
>>>> meetings is (should be) a priority, and that includes ensuring that a
>>>> record of that much exists.
>>>> Ideally the concalls and other interims would be recorded.
>>> I agree completely. My point was that meeting records (including minutes) will inevitably be
incomplete, or possibly inaccurate, and that relying on the mailing list as an authoritative record is
more effective.
>>> Of course it is disappointing that we can't meaningfully translate voice discussions into text, in the
minutes or in mailing list threads. If there were some magic tool e.g. that took better minutes then I'd be
happy to use it. But otherwise, I think we just have to trust chairs to manage WG collaboration in whatever
way is most effective for their WG's collaborators.
>> 	The first step is to agree that an A/V recording is record enough. 
> It absolutely is not enough. Please see my previous message,
> and the relevant rules in RFC 2418.
>   Brian

	You are missing my point. RFC or not, the IETF needs to evolve.


>> Perhaps having meetbot/txt notes that at a min include actions/decisions like we do in the issue tracker
we've used for NETMOD's Yang 1.1's issues. 
>> 	--Tom
>>> This will inevitably be suboptimal for some part of the population. (For instance, I've never been able
to find an interim meeting time that fits the schedules of all attendees.) But if they (we) always revert to
the mailing list for decision making then I suspect our work can remain open and transparent.
>>> Cheers,
>>> -Benson

IETF Chair | 26 Feb 00:08 2015

DNSSEC change on IETF web pages

Some time ago we moved the static parts of the IETF web page to
a CDN service. While this provided a significant improvements for
page load times and retained our ability to serve the pages over
IPv6, we were unable to provide DNSSEC for the web pages 
that were being served by the CDN.

Our CDN vendor, Cloudfare, however, has worked in the 
background to enable DNSSEC for their customers. They 
have now come back with a system that we have enabled 
for the IETF web pages. (Thank you Cloudfare, this was

We plan to keep the new arrangement on at for a while before finally moving
to this arrangement on Testing the
new arrangement on would be

Jari Arkko, IETF Chair

John C Klensin | 25 Feb 15:16 2015

Re:(long/architectural version) Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard


A few comments about, or inspired by, this draft.  Note that
these comments raise issues that go well beyond the particular
URI draft/proposal.  I consider it more important that the
community address those issues than that any particular decision
be made about them for this draft.    These comments are
insensitive to the differences between -10 and -11 although I
believe -11 is an improvement.  My approval recommendation
appears in a separate, shorter, note posted two days ago
although some of the comments below (particularly item (3),
which recommends removing a section) qualify that recommendation
a bit.  That note should probably be read before this one.  

While I believe this specification represents a step forward
given the path we are on, it seems to me to raise several
troubling issues.  This note is an attempt to address four of
those issues, in no particular order:

(1) Integrity of the standards process.  

(2) Iterative DNS use

(3) The state of DDDS and further complicating NAPTR

(4) URIs, URLs, URNs, and the future


(1)  Integrity of the standards process.  

For many years, it was a key IETF principle that standardization
of a particular technology meant that the community had been
able to review all of the details, make changes where needed,
and then reach rough consensus on the result.  The notion of
registering an RRTYPE via Expert Review and then turning around
and asking that it be standardized while claiming that details
(or even design principles) cannot be changed because it is
already registered and in use represents a fundamental departure
from and threat to our historical standardization model.  No
malice is implied here, just a bad sequence of steps.   I don't
know that it makes a lot of difference how this particular spec
is classified, but, noting that the same situation could apply
to a number of other specifications where registration is by
expert review (Media Types come to mind as do URIs and, if
2141bis is approved in more or less its current form, URNs), it
seems to me that the IETF needs to address this issue, perhaps
confining specifications for already registered names to
Informational or Experimental categories and figuring out an
alternative to expert review for specs that people will want on
the standards track. 

(IESG: Please note the interaction between this issue and

Several of the comments below might have been more relevant at
registration time, but, since the spec is going through Last
Call for Proposed Standard, it is at least reasonable to expect
that the spec address and explain the issues involved.

(2)  Iterative DNS use

While I wouldn't argue that everything was gotten right, the
original DNS design was structured to minimize the possibility
of multiplicative latency associated with making an arbitrary
number of lookup trips after a particular domain name was
encountered.  MX records are restricted to use only primary
names (no aliases) in RDATA precisely to avoid having to do a
third or fourth lookup.  If we have decided that multi-stage
iterative lookups are ok after all, that should be documented
and referenced.  If (as I believe to be the case) the main
argument for this URI RR is that it is less problematic than
NAPTR, S-NAPTR, U-NAPTR, and (maybe) SRV, then this document
should probably include a plan about phasing some of those, or
at least some instances of some of those, out.  If, instead,
these five (or fewer, see below) types of potentially-iterative
indirect references are to exist in parallel, it becomes
reasonable to ask that a standards-track document explain how
many more of them are expected or why we should assume this one
is the last.

Speaking of U-NAPTR, this is either a replacement or it isn't.
"Can be viewed" in Section 8 is unsatisfactory in a
standards-track document.  If it is a replacement, then this
document should update RFC 4848 to deprecate that record type
and mechanism.  If it isn't, then this document should explain
when to use which one.

To generalize a bit, if we expect this RRTYPE to be broadly
accepted and used, experience suggests that we should make it as
simple and efficient as possible.  When we do things that add
complexity (see also (3) below), those require explanation and
justification.  Conversely, if we don't have that expectation,
the document should be published as Informational, not proposed
for standardization.

(3) The state of DDDS and further complicating NAPTR

I may have missed important and widely-deployed applications,
but my impression is that DDDS, and the original NAPTR record
format, have not been one of IETF's great success stories, at
least outside of the ENUM space for which NAPTR was first
designed.  While I usually believe in general solutions, more
complexity is both an opportunity for sloppy implementations and
potential attack vectors waiting to be discovered and exploited.

The very fact that NAPTR has been evolved into a series of
variations (of which this one may nearly be the latest),
reinforces the hypothesis that it is time to consider a "don't
use this except for existing, established, applications"
applicability statement for NAPTR and, perhaps, a more general
review of DDDS and _its_ applicability.

Especially against that backdrop, it is troubling that, while
the title, abstract, and introduction to this document are about
adding a URI-specific DNS RRTYPE, Section 5 provides an update
to the NAPTR spec itself that modifies and extended that spec.
It does not explain why that modification is desirable and why
this new RRTYPE does not simply replace NAPTR for relevant uses,
nor does it make recommendations as to when one or the other
should be used.  

Without the excursion into NAPTR modifications, it appears to me
that this specification does not need DDDS at all (further
reducing complexity).

At least absent clear explanation and justification (and with
modifications to the Abstract, Introduction, and maybe title), I
believe Section 5 should be dropped from this specification.
That would turn it into the pure description of a new RRTYPE
that it claims to be.   If modifications to NAPTR and/or
reassessments of DDDS are required, let's put them into an
appropriate separate document and be sure they are properly

If Section 5 were removed, it appears that this specification
would no longer modify/ update RFCs 3404 and 3958, improving its
quality as a self-contained definition of a new RRTYPE.

I have seen no evidence of community review of Section 5.
Because it is rather different from the rest of this
specification, a claim of rough consensus about the document
that includes it and does not show evidence of such review would
be, at best, suspect.

(4) Location abstractions, URIs, URLs, URNs, and the future

Architecturally, having primary user-exposed protocol elements
that identify objects by their rather specific location on the
network is, and has always been, a mistake (in fairness to what
I understand to be the original design of the web and its the
designers, URLs were never expected to be user-visible).  The
issues with an approach in which an object is identified by its
location has led to a large series of approaches and derivations
that, in many cases, have ultimately been workarounds for a bad
idea that have caused their own problems.   We've seen
generalizations of URLs to URIs, some of which have worked
better than others.  We've seen efforts to accommodate local
characters -- to turn URIs from protocol identifiers to
something more user-friendly -- with IRIs and "short" URLs.
We've seen complex URLs with domains identifying search,
redirection, or charging services and the "real" URL buried in
queries.   We've seen several uses for redirection that are
ultimately the result of bad identifiers as well as tricks that
violate the basic DNS design in order to make DNS names
location-dependent.  There have been yet other tricks that try
to create adaptive synonyms for names and subtrees.   We've seen
at least one model for what URNs are about that sees them as
location-independent identifiers that resolve to
location-specific URLs.  We've also seen  the development and
growth of other systems, including Handles and the derivative
DOIs, partially because of a perception that the IETF has been
too concerned with the URI model and has therefore fallen down
on the job.   In many cases, these approaches and techniques
have been expanded into demonstrations of the adage that every
significant design error creates a business opportunity.

The collection of services that use the DNS to point to
URI-identified resources (NAPTR, U-NAPTR, S-NAPTR, URI) can be
seen as yet another approach to that same set of issues,
potentially a set that allows

	  DNS-name-lookup -> URI with DNS authority ->
	DNS-name-lookup -> NAPTR with multiple URIs, several of
	which need to be looked up to determine availability ->
	DNS-name-lookup -> URI with DNS authority -> ... 

with potentially unlimited recursion depth.  Whether that is a
good idea or not (see (2) above), we are developing a rather
large collection of ways to do nearly the same thing, i.e., to
create names that are either location-independent or that can
designate a family of locations.  While multiple ways to do the
same thing are sometimes an advantage, they are more often a
source of confusion (and, again, potential bad implementation
behavior and attack vectors).   It would be _really_ good to do
some architectural work that would lead to both design and
applicability statements, rather than continuing to add more of
them without an obvious plan.


Tim Chown | 25 Feb 14:45 2015

Re: Remote participation fees


> On 15 Feb 2015, at 16:19, James Gannon <james <at>> wrote:
> Speaking purely about the remote participation aspect, I think one of the issues is that yes there are full
featured solutions out there (Adobe Connect for example as used in ICANN) but they can be complex and not cheap.
> The decision would need to be made whether remote participation is of a high enough priority to IETF to go
after a full featured solution first, before then considering means of funding it. As Stephen says I think
if remote participation fees are introduced without the remote experience to match it would not be a success.

So I don’t think there’s a one size fits all requirement here.

Who might want to participate remotely? The list may include:

a) people who have followed a mail list for a while and want to casually join a specific WG session at a meeting
to get a feel for what a session is like
For this, streamed audio is probably fine, with some form of chatroom.
If a question is to be asked, it might be nice to be able to identify the person asking.

b) people who are very active in a WG, but can’t get to a given meeting, but needs high quality
participation (along the lines Randy described earlier)
Here the ability to see slides, and perhaps to present, is likely to be needed. Reliable audio is more important.

c) perhaps a WG chair who can’t make a meeting, but would be willing timezone-permitting to chair
Unless the solution for this is very good, we would want at least one chair present in person (because of the
various administravia to deal with)
Needs are similar to (b), except a way to chat discretely with the co-chair would certainly be useful, and to
see the room, and maybe to hear hums.

What other cases are there? How do we do a virtual Ted?

Then there’s the question of whether the participant is interested in just one WG, and thus minimal
attendance, or attendance for multiple WGs in the week.

Perhaps charging is introduced for higher quality access (cases b, c), while casual ‘best effort’
remote participation is kept open and free (case a).

BTW a focus on the meeting room experience misses out on a big piece of value in attending - the corridor and
bar room discussions.


IETF Secretariat | 24 Feb 18:01 2015

IETF Hackathon at IETF 92, March 21-22, Dallas, TX

The Internet Engineering Task Force (IETF) is holding a Hackathon to encourage developers to discuss,
collaborate and develop utilities, ideas, sample code and solutions that show practical
implementations of IETF standards. It takes place just before IETF 92, and it’s free and open to everyone.

All you need is a knowledge of networking technologies, and you’ll be guaranteed to learn something new
and have fun!

Event details:
Link to register:

Thomas Narten | 20 Feb 06:53 2015

Weekly posting summary for ietf <at>

Total of 166 messages in the last 7 days.

script run at: Fri Feb 20 00:53:02 EST 2015

    Messages   |      Bytes        | Who
  9.04% |   15 |  6.77% |   111524 | ted.lemon <at>
  5.42% |    9 |  7.15% |   117792 | dave <at>
  6.63% |   11 |  5.57% |    91701 | john-ietf <at>
  4.82% |    8 |  7.34% |   120878 | mary.h.barnes <at>
  4.22% |    7 |  5.14% |    84699 | superuser <at>
  4.82% |    8 |  3.97% |    65363 | mcr+ietf <at>
  4.22% |    7 |  4.01% |    66026 | brian.e.carpenter <at>
  3.01% |    5 |  2.29% |    37643 | jari.arkko <at>
  3.01% |    5 |  2.14% |    35301 | john <at>
  2.41% |    4 |  2.40% |    39577 | phill <at>
  1.81% |    3 |  2.94% |    48366 | allison.mankin <at>
  1.81% |    3 |  2.93% |    48274 | spromano <at>
  1.81% |    3 |  2.54% |    41843 | <at>
  2.41% |    4 |  1.85% |    30481 | melinda.shore <at>
  2.41% |    4 |  1.72% |    28374 | hartmans-ietf <at>
  0.60% |    1 |  3.48% |    57252 | albert.cabellos <at>
  1.81% |    3 |  1.80% |    29663 | marc.blanchet <at>
  1.81% |    3 |  1.80% |    29583 | ynir.ietf <at>
  1.20% |    2 |  2.08% |    34290 | cveraq <at>
  1.20% |    2 |  1.39% |    22946 | masinter <at>
  1.20% |    2 |  1.12% |    18492 | daedulus <at>
  1.20% |    2 |  1.12% |    18387 | alexey.melnikov <at>
  1.20% |    2 |  1.07% |    17564 | housley <at>
  1.20% |    2 |  1.07% |    17553 | info <at>
  1.20% |    2 |  1.07% |    17546 | bmoeller <at>
  1.20% |    2 |  1.00% |    16442 | jmh <at>
  1.20% |    2 |  0.95% |    15730 | stbryant <at>
  1.20% |    2 |  0.92% |    15127 | ggx <at>
  1.20% |    2 |  0.88% |    14570 | christer.holmberg <at>
  1.20% |    2 |  0.88% |    14483 | ietf-secretariat <at>
  1.20% |    2 |  0.87% |    14393 | stephen.farrell <at>
  1.20% |    2 |  0.87% |    14368 | randy <at>
  1.20% |    2 |  0.85% |    13951 | lixia <at>
  1.20% |    2 |  0.82% |    13555 | paul.hoffman <at>
  0.60% |    1 |  1.39% |    22862 | bjoernboesch <at>
  1.20% |    2 |  0.76% |    12509 | nico <at>
  0.60% |    1 |  1.11% |    18288 | ted.ietf <at>
  0.60% |    1 |  0.85% |    13976 | spencerdawkins.ietf <at>
  0.60% |    1 |  0.80% |    13149 | peter <at>
  0.60% |    1 |  0.77% |    12726 | chair <at>
  0.60% |    1 |  0.72% |    11890 | ron.even.tlv <at>
  0.60% |    1 |  0.68% |    11142 | otroan <at>
  0.60% |    1 |  0.64% |    10556 | james <at>
  0.60% |    1 |  0.63% |    10377 | thomas.haynes <at>
  0.60% |    1 |  0.59% |     9716 | suresh.krishnan <at>
  0.60% |    1 |  0.58% |     9607 | narten <at>
  0.60% |    1 |  0.55% |     9016 | lear <at>
  0.60% |    1 |  0.52% |     8574 | ietf <at>
  0.60% |    1 |  0.51% |     8428 | k.pentikousis <at>
  0.60% |    1 |  0.50% |     8229 | rpelletier <at>
  0.60% |    1 |  0.46% |     7657 | barryleiba <at>
  0.60% |    1 |  0.45% |     7436 | mhammer <at>
  0.60% |    1 |  0.44% |     7226 | scott <at>
  0.60% |    1 |  0.43% |     7010 | rsk <at>
  0.60% |    1 |  0.42% |     6898 | loa <at>
  0.60% |    1 |  0.41% |     6684 | mcr <at>
  0.60% |    1 |  0.40% |     6642 | ned+ietf <at>
  0.60% |    1 |  0.39% |     6434 | turners <at>
  0.60% |    1 |  0.38% |     6323 | dwm <at>
  0.60% |    1 |  0.38% |     6318 | adrian <at>
  0.60% |    1 |  0.38% |     6275 | farinacci <at>
  0.60% |    1 |  0.38% |     6263 | derhoermi <at>
  0.60% |    1 |  0.38% |     6188 | dhc <at>
  0.60% |    1 |  0.32% |     5221 | nomcom-chair-2014 <at>
100.00% |  166 |100.00% |  1647357 | Total