ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


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

RE: [gnso-ff-pdp-may08] Proposed Recommendation and FAQ, v1

  • To: "Mike O'Connor" <mike@xxxxxxxxxx>, "gnso-ff-pdp-May08@xxxxxxxxx" <gnso-ff-pdp-May08@xxxxxxxxx>
  • Subject: RE: [gnso-ff-pdp-may08] Proposed Recommendation and FAQ, v1
  • From: Liz Gasster <liz.gasster@xxxxxxxxx>
  • Date: Mon, 11 Aug 2008 11:16:11 -0700

Mike, thanks so much for thinking through some next steps.  As we consider 
Mike's draft, it is important for the revised charter to consider how to 
further define the issue to ensure that it is properly within the scope of the 
ICANN policy process and within the scope of the GNSO.  I think the following 
language will need to be adjusted:

 ..."a project to find ways that the ICANN community can help reduce fraud and 
abuse on the
Internet by identifying measures that can be taken while protecting the rights 
of lawful
users and stakeholders."

The PDP process is limited to issues within the scope of ICANN's mission 
statement (among other limitations) or that implicate or affect an existing 
ICANN policy (see specific reference in Annex A of the bylaws).

The team should consider language that would narrow the scope of the charter 
along these lines.  I can help with drafting if the group agrees.

Thanks, Liz

-----Original Message-----
From: owner-gnso-ff-pdp-may08@xxxxxxxxx 
[mailto:owner-gnso-ff-pdp-may08@xxxxxxxxx] On Behalf Of Mike O'Connor
Sent: Monday, August 11, 2008 7:28 AM
To: gnso-ff-pdp-May08@xxxxxxxxx
Subject: [gnso-ff-pdp-may08] Proposed Recommendation and FAQ, v1

Hi all,

Here's my first try at the "rechartering"
recommendation that we discussed on the phone call this Friday.

I decided to propose a BOHAG (Big Overarching Hairy Audacious Goal) in this 
recommendation.  I'm also starting to think of this as the first draft of our 
Initial
Report.   Sure, we can work through a more
focused discussion of Fast Flux if you want.  But my feeling is -- why not go 
for the bleachers and address the elephant in the room instead?  Besides, this 
could put us back on schedule!

So here goes -- in two forms.  It's pasted into this email, and attached as a 
formatted PDF (which I find easier to read).

Reactions?  Criticisms?  Shouts of adulation and enthusiasm most appreciated.

I'm going to be spending the day on the tractor (and travelling to St Paul) so 
I may be a little sluggish in my replies.  But I look forward to our usual 
lively discussion when I return.

chairman mikey

- - - - -


Proposal.

The Fast Flux working group proposes that the next phase of this effort be to 
redefine and broaden the charter of the working group.  The charter we envision 
would describe a project to find ways that the ICANN community can help reduce 
fraud and abuse on the Internet by identifying measures that can be taken while 
protecting the rights of lawful users and stakeholders.  This multi-phase 
collaborative project would break the work up into a series of manageable 
tasks, and would include stakeholders from outside the GNSO.

Questions;

*** Question *** Why "ICANN community", not "GNSO"?

This is a puzzle that needs to be solved by a larger group of stakeholders than 
just those within GNSO.  GNSO, ccNSO, ASO, GAC, and ALAC should be involved and 
a mechanism should be found that allows this project to be sponsored by the 
ICANN community as a whole.

*** Question *** Why the focus on "charter"?

This is either a big project, or a program (a series of interrelated projects). 
 The chartering of things of this size is important and the community needs to 
focus on launching this effort in a way that will provide the best odds for 
ultimate success.  Thus, we should take care to describe and staff this effort 
well, and build support for it across the whole community, before launching the 
actual work.  The chartering process is a known and effective way to do this, 
but it is a project in and of itself.

*** Question *** Why "multi-phase"?

We want to acknowledge that this project is too big for us to finish within the 
time allotted.  We want to encourage the use of proven engineering techniques 
to ensure that we arrive at the optimum solution for all stakeholders and 
provide the proper balance of effectiveness, cost, delivery schedule and 
delivery risk.  A very preliminary list of possible phases includes;

Charter  - This is the next step we are
proposing.  This phase of the project would be to develop a detailed project 
charter that includes:
project organization (stakeholders, organization chart, roles, 
responsibilities), a statement of scope, goals and objectives, critical success 
factors, approach (work-plans, tasks, dates, deliverables), an assessment of 
readiness and plans to address shortcomings, and resource requirements (people, 
time, money, access to decision-makers, etc.).  This is a far from 
insignificant task, likely to be on roughly the same scale as our current 
project.

Assess Need -- Define and investigate nature and scope of the problem and 
define the benefits and beneficiaries of solving it

Determine Feasibility -- Describe alternative approaches (technical, policy, 
process, pricing, information-sharing, etc.) to solving the problem, evaluate 
costs and impact of each, determine which if any are feasible and recommend 
preferred solutions.

Define requirements -- Develop a high-level design of preferred solutions -- 
including roles, responsibilities, obligations, tools, metrics and goals.  To 
restate, we envision a variety of options will be proposed.  We recommend that 
this analysis be applied to technical and non-technical solution-proposals.

Design and build -- Develop the tools and techniques needed to deliver the 
solutions -- including contracts, targets, systems, policies, processes, 
training/education materials and an approach to outreach

Test -- Confirm that the solution will deliver the desired outcomes -- conduct: 
reviews of contracts and policies, walkthroughs of procedures and educational 
materials, system tests if required, pilot-projects with "early adopters", 
1st-round training/education, "early adopter" deployments

Deploy -- Move the solution into "production"
mode -- Depending on whether there are technical or policy solutions, this 
could mean turning on new systems, establishing contracts, changing to new 
policies, formalizing relationships with stakeholders outside ICANN, etc.

Maintain -- Address issues and improve the solution as conditions change -- 
These are problems that are very unlikely to remain static, so nimble response 
to changes in the environment would likely be a good thing.

*** Question *** This looks like it will take forever, does it bring things to 
a halt?

This is likely to take some time, as does any large endeavor.  We think this 
problem deserves this kind of rigor and effort.  At the same time, we don't 
want this project to stand in the way of progress.  We encourage those who wish 
to experiment with new techniques to carry on, and participate in this project 
as "early adopters."  The experience gained will be invaluable to the project 
team at every step along the way.


*** Question *** Why "collaborative"?

ICANN is based on bottom-up, consensus-based decision-making.  The project we 
envision should reflect that fundamental principle.

*** Question *** Why "project"?

By calling this a project, we hope to increase the odds of success.  Projects 
(as opposed to "functions" which are managed differently) have a distinct 
beginning, middle and end.  They are comprised of tasks and produce 
deliverables within a predefined scope.  There is a rich body of knowledge, 
tools and techniques that can be applied to help participants be successful in 
their work.

*** Question *** Why "fraud and abuse"

This is the heart of the matter.  This phrase will present the most difficult 
definitional challenge to the chartering group and is included here as a 
preliminary description of the problem we are trying to solve.  We expect 
considerable energy and creativity will be devoted to refining this term.  We 
also acknowledge that the case by case determinations will fall outside the 
ICANN community.

*** Question *** Why are the words "Fast Flux"
missing from your recommendation?

We feel that Fast Flux (a term that we have been unable to define to 
everybody's satisfaction) is a technique rather than a root-cause problem.  
Simply arriving at a shared definition has been outside the reach of the 
working group so far.  Finding and analyzing data describing the scope and 
nature of Fast Flux has also proven to be very difficult.  And we worry that by 
focusing so narrowly, we will miss the forest for the trees

*** Question *** What kind of "measures" do you envision?

We imagine that the solutions that are ultimately proposed will include a mix 
of information-sharing, technical systems, process changes and/or policy 
changes.  Bad-actors are using Internet names and numbers to cause harm to a 
wide range of our stakeholders.  We seek to make this more difficult and 
expensive, and thus reduce that avenue to causing harm.

Why "protecting the rights of lawful users and stakeholders"?

One translation of Hippocrates' Epidemics includes the phrase "Declare the 
past, diagnose the present, foretell the future; practice these acts. As to 
diseases, make a habit of two things  to help, or at least to do no harm."  We 
hope that subsequent project teams follow that principle in their work at every 
step in the process.



voice: 651-647-6109
fax: 866-280-2356

web: www.haven2.com







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

Privacy Policy | Terms of Service | Cookies Policy