At-Large Proposed Final 2013 RAA Workspace

FINAL VERSION TO BE SUBMITTED IF RATIFIED

The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote. 

FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

Introduction

The ALAC extends its congratulations to all parties on completion of the Registrar Accreditation Agreement (RAA) negotiations and the accompanying documents (the Contract).

The ALAC Statement on the Revised New gTLD Registry Agreement Including Additional Public Interest Commitments Specification outlined a position which generally supported ICANN’s posture on certain contentious issues even as we signaled our qualified acceptance. While we are inclined to support all the major accompanying documents with the Contract, the details of some specifications very critical to deciding our full support remain in limbo. The Privacy/Proxy Specifications is one such example.

Until such time as these are decided, this Statement records our qualified support for the Final RAA 2013 as published.

Overall Structure and Process

The structure of this contract competently delineates commitments of ICANN and Registrars as well as the issues that require strong agreement, thus bringing much needed clarity on its purpose. We recognize the efforts to forge a stronger clause on conditions for changing the relationship midstream, including termination of the agreement. This development has our full endorsement, although it would have been helpful if some examples of ‘material breach’ were enumerated. 

We give our full support for the Consensus Policies and Temporary Policies Specification. In the matter of the so-called ‘right to unilaterally amend the RAA,’ we believe the updated construct per Clause 6.5 incorporates additional safeguards and attracts our endorsement. Nevertheless, some have argued the intent in this clause undermines the consensus policy making that has produced this RAA. We disagree and take a different and more benign view of the role reserved for ICANN as the public benefit corporation. Indeed, there might be exceptional circumstances in which ICANN would have to take unilateral action - part of being prepared for unknown unknowns.

For the first time, the topics and areas pertinent to the RAA that are within the purview of consensus policy making are finally unambiguously defined. The contract is intended, among other things, to protect and defend the global public interest. The language of Clause 1.4.4 acknowledges said Consensus Policies, or the procedures derived from them, shall not “Modify ICANN’s obligations to not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably.” The converse is equally true: the language also embraces the notion that there are matters outside of the consensus policy domain for which the Board has a duty of care and is empowered to act in protecting the global public interest. The ALAC fully supports this approach.

That said, the ALAC was among those who condemned the severe restrictions placed on some stakeholder parties from the negotiating sessions and even at this stage, we remain convinced it was unwise to exclude the community from even an active ‘watching brief’ of the negotiations especially for a contract intended to convey consensus policies and around which so many stakeholder interests converge. We deplore the flagrant lack of transparency in this process.

Whois

Whois-related matters remain on top of the ALAC agenda for the RAA. The completeness, accuracy and accessibility of Whois data (information required under Clause 3.3.1 of the RAA) is critical for Internet users: for consumers dealing with online providers of products and services, for trademark holders, for corporate and communications regulators and for law enforcement agencies. The ALAC position is that all ‘Whois’ information for the actual holder of the domain name, i.e. the beneficial user which is a term in the proposed privacy and proxy specification, should be complete and verified. If verification is not possible, the registration should be suspended.

The ALAC therefore supports the WHOIS Accuracy Program Specification ("the Specification") improvements and the set of requirements imposed on Registrars for the completeness and accuracy of Whois Data.

We fully endorse the requirement compelling Registrars to suspend the registration of the Registered Name Holder in circumstances where the Whois contact information cannot be verified. The ALAC is concerned, however, that the “account holder’ is relieved of a similar requirement if there is no affirmative response from the ‘account holder'. The ALAC believes that a similar enforcement regime should be instituted and advise suspension of the registration in this case as well. We support the extension of specification requirements to verify contact details of what the specification calls the 'account holder ' even as we recognize some challenges with its practical implementation. We understand the intent of the requirement on ‘account holders’ is to be able to contact Registered Name Holders who may be using privacy or proxy services, or otherwise not be easily contacted through using Whois data. We note ‘account holder’ identity will vary, depending on corporate arrangements within a Registered Name Holder as well as varying payment arrangements of different Registrars. So that clarity is achieved in these verification requirements, the ALAC recommend that the term ‘account holder' should be defined in the Specification as the individual or organization that has the beneficial use of the Registered Name. That will ensure that contact details relating to the actual user of the domain name are available, regardless of varying payment arrangements.

We also note that verification requirements in the Specification include contact information relating to the phone, email and postal address. However, the Whois requirements relating to phone and email contact information are only for the Registered Name Holder’s administrative and technical support contacts. (Clauses 3.3.1.7-3.3.1.8) The only contact details required of the ‘Registered Name Holder’ is for a postal address.  The ALAC's position is this too should be harmonized in the specification.

We applaud the contractual obligation imposed on Registrars to support future development in Whois specifications, inclusive of an ability to develop centralized Whois service across all Registrars. The ALAC believes such a development is in the global public interest and one feature of the comprehensive approach required to retain confidence in the domain name system to which we are committed.

Privacy/Proxy Services

The ALAC is on record supporting a regulated privacy/proxy service for domain name registration. While the Specification is short on details, we welcome the declaration of the intent to formally develop and extend rules governing the provisioning of proxy/privacy services. The ALAC notes and gives full endorsement to this new development that covenants Registrars to account for Resellers under this contract. 

Our key advice for all this remains: proxy/privacy service providers should only be accredited to the extent they meet all relevant RAA requirements (including accuracy and verification of Whois information for the beneficial users of the domain name) and they accept strict liability for all other pertinent covenants. Under the circumstances, it seems rational that redress and accounting damages attributable to privacy/proxy services may be best achieved by explicit recognition of third party rights in this Specification.

Conclusion

On balance, the ALAC accepts this 2013 RAA as marked improvement on the 2009 Agreement and the ALAC looks forward to continued participation in the evolution of a contract consistent with our commitment to be a watchdog of the global public interest. We also strongly believe that all stakeholders, including the ALAC community, should have at least a 'watching brief' on any further development of the RAA and its accompanying documents.

 

-- End of Statement ---

 

FIRST DRAFT SUBMITTED by Carlton Samuels with contributions by Holly Raiche

The ALAC extends its congratulations to all parties on completion of the negotiations for this contract. The ALAC’s Statement of March 2013 on the Draft Contract outlined a position which generally supported ICANN’s posture on certain contentious issues even as we cautioned our qualified acceptance. While we are inclined to support all the major Heads of Agreement in the Final Contract, the details of some specifications very critical to deciding our full support remain in limbo. The Privacy/Proxy Specifications is one such example. And until such time as these are decided, this statement records our qualified support for the Final RAA 2013 as published.

Regarding the structure of the Agreement, we are unanimous that the structure of this contract competently delineates commitments of ICANN and Registrars as well as the issues that require strong agreement, thus bringing much needed clarity on its purpose. We recognize the efforts to forge a stronger statement on conditions for changing the relationship midstream, including termination of the agreement. This development has our full endorsement, although it would have been helpful if some examples of ‘material breach’ were enumerated. All this aside, we were among those who lamented the severe restrictions on some stakeholder parties from the negotiating sessions and even at this stage, we remain convinced it was unwise to exclude the community from even an active ‘watching brief’ of the negotiations for a contract intended to be an embodiment of consensus policies and around which so many stakeholder interests converge.

We give our full support for the Consensus Policies and Temporary Policies Specification. In the matter of so-called ‘right to unilaterally amend the RAA,’ we believe the updated construct per Clause 6.5 incorporates additional safeguards and attracts our endorsement. Notwithstanding, some have argued the intent in this clause undermines the consensus policymaking that has produced this RAA. We disagree and take a different and more benign view of the role reserved for ICANN, the public benefit corporation. For the first time at last, the topics and areas pertinent to the RAA that are within the purview of consensus policy making are unambiguously defined. The contract is intended, among other things, to protect and defend the global public interest. The language of Clause 1.4.4 acknowledges Consensus Policies - or the procedures derived from them - shall not “Modify ICANN’s obligations to not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably”. The converse is equally true: the language also embraces the notion that there are matters outside of the consensus policy domain for which the Board has a duty of care and is empowered to act in protecting the global public interest.

Whois-related matters remain top of the ALAC Agenda for the RAA. On the whole, the ALAC favours an Accuracy Specification, inclusive of verification for all contact data defined in the Registration Data Directory Service [Whois]. The ALAC therefore supports the WHOIS Accuracy Program Specification (the Specification) improvements in requirements imposed on Registrars for the completeness and accuracy of Whois Data, as required under clause 3.3.1 of the RAA. We fully endorse the requirement compelling Registrars to suspend the registration of the Registered Name Holder in circumstances where the Whois contact information cannot be verified. The ALAC is concerned that “account holder’ is relieved of a similar requirement if there is no affirmative response from the ‘account holder'. The ALAC believes that a similar enforcement regime should be instituted and advise suspension of the registration in this case as well. We also note that verification requirements in the Specification include contact information relating to the phone, email and postal address. However, the Whois requirements relating to phone and email contact information are only for the Registered Name Holder’s admin and technical support contacts. (Clauses 3.3.1.7-3.3.1.8) The only contact details required of the ‘Registered Name Holder’ is for a postal address.

We also support the extension of specification requirements to verify contact details of what the specification calls the 'account holder paying for the Registered Name' as well, even as we recognize some challenges with its practical implementation. We understand the intent of the requirement on ‘account holders’ is to be able to contact Registered Name Holders who may be using privacy or proxy services, or otherwise not be easily contacted through using Whois data. We hold ‘account holder’ identity will vary, depending on corporate arrangements within a Registered Name Holder as well as varying payment arrangements of different Registrars. So that clarity is achieved in these verification requirements, the ALAC advise and recommend that the term ‘account holder' should be defined in the Specification as the individual or organisation that has the beneficial use of the Registered Name. That will ensure that contact details relating to the Registered Name Holder are available, regardless of varying payment arrangements. 

The ALAC is on record <link the ALAC Statement on WHOIS Review Final Report> supporting a regulated privacy/proxy service for domain name registration. And while the Specification is short on details, we welcome declaration of the intent to formally develop and extend rules governing the provisioning of proxy/privacy services. The ALAC notes and gives full endorsement to the new development which covenants Registrars to account both Resellers and Proxy/Privacy Service providers under this contract.  Our key advice for all this remains: proxy/privacy service providers may only be accredited to the extent coverage of all relevant requirements of this Agreement is fully extended to those accredited and they accept strict liability for all other pertinent covenants. Under the circumstances, it seems rational that redress and accounting damages attributable to privacy/proxy services may be best achieved by explicit recognition of third party rights in this Specification.

We applaud and affirm the contractual obligation imposed on Registrars to support future development in Whois specifications, inclusive of an ability to develop centralized Whois service across all Registrars. We believe such a development it is the global public interest and a feature of the comprehensive approach required to retain confidence in the domain name system.

On balance, the ALAC accepts this RAA 2013 as marked improvement on the 2009 Agreement and looks forward to continued participation in the evolution of a contract vehicle consonant with our commitment to be the watchdog of the global public interest.

===================================================================================================================================================================

 WHAT FOLLOWS IS TEXT CONTRIBUTED BY HOLLY RAICHE. SEE HER THREADED COMMENTS BELOW 

The completeness, accuracy and accessibility of Whois data is critical for Internet users: for consumers dealing with online providers of products and services, for trademark holders, for corporate and communications regulators and for law enforcement agencies. The ALAC position is that all ‘Whois’ information for the actual holder of the domain name - the beneficial user (a term in the proposed privacy and proxy specification) should be complete and verified. If verification is not possible, the registration should be suspended.

One of the major concerns of the ALAC has been the looseness of RAA requirements for Whois data. It was not clear that Whois data requirements covered the beneficial user of the Registered Name if they used resellers or privacy/proxy services. It was also not clear whether or how their Whois data would be verified. The wording of Whois requirements also made ICANN enforcement of the Whois requirements difficult if not impossible.

The ALAC therefore supports changes to the RAA and its accompanying documents. Together, they significantly tighten information requirements, particularly on resellers, and include a new requirement that contact information be verified. We particularly support the new requirement on the Registrars to suspend the registration of the Registered Name Holder in circumstances where the Whois contact information cannot be verified.

There are, however, still significant gaps that have not been addressed. 

Revised RAA:

Both the data that a registrar must provide to a registry (3.2.1) and the Whois information that a registrar must collect and make publicly available (3.3.1.8) can be changed merely by agreement between the registrar and registry, and with ICANN approval. With the movement towards universally ‘thick’ Whois registries, the data a registrar provides to a registry should include all of the Whois data, not simply what is now required. And given the importance of Whois data, the Whois information collected and published by registrars should not be changed without public discussion and input.

Proposed Whois Accuracy Program Specification

The Specification uses the term ‘account holder’ or ‘account holder who pays’. We assume what is meant is the beneficial user of the domain name, regardless of payment method. Therefore, the term ‘account holder’ should be defined in the RAA as the individual or organisation that is the beneficial user of the domain name. 

The Specification has lesser requirements on verification of Whois data for the beneficial users than for Registered Name Holders. Specifically, while registrars are required to suspend registration when Whois information for a Registered Name Holder cannot be verified, there is no suspension requirement for beneficial user information. Because of the importance of complete and accurate Whois information for the actual user of the domain name, any registration where the beneficial user Whois information cannot be verified should be suspended.

The verification of Whois data for the beneficial user may be done by one of three organizations. Clearly the actual registrar is responsible under the RAA for compliance with Specification requirements for verification and suspension. (RAA 3.7.8 now requires registrar compliance with the Specification). Registrars are also responsible for their reseller compliance with all RAA requirements. (RAA 3.12)

The difficulty is with the privacy/proxy servers. Under the RAA, any Registered Name Holder that licenses the use of a domain name to a third party is nevertheless deemed to be the Registered Name Holder (RAA 3.7.7.3), rather than the actual beneficial user of the name. Therefore, it is critical that there are similar requirements for Whois data collection, verification and, when necessary, suspension for Whois information of users of privacy and proxy services.

Specification on Privacy and Proxy Registrations

Under the RAA, any Registered Name Holder that licenses the use of a domain name to a third party is, nevertheless, the registered name holder of that name. However, because they are distributing the use of a domain name, they should be caught by the same requirements for the collection and accuracy of Whois data as for all beneficial users of the domain name. Therefore, the Specification should contain specific requirements on all privacy and proxy servers to collect and verify Whois information for any beneficial user of a domain name they licence. And they should be required to suspend the registration of that name if contact details cannot be verified.

There are, nevetheless, legitimate reasons why beneficial users of a domain name may not want their contact details publicly available. Therefore, while requirements for Whois data for privacy and proxy services should be for complete, verified Whois data, the circumstances in which that data will be made available will be limited.

Indeed, the Specification lacks significan detail on what such services should offer. It does not include any requirement for accurate contact details of the beneficial user, discussed above. Significantly, it also gives no guidance as to what privacy protection a privacy server should offer. Nor does it provide any guidance on circumstances where it may be legitimate to access those details.

In the interests of both Whois data accuracy and genuine privacy protection, the Specification should be developed as soon as possible.