RE: [gnso-ff-pdp-may08] Comment References, Interim Conclusions and Next Steps

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

Hi Greg,

#You mistake my meaning on a point; forgive me if I was not clear.  

If I misunderstood your meaning, the failure was all mine, however I'm not
sure that there was any misunderstanding. 

#WPDRS is a compliance tool with segments designed for reporting, 
#investigating, and following up on contractual obligations.  

FFDRS could be the same way.

Assume ICANN forbids fast flux by default (with provision for
exceptions where appropriate) as a contractual matter. Why would 
something like FFDRS be exactly parallel in that case?

#As far as a tool created by ICANN: the security community already knows how
#fast-flux works, 

An interesting assertion, given all the places in the current report where 
the committee says, "Ya know, we really don't know" and "Further study is
required" and "There is no consensus on this"

If this baby's 100% locked down and 100% sussed out, it sure doesn't come 
across that way. 

#I wonder whether
#there is really anything "murky" about our understanding that such an ICANN
#tool would help clear up.  

If you're proposing the excision of all the points in the current report
where we currently say, "Don't know," "Need more study" and "No consensus,"
*that's* something I could get behind. But as long as we have uncertainty,
or need more analysis, or there's a lack of reasonable consensus, we need
data. 

#So I question the utility, and I question whether
#this is a good use of ICANN's money and time, since I believe fast-flux
#mitigation is beyond ICANN's mission and ability.  

The only way of interdicting fast flux is by dealing with the domains.
If the registrars aren't interested in doing so for whatever reasons 
(potential liability, no legal or contractual basis for doing so, the
money's too good so who cares about complaints, whatever), that leaves
the registries and ICANN. If the registries point their finger at ICANN
and ICANN points their finger at the registries, all you'll hear is the
sweet sound of the miscreants laughing.

Put another way, if this *isn't* ICANN's mission and responsibility, whose
mission and responsibility is it? The registries? I can think of at least
a couple of registries who might disagree with that assertion. 

#I think it would be more effective and more properly situated if someone 
#in the security community created and maintained such a tool.

Can't (or at least they can't do a good job of it) because the whois data
access you need to do this right is constained, and even if you build
the evidence, what then? No one is obligated to listen to Bob's Bait Shop
and Fast Flux Analysis Center, or at least not the way they are ICANN.

There's also the question of trusting the private sector to do this sort
of analysis. Is ICANN prepared to trust data collected by a random 
researcher? What if the researchers come to dramatically different 
conclusions (even ruling out things like analysis errors)? I think having
authoritative common data is critically important to studying this issue.

Regards,

Joe