ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


<<< Chronological Index >>>    <<< Thread Index >>>

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

  • To: joe@xxxxxxxxxxxxxxxxxx
  • Subject: RE: [gnso-ff-pdp-may08] i need some help formulating options for "next steps"
  • From: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Date: Mon, 25 Aug 2008 13:05:59 -0500


to your question about the little green boxes -- i'm hoping that when you click on the box, you'll either see choices (mostly yes or no, but sometimes little lists) or freeform. try clicking on one of the boxes with "- - -" in it. it should drop a list from which you can choose your answer. the pre-formatting is there so that i can do arithmetic on the responses.

to your second part -- i'm really just curious to see if we can find some clumps of agreement about what options to propose as our next step. i'm exposing my bias (i'm including a lot of details in the "assess need" option because i think we need to get a better handle on that before we move on to describing solutions). and i am implying a sequence -- identify need, *then* describe solutions (if they're required), *then* select/build/implement the solutions.

m

At 12:11 PM 8/25/2008, Joe St Sauver wrote:
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

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.6.7/1632 - Release Date: 8/25/2008 7:05 AM




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy