Re: TCPMUX (RFC 1078) status

[Martin Sustrik]

On 21/08/13 19:00, Joe Touch wrote:


So what would you use for muxing, if TCPMUX is not a good idea?


You need to roll your own. The requirements of systems vary widely, as
do the costs/benefits of different approaches.

I listed a few before, but here's a more comprehensive list:
 - service per message
 demux based on message ID
 use IPC (interprocess comm) to handoff internal
 to your system

 - service per connection
 demux based on the first message in an
 association (TCP or UDP), and either continue to
 forward messages to a different process or handoff
 the connection


So, if I proceed with this option why not use RFC1078 to implement it? 
Why write a new RFC if there's an old one that fits the bill?




 - subservice on different ports
 determine what subservice you want to initiate,
 start it on an ephemeral port, and indicate the
 port number in-band (e.g., as with FTP and others)


Martin

Re: TCPMUX (RFC 1078) status

[Martin Sustrik]

On 21/08/13 20:03, Bob Braden wrote:


Indeed, TCPMUX is quite historic... it represents a Road Not Taken. My
memory is a bit hazy after 30+ years,
but I think there was a serious discussion around 1979 of using strings
instead of contact port numbers
for opening TCP connections. Here is the hazy part... I *think* that
Chaosnet used strings, and two
well known MIT Daves introduced a proposal to adopt this mechanism for
TCP. (Also, maybe XNS
used strings? Not sure about that...) The internet working group
ultimately rejected the idea, I think when Jon Postel argued that
contact ports provided greater conceptual economy.


Hi Bob, thanks for historic insight. Btw, do you remember why TCPMUX was 
even defined given the above sentiment?



Maybe I got this wrong, but in any case I hope that someone else who was
in the room then will correct me. Jack? Vint? Dave?  Danny?


Martin

Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Måns Nilsson]

Subject: Re: [spfbis] Last Call:  (Sender 
Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to 
Proposed Standard Date: Thu, Aug 22, 2013 at 12:23:56AM -0400 Quoting Scott 
Kitterman (scott@kitterma
> On Thursday, August 22, 2013 00:26:35 Måns Nilsson wrote:
> ...
> > SPF is a flagship case for the "use a TXT record and continue to IPO"
> > fast and sloppy crowd. It needs correcting. Badly.
> 
> Which IPO was that?
> 
> BTW, in 2003 the choice was use TXT or nothing.  So it was a crowd that 
> wanted 
> to accomplish something and did it the only way it was possible.  Considering 
> use of TXT wasn't an important factor in the DKIM last call, I conclude that 
> this isn't really about using TXT.

It indeed is -- but SPF is as I wrote above a flagship case. SPF was the
first, is the most deployed (as its supporters repeatedly assert, wringing
their hands, trying to sound apologetical and/or defaîtistic) case of
tragedy in the commons that is "automated data processing of content
in comments" and when its proponents try to codify the behaviour of
stampeding into the commons by removing the SPF rrtype, enough is enough.

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
Are we THERE yet?


signature.asc
Description: Digital signature

Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Jelte Jansen]

On 08/21/2013 08:44 PM, Olafur Gudmundsson wrote:
> 
> Most of the recent arguments against SPF type have come down to the following 
> (as far as I can tell): 
>   a) I can not add SPF RRtype  via my provisioning system into my DNS 
> servers
>   b) My firewall doesl not let SPF Records through 
>   c) My DNS library does not return SPF records through or does not 
> understand it, thus the application can not receive it.
>   d) Looking up SPF is a waste of time as they do not get through, thus 
> we only look up TXT
> 
> So what I have taken from this is that the DNS infrastructure is agnostic to 
> RRtype=99 but the 
> edges have problems. 
> As to the arguments 7 years is not long enough to reach conclusion and force 
> the changes through the
> infrastructure and to the edges. The "need" for SPF has been blunted by the 
> "DUAL SPF/TXT" strategy and 
> thus we are basically in the place where the path of lowest-resistence has 
> taken us. 
> 
> What I want the IESG to add a note to the document is that says something 
> like the following: 
> "The retirement of SPF from specification is not to be taken that new RRtypes 
> can not be used by applications, 
> the retirement is consequence of the dual "quick-deploy" strategy. The IETF 
> will continue to advocate application 
> specific RRtypes applications/firewalls/libraries SHOULD support that 
> approach."
> 

So what makes you think the above 4 points will not be a problem for the
next protocol that comes along and needs (apex) RR data? And the one
after that?

While I appreciate the argument 'this works now, and it is used'
(running code, and all that), I am very worried that we'll end up with
what is essentially a free-form blob containing data for several
protocols at the zone apexes instead of a structured DNS.

So if this approach is taken, I suggest the wording be much stronger, in
the hope this chicken/egg problem (with 5 levels of eggs. or chickens)
will be somewhat mitigated at some point. Preferably with some
higher-level strategy to support that goal.

Jelte

Re: Rude responses (Was: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)

[Pete Resnick]

On 8/21/13 4:40 PM, Dave Crocker wrote:

On 8/21/2013 12:46 PM, Pete Resnick wrote:

It is not your complaint about the imposition of new requirements that
is problematic, or your point that it is not useful to continue that
line of discussion. Talk about the utility of a comment all that you
want. It is the sarcasm and the rudeness that I am saying is
unreasonable. Especially coming from a senior member of the community,


OK.  No sarcasm in IETF postings.  Good luck with that.


Luckily, again, that's not what I said or intended.

Some evidence to the contrary, the IETF is a human endeavor. It involves 
interactions among people. So there will be sarcasm, and humor, and loss 
of temper, and comments with all sorts of embedded meanings. Sometimes 
these things lighten the mood, make the conversation more interesting, 
cause people to think about things in different ways, and contribute to 
the interaction. Sometimes they can have seriously problematic effects. 
Sometimes it will be unclear. And, even though some of our ranks appear 
to want it to be otherwise, there are no nice engineering specs for 
this. It's all very contextual, and is going to depend on the speakers 
and the listeners and the topic of conversation. Social interactions are 
complicated that way.


But there is something going on in the present thread, and in particular 
the mode of communication I objected to here, that I think warrants 
pushback:



More seriously...

You might have noticed that there have been a variety of folk making 
unrealistic or misguided suggestions and that they have been receiving 
entirely muted and exploratory -- albeit negative -- responses.


The implication that I think you've missed here is the obligation that 
should hold for a 'senior' participant who is lodging concerns.  The 
current thread is being tenaciously pursued by another "senior" member 
and former AD and the line of objections and requirements being put 
forward are studiously ignoring the considerable efforts of the 
working group and the considerable practical field history.


As such, they represent their own form of disrespect.


I used the word "bullying" with regard to your particular message for a 
very specific reason. Bullying is normally using one's position of power 
to intimidate. I want to circle back a bit to the particulars of the SPF 
discussion:


The SPFBIS WG came to the conclusion regarding deprecating the use of RR 
99 through a very long discussion. There was an extensive review of 
data. (Indeed, there was some initial reluctance in the WG to do as much 
research into the numbers as was eventually done, and I think in the end 
everyone was glad that the WG did do as much work as it did on the 
topic.) There was an extensive discussion of the implications of all of 
the choices. And, with some rough edges, the WG pretty solidly convinced 
itself that it had chosen the right path. And not just that: The WG 
convinced both chairs that they had chosen the right path (one of the 
chairs being the chair of DNSEXT). And they convinced the responsible 
AD. And during WGLC they even convinced the responsible AD for DNSEXT, 
who was originally quite opposed, that the decision was well-considered 
and the correct one in the end. And I believe none of these folks were 
convinced because opposing views were kicked out of the conversation; 
data was presented and explanations were made, and they were convinced. 
Solid consensus was reached, such that as the eventual consensus caller, 
I am quite sure that I'm going to have to see a very carefully reasoned 
new argument in order for me to think that something was missed by this 
WG. Anyone currently outside of the consensus has a pretty high bar to 
clear; they are at a significant disadvantage in the conversation if 
they have an important point to make.


So, now at the point of IETF LC, the correct thing to happen is to let 
folks make their objections, point them to places in the prior 
conversation where the WG, the chairs, the ADs, and assorted other folks 
became convinced, and see if their arguments have some new subtlety that 
was missed earlier. And try to explain. Remember, these folks are 
already at a disadvantage; they've got an uphill climb to convince 
anyone else (especially, me and the rest of the IESG) that this 
long-considered conclusion is incorrect. IMO, that's the time to cut 
them as much slack as possible, because if they do have a serious 
objection hidden in among things that we've seen before, we *all* should 
want to hear it.


But that's not what's gone on. Some folks have simply dismissively said, 
"Go read the archive", without pointers. I found that 
less-than-collegial, and the more dismissive folks I dropped a private 
note asking them to cool it. The dismissiveness AFAICT simply encourages 
people to post more comments without looking at the previous 
conversation. But your note went above and beyond. The sarcasm was sharp 
and directed. It see

SPFBIS LAST CALL: SenderID Framework (PRA, SUBMITTER)

[Hector Santos]

Hi SM,

Besides the SPF type issue, I believe there are still a number of 
integrated protocol issues to address.  How does the following RFCs 
play into SPFBIS output, the SPF type and the overall BIS document? 
Should RFC4408BIS update any of these documents?


[1] RFC4405  SUBMITTER SMTP Service Extension
[2] RFC4406  Sender ID: Authenticating E-Mail
[3] RFC4407  Purported Responsible Address (PRA)

For example:

In RFC 4406 (SenderID), section 3.1 says:

   This section replaces the definition of the version identifier in
   Section 4.5 of [RFC4408] and adds the concept of SPF record scopes.

In section 4.4, item 1:

   1. If any records of type SPF are in the set, then all records of
  type TXT are discarded.

Overall,

1) Do SenderID publishers need to drop the SPF type as well?

2) Do PRA/SUBMITTER compliant receivers need to also drop SPF type 
queries?


3) Do SMTP vendors need to begin dropping SUBMITTER as well?

Procedurally, does SPFBIS need to address or take over these multiple 
protocols integration concerns (including SMTP SUBMITTER receivers) or 
should it just remain silent and allow vendors make a guess at all 
this?  What is the SPF summary in this regard for the application 
integrator?


Should the IETF consider a new SenderID WG to discuss what are the 
repercussions the SPFBIS results have on it?



--
HLS

[1] http://tools.ietf.org/html/rfc4405
[2] http://tools.ietf.org/html/rfc4406
[3] http://tools.ietf.org/html/rfc4407

Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Olafur Gudmundsson]

On Aug 22, 2013, at 4:36 AM, Jelte Jansen  wrote:

> On 08/21/2013 08:44 PM, Olafur Gudmundsson wrote:
>> 
>> Most of the recent arguments against SPF type have come down to the 
>> following (as far as I can tell): 
>>  a) I can not add SPF RRtype  via my provisioning system into my DNS 
>> servers
>>  b) My firewall doesl not let SPF Records through 
>>  c) My DNS library does not return SPF records through or does not 
>> understand it, thus the application can not receive it.
>>  d) Looking up SPF is a waste of time as they do not get through, thus 
>> we only look up TXT
>> 
>> So what I have taken from this is that the DNS infrastructure is agnostic to 
>> RRtype=99 but the 
>> edges have problems. 
>> As to the arguments 7 years is not long enough to reach conclusion and force 
>> the changes through the
>> infrastructure and to the edges. The "need" for SPF has been blunted by the 
>> "DUAL SPF/TXT" strategy and 
>> thus we are basically in the place where the path of lowest-resistence has 
>> taken us. 
>> 
>> What I want the IESG to add a note to the document is that says something 
>> like the following: 
>> "The retirement of SPF from specification is not to be taken that new 
>> RRtypes can not be used by applications, 
>> the retirement is consequence of the dual "quick-deploy" strategy. The IETF 
>> will continue to advocate application 
>> specific RRtypes applications/firewalls/libraries SHOULD support that 
>> approach."
>> 
> 
> So what makes you think the above 4 points will not be a problem for the
> next protocol that comes along and needs (apex) RR data? And the one
> after that?
> 

There are two reasons, mail is a legacy application with lots of old cruft 
around it. 
New protocols on the other hand can start with clean slate, and the use of the 
protocol is
optional unlike email. 
With a new protocol you can tell someone "you can not use Vendor X as it does 
not support Y" 
and they will put up a system that works, for email there is installed base and 
enterprise policies to use
Vendor X then SPF RR can not be used. 


> While I appreciate the argument 'this works now, and it is used'
> (running code, and all that), I am very worried that we'll end up with
> what is essentially a free-form blob containing data for several
> protocols at the zone apexes instead of a structured DNS.
> 
> So if this approach is taken, I suggest the wording be much stronger, in
> the hope this chicken/egg problem (with 5 levels of eggs. or chickens)
> will be somewhat mitigated at some point. Preferably with some
> higher-level strategy to support that goal.
> 
> Jelte


I agree 

Olafur

Re: WG Review: Secure Telephone Identity Revisited (stir)

[Cullen Jennings (fluffy)]

This looks reasonable to me and given how much effort it has taken to get 
agreement on theses words, I am not keen on any of the material changes I have 
seen proposed.


On Aug 21, 2013, at 11:52 AM, The IESG  wrote:

> A new IETF working group has been proposed in the Real-time Applications
> and Infrastructure Area. The IESG has not made any determination yet. The
> following draft charter was submitted, and is provided for informational
> purposes only. Please send your comments to the IESG mailing list (iesg
> at ietf.org) by 2013-08-28.
> 
> Secure Telephone Identity Revisited (stir)
> 
> Current Status: Proposed WG
> 
> Chairs:
>  TBD
> 
> Assigned Area Director:
>  Richard Barnes 
> 
> Mailing list
>  Address: s...@ietf.org
>  To Subscribe: https://www.ietf.org/mailman/listinfo/stir
>  Archive: http://www.ietf.org/mail-archive/web/stir/
> 
> Charter:
> 
> The STIR working group will specify Internet-based mechanisms that allow 
> verification of the calling party's authorization to use a particular 
> telephone number for an incoming call.  Since it has  become fairly easy 
> to present an incorrect source telephone number, a growing set of 
> problems have emerged over the last decade.  As with email, the claimed 
> source identity of a SIP request is not verified, permitting unauthorized
> 
> use of the source identity as part of deceptive and coercive activities, 
> such as robocalling (bulk unsolicited commercial communications), vishing
> 
> (voicemail hacking, and impersonating banks) and swatting (impersonating 
> callers to emergency services to stimulate unwarranted large scale law 
> enforcement deployments).  In addition, use of an incorrect source 
> telephone number facilitates wire fraud or can lead to a return call at 
> premium rates.  
> 
> SIP is one of the main VoIP technologies used by parties that want to
> present an incorrect origin, in this context an origin telephone number.
> Several previous efforts have tried to secure the origins of SIP
> communications, including RFC 3325, RFC 4474, and the VIPR working group.
> To date, however, true validation of the source of SIP calls has not seen
> any appreciable deployment.  Several factors contributed to this lack of
> success, including: failure of the problem to be seen as critical at the
> time; lack of any technical means of producing a proof of authorization
> to
> use telephone numbers; misalignment of the mechanisms proposed by RFC
> 4474
> with the complex deployment environment that has emerged for SIP; lack of
> end-to-end SIP session establishment; and inherent operational problems
> with a transitive trust model.  To make deployment of this solution more
> likely, consideration must be given to latency, real-time performance,
> computational overhead, and administrative overhead for the legitimate
> call source and all verifiers.
> 
> As its priority mechanism work item, the working group will specify a SIP
> header-based mechanism for verification that the originator of a SIP 
> session is authorized to use the claimed source telephone number, where 
> the session is established with SIP end to end.  This is called an
> in-band 
> mechanism. The mechanism will use a canonical telephone number 
> representation specified by the working group, including any mappings
> that 
> might be needed between the SIP header fields and the canonical telephone
> 
> number representation.  The working group will consider choices for 
> protecting identity information and credentials used.  This protection 
> will likely be based on a digital signature mechanism that covers a set 
> of information in the SIP header fields, and verification will employ a 
> credential that contains the public key that is associated with the one 
> or more telephone numbers.  Credentials used with this mechanism will be 
> derived from existing telephone number assignment and delegation models. 
> 
> That is, when a telephone number or range of telephone numbers is 
> delegated to an entity, relevant credentials will be generated (or 
> modified) to reflect such delegation.  The mechanism must allow a 
> telephone number holder to further delegate and revoke use of a telephone
> 
> number without compromising the global delegation scheme.
> 
> In addition to its priority mechanism work item, the working group will
> consider a mechanism for verification of the originator during session
> establishment in an environment with one or more non-SIP hops, most
> likely requiring an out-of-band authorization mechanism.  However, the
> in-band and the out-of-band mechanisms should share as much in common as
> possible, especially the credentials.  The in-band mechanism must be sent
> to the IESG for approval and publication prior to the out-of-band
> mechanism.
> 
> Expansion of the authorization mechanism to identities using the
> user@domain form is out of scope.  The work of this group is limited to
> dev

Re: Rude responses (Was: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)

[Scott Brim]

On Thu, Aug 22, 2013 at 10:22 AM, Pete Resnick wrote:

> Some folks have simply dismissively said, "Go read the archive", without
> pointers.


Pete, I like your position, but I believe "go read the archive" or the
equivalent will continue to be a standard response unless someone is
responsible for giving a more thorough response. Who do you think that
should be?

Re: Rude responses (Was: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)

[Thomas Narten]

Barry Leiba  writes:

> The general point is that the new people whom we want
> to draw in as productive participants will be watching how we treat
> each other and deciding whether they want to wade into that pool.

It's not just new people watching and being turned off.  There are
plenty of old timers who get turned off and I doubt I'm alone in
thinking very carefully these days whether I want to wade into any
particular discussion.

Thomas

Re: Rude responses (Was: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)

[Pete Resnick]

OK, direct question; I'll take the (short) time to give a direct answer.

On 8/22/13 9:53 AM, Scott Brim wrote:
Pete, I like your position, but I believe "go read the archive" or the 
equivalent will continue to be a standard response unless someone is 
responsible for giving a more thorough response. Who do you think that 
should be?


It would be a bummer if it is entirely left to the AD/consensus caller 
or the chair/shepherd, but unfortunately "the buck stops here", as they 
say. Eventually, it should be everyone's responsibility to help their 
colleagues. But obviously my rose-colored glasses are especially rosy 
today, other evidence to the contrary notwithstanding.


pr

--
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478

Re: TCPMUX (RFC 1078) status

[Joe Touch]

On 8/22/2013 12:44 AM, Martin Sustrik wrote:

On 21/08/13 19:00, Joe Touch wrote:


So what would you use for muxing, if TCPMUX is not a good idea?


You need to roll your own. The requirements of systems vary widely, as
do the costs/benefits of different approaches.

I listed a few before, but here's a more comprehensive list:
 - service per message
 demux based on message ID
 use IPC (interprocess comm) to handoff internal
 to your system

 - service per connection
 demux based on the first message in an
 association (TCP or UDP), and either continue to
 forward messages to a different process or handoff
 the connection


So, if I proceed with this option why not use RFC1078 to implement it?
Why write a new RFC if there's an old one that fits the bill?


There are two cases to consider:

- you're creating your own set of services, at which point
you'll need to roll your own dispatch mechanism

- you want to use TCPMUX, either for your own services or for
all services
you should already realize why that's a dead-end.
any sysadmin that blocks *any* ports will always
block TCPMUX

One final reason TCPMUX isn't deployed is that it changes the semantics 
of many existing services, many of which are defined as "if the 
connection opens, then the service is there".


If you roll your own version, you can define your services to accept 
those semantics.


Joe

RE: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

[mohamed.boucadair]

Hi Erik,

Thank you for the review. 

Please see inline.

Cheers,
Med

>-Message d'origine-
>De : v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] De la part de
>Erik Kline
>Envoyé : jeudi 22 août 2013 13:22
>À : Owen DeLong
>Cc : v6...@ietf.org; IETF Discussion
>Objet : Re: [v6ops] Last Call: 04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile
>Devices) to Informational RFC
>
>REQ 1:
>6434 5.9.1 is already a MUST.  This does not need to be repeated.

[Med] Because some requirements are stronger in this document than what is 
documented in RFC6434, we had two way to implement this in the document:
(a) Indicate RFC6434 must be supported with the exceptions in the language for 
some requirements listed in this document.
(b) Call out explicitly the requirements from RFC6434 that are mandatory + 
indicate which requirements are stronger than rfc6434.
We decided to go for (b) as it provides a comprehensive list of requirements 
for 3GPP mobile devices grouped in one single document. IMHO, this is just a 
matter of presentation. 

This rationale is explained in the introduction.


>6434 5.8 is already a MUST.  Unless you want to make multipart
>ICMP a MUST (why?) as well, this too can be removed.
>
>REQ 6:
>re 6434 12.2, this MUST does not appear to be stronger than 12.2's MUST
>frankly even 5.2 reads like MUST for 3GPP, but it does SHOULD so
>this MUST appears stronger.  Bizarre, though, I never noticed that "ND
>SHOULD" before.

[Med] The language is stronger compared to the SHOULD in Section 5.2 of RFC6434.

>
>REQ 10:
>this reads kind weird.  In REQ 9 you require 6106 support, but in
>REQ 10 you say "if 6106 is not supported."  I think you mean something
>like "if the network to which the mobile node is attaching does not
>support 6016".

[Med] Yes, agree. As mentioned in the document,

"   Some of the features listed in this profile document require to
   activate dedicated functions at the network side."

This will be fixed.

Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

[Erik Kline]

REQ 1:
6434 5.9.1 is already a MUST.  This does not need to be repeated.
6434 5.8 is already a MUST.  Unless you want to make multipart
ICMP a MUST (why?) as well, this too can be removed.

REQ 6:
re 6434 12.2, this MUST does not appear to be stronger than 12.2's MUST
frankly even 5.2 reads like MUST for 3GPP, but it does SHOULD so
this MUST appears stronger.  Bizarre, though, I never noticed that "ND
SHOULD" before.

REQ 10:
this reads kind weird.  In REQ 9 you require 6106 support, but in
REQ 10 you say "if 6106 is not supported."  I think you mean something
like "if the network to which the mobile node is attaching does not
support 6016".

Re: SPFBIS LAST CALL: SenderID Framework (PRA, SUBMITTER)

[S Moonesamy]

Hi Hector,
At 07:29 22-08-2013, Hector Santos wrote:
Besides the SPF type issue, I believe there are still a number of 
integrated protocol issues to address.  How does the following RFCs 
play into SPFBIS output, the SPF type and the overall BIS document? 
Should RFC4408BIS update any of these documents?


[1] RFC4405  SUBMITTER SMTP Service Extension
[2] RFC4406  Sender ID: Authenticating E-Mail
[3] RFC4407  Purported Responsible Address (PRA)


I would say no as the above RFCs are not related to 
draft-ietf-spfbis-4408bis-19.  I'll mention the following text from RFC 6686:


  "The experiments comprising the series of RFCs defining the
   SUBMITTER SMTP extension (RFC4405), the Sender ID mechanism
   (RFC4406), the Purported Responsible Address algorithm (RFC4407),
and SPF (RFC4408), should be considered concluded.

That is the official position of the IETF.  I can state that the text 
reflects the consensus of the SPFBIS WG as I verified whether there 
was working group agreement before requesting the publication of RFC 
6686.  The following text is from RFC 6686:


  "This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG)."

From an IETF perspective that's the answer that will be given.


For example:

In RFC 4406 (SenderID), section 3.1 says:

   This section replaces the definition of the version identifier in
   Section 4.5 of [RFC4408] and adds the concept of SPF record scopes.

In section 4.4, item 1:

   1. If any records of type SPF are in the set, then all records of
  type TXT are discarded.

Overall,

1) Do SenderID publishers need to drop the SPF type as well?

2) Do PRA/SUBMITTER compliant receivers need to also drop SPF type queries?

3) Do SMTP vendors need to begin dropping SUBMITTER as well?


Somebody can submit a draft which answers those questions and have it 
discussed in the IETF.  The SPFBIS WG Chairs have mentioned that once 
the work on draft-ietf-spfbis-4408bis is completed the SPFBIS WG will 
be ready to close ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10124.html 
).  I don't think that the SPFBIS WG will take on the draft.  The 
person submitting the draft can contact the Application Area 
Directors to find out where to discuss the draft.


Procedurally, does SPFBIS need to address or take over these 
multiple protocols integration concerns (including SMTP SUBMITTER 
receivers) or should it just remain silent and allow vendors make a 
guess at all this?  What is the SPF summary in this regard for the 
application integrator?


Procedurally, the SPFBIS WG does not need to address that (see above 
comments).  SPFBIS will remain silent and allow vendors to make a 
guess.  The SPF summary is that it is out of scope for 
draft-ietf-spfbis-4408bis-19.


Should the IETF consider a new SenderID WG to discuss what are the 
repercussions the SPFBIS results have on it?


The above question is about a SenderID BoF.  I personally do not 
think that there is currently interest in having that BoF (see RFC 5434).


Regards,
S. Moonesamy 

Re: Rude responses (Was: Last Call:

[Aaron Yi DING]

On 22/08/13 16:01, Thomas Narten wrote:

Barry Leiba  writes:


The general point is that the new people whom we want
to draw in as productive participants will be watching how we treat
each other and deciding whether they want to wade into that pool.


It's not just new people watching and being turned off.  There are
plenty of old timers who get turned off and I doubt I'm alone in
thinking very carefully these days whether I want to wade into any
particular discussion.



Thanks for pointing out this sensitive spot. It does exist, not just 
turning off, but even driving people away. Happen to know a such senior 
ietfer..


The line between being Rude and being Upfront is tricky and highly 
context dependent.


Aaron




Thomas

Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Murray S. Kucherawy]

On Thu, Aug 22, 2013 at 1:36 AM, Jelte Jansen  wrote:

> While I appreciate the argument 'this works now, and it is used'
> (running code, and all that), I am very worried that we'll end up with
> what is essentially a free-form blob containing data for several
> protocols at the zone apexes instead of a structured DNS.
>

With or without SPF, we're long past the point where worrying about that is
worthwhile.  Try a TXT lookup for ut.edu or banctec.com, for example.

When I did one of the surveys for RFC6686, it recorded the TXT RRs returned
for various domain queries.  The top ten in terms of record counts returned
back then (most have been cleaned up now):

+---+--+
| count(id) | domain   |
+---+--+
|43 | wncy.com |
|43 | b93radio.com |
|43 | wtaq.com |
|29 | dealdirectsendz.info |
|23 | voamn.org|
|18 | ut.edu   |
|15 | aaronline.com|
|10 | dwgsecurity.com  |
| 9 | emergogroup.com  |
| 9 | banctec.com  |
+---+--+

The top three were loaded with "google-site-verification=" records.
ut.edu and banctec.com have a mix of things.

-MSK

Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[John Levine]

In article <5215cd8d.3080...@sidn.nl> you write:
>So what makes you think the above 4 points will not be a problem for the
>next protocol that comes along and needs (apex) RR data? And the one
>after that?

SPF is ten years old now.  It would be helpful if you could give us a
list of other protocols that have had a similar issue with a TXT
record at the apex during the past decade.

R's,
John

New IETF Trust Chair

[IETF Administrative Director]

The IETF Trust Trustees are pleased to announce that Ole Jacobsen has been 
selected as the IETF Trust 
Chair.  Ole was selected following the resignation of Chris Griffiths as Chair, 
who assumed the 
chairmanship of the IAOC.   This will be Ole's second stint as Chair as he 
succeeded Marshall Eubanks 
when Marshall resigned from the IAOC.  

Congratulations Ole!  

Ray Pelletier
Trustee
IAD
http://trustee.ietf.org/

Re: Rude responses (Was: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)

[Barry Leiba]

> Pete, I like your position, but I believe "go read the archive" or the
> equivalent will continue to be a standard response unless someone is
> responsible for giving a more thorough response. Who do you think that
> should be?

If you've had the most fleeting look at this:
https://datatracker.ietf.org/doc/draft-leiba-extended-doc-shepherd/

... then you'll know what *my* answer to that question is.  Happily,
this document has an excellent shepherd (see the Most Excellent(tm)
shepherd report:
https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/shepherdwriteup/
), who has been posting summaries and pointers throughout the
conversation.

Perhaps said shepherd could give even better pointers; if so, a quiet
message to him asking for specifics would surely be met with cheerful
diligence.

Barry

RE: Gen-ART review of draft-ietf-dime-overload-reqs-10

[Black, David]

Hi Eric,

This looks good - comments follow ...

> > a) I assume that overload control development work will derive more specific
> > security requirements - e.g., as REQ 27 is stated at a rather high level.
> > The discussion in security considerations section seems reasonable.
> 
> We agree with this.  The thinking here was that we didn't want to specify this
> in a way that would be specific to a particular type of mechanism.  It might
> not hurt to state that assumption, either as a note on Req 27 or in the sec
> considerations.

That would be good to add as a note on REQ 27.

> The intent was very much as you say, where requirements on individual node
> capabilities are hoped to result in better overall system behaviors. There are
> also some requirements that are stated more at the system level (e.g. 7 and
> 17.) Also the text in section 2.2 that discusses Figure 5 talks about how
> insufficient server capacity at a cluster of servers behind a Diameter agent
> can be treated as if the agent itself was overloaded.
> 
> On the other hand, any mechanism we design will have to focus on actions of
> individual nodes, so the numbered requirements tend to focus on that. I'm not
> sure where to change the balance here--do you have specific suggestions?

I noted this as editorial rather than a minor issue, as I was mostly concerned
that the actual design work will be informed by a sufficient architectural 
"clue"
that the goal is "better overall system behaviors", which your response 
indicates
will definitely be the case ;-).

Rather than edit individual requirements, how about adding the following 
sentence
immediately following the introductory sentence in Section 7?:

These requirements are stated primarily in terms of individual node
behavior to inform the design of the improved mechanism;
that design effort should keep in mind that the overall goal is
improved overall system behavior across all the nodes involved, 
not just improved behavior from specific individual nodes.

> > This inadequacy may, in turn, contribute to broader congestion collapse
> >
> > "collapse" is not the right word here - I suggest "issues", "impacts",
> > "effects" or "problems".
> 
> We are fine with any of those alternatives.  How about impacts.

That's fine.  FWIW, "congestion collapse" has a specific (rather severe)
meaning over in the Transport Area, and that meaning was not intended here.

> 23.843 is the least stable reference.  I don't have any issue with pointing
> that out.  The part of it we are referencing is historical front matter
> though.

I'd note the reference as work in progress, and put the statement about stable
front matter (historical is a bad work to use here) in the body of the draft
that cites the reference.
 
> I tried the web and downloaded versions of 2.12.17 and was not able to get the
> warnings you saw (about the references).  What did it say?

Sorry, I didn't mean to send you on a wild goose chase :-).  The idnits 
confusion
manifested right at the top of the output, where everyone ignores it ...

   Attempted to download rfc272 state...
   Failure fetching the file, proceeding without it.

You didn't reference RFC 272, so that output's apparently courtesy of idnits
misinterpreting this reference:

1195   [TS29.272]
1196  3GPP, "Evolved Packet System (EPS); Mobility Management
1197  Entity (MME) and Serving GPRS Support Node (SGSN) related
1198  interfaces based on Diameter protocol", TS 29.272 11.4.0,
1199  September 2012.

I was amused :-).

Thanks,
--David

> -Original Message-
> From: Eric McMurry [mailto:emcmu...@computer.org]
> Sent: Thursday, August 22, 2013 3:06 PM
> To: Black, David
> Cc: b...@nostrum.com; General Area Review Team (gen-...@ietf.org);
> ietf@ietf.org; d...@ietf.org; bcla...@cisco.com
> Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
> 
> Hi David,
> 
> Thank you for the review.  Your time and comments are appreciated!
> 
> comments/questions inline.
> 
> 
> Eric
> 
> 
> 
> On Aug 17, 2013, at 9:18 , "Black, David"  wrote:
> 
> >
> > 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-dime-overload-reqs-10
> > Reviewer: David L. Black
> > Review Date: August 17, 2013
> > IETF LC End Date: August 16, 2013
> > IESG Telechat date: (if known)
> >
> > Summary:
> > This draft is basically ready for publication, but has nits that should be
> > fixed before publication.
> >
> > This draft describes scenarios in which Diameter overload can occur and 
> > provides
> > requirements for development of new overload control functionality in 
> > Diameter.
> > It is well written, and the inclusion of scenarios in wh

Re: Gen-ART review of draft-ietf-dime-overload-reqs-10

[Ben Campbell]

Hi David,

We agree on all your points, and will make the updates in the next version, 
pending shepherd instructions.

Thanks!

Ben.

On Aug 22, 2013, at 2:50 PM, "Black, David"  wrote:

> Hi Eric,
> 
> This looks good - comments follow ...
> 
>>> a) I assume that overload control development work will derive more specific
>>> security requirements - e.g., as REQ 27 is stated at a rather high level.
>>> The discussion in security considerations section seems reasonable.
>> 
>> We agree with this.  The thinking here was that we didn't want to specify 
>> this
>> in a way that would be specific to a particular type of mechanism.  It might
>> not hurt to state that assumption, either as a note on Req 27 or in the sec
>> considerations.
> 
> That would be good to add as a note on REQ 27.
> 
>> The intent was very much as you say, where requirements on individual node
>> capabilities are hoped to result in better overall system behaviors. There 
>> are
>> also some requirements that are stated more at the system level (e.g. 7 and
>> 17.) Also the text in section 2.2 that discusses Figure 5 talks about how
>> insufficient server capacity at a cluster of servers behind a Diameter agent
>> can be treated as if the agent itself was overloaded.
>> 
>> On the other hand, any mechanism we design will have to focus on actions of
>> individual nodes, so the numbered requirements tend to focus on that. I'm not
>> sure where to change the balance here--do you have specific suggestions?
> 
> I noted this as editorial rather than a minor issue, as I was mostly concerned
> that the actual design work will be informed by a sufficient architectural 
> "clue"
> that the goal is "better overall system behaviors", which your response 
> indicates
> will definitely be the case ;-).
> 
> Rather than edit individual requirements, how about adding the following 
> sentence
> immediately following the introductory sentence in Section 7?:
> 
>   These requirements are stated primarily in terms of individual node
>   behavior to inform the design of the improved mechanism;
>   that design effort should keep in mind that the overall goal is
>   improved overall system behavior across all the nodes involved, 
>   not just improved behavior from specific individual nodes.
> 
>>> This inadequacy may, in turn, contribute to broader congestion collapse
>>> 
>>> "collapse" is not the right word here - I suggest "issues", "impacts",
>>> "effects" or "problems".
>> 
>> We are fine with any of those alternatives.  How about impacts.
> 
> That's fine.  FWIW, "congestion collapse" has a specific (rather severe)
> meaning over in the Transport Area, and that meaning was not intended here.
> 
>> 23.843 is the least stable reference.  I don't have any issue with pointing
>> that out.  The part of it we are referencing is historical front matter
>> though.
> 
> I'd note the reference as work in progress, and put the statement about stable
> front matter (historical is a bad work to use here) in the body of the draft
> that cites the reference.
> 
>> I tried the web and downloaded versions of 2.12.17 and was not able to get 
>> the
>> warnings you saw (about the references).  What did it say?
> 
> Sorry, I didn't mean to send you on a wild goose chase :-).  The idnits 
> confusion
> manifested right at the top of the output, where everyone ignores it ...
> 
>   Attempted to download rfc272 state...
>   Failure fetching the file, proceeding without it.
> 
> You didn't reference RFC 272, so that output's apparently courtesy of idnits
> misinterpreting this reference:
> 
> 1195 [TS29.272]
> 11963GPP, "Evolved Packet System (EPS); Mobility Management
> 1197Entity (MME) and Serving GPRS Support Node (SGSN) related
> 1198interfaces based on Diameter protocol", TS 29.272 11.4.0,
> 1199September 2012.
> 
> I was amused :-).
> 
> Thanks,
> --David
> 
>> -Original Message-
>> From: Eric McMurry [mailto:emcmu...@computer.org]
>> Sent: Thursday, August 22, 2013 3:06 PM
>> To: Black, David
>> Cc: b...@nostrum.com; General Area Review Team (gen-...@ietf.org);
>> ietf@ietf.org; d...@ietf.org; bcla...@cisco.com
>> Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
>> 
>> Hi David,
>> 
>> Thank you for the review.  Your time and comments are appreciated!
>> 
>> comments/questions inline.
>> 
>> 
>> Eric
>> 
>> 
>> 
>> On Aug 17, 2013, at 9:18 , "Black, David"  wrote:
>> 
>>> 
>>> 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-dime-overload-reqs-10
>>> Reviewer: David L. Black
>>> Review Date: August 17, 2013
>>> IETF LC End Date: August 16, 2013
>>> IESG Telechat date: (if known)
>>> 
>>> Summary:
>>> This draft

Re: [dnsext] Deprecating SPF

[Mark Andrews]

Part of the question is whether the IETF is going to work with ICANN, IANA
and the ccTLD to audit delegations for servers that are not RFC 103[45]
compliant and suspend delegations where the servers are not compliant.

* no responding to queries based on query type
* not having a NS rrset at the delegation point

Enforcing that ccTLD and ICANN TLD regularly audit delegations and
have mismatches corrected.  This is REQUIRED by RFC 1034 in part to
stop the sorts of problems we are seeing today.

We don't have to put up people putting up misconfigured / broken servers.

For the non responding servers I have written
draft-andrews-dns-no-response-issue to try to capture the issues.
It was on the dnsop agenda for Berlin but didn't get covered as time
ran out.  I would like everyone to read it and comment on it.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

RE: Rude responses (Was: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)

[l.wood]

> I can't myself think of a good justification for sarcasm, (well, maybe [1]:-)

good sarcasm is like good protocol design - many can recognise it, some can 
appreciate it, few can truly understand its nuances, and even fewer can create 
it.

You're just not one of them.

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

The Last Call social contract (was - Re: Rude responses)

[Dave Crocker]

Pete, et al,


On 8/22/2013 7:22 AM, Pete Resnick wrote:

So, now at the point of IETF LC, the correct thing to happen is to
let folks make their objections, point them to places in the prior
conversation where the WG, the chairs, the ADs, and assorted other
folks became convinced, and see if their arguments have some new
subtlety that was missed earlier. And try to explain. Remember,
these folks are already at a disadvantage; they've got an uphill
climb to convince anyone else (especially, me and the rest of the
IESG) that this long-considered conclusion is incorrect. IMO, that's
the time to cut them as much slack as possible, because if they do
have a serious objection hidden in among things that we've seen
before, we *all* should want to hear it.

...

So, now at the point of IETF LC, the correct thing to happen is to
let folks make their objections, point them to places in the prior
conversation where the WG, the chairs, the ADs, and assorted other
folks became convinced, and see if their arguments have some new
subtlety that was missed earlier. And try to explain.



That's certainly a kind and gentle view of the obligations for handling
LC comments.  Kind and gentle on the folks making the comments.  Not so
kind or gentle or useful on the folks who have been spending months (or
years) doing the work of developing the document.

Therefore, I'm going to posit that your model is, in fact, critically
flawed.  (And on review I see there's an apt pun in that wording...)

In pragmatic terms, the current operational model for a LC (and IESG)
review tends to enforce no rules or limits to what can be challenged or
suggested, while simultaneously expecting those who have been doing the
work to then be responsible for educating the commenter and defending
decisions in the document, at the level of re-arguing resolved issues.
Your admonition that "these folks are already at a disadvantage"
encourages this sense of obligation.

However this is direct contradiction to our published rules for Last Call:

   RFC 2418, Working Group Guidelines and Procedures
   Section 8, Review of documents

   "It is important to note
   that a Last-Call is intended as a brief, final check with the
   Internet community, to make sure that no important concerns have been
   missed or misunderstood. The Last-Call should not serve as a more
   general, in-depth review."

Note that last sentence.  It's the essential point, if we are to have
any real /respect/ for the extended effort already put into developing
the document.  It contrasts completely from the burden that is regularly
placed on such folk these days.

In other words, those making comments have obligations too, but that is
not being discussed here, except to make excuses for them.  And it is
the fundamental flaw with your line of thinking.

In practical terms, that thinking suggests that rather than treat it as
a joke, we take seriously and tolerate behavior matching the cliche "I
haven't read the spec, but I have some criticisms of your work."

Besides mostly being incredibly wasteful, to the point of abuse, your
model serves as its own disincentive for bringing work to the IETF; the
hassle factor is just too damn high and, worse, the outcome too damn
unpredictable.

For all that we tout the occasional bit of added insight -- and I'm
entirely in favor of those rare moments -- they are drowned out by the
more predictable and dominant demands to re-explore old topics or new
silly ones or to argue religious technical preferences.



But that's not what's gone on. Some folks have simply dismissively
said, "Go read the archive", without pointers.


Last Call is for catching oversights and errors.  It is not for
educating folk who chose not to track the working group. If someone
cares enough to press for specific choices, they need to show up when
the work is being done.  If they don't care that much, then I'm sorry
but "we discussed that" or "go read the archives" is in fact an entirely
sufficient and complete response.  That is, if the IETF has any real
respect for the work that was done developing the document.

[For completeness, I'll note that this is an issue where it makes sense
to handle Individual Submissions quite differently.  Here there is no
archive of IETF group work, and so it is reasonable to demand of the
authors a handling of Last Call comments that really does look more like
education and marketing. But not for working group documents.]



The dismissiveness AFAICT simply encourages people to post more
comments without looking at the previous conversation. But your note
went above and beyond. The sarcasm was sharp and directed. It seemed
intent on ridiculing.


That's quite a lot to lay onto my brief "very constructive" statement.
Which isn't to say you are wrong; although the intensity of your
reaction really goes considerably beyond the worth of such a single,
brief comment, particularly one lacking an explicitly ad hominem
component and especially given tha

RE: The Last Call social contract (was - Re: Rude responses)

[l.wood]

> LC should not be treated as a right of passage, to test the patience of
> folks who have developed a document.

rite?

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

Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of 272 messages in the last 7 days.
 
script run at: Fri Aug 23 00:53:02 EDT 2013
 
Messages   |  Bytes| Who
+--++--+
  5.88% |   16 |  5.06% |   118905 | d...@dcrocker.net
  5.51% |   15 |  5.10% |   119919 | sc...@kitterman.com
  4.78% |   13 |  4.71% |   110859 | hadriel.kap...@oracle.com
  4.41% |   12 |  4.14% |97312 | sm+i...@elandsys.com
  4.04% |   11 |  4.03% |94724 | presn...@qti.qualcomm.com
  3.68% |   10 |  2.77% |65248 | p...@frobbit.se
  2.94% |8 |  2.96% |69522 | john-i...@jck.com
  3.31% |9 |  2.41% |56561 | jo...@taugh.com
  2.94% |8 |  2.73% |64211 | ma...@isc.org
  2.94% |8 |  2.65% |62387 | mansa...@besserwisser.org
  2.57% |7 |  2.92% |68721 | superu...@gmail.com
  2.94% |8 |  2.15% |50470 | a...@anvilwalrusden.com
  2.21% |6 |  2.42% |57003 | hsan...@isdg.net
  2.57% |7 |  1.99% |46750 | to...@isi.edu
  2.57% |7 |  1.96% |46054 | sust...@250bpm.com
  2.21% |6 |  2.26% |53090 | hal...@gmail.com
  1.84% |5 |  2.36% |55546 | david.bl...@emc.com
  1.10% |3 |  2.99% |70357 | adr...@olddog.co.uk
  2.21% |6 |  1.86% |43651 | s...@resistor.net
  1.84% |5 |  1.67% |39285 | d...@virtualized.org
  1.10% |3 |  2.37% |55685 | lionel.mor...@orange.com
  1.47% |4 |  1.70% |40054 | jgu...@csc.com
  1.10% |3 |  1.98% |46464 | stefan.win...@restena.lu
  0.37% |1 |  2.41% |56657 | sgin...@amsl.com
  1.10% |3 |  1.52% |35764 | stephen.farr...@cs.tcd.ie
  1.10% |3 |  1.26% |29653 | yaronf.i...@gmail.com
  1.10% |3 |  1.13% |26577 | l...@cisco.com
  1.10% |3 |  1.03% |24218 | mo...@network-heretics.com
  1.10% |3 |  0.93% |21961 | ted.le...@nominum.com
  1.10% |3 |  0.86% |20116 | arturo.ser...@gmail.com
  0.74% |2 |  1.03% |24151 | b...@nostrum.com
  0.74% |2 |  0.86% |20259 | vinay...@gmail.com
  0.74% |2 |  0.81% |19089 | morrowc.li...@gmail.com
  0.74% |2 |  0.70% |16537 | nar...@us.ibm.com
  0.74% |2 |  0.68% |15909 | o...@ogud.com
  0.37% |1 |  1.01% |23832 | zhangfa...@huawei.com
  0.74% |2 |  0.64% |14977 | barryle...@computer.org
  0.74% |2 |  0.63% |14901 | c...@tzi.org
  0.74% |2 |  0.63% |14884 | jelte.jan...@sidn.nl
  0.74% |2 |  0.58% |13716 | hous...@vigilsec.com
  0.37% |1 |  0.95% |22357 | car...@qosient.com
  0.74% |2 |  0.56% |13284 | l.w...@surrey.ac.uk
  0.74% |2 |  0.56% |13095 | h...@cs.columbia.edu
  0.74% |2 |  0.55% |12920 | ka...@mit.edu
  0.74% |2 |  0.54% |12636 | hartmans-i...@mit.edu
  0.37% |1 |  0.60% |14113 | flu...@cisco.com
  0.37% |1 |  0.59% |13830 | g...@ninebynine.org
  0.37% |1 |  0.53% |12564 | sant9...@gmail.com
  0.37% |1 |  0.51% |11888 | lore...@google.com
  0.37% |1 |  0.48% |11270 | brian.e.carpen...@gmail.com
  0.37% |1 |  0.46% |10716 | ron.even@gmail.com
  0.37% |1 |  0.44% |10451 | petit...@acm.org
  0.37% |1 |  0.44% |10329 | hannes.tschofe...@gmx.net
  0.37% |1 |  0.42% | 9832 | a...@yumaworks.com
  0.37% |1 |  0.40% | 9429 | dotz...@gmail.com
  0.37% |1 |  0.37% | 8698 | mbaug...@cisco.com
  0.37% |1 |  0.36% | 8564 | turchanyi.g...@gmail.com
  0.37% |1 |  0.36% | 8497 | t...@att.com
  0.37% |1 |  0.36% | 8370 | bmann...@isi.edu
  0.37% |1 |  0.35% | 8218 | j...@joelhalpern.com
  0.37% |1 |  0.34% | 8006 | aal...@blackberry.com
  0.37% |1 |  0.33% | 7828 | mohamed.boucad...@orange.com
  0.37% |1 |  0.33% | 7784 | paul.hoff...@vpnc.org
  0.37% |1 |  0.32% | 7619 | scott.b...@gmail.com
  0.37% |1 |  0.32% | 7531 | khalil.yac...@atecgrp.com
  0.37% |1 |  0.30% | 7094 | hil...@cursive.net
  0.37% |1 |  0.30% | 7084 | d...@dotat.at
  0.37% |1 |  0.30% | 7083 | j...@jlc.net
  0.37% |1 |  0.30% | 7049 | ietf...@comcast.net
  0.37% |1 |  0.30% | 7013 | e...@google.com
  0.37% |1 |  0.29% | 6800 | carlosm3...@gmail.com
  0.37% |1 |  0.29% | 6785 | n...@cryptonector.com
  0.37% |1 |  0.29% | 6750 | melinda.sh...@gmail.com
  0.37% |1 |  0.28% | 6535 | aser...@lacnic.net
  0.37% |1 |  0.28% | 6521 | berti...@bwijnen.net
  0.37% |1 |  0.27% | 6460 | j...@apple.com
  0.37% |1 |  0.27% | 6313 | rpellet...@isoc.org
  0.37% |1 |  0.27% | 6300 | o...@delong.com
  0.37% |1 |  0.27% | 6295 | jh...@cmu.edu
  0.37% |1 |  0.27% | 6260 | uma.chund...@ericsson.com
  0.37% |1 |  0.26% | 6192 | masin...@adobe.com
  0.37% |1 |  0.26% | 6050 | d...@xpasc.com
  0.37% |1 |  0.25% | 5951 | bra...@isi.edu
  0.37% |1 |  0.25% | 5920 | ves...@tana.it
  0.37% |1 |  0.25% | 5833