Thanks for taking the time to explain Bruce. I just which someone on the Council could explain to me why we would not have been better off approving the current RAA amendments as they are rather than delaying them along with other possible future changes. I haven't heard anything yet that makes sense to me from a practical point of view. Are there any of the proposed changes that would not be at least as good as those in the existing RAA? I understand other frustrations but in my opinion they don't justify delaying some improvements any further than we have to. Chuck
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Bruce Tonkin Sent: Tuesday, January 13, 2009 3:34 AM To: Council GNSO Subject: RE: [council] RAA amendment process
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