<<<
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
>>>
|