Re: [council] Draft Call for papers, new gTLD PDP

[Ken Stubbs <kstubbs@xxxxxxxxxxxx>]

*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  
>
>
>