ICANN/GNSO GNSO Email List Archives

[council]


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

Re: [council] Rodenbaugh Comment re GNSO Restructure Amendments to ICANN Bylaws

  • To: <icann@xxxxxxxxxxxxxx>, <gnso-council-draft2@xxxxxxxxx>
  • Subject: Re: [council] Rodenbaugh Comment re GNSO Restructure Amendments to ICANN Bylaws
  • From: Stéphane Van Gelder <stephane.vangelder@xxxxxxxxx>
  • Date: Mon, 24 Aug 2009 18:59:31 +0200
  • Cc: "'Council GNSO'" <council@xxxxxxxxxxxxxx>
  • In-reply-to: <75F0A821C5684662A5B5413CDBF73C85@HPLAPTOP>
  • List-id: council@xxxxxxxxxxxxxx
  • Sender: owner-council@xxxxxxxxxxxxxx
  • Thread-index: Acoh1IN3HarulzkUSuSog2Y3ock91QDAOANwAAG2/mA=
  • Thread-topic: [council] Rodenbaugh Comment re GNSO Restructure Amendments to ICANN Bylaws
  • User-agent: Microsoft-Entourage/12.20.0.090605

Mike,

I'm sure your passionate tirade will generate a lot of comments and there is
certainly a lot to be said.

One of the main points for me is the resentment you speak of. It has become
clear over the past few months that there is a certain amount of
dissatisfaction in the "non-contracted" side of the GNSO. Both the opinions
you voice in your email and the ongoing "NCUC controversy" are obvious signs
of that. It is something that, on a personal level, has me worried. I care
about the GNSO and I believe in the way it brings together such diverging
interests in a (nearly) homogeneous way. I think it would be a great shame
for all concerned if we were not able to maintain this 'entente cordiale' in
the long run.

This is why I feel strongly that discussion should be encouraged on the
points you raise. This despite the fact that, as the general manager of a
company that is forced to have a direct contract with ICANN in order to do
business, I feel that a lot of what you say borders on propaganda and
certainly paints a slanted picture of the real situation. I resent what I
feel is an attempt to stigmatise the contracted parties.

In your assessment of the situation, I don't think you should forget that
the contracted parties find themselves in the unique situation of having to
negotiate their key business contracts in a forum that includes other
parties in addition to the two contracting parties involved. I'm not sure
that when your law firm negotiates a contract with a customer, it discusses
the details of that contract with third parties and even allows them to vote
on certain aspects of that contract...

I think if we can all strive for a little understanding of the other
entities' points of view, we can move forward in a positive way with the
restructuring effort. And address what are very clear and very real feelings
of resentment which, I fully agree, must be addressed.

Thanks,

Stéphane

Le 24/08/09 18:25, « Mike Rodenbaugh » <icann@xxxxxxxxxxxxxx> a écrit :

> 
> For nearly three years I have represented the Business Constituency as one
> of its Officers and GNSO Councilors, but make these comments in my personal
> capacity only, as they have not been reviewed by the BC.
> 
> Why is ICANN refusing to allow new constituencies in the Contracted Party
> SG?  
> 
> There are applications for two subsets of newTLD registry operators --
> geoTLDs and IDN TLDs.  It seems reasonable for there to be a "Resellers
> Constituency."  These commercial entities have interests wholly aligned with
> those of the Contracted Parties.  Indeed resellers effectively are
> contracted parties, and prospective registry operators will have a contract
> with ICANN upon making their application.  Meanwhile they have an "as soon
> as possible" expectancy of such a contract, and then a registry contract.
> Yet the Board and Staff, without any explanation that I have seen, have
> unilaterally decided that no other entities will be allowed into the
> "Contracted Party" House.
> 
> These entities do not belong in the Non-Contracted Party SG, as they simply
> would dilute the power and voice of the vast majority of entities and
> individuals in the world, who do not rely substantially on ICANN contracts
> (or the expectation of ICANN contract) for their livelihood, but are
> materially impacted by the policies of ICANN and its contracting parties.
> Resellers and prospective registry applicants (if that was their primary
> purpose, at least) would not be allowed in the existing or proposed Business
> Constituency, ISPCPC or IPC -- and should not be allowed to dilute the
> voices of the new Commercial SG and Non-Commercial SG.  Representatives of
> those parties have indicated assent, however reluctantly in many cases, to
> this restructuring plan on the basis that parties aligned with ICANN
> Contracting Parties would find their voice through that House, not ours.
> 
> The voices and voting power of so-called "Non-Contracting" commercial
> interests are already heavily diluted under this restructuring scheme, with
> the NCSG gaining much and the Contracting Parties losing nothing whatsoever.
> Yet it is those "Non-Contracting" commercial interests that essentially fund
> by far the greatest portion of ICANN's budget through their domain
> registration fees, and it is those commercial interests that make domain
> names valuable.  While those interests suffer much already in the proposed
> restructure, now it will be proposed that 'contracting party' interests be
> allowed in our House as well?
> 
> The result will be an even stronger stranglehold on policy development than
> is already wielded by the Contracting Parties.  Their two Constituencies are
> essentially aligned in interest on virtually all issues.  Alignment will
> only increase if ICANN repeals restrictions on cross-ownership, which anyway
> do not exist with respect to ccTLDs in most cases, so we have seen
> registrars and registries teaming up on ventures for many years now.  One of
> the GNSO Councilors, for the Registrar Constituency, is CEO of a registry
> services company.  Effectively today they are one block with effective veto
> power over anything.  The best way to cement that in place is to forbid any
> other voices from joining their House.
> 
> Why do Contracting Parties maintain double voting?
> 
> It is unwise that the Contracting Parties are allowed to continue with
> 'double voting' on the new Council.  Is it not a main point of the
> restructure to increase participation and diversity on the Council?  Why
> does this only apply to one House, and not the other?  Particularly in the
> near future with hundreds more new TLD operators, and most likely hundreds
> more registrars, there is no excuse to allow just six seats in that House,
> while there are twelve in the other.  That makes it twice as hard to
> persuade a single vote to "switch sides", which might make the difference in
> many cases.  [Not sure if this is changed in their new charters, but for
> similar reasons it also should be forbidden that the Registry Constituency
> Councilors be required to vote as a block as they are today, rather than
> individually as in the Registrar Constituency.]
> 
> ICANN should be well aware that this entire GNSO restructure has been a
> bitter pill for the "Non-Contracting" business community to swallow.  Their
> power and voices will be diminished and those who have been involved know
> it.  It has not caused such recent uproar since the newTLD process has
> proved to be a more immediate and distressing battle for some in that
> community, though by no means all.  These details are also rather
> uninteresting for any normal person to consider, particularly anyone who has
> not participated on Council.  From my perspective, these specific elements
> of the new restructure could result in a lot more bitterness in the years to
> come, and appear wholly contrary to the spirit and stated intention of the
> ICANN Board in its mandate of this effort.  Moreover, they were primary
> facets of the compromise reached in 2008, which now appear to have been
> discarded by the Board and Staff, without explanation or reason.
> 
> Sincerely,
> 
> Mike Rodenbaugh
> Rodenbaugh Law
> 548 Market Street
> San Francisco, CA  94104
> +1.415.738.8087
> www.rodenbaugh.com
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature



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