RE: [gnso-ff-pdp-may08] i need some help formulating options for "next steps"
- To: mike@xxxxxxxxxx
- Subject: RE: [gnso-ff-pdp-may08] i need some help formulating options for "next steps"
- From: Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>
- Date: Mon, 25 Aug 2008 10:11:30 -0700
#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
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
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:
Do we agree what fastflux is, and what it isn't?
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?
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?)
Does the fact that fastflux is canonically implemented via botted
hosts have a fundamental impact on our work on this issue?
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?
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)
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?
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?