[council] RE: Next steps with the new gTLD recommendations (was: Draft Agenda for... 7 June 2007)

[Mawaki Chango <ki_chango@xxxxxxxxx>]

Political ambition? Hmm... interesting to hear that.

Based on reactions to my earlier email both on the list and off,
I think the following clarification is in order.

When I used the term "deceitful", I didn't mean that the
committee was manipulating and deceiving people. In fact, I was
talikng of a specific *argument*, right? In my mind at the time
of writing, that term means the same as flawed, fallacious or
misleading. And indeed, it is misleading: again how can you be
so sure you've correctly and fairly address those issues without
the participation of the proponents, without any contradicting
party? or was there one?

So if that term offended any one committee member, I do
apologize for that. It was not meant to offense people, but to
point out that an *argument* was flawed and misleading.

Other than that, I think I have the right to worry that a past
and prospective chair of the council: 

i) threatens to return to the starting blocks with his
constituency "wish list" (demands? revendications?) because some
of another constituency's critical views have been mostly
discussed in their absence and they feel those are not
substantially addressed enough as a consequence; 

ii) displays the disdain of picking, as chair of the Whois WG,
the members of the WG whose questions to address and ignoring
the rest as he pleases (note: addressing a question directed to
someone, as that was the case, does not necessary mean having a
definite answer to it.)  

I don't know if those are "parliamentary" manners. If others
here wouldn't find the above latter offensive, some others do
and I certainly am part of these others.

Regards,

Mawaki  

--- "Gomes, Chuck" <cgomes@xxxxxxxxxxxx> wrote:

> Mawaki,
> 
> I personally think the suggestions of deceit and political
> ambition are
> inappropriate and suggest that you argue your points
> objectively without
> making such assertions.
> 
> Chuck Gomes
>  
> "This message is intended for the use of the individual or
> entity to
> which it is addressed, and may contain information that is
> privileged,
> confidential and exempt from disclosure under applicable law.
> Any
> unauthorized use, distribution, or disclosure is strictly
> prohibited. If
> you have received this message in error, please notify sender
> immediately and destroy/delete the original transmission." 
>  
> 
> > -----Original Message-----
> > From: owner-council@xxxxxxxxxxxxxx 
> > [mailto:owner-council@xxxxxxxxxxxxxx] On Behalf Of Mawaki
> Chango
> > Sent: Tuesday, May 29, 2007 1:29 PM
> > To: 'Council GNSO'
> > Subject: Re: [council] Draft Agenda for Council meeting - 
> > Thursday 7 June 2007
> > 
> > >>> [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
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
>