Re: [gnso-ff-pdp-may08] Things learned thus far

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

Mike mentioned:

#Dear Proposers of Solutions (aka Team Fast Flux),
#
#You haven't made the sale yet.  Here are the objections you're 
#hearing from prospective customers and partners;

Keep in mind, I'm not a sales guy. I'm a technically inclined guy. 

So, alternatively, howe about we treat this issue as a technical one, 
because that's what FF ultimately is, whether marketing's "on board" 
or not. :-;

#- Some remain unconvinced that Fast Flux a problem (or a subset of a 
#problem) that needs to be solved at all (providers of data take note, 
#stronger facts would be useful here)

What sort of "stronger facts" would be helpful? I've attempted to provide
examples, plus connections to third party researchers in this area, etc.

Pretty darn hard to provide data if there's no consensus about what data
is still needed. 

Do you want a list of a thousand fast flux domains?

Ten thousand dotted quads abused by those thousand fast flux domains?

I've previously offered bulk data, but had no takers, even though folks
keep talking about "wanting data."

Tell me what you want, and if there's any way in heck to get it, I'll
send it along. 

Or should I just start sending along example after example, with dig
output showing the behavior? I suspect that would pretty quickly drown
out discussion on the list, and frankly, I don't think that would be
persuasive -- or would it be? 

Do we need a separate data-reporting list just for those who want data 
samples?

#- Some remain unconvinced that your proposed solution will work 
#without imposing inordinate burdens on the partners you're trying to 
#recruit to your cause

We've talked about proposed approaches that require minimal data
collection (just a fully qualified domain name!), simple mechanical
testing based on an objective test, some simple checks to prevent 
accidents, and minimal levels of human review. Don't know how to make
better make the point that that's not inordinant, except perhaps by 
showing the process as part of a data feed to the data-reporting list
I've previously mentioned. 

#- Some are concerned that the proposal lacks sufficient safeguards to 
#protect registrants and users from the impact of false positives

Wouldn't human review plus a right of appeal deal with those issues?
If not, I'd love to hear why not.

#These objections are crucial pieces of information -- for they 
#provide you guidance as to what parts of your proposals need to be 
#improved.  

If we hadn't already gone over those points, I'd concur that they
need more coverage. But we *have* gone over them, repeatedly.

#Do not argue with them, 

Hopefully attempting to address articulated concerns is not "arguing
with them." If articulated concerns cannot be addressed, then dialog
becomes dang difficult. 

#for they are prospective partners 
#you are trying to win over and, as any sales person will tell you, 
#arguing with prospects makes them cranky and less inclined to buy 
#into your solution.  

Some prospects may not be interested in buying under any circumstances,
and smart salesmen recognize that reality.

I will also say in passing that the greatest salesman I ever saw was a 
car salesman who simply laid out the facts, and who DID argue with 
customers, including steering them away from higher priced, higher margin 
vehicles to cars that offered the best value and had the best features, 
reliability, etc.

*Why* was he a great salesman? Because he just laid it out. No fawning,
no pandering, no compromises, no spin, he knew the product lines backwards
and forwards, and he told folks what *he'd* want to know if he was buying
a car instead of acting as the guy selling the cars. 

Not only did people buy cars from him, they sent their friends to buy cars 
from him as well.

#Rather, listen to what they are saying and 
#address their concerns by improving the underpinnings of your 
#argument and refining your proposal to meet their needs.

Trying to do so. 

But what if the hypothetical requirement is for us to converge around 
the proposition that "Fastflux is not an issue, or if it is an issue, 
it's not an issue for ICANN, nor the registries, nor the registrars."

That, in a nutshell, may very well be the position that would "best meet 
the needs of ICANN, the registries and registrars," because if that's the 
position that's adopted, then they need do nothing about the fastflux 
problem (problem? what problem?).

If that's the product the "customer"/"partner" wants, I don't see any way 
to polish up the storyboards or dream up a clever jingle to sell them
something that's 180 degrees diametrically opposed to that.

And in the mean time the users of the Internet, including all the people
with hosts that have been botted for FF, all the victims of phishing,
all the ISPs drowning in spam, and all the victims of all the sorts of 
crimes that fastflux uniquely empowers, will continue to suffer until
action is taken against this threat.

Regards,

Joe

Disclaimer: all opinions strictly my own.