<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [gnso-ff-pdp-may08] Proposed Recommendation and FAQ, v1 -- Chartering
- To: <gaaron@xxxxxxxxxxxx>, <gnso-ff-pdp-May08@xxxxxxxxx>
- Subject: RE: [gnso-ff-pdp-may08] Proposed Recommendation and FAQ, v1 -- Chartering
- From: "Mike O'Connor" <mike@xxxxxxxxxx>
- Date: Wed, 13 Aug 2008 10:17:39 -0500
Ah! That's another angle.
What if we propose that the next step is a PDP to issue a
carefully-crafted "RFP" requesting policy-proposals from
organizations like APWG? The working group could put lots of energy
into defining the framework that those proposals should adhere to,
the kinds of proof/justification sought, descriptions of other
non-policy non-ICANN solutions that they would recommend, the reasons
why the ICANN policy-change (PDP) is needed, descriptions of the
safeguards for lawful users, etc. etc.?
I have to admit that I've struggled a bit with why we, a
policy-making group following a policy-making process, have been
charged to do a fair amount of pre-policy research and
solution-definition. For example, I was surprised to find out how
much original work we were being asked to do in defining what FF is,
obtaining data to support moving forward, describing harm/benefit,
etc. Frankly I was expecting preexisting industry-expert answers to
all these. I would support the notion of shifting the policy
prep-work to another organization.
What say you?
At 09:36 AM 8/13/2008, Greg Aaron wrote:
Hi, Mike:
Broaden the scope in that manner? No. To "find ways that the ICANN
community can, within it's purview, help reduce fraud and abuse on the
Internet by identifying measures that can be taken while protecting the
rights of lawful users and stakeholders" would expand the scope to spam,
phishing, malware, 419 scams, identity theft of all kinds, etc. etc.
That is an even bigger hairball, and frankly beyond ICANN's purview.
And there's an organization that already has that mission -- the APWG.
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: Tuesday, August 12, 2008 6:51 PM
To: gaaron@xxxxxxxxxxxx; gnso-ff-pdp-May08@xxxxxxxxx
Subject: RE: [gnso-ff-pdp-may08] Proposed Recommendation and FAQ, v1 --
Chartering
At 12:13 PM 8/12/2008, Greg Aaron wrote:
>Dear Mike:
>
>I guess I'm looking to you for the plan of how the group will deliver a
>report for October as per charter, in addition to seeing how we can revise
>the charter for past October. Energy needs to be expended on both the
>former and the latter.
Yep, which really means that we need to deliver a report within the
next week or 10 days, given the 30-day Constituency-review cycle that
we have to adhere to.
I'm completely stumped on how to pull a "answers to the questions"
report out of our hat -- for all the reasons that we've discussed on
the list. One approach might be for each WG member to write *their*
answers to the questions, then we smash that together and report it
out. Would others be up for this kind of approach? I am overwhelmed
by the idea of trying to summarize 1000+ emails, especially given
that our opinions have moved a bit during the conversation.
>Missing tools may be useful, but are not a panacea. I think the charter
>already addresses many categories you list below, and gives us some freedom
>to define things as we see fit.
>
>Here are your categories, and my notes about them:
>
>Problem Statement: The existing charter allows us to define the problem
>(which we have spent a lot of time on).
Could we go so far as to redefine-away Fast Flux (a technique) to
address the broader "find ways that the ICANN community can, within
it's purview, help reduce fraud and abuse on the Internet by
identifying measures that can be taken while protecting the rights of
lawful users and stakeholders." ?
>Stake Holders: the charter asks us who is affected and how. All GNSO
>stakeholders are represented.
I could see leaving the next phase (say, Assess Need) within GNSO,
but reach out to other Constituencies who wish to participate. Would
that work?
>Scope, Size, and Perspective: The GNSO is basically asking us to define
this
>for them. We can say what we know so far, and what needs more work.
Agreed.
>Preferred Problem-Solving Approach: Again, the GNSO is basically asking us
>to define this. Also, the WG is not necessarily tasked with finding a
>solution or solutions at this time. Approach is for us to define within
the
>general WG guidelines that were given -- consensus, consideration of
>constituency statements, etc.
I could see issuing a report that defines the charter for the next
(Needs Assessment) phase, but it would be sketchy, given the time we
have remaining. Or, we could recommend that the next phase be a
"chartering" phase that would go into more depth. Preferences, folks?
>Goals & Objectives: The charter asks us to answer 10 questions to the best
>of our ability. Any unknowns or suggestions may be stated, and that's fine
>to do.
I'm ok with making the attempt -- but I need help figuring out the
"how" of it, given the dispersion we've got in our respective answers
right now.
>Critical Success Factors: this perhaps assumes too much and gets ahead of
>things. We should let the process proceed and not assume any conclusion is
>"right."
Eh? Just don't follow this comment. I agree -- don't presuppose the
solution, but a critical success factors devolve to answering the
question "what do we need to do *well* in order for this project to
succeed?" For example one critical success factor that I'd like to
focus on for the next phase is "what's the mechanism to get opinions
to converge rather than diverge?"
>Readiness: we have already been given instruction to state what we know,
>what we don't, and in what areas there is disagreement. You bring up the
>issue of GNSO scope.
I could write this -- but most of the answers would be "things we
don't know right now."
>Resource Requirements: state it in our report, sure. We have plenty of
>access to experts already, though, and are free to get more.
I think it's more the time-resource issue. This one certainly soaked
up a lot more hours for me than I was anticipating. And likely for
others. One thing that would be useful for the next phase would be
to do a better job of laying out the tasks, time-estimates and
target-dates before we started so that folks could decide whether
they can commit.
For example, my time-availability is going to fall to zero on next
Wednesday night as I prepare to head into the hospital for some
pretty substantial surgery -- and I'll be out of commission for a
while (dang body -- it's outside the 55 year warrantee period). I
wasn't anticipating this, but there you go. So I'm trying really
hard to get as close to a report as we can before then. It would be
good to have a better estimate of these kinds of things so that
people aren't caught by surprise.
>All best,
>--Greg
Thanks Greg, let's keep polishing.
People, I'd like to ask whether you could each put together your
summary answers to the questions in the next day or two. I will work
on a draft of the "next phase" charter and we'll see where we're at
on Friday. Sound like a plan?
>-----Original Message-----
>From: owner-gnso-ff-pdp-may08@xxxxxxxxx
>[mailto:owner-gnso-ff-pdp-may08@xxxxxxxxx] On Behalf Of Mike O'Connor
>Sent: Tuesday, August 12, 2008 11:17 AM
>To: gnso-ff-pdp-May08@xxxxxxxxx
>Subject: RE: [gnso-ff-pdp-may08] Proposed Recommendation and FAQ, v1 --
>Chartering
>
>
>Hi Greg,
>
>Here's the snippet from your post that I'd like to use to kick off this
>thread.
>
>
> >* 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.
>
>I agree. I'm not really lobbying to invalidate the charter we were
>given. The charter's the charter. But it's missing a few things,
>and those missing pieces are part of why we ran into such heavy
>weather. To throw a notion in front of you (and the broader ICANN
>community), I'm going to paste a very basic set of questions that are
>usually answered by a project charter. Larger projects require much
>more rigor, but this is a pretty good basic list that I've been
>incrementally updating for, gosh I dunno, 20 years or so. Commentary
>follows the list...
>
>= = Project Charter -- Sections and
>Questions (http://www.haven2.com/pdchecklist.html) = =
>
>
>Problem Statement
>
>What is the problem (or puzzle) to be solved? How does not solving
>this problem get in the way of achieving the organization's
>objectives? What is the chronology of the situation - how did you
>get here? Are there trends at work - social, industry, financial,
>economic? Is this a 'solution' that has turned into a problem - if
>so, what is the original problem that this solution-turned-problem
>was supposed to solve? What alternatives have been explored?
>
>Stake Holders
>
>Who will be affected by the problem? Which
>employees? Stakeholders? Customers? Others? Have they been
>involved sufficiently up to this point? Should they be brought in to
>the project? When? To what degree do they share the belief that
>this is a problem that needs to be solved? Who ought to 'champion'
>this project? To whom should the project team report? Has a project
>leader been selected yet?
>
>Scope, Size and Perspective
>
>What written definition clearly distinguishes between what is inside
>this project, and what is outside? What is the level of detail and
>precision involved in this effort - is this a sweeping global effort
>(like a vision or strategy) or is this a project to produce specific
>outcomes (like install a system, or build a house)? What's the point
>of view that should be taken during the project - there can be more
>than one, better to identify 'em rather than discover them at final
>review. What's the degree of generalization being sought?
>
>Goals & Objectives
>
>What tangible, deliverable things do we want to see when this project
>is completed? How do we know when the project is done?
>
>Critical Success Factors
>
>What things do we need to do well in order for this project to
>succeed? What are the attributes of projects like this that have
>succeeded in the past? Describe some projects of this type that have
>failed. What can we do to avoid those problems this time?
>
>Preferred Problem-Solving Approach
>
>Who will do what, with whom, by when? What are the intermediate
>milestone events or deliverables that we can use as checkpoints to
>monitor the progress of the project? Are they more than 1 or 2 weeks
>apart? Do we need more (or fewer) objectives to keep the project
>under a reasonable level of control?
>
>Readiness
>
>How dissatisfied are people with the current state of affairs? How
>clear is the vision? Do people think this project needs to
>happen? Do people have the tools and training they require in order
>to perform their role in the project team? What do other people in
>the organization need to do in order to get ready? Is the project
>team in need of some time to establish how they are going to work
>together, or have they succeeded as a group before?
>
>Resource Requirements
>
>What people, time, money, access-to-decision-makers, technology,
>space, etc. do we estimate this project to take? How well do people
>understand the resources required to solve the problem? Are those
>resources available, or do we need to redirect from somewhere
>else? Is there wide support, and willingness to commit the
>resource, across the whole organization? Do people think the change
>is worth the investment? What are the organizational impacts (how
>broad, how deep)?
>
> = = = = = = = = = = = = [end] = = = = = = = = = = = =
>
>
>I'd like to make several points, based on this little list.
>
>As you read through the list, you'll see that we are missing a few
>things. Because of that, and this is important, we don't have all
>the tools we need to reach consensus. A few examples, but not an
>exhaustive list;
>
>Problem statement -- we're struggling on several dimensions here,
>because problem statement could use some refinement. Are we a
>research group trying to understand the definition and impact of fast
>flux? A design group, trying to craft good responses for the
>community? A policy group, trying to hammer out agreement across the
>Constituencies? The questions we've been posed touch on all of these
>and more. Which, to use an engineering example, is kinda like trying
>to buy the steel for a bridge at the same time that we're determining
>whether a bridge needs to be built. Part of the vehemence of our
>conversation is based on real fear of making a huge mistake (building
>the wrong bridge), or missing a huge opportunity.
>
>Stakeholders -- several people have observed on-list, and others
>off-list, that we need to have more people at the table. This is a
>*very* healthy observation. Countless projects have failed because
>the project team didn't include participation from all parts of an
>organization. An HR project will fail if they install an employee
>system without involving the security and regulatory folks, a
>manufacturing system will fail if they don't have cost-accounting
>represented, etc.
>
>Scope -- we're blinking back and forth between "yes" and "no" on the
>"scope-problems?" question in the status reports. I had us as "yes"
>3 weeks ago when we were struggling with a definition of Fast Flux,
>"no" the following week when I thought we had one, and "yes" in this
>last status report when we realized that we still needed more work on
>our scope. It would be helpful to have those written
>scope-boundaries laid out before the group gets started.
>
>Approach -- here again, we're suffering from me building the engine
>of our plane while we're in flight. The little task-plan with dates
>and deliverables that's laid out on the top page of the wiki is (he
>said humbly) a great contribution to the community and may be useful
>as people strive to improve the process going forward. But it would
>have been useful to lay that out in advance. As the work
>progresses, there should be a healthy debate about what those phases
>should look like (more on *that* in another post) but that debate
>should take place before the team is formed and launched. Just for
>instance -- the phases I've laid out are based on classic systems
>development lifecycle methodology (SDLC for short) which may or may
>not be the best way to break up the work. The chartering team should
>figure that out.
>
>Readiness -- this is a big one for me. Given the questions in that
>section, I would submit the proposition that we as a team weren't
>ready to take on this task when we started. This is not a
>condemnation, but rather tees up the very healthy question "what do
>we need to do to *GET* ready?" An example -- I'm not ready to run a
>marathon today, but I could undertake to *get* ready to run a
>marathon and succeed some time in the future. In our case, the very
>first question is the biggie -- we don't have agreement that the
>problem we've been presented needs to be solved. There are a bunch
>of things that we could encourage people to do in the future to fix
>this, but that's the situation we face today. That's not evil, or a
>mistake, it's just a readiness issue.
>
>There's more to rant about, but this is enough to give you a sense of
>where I'm at and I don't want to belabor your eyeballs.
>
>Back to your point about the charter. No charter is invalid, it's
>just a charter. But we're drawing to the close of our current
>charter, and I think it is useful to suggest positive ways to improve
>the next round. The suggestion I'm making in our proposal is that
>the whole first phase of the "next thing" be devoted to a more
>rigorous chartering effort, which will lead to better buy-in from the
>community and remove some roadblocks for the group.
>
>Thanks Greg,
>
>m
>
>No virus found in this incoming message.
>Checked by AVG - http://www.avg.com
>Version: 8.0.138 / Virus Database: 270.6.0/1604 - Release Date:
>8/11/2008 5:50 AM
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.6.2/1609 - Release Date:
8/13/2008 6:43 AM
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|