[council] ICANN policies, Consensus Policies, and Contracts

Bruce Tonkin Bruce.Tonkin at melbourneit.com.au
Mon Mar 13 23:11:10 UTC 2006


Hello All,

Following the various discussions about the relationship between
policies and contracts, that was discussed in Washington a couple of
weeks ago, I have set out some basic facts to help think through the
relationships.

(1) ICANN is a corporation and can enter into contracts with third
parties.

(2) The ICANN corporation must comply with its bylaws.

(3) The Board of the ICANN corporation can establish Policies for the
corporation that are consistent with the bylaws (which includes mission
and core values).  The staff of the ICANN corporation must comply with
these policies.

(4) The GNSO can recommend policies regarding gTLDs that are consistent
with the ICANN Bylaws to the Board.   The Board must approve the
Policies.

(5) ICANN has contracts with registries and registrars relating to
gTLDs.

(6) Once a contract is signed, the terms of the contract can usually
only be changed with the agreement of both parties.

(7) The gTLD registry and registrar agreements have a special provision
in them that require registries and registrars to comply with certain
ICANN policies called "Consensus Policies" that can be established or
changed during the lifetime of the contract.    These policies can have
a significant impact on the business of registries and a registrars -
thus the areas where these policies can apply are constrained in the
contract, and also the process for establishing such Consensus policies
is tightly defined (ie via the GNSO PDP in the bylaws, by the voting
rules of the GNSO Council, and by the membership structure of the GNSO
Council).

(8) Contracts typically have a term (ie length of the contract),
conditions for the termination of a contract, and also sometimes
conditions that describe the renewal of the contract.   Some of the gTLD
registry contracts have a right of renewal and also specify that with
the renewal that some terms from the previous contract must carry
forward into the next contract.

Conclusions
===========

(a) A GNSO Consensus Policy may apply to an EXISTING contract ONLY with
respect to the narrow definition of where such policies may apply in the
contract.

(b) An ICANN Policy would apply to any future contract signed by ICANN
(including negotiating a change to a contract)

(c) With respect to an existing contract, a change to a contract to
reflect a new ICANN policy (other than a GNSO Consensus Policy as
defined in the contract) would require mutual consent between the two
parties.    


Example
=======

The ICANN Board could create a policy that all gTLD registry agreements
are for a term of one year.   The term length is not an area in the
existing contracts that could be changed by the Consensus Policy
process.   Thus existing contracts would not be affected.   Also because
term length may carry forward into a renewal of an existing contract -
this would not be affected either.   However for new contracts the term
length would be one year.

Another complicating factor is that ICANN must treat similar
organisations such as registries and registrars equitably.   So although
it could establish a policy for 1 year contracts, this may seem to be
inequitable for new registries compared to existing registries.

Alternatively the ICANN Board could create a policy that all gTLD
registry agreements are for a term of 10 years.   In this scenario it is
highly likely that an existing registry operator would agree with the
ICANN corporation to adjust their existing registry contract.


So as part of considering new policies, the GNSO needs to consider:
- the existing contracts, which also have some provisions that carry
forward when renewed
- equity between holders of existing contracts and holders of new
contracts

Regards,
Bruce Tonkin





More information about the council mailing list