RE: [council] RAA amendment process
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@xxxxxxxxxxxxxx
> [mailto:owner-council@xxxxxxxxxxxxxx] 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
>
>