RE: [gnso-ff-pdp-may08] i need some help formulating options for "next steps"

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

Hi Mike!

#I've attached Version 1 of my little poll for you to review.  Don't 
#complete the poll yet.  Rather, take a look at the questions I'm 
#asking and see if
#
#         a) they need to be reworded
#         b) something needs to be added

I'm a little confused. Can you describe what you envision going into 
the shaded green boxes? 

For example, will there be multiple choice answers from which to select,
in which case folks will just be entering A or B or C or whatever? Are
we supposed to suggest potential values for A, B, C, D, etc. in each
case? 

Or do you anticipate folks entering free-form short answers in each
box? (that would be a bear to tally, I'd think)

Or will we be ranking the items in terms of relative importance, or 
in terms of required precedence (you must have a definition before you 
can specify an algorithm) or ?

#I've provided space for you to describe two options -- of equal 
#rank.  View this as mechanized brainstorming.  I'm looking for lumps 
#of opinion about what the options should contain and put two choices 
#out there so that you can offer a couple of options if you 
#like.  It's fine if you only want to describe one option, I'll 
#exclude blank cells from tallies.

If we really like one option, can we list it twice to give it double
emphasis? :-)

All that aside, having been recycled through facilitation training
multiple times courtesy of one of the professional organizations with
which I work (think of it as sending the one recruit who somehow can't 
make a passing score on the rifle range back through basic training 
time after time after time in the vain hope that ability will somehow 
spontaneously develop through repetition -- breath, relax, aim, slack,
squeeze -- MISS! :-) ), I think I *may* be detecting the use of a "data 
gathering tool" as a "consensus building"/"consensus testing" device -- 
could I be right, Mike?

If so, just to cut to the chase, I think the areas which need testing are:

-- Definition:

   Do we agree what fastflux is, and what it isn't?

-- Importance:

   Is fastflux an important issue, or is it a de minimis corner case 
   phenomena which can safely be disregarded?

-- Subject Matter Jurisdiction:

   If we know what fastflux is, and it is important, is fastflux an 
   "ICANN issue," or is this someone else's fight? If it is someone 
   else's issue, whose issue would it be?

-- Ripeness:

   If it is ICANN's issue, is the issue "ripe" or should it be allowed
   to mature/fester a while longer?

-- Correlation with other phenomena:

   Is there another existing phenomena (such as bad/incomplete whois data) 
   which eliminates or mitigates the need for us to deal with the new topic
   fastflux? (e.g., if all fastflux domains also have bad whois data, could 
   we avoid having to deal with the fastflux problem by simply considering 
   fastflux to be a variant of the bad whois data problem?)

-- Means:

   Does the fact that fastflux is canonically implemented via botted 
   hosts have a fundamental impact on our work on this issue?

-- Intent:

   Does it matter if fastflux is used for criminal/undesirable/bad
   things such as financial fraud/phishing, or the distribution of
   malware, or the distribution of child porn?

-- Intent As It Relates to Legitimate Use:

   Have we succeeded in identifying a legitimate use that squarely
   fits the definition of fastflux, but which doesn't use unlawful
   means and which doesn't serve unlawful ends? Can we protect those
   sort of legitimate uses from impacts associated with work on
   bad fastflux domains?

-- Data Collection:

   Will collecting more data about fastflux help? Why? Are some questions
   fundamentally unquantifiable? What's being done with the data that
   researchers have already provided? What if there is no more data
   available -- is an ICANN-sponsored data collection project needed?

-- Standing to Complain:

   Do we agree who should be able to complain about a fastflux domain?
   Any individual? Only accredited parties? Only sworn law enforcement?
   Only those with legal paperwork (such as an injunction)?

-- Complaint Process:

   If ICANN were to become operationally involved in dealing with 
   fastflux issues, do we know what the complaint process might entail?
   Would it require just the submission of a domain name, or would it
   require something more, like a package documenting fastfluxiness or
   malicious use of the domain? 

-- Screening:

   Can we mechanically screen/identify fastflux domains? (recognizing 
   that we may need (or want) to do additional verification/validation 
   in some cases, e.g., before taking administrative action)

-- Action:

   Having identified a fastflux domain, do we agree what should be
   done to "process" it? Do ICANN/the registries/the registrars have
   the ability to do what's needed?

-- Procedural Redress:

   Once a fastflux-related process has been employed against a domain,
   what if it went awry? Do we have consensus about how procedural 
   errors might be redressed?

-- Deterrence:

   Can we reduce the occurence of fastflux by some means, such as 
   increasing the transparency of data sharing, making a process
   change, or changing financial charge structures, perhaps?

-- Cost Model/Funding:

   Speaking of money, do we know what this would cost and how would 
   it would be paid for? Do we agree about *WHO* would pay for it?

Regards,

Joe