<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [council] Draft Agenda for Council meeting - Thursday 7 June 2007
- To: "'Council GNSO'" <council@xxxxxxxxxxxxxx>
- Subject: Re: [council] Draft Agenda for Council meeting - Thursday 7 June 2007
- From: Mawaki Chango <ki_chango@xxxxxxxxx>
- Date: Tue, 29 May 2007 10:29:15 -0700 (PDT)
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=n2byRnVGT/J+jZkocOiVgwocX6yIw6Z+R3tDv6ylxyK/+flHlzmhNhRTYPIm69Yy10JaYPWlIdyff7y2Nld+7f+wGmGhHTdvtSdO55o0HmfRNErNR6M/AOfPEKcSuxtqGxxoYZxZ6icOBMviLo2lX/H9iMhxyVkWyKkBcqBG+HQ=;
- In-reply-to: <000901c7a1ca$7f1cad40$e601a8c0@PSEVO>
- Sender: owner-council@xxxxxxxxxxxxxx
>>> [Bruce] it is better to proceed in such a way that minimises
risk in the first round, but also allows flexibility to update
the recommendations based on experience of the first round.
Do you have anything specific in mind? what and where are the
provisions to ensure such flexibility? I think it is important
to know concretely how this can be handled, should the need
arise.
I don't see any contradiction between the fact that a lot of
work has been put into a PDP, and the possibility for the
*Council* to determine in the end the level of support for each
recommendation so that, as Bruce has put it, at least the
recommendations that are capable of supermajority be secured and
built on later on.
The argument that the recommendations cannot be considered
individually because they are inter-dependent is a fallacious
one because i) most of the recommendations have been discussed
separately during the process, and ii) if recommendations are so
inter-related that it wouldn't make sense to adopt/implement one
without the other, then clearly those who support one will
support the other.
Similarly, the idea of the committee having thoroughly discussed
the issues raised by NCUC (for example) without any proponents
of those ideas/issues being there to explain and respond is
deceitful.
> Note
> Not all the recommendations please everyone.
> It is not appropriate for Council to revisit issues just
> because individuals wish to re-run
> arguments that earlier failed to persuade.
> If that's how we will play it then the BC will return with our
> original wish list, so may
> the IPC, so may the ISPs, so may ... etc.
This is so bright! just that in such perspective, the PDP
process is nothing but a merely political process governed by
corporatism. (You may note, Liz, that this is not the best
mindset and environment for dialogue between constituencies as
you've been encouraging for.) If that's the case, then it should
be no surprise that courts become (are?) the only place where
some sense of higher norms and overall legitimacy is
re-stablished in the ICANN's decisions.
That shouldn't worry me, but I'm worried that this is the
perspective of an aspirant chairman for the council.
Mawaki
--- Philip Sheppard <philip.sheppard@xxxxxx> wrote:
>
> Bruce,
> allow me to respond to your questions about how we handle the
> gTLD report.
>
> 1. We treated this issue as a committee of the whole of
> Council. This process was explicitly
> to ensure incremental buy-in to recommendations by Council. It
> escapes all logic that
> Council would then vote on each recommendation. That process
> would seem suited to a task
> force report. Have we all been wasting our time? I trust not.
>
> 2. We also opened the group to observers and received
> excellent input. That was also a
> process designed to explicitly ensure incremental buy-in to
> recommendations by the wider
> community.
>
> 3. Staff have diligently drafted version upon version of the
> report so that we were all able
> to track emerging recommendations that achieved broad support.
> What was the point of all
> that if we now vote on each recommendation as if it came from
> nowhere ?
>
> 4. The recommendations were not made in glorious isolation.
> Many are inter-dependent. We
> will end up with a pigs breakfast if we assume the
> recommendations can operate in isolation.
>
> Conclusion
> We must vote on the report as a whole.
>
> Note
> Not all the recommendations please everyone.
> It is not appropriate for Council to revisit issues just
> because individuals wish to re-run
> arguments that earlier failed to persuade.
> If that's how we will play it then the BC will return with our
> original wish list, so may
> the IPC, so may the ISPs, so may ... etc.
>
> Further work
> There are a lot of issues that need further work or at least
> feedback to Council on their
> implementation. Indeed this applies to most recommendations !
> It would be useful therefore to explicitly mark in the report
> where Council expects formal
> feedback from staff.
> That makes it clear for us, clear for staff.
>
> Link to the sub groups
> We also need to make explicit reference to the inclusion and
> support for these reports where
> appropriate.
>
>
> Philip
>
>
>
>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|