[council] RAA amendment process

[Bruce Tonkin]

Hello Alan,

Your email highlights one of the key problems that ICANN has had over
several years - that being the difference between developing
policies/technical standards that all parties need to adhere to when
they are created, and the process for changing a contract.

I will attempt to describe at the least my understanding of the
situation.

(1) Consensus Policies

- within the gTLD registry and gTLD registrar contracts - over time this
has the meaning of those policies that are mandatory and must be
complied with as soon as they are posted to:
http://www.icann.org/en/general/consensus-policies.htm

- the GNSO PDP process was specifically developed for this scenario


(2) Contractual terms

- ICANN has run various processes to update the .com agreement during
the term of the agreement, and also update the new gTLD agreements
(.biz, .info ) when they have come up for renewal

- these contracts have been updated by mutual agreement between ICANN
and the contracting party, but ICANN did seek public input in all cases
but did not go through any GNSO approval process

- the .com agreement in particular was very controversial

- one of the issues is that portions of the contracts that have been
developed overtime - have components that do have policy implications -
for example section 3.3.1 of the RAA
(http://www.icann.org/en/registrars/ra-agreement-17may01.htm#2)
specifies what data elements must be provided as part of a WHOIS
service.   So it would be inappropriate for a registrar to negotiate
with ICANN to change such text in the absence of consensus agreement.
Items such as WHOIS do not have a complete consensus policy defined in
http://www.icann.org/en/general/consensus-policies.htm, as they were
encapsulated into the RAA at the time of creating the registry/registrar
model in 1999.   This work predated the GNSO and the policy development
process (PDP).

- other aspects of a contract - e.g section 3.9.1 the yearly
accreditation fee is specified as US$4,000-  are not really policy
issues - and ICANN should be able to negotiate with a registrar to
change this number up or done, consistent with ICANN's overall budget
process etc.

- with respect to registry agreements, a policy was created for a
process called the "Registry Services Evaluation Policy"
http://www.icann.org/en/registries/rsep/rsep.html to allow a registry
operator to change the specifications of the services it offers that are
defined in the contract using a standard process

- the RAA process has become confusing in that it has started out with a
simple shared objective between registrars an ICANN to improve the
contract to deal with situations such as the RegisterFly incident (such
changes including mechanisms for ICANN to suspend a registrar and
mechanisms to deal with private or proxy registrations), and to carry
out these changes quickly.   ICANN has sought public comments on the RAA
as part of this process.   I believe that ICANN staff believe that there
are some policy implications with some of the proposed changes - and
thus they are now seeking approval from the GNSO, before presenting it
to the Board.   As this is a contract change - either the parties both
agree to update the current agreement (as was done for .com), or ICANN
updates the agreement at the time of renewal (as was done for .biz and
.info).


- we now have a community expectation problem - a wide range of
improvements to the RAA have been suggested as part of the consultation
- but many of these changes are in effect significant policy changes and
should go through a full PDP process.   The perception is that because
these changes have not be incorporated into the RAA that the public
input has been ignored.


(3) Possible way forward?

Perhaps the path forward is to identify the changes that have been
proposed that provide a clear benefit and are not major policy issues.
So for example the proposed change to section 2.1 - gives ICANN stronger
mechanisms to suspend a registrar ability to register names, should be
able to be accepted as a commercial term between a registrar and ICANN,
whereas the proposed change to section 3.2 relates to privacy services
and WHOIS and is probably best left to a GNSO policy process - even
though the change is certainly an improvement on the current contract,
and even though the GNSO process will take longer to complete.    In the
meantime, registrars may voluntarily agree to implement the proposed
language in clause 3.2.

- - maybe ICANN could create a fresh redline of changes that do not have
policy implications and don't need a consensus approval process, and
leave the other changes to a PDP process to develop consensus policy
around topics such as privacy and proxy registration services.


I hope these personal observations may be helpful, coming from someone
that has been involved in ICANN discussions on contracts and policies
since 2001.

Regards,
Bruce Tonkin