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

["Mike O'Connor" <mike@xxxxxxxxxx>]

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