<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [council] Draft Call for papers, new gTLD PDP
- To: <kstubbs@xxxxxxxxxxxx>, <marilynscade@xxxxxxxxxxx>
- Subject: RE: [council] Draft Call for papers, new gTLD PDP
- From: <tony.ar.holmes@xxxxxx>
- Date: Wed, 4 Jan 2006 18:43:45 -0000
- Cc: <tom@xxxxxxxxxx>, <ross@xxxxxxxxxx>, <ki_chango@xxxxxxxxx>, <council@xxxxxxxxxxxxxx>
- Sender: owner-council@xxxxxxxxxxxxxx
- Thread-index: AcYRWlWMgavMfCU1QlePODLngagofgAAwQSA
- Thread-topic: [council] Draft Call for papers, new gTLD PDP
Whilst agreeing with Ken in principle, the reality is that some (a few)
PDPs are likely to become challenging as the process evolves, no matter
what timelines are initially set. However if we are doing our jobs
properly the number should be few to start with, and also decrease with
time as we gain expertise in setting reasonable timeframes. Therefore
I'm reluctant to take way the ability of council to vote for time
extensions, as it appears an easier process than initiating an entirely
new PDP.
If over the course of time, the number of time extensions proves to be
unacceptably high, then I would support a move remove the time extension
capability.
Tony
-----Original Message-----
From: owner-council@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx]
On Behalf Of Ken Stubbs
Sent: 04 January 2006 18:09
To: Marilyn Cade
Cc: 'Thomas Keller'; 'Ross Rader'; 'Mawaki Chango'; 'Council GNSO'
Subject: Re: [council] Draft Call for papers, new gTLD PDP
I am becoming a firm believer in the concept of a "drop dead" date for
PDP's.
I believe that we need to insure against "perpetuity" by providing in
the process a "reasonable" time period
for completion.. If the time period is not met then that specific PDP
would expire and an entirely new PDP would have to be initiated.
I do not think it is a good idea to allow for council votes for "time
extensions" for a specific PDP as this
would circumvent the concept of a "timely " process..
your thoughts ?
Ken Stubbs
Marilyn Cade wrote:
Tom, my thinking is somewhat aligned with yours, but with some slight
variations, but I think that this is very worthwhile to develop as a
"straw
proposal". As I used to manage policy development, and it involved both
internal and external policy, there were timelines "we" could control,
and
some we could not -- e.g. when a policy was going to morph into a public
policy issue, such as "data retention", where governments became
involved.
However, still, there were stages that were within control that could be
defined and time frames established and adhered to.
Thanks for your example. Helpful.
Marilyn
-----Original Message-----
From: owner-council@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx]
On
Behalf Of Thomas Keller
Sent: Wednesday, January 04, 2006 10:52 AM
To: Ross Rader
Cc: Mawaki Chango; Council GNSO
Subject: Re: [council] Draft Call for papers, new gTLD PDP
Ross,
I'm very sympathetic of the idea of moving the PDP out to a seperate
document which can be amended more easily as well as I'm sympathethic
of the thought of keeping the PDP as narrow in purpose as possible.
Having said the latter I have to note that if we start to really focus
the PDP on policy making only we need to deal with the information
gathering and understanding part in a different manner. A manner which
does not loose the benefit of the offical character of a formal PDP
(it is my experience that a issue only gets "real" attention if there
is a decision made at the end) but with more freedom for the council
to define timelines for the research part for each issue independently.
This could be done by a more project based approach with an PDP at
its end. Let me give you a short example:
1. The council recognises that IDNs are an important issue
2. The council officially announces a timeline and events to take place
in
this time for research and "understanding" the IDN issue.
3. 2. can be repeated if needed
4. The staff manager produces an issues report on IDNs
5. The PDP is invoked
6. The PDP must be finished in time with an result
I guess the main sense of the last point is to have an defined end point
for each discussion. To be able to reach a result the TOR of the PDP
must be very minimal and defined very precisely. It would therefore be
very likely that we and up with more than one PDP for each issue.
Thats my 2 cents worth on this.
Best,
tom
Am 03.01.2006 schrieb Ross Rader:
Mawaki Chango wrote:
OK, now that this is clarified and we seem to agree that
we
need all those processes, the next question I'm
attempted
to ask is how do we do that, to "redefine" how we should
look at the PDP?
My recommendation is two-fold. First, the amendment to the
bylaws
should be to move the GNSO PDP to a separate document. This
would allow
us to modify it in the future without having to amend ICANN's
bylaws.
The amendment should be constructed so that a majority of the
board of
directors would have to vote in favor of the amendment (as
opposed to
the 2/3s required now). Second, we should only be looking to
modify the
timelines in the PDP right now. There might be additional
changes
required in the future to streamline or otherwise make the
process more
efficient, but my preference would be to avoid a wholesale
reconstruction of the PDP - we have work that we need to
undertake
immediately that would benefit from having clarified timelines.
Let's
make sure that we stay focused on the practical goal of getting
better
at what we do.
I have another question, Ross. What do you mean by "our
getting our technology acts together process"? As
enumerated in your ealier email, I suspect this is
something the GNSO Council might be doing as well (maybe
as
part of the sausage-like PDP), so I guess I need to be
able
to identify what piece is this one, thanks.
I was referring to instances where the technical environment
wasn't
quite ready for the policy work going on in the GNSO and vice
versa,
where the policy environment wasn't ready for new technical
developments being implemented. For me, this comes down to
making sure
that we are appropriately informed regarding the capabilities of
differing technologies (and often, identifying areas where new
technology might be required) prior to conducting a PDP. For
instance,
the GNSO has very little understanding of the policy
implications and
new policy requirements presented by the IRIS protocol - or
whether or
not the protocol is even appropriate for the applications that
some
would like to embed in ICANN policy. In a perfect world, we
would have
a clear understanding of these implications before we conducted
a PDP.
In this world, we need to make sure that this lack of
understanding
doesn't stand in the way of the PDP and that we rise to a proper
level
of understanding of the relevant issues in a timely manner.
Regards,
-ross
Gruss,
tom
(__)
(OO)_____
(oo) /|\ A cow is not entirely full of
| |--/ | * milk some of it is hamburger!
w w w w
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|