[council] Draft Call for papers, new gTLD PDP

[Ken Stubbs]

*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 at gnso.icann.org [mailto:owner-council at gnso.icann.org] 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  
>
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20060104/102118be/attachment.html>