Page History

...

The ALAC extends its congratulations to all parties on completion of the negotiations for the RAA and accompanying  documents documents (the 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 signalled  our signaled our qualified acceptance. While we are inclined to support all the major  accompanying documentswith 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. And until such time as these are decided, this statement records our qualified support for the Final RAA  2013 2013 as published.  

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. 

...

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 asthe 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 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.  The 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 - 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.

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.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 ' 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  note 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 organisation 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 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.

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 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 for  for Resellers under this contract. 

 Our key advice for all this remains: proxy/privacy service providers  providers should only be accredited to the extent  extent they meet  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.

...

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 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 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.

...

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

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

...

One of the major concerns of the ALAC has been the looseness of RAA requirements for Whois data.  It 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.

...

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.

...

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.

...

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.

...