ICANN ICANN Email List Archives

[gnso-vi-feb10]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [gnso-vi-feb10] Board Resolution 2010.11.05.20

  • To: "'Milton L Mueller'" <mueller@xxxxxxx>, <icann@xxxxxxxxxxxxxx>, <Gnso-vi-feb10@xxxxxxxxx>, "'Council GNSO'" <council@xxxxxxxxxxxxxx>
  • Subject: RE: [gnso-vi-feb10] Board Resolution 2010.11.05.20
  • From: "Roberto Gaetano" <roberto@xxxxxxxxx>
  • Date: Mon, 15 Nov 2010 11:31:10 +0100

Now that a decision has been taken and the dust is settling after the storm,
wemight want to exchange some ideas on the lessons we have learned in this
WG, that already 2 qualified participants have labeled as one of the most
interesting ones.
The first consideration I would like to make is prompted by Michael's
concern about the Board making decisions in absence of community consensus.
I am also worried about those circumstances, but have to recognize that we
have to live with that. It has already been said that we cannot assume that
community consensus can be reached in each and every circumstance: this is
not always the "failure" of the WG, but often the simple result of
environmental circumstances. If I am a little worried about the Board
decisding in absence of consenus, I would be orders of magnitude more
worried by a Board who would *not* make a decision, as this would mean that
all what the incumbents that are happy with the status quo have to do is to
stall the consensus process.
In this particular case, in which it was obvious that the number of items on
which consensus was possible was very small, we could have gone on forever
without reaching substantial results, and eventually the Board would have
either recognized that no consensus was possible on a change, therefore
letting the status quo unchanged, or make a decision without the advantage
of community consensus.
We mistakenly believe that ICANN's policy making process is just based on
community consensus. It is indeed based on it, but with the caveat that the
Board, who has the ultimate responsibility of the management of the
organization, has not only the right but the duty to intervene when all
reasonable attempts at reaching community consensus have been made without a
clear cut outcome.
By making this step, this Board has taken full responsibility of its role,
and has given a sign of leadership that has not overstepped the will of the
community, but has supplemented the will of the community in a case where no
common voice has emerged.
I wonder whether this is a bird of a feather, dictated moreover by the
pressure for the introduction of net TLDs, or whether the Board is willing
to engage further in this direction, and possibly revisit issues in which,
because of lack of community consensus, things are maintained in an
inadequate state with no clear decision from the Board. The first example
that comes to mind is the WhoIs.
Cheers,
Roberto



> -----Original Message-----
> From: owner-gnso-vi-feb10@xxxxxxxxx 
> [mailto:owner-gnso-vi-feb10@xxxxxxxxx] On Behalf Of Milton L Mueller
> Sent: Wednesday, 10 November 2010 21:42
> To: icann@xxxxxxxxxxxxxx; Gnso-vi-feb10@xxxxxxxxx; 'Council GNSO'
> Subject: RE: [gnso-vi-feb10] Board Resolution 2010.11.05.20
> 
> 
> Agree. We should disband. And agree with Palage that it 
> certainly has been one of the more interesting WGs. Like 
> Michael, while pleased with the result I have nagging 
> concerns about the long-term procedural implications of the 
> board making policy without a recommendation from a WG, even 
> when it has made the right decision and even when it is 
> obvious that vested economic interests can block consensus in 
> a WG. This is not criticism of the board just pondering 
> ICANN's policy making methods...
>  
> Happy to see one less list to monitor. And happy to see that 
> Erik BW is being a good sport! 
> 
> Ciao
> 
> >I agree that there is nothing else this WG should do, and it 
> should be 
> >disbanded.  Curious to know if there are any different views 
> in the WG 
> >or on Council.
> 




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy