[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 Attachment:
Proposed Recommendation and FAQ v1.pdf
|