Re: [council] FW: Blog Piece on Unilateral Right to Amend

[joy <joy@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

thanks Jeff - that was a nice, cogent commentary
regards
Joy


On 16/03/2013 10:31 a.m., Neuman, Jeff wrote:
> Given the conversation we had during the GNSO Council call, I
> thought you may find this blog post we drafted on the Unilateral
> Right to Amend: 
> http://blog.neustar.biz/neustar-insights/clearing-up-the-logjam-time-for-icann-to-drop-request-for-a-unilateral-right-to-amend-the-agreements/
>
> 
> 
> 
> I have printed the full version below;
> 
> 
> 
> 
> 
> 
> 
> *Clearing Up the Logjam: Time for ICANN to Drop Request for a
> Unilateral Right to Amend the Agreements* By: Jeff Neuman
> 
> A very rare thing happened in the GNSO Council meeting this
> week?the ICANN community spoke with one voice.  Registries,
> registrars, non-commercial interests, new TLD applicants, IP owners
> and businesses unanimously and unambiguously agreed that giving
> ICANN a "unilateral right to amend" the registry and registrar
> agreements is not compatible with ICANN?s bottom-up processes and
> poses a fundamental threat to the multi-stakeholder model.  There
> is true consensus that this change should be rejected.
> 
> On February 5, 2013, ICANN surprised the community by
> re-introducing its demand for a unilateral right to amend the gTLD
> Registry Agreement. ICANN made the same change in the Registrar
> Accreditation Agreements. (This was posted for public comment on
> March 7, 2013.  See: 
> http://www.icann.org/en/news/public-comment/proposed-raa-07mar13-en.htm).
>
>  This move came without consultation, nearly five years after the
> new gTLD Program moved into the implementation phase, and three
> years after the community and ICANN, through a bottom-up process,
> rejected this approach and reached a compromise on similar
> language.
> 
> During the GNSO Council's monthly teleconference on March 14,
> 2013, while discussing the recent changes to the Registrar
> Accreditation Agreement, Council members raised the topic of
> ICANN's proposed unilateral right to amend the registry and
> registrar agreements.  ICANN staff present on the call explained
> its position, saying, "the amendment clause is actually intended to
> be last resort for when there is agreement that something needs to
> be done, but there is a logjam within the processes that we have
> that don?t allow us to move forward." Essentially, ICANN is asking,
> "what happens when everyone agrees that a particular change is
> needed, but the multi-stakeholder processes ? or someone
> manipulating those processes - prevents the community from moving
> forward with what the community wants."
> 
> Taken in isolation and without any other context, this is a
> perfectly reasonable question.  If there truly were no mechanisms
> in the registry or registrar agreements to make necessary changes
> when the community demands action, then ICANN staff's concerns
> would be justified.  It would be a good question to ask if someone
> could use ICANN processes to block a change that everyone else
> supported.  The fact is, however, that there already are a number
> of mechanisms ICANN can take to implement community supported
> changes.
> 
> First, of course, contracted-parties can agree to make a change
> they support.  Second, there is a bottom-up Consensus Policy
> mechanism for critical changes that ensures that any implementation
> is appropriately balanced across multiple constituencies and
> stakeholder groups.  Truly important and time-sensitive issues can
> be addressed via Temporary Policies that remain in place for up to
> a year and, during that year, can be adopted as Consensus Policies.
> Finally, the new gTLD agreement contains a new mechanism that gives
> ICANN authority to make amendments supported by a specific
> percentage of the registry operators effective across the entire
> registry group.  This is the compromise that was developed through
> a bottom-up process in 2009-2010 when the community rejected the
> unilateral change provision.
> 
> ICANN agreed in 2010 that these three mechanisms gave it the
> necessary tools to amend the registry contract to implement changes
> demanded by the community.  Apparently, it has had a change of
> heart and now wants the authority to unilaterally impose changes to
> the agreements.  To date, ICANN?s explanation is that the
> introduction of new gTLDs will change things in ways that cannot be
> anticipated. ICANN has not responded to community requests for a
> concrete example of when this right would actually be needed.
> 
> Of course, the ICANN world is not unique ? the future is
> inherently unknown, but parties enter into long-term contracts with
> high stakes all the time without introducing the kind of
> uncertainty that a unilateral amendment right would create. To
> borrow from the gTLD Registries comment made on February 26, 2013:
> "we are in the midst of dramatic change in the administration of
> the top-level domain name system.  All businesses ? whether for
> profit or nonprofit - require a measure of predictability, 
> stability and certainty of contracts.  Public and multi-national
> company applicants are subject to regulatory regimes that cannot be
> reconciled with the expanded unilateral authority ICANN is seeking.
> In deciding whether or not to utilize new gTLDs for their critical
> infrastructure assets, a key goal of the new gTLD program,
> registries cannot be subject to the whim of one private entity,
> even those acting under the guise of public interest, regardless of
> how well-intentioned that private entity purports to be."
> 
> ICANN's proposal for this new mechanism, however, has been met
> with opposition not only from the new gTLD Applicants and existing 
> registries, but also the registrars, non-commercial interests, 
> businesses and IP owners.  In fact, every single comment on ICANN?s
> last minute changes to the new gTLD registry agreement called for
> its removal. EVERYONE is in agreement that this is a bad idea and
> should be withdrawn. The fact that the entire community has never
> been so aligned about a particular subject speaks volumes, but
> despite this clarity ICANN continues to insist on a unilateral
> right to amend the registry and registrar agreements,
> 
> Ironically, in this case ICANN itself is creating a logjam that is 
> preventing forward movement.  By walking away from the version of
> the legal agreement contained in the final Applicant Guidebook,
> ICANN is preventing the new gTLD Program from going forward.  This
> same issue is also the logjam preventing the roll out of a new
> registrar accreditation agreement containing enormous changes that
> would benefit registrants, law enforcement, intellectual property
> owners and Internet users in general.
> 
> So in response to ICANN?s question about clearing logjams, we think
> they are asking the wrong question.  ICANN should stop worrying
> about the theoretical logjams of the future.  It?s time to take
> this request for extraordinary, unilateral power off the table in
> order to clear away today?s very real logjam.  Once this request is
> withdrawn, the new gTLD program can move forward and the Registrar
> Accreditation Agreement can be finalized.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *Jeffrey J. Neuman Neustar, Inc. / Vice President, Business
> Affairs* 46000 Center Oak Plaza, Sterling, VA 20166 
> *Office:***+1.571.434.5772  *Mobile: *+1.202.549.5079 *Fax: 
> *+1.703.738.7965*/*jeff.neuman@xxxxxxxxxxx 
> <mailto:jeff.neuman@xxxxxxxxxxx>  */*www.neustar.biz 
> <http://www.neustar.biz/>
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRRozFAAoJEA9zUGgfM+bq15EH/1pWjHvwtGC4mFsnblLb5wOA
kmrFq1ZN/0xRxSmBsMMWjJ98PtyHp5yg6Qs8s4ez5xGiXQOSetxv2wLDr8Bai9/H
1NYu0EUYQnYWY4CzOwYHxLPOQe1Lx5BJMPkwS8sgoW4vR1XrY2d/svOLF5kNmLtt
5UQ8bHQeeeC5FB7e277vHKG4YOPc/ZqUbwXzCS3W3XbTcvxX9k9/ULD9e9E64lGG
GUzrOKUjKzh4MgiXc5l5HXUyzHZGd5F8BXzFyRwcywskzgtpwHpGfI1QW6JExRyr
rZckrpSsbLeQkt9rRBYKe0yk9jGuYB2CSZnRsXOkhcblaO9cQlf0iIVEwhubyiM=
=mOYf
-----END PGP SIGNATURE-----