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

["Greg Aaron" <gaaron@xxxxxxxxxxxx>]

Dear Mike:

A few notes below.  Friday's meeting was sparsely attended, and everyone
needs a clear view of what is being proposed here. 

* I agree that the group seems to lack consensus on many points -- but that
is a potential outcome in any WG, and does not invalidate a WG's charter.  

* A revised charter can be a good idea -- but I don't support a plan that
will chuck the work done to date.  The WG has an obligation to report what
it has done and learned -- and if we don't have all the problems defined and
solutions yet, that's OK to say.  The 10 questions are not without merit.
Constituency statements, and minority opinions, are also to be reflected in
a WG's product.  We should not slip our obligations to put the work and
opinions on the record, and just change the goalposts instead. 

* It is critical that any new charter stay within ICANN's purview.  

* A charter should not presuppose any conclusions.  It should reference work
already done and could list possible ideas within ICANN's purview that could
be further explored without passing judgment on them.

* Your draft document assumes some outcomes.  It should not.  For example,
there is no agreement whatsoever that "the solutions that are ultimately
proposed will include a mix of information sharing, technical systems,
process changes and/or policy changes."  

* The following strike me as beyond the charter of the present WG, and of a
future one too:
- "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."  This gets into
implementation, which should mostly be deferred.  Feasibility of
implementation needs to be considered because recommending a solution or
solutions that are unfeasible would be a waste of time. 

It might be more appropriate to say: "Develop a high-level list of possible
solutions that could be explored -- including roles, responsibilities,
obligations, tools, metrics, and goals.  It is anticipated that a variety of
possible solutions would be proposed. We recommend that both technical and
non-technical proposals be explored to the extent they are within ICANN's
mission."

* It's beyond scope of this WG to figure out how to re-engineer ICANN
processes, which is what you're getting into below.  

All best,
--Greg



-----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 5:26 PM
To: gnso-ff-pdp-May08@xxxxxxxxx
Subject: RE: [gnso-ff-pdp-may08] Proposed Recommendation and FAQ, v1


Ah!  Good point.  That highlights one of the puzzles that I think 
we're trying to address with this recommendation -- how do we (ICANN) 
do things that span more than one Supporting Organization, and 
accommodate their respective PDP processes?  I'm intentionally 
forcing this issue with this proposal, because I think staying within 
the GNSO silo presents some almost-insurmountable hurdles.

To make this a litter clearer, and lay out a possible approach, I've 
added the following to the FAQ:

What do you mean by "project"?

We've chosen that term as a way to distinguish this cross-SO effort 
from those that are managed through the PDP processes within a given 
Supporting Organization.

We believe that PDPs will be required to enact various 
recommendations as the project proceeds.  Indeed at a minimum it may 
be a good idea to have "go/no-go" PDPs at the end of each project 
phase to allow SOs to comment on and accept the work that has been 
completed, and approve launching the next phase.  In addition, policy 
and process recommendations would need PDPs to be enacted.

Our hope is that by using a series of incremental phases, with PDP 
checkpoints along the way, we can move forward in an orderly way 
while still ensuring that constituencies have a proper say over what 
is done and proposed.


I also changed the wording to make it clearer that the Fast Flux 
working group would come to an end, and that a new cross-SO team 
would be formed to carry on.   I'll wait for more comments and 
release a new draft tomorrow some time.

At 01:16 PM 8/11/2008, Liz Gasster wrote:
>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

[snip]