Comment Close
Date
Statement
Name 

Status

Assignee(s) and
RALO(s)

Call for
Comments
Call for
Comments
Close 
Vote
Announcement 
Vote OpenVote
Reminder
Vote CloseDate of SubmissionStaff Contact and EmailStatement Number
13.05.2013Proposed Final 2013 RAAAdopted 12Y, 0N, 0A23.04.201221.05.201323.05.201323.05.201302.06.2013

03.06.2013

04.06.2013Samantha Eisner
samantha.eisner@icann.org
AL-ALAC-ST-0613-01-00-EN
Comment / Reply Periods (*)
Comment Open Date: 
22 April 2013
Comment Close Date: 
13 May 2013 - 23:59 UTC
Reply Open Date: 
14 May 2013
Reply Close Date: 
4 June 2013 - 23:59 UTC
Important Information Links
Brief Overview
Originating Organization: 
ICANN
Categories/Tags: 
  • Contracted Party Agreements
Purpose (Brief): 

ICANN is seeking public comments on the Proposed Final 2013 Registrar Accreditation Agreement (RAA). This is the culmination of 18 months of intensive negotiations.

Current Status: 

ICANN and the Registrar Negotiating Team commenced negotiation on amendments to the RAA in October 2011. Since the 7 March 2013 version was posted, ICANN and the Registrars (through the Registrar Negotiating Team) continued to reach agreement on the proposed text of the 2013 RAA, which is now posted for community comment.

Next Steps: 

After review of the comment received, the Proposed Final 2013 RAA will be reviewed to determine if further changes are warranted. Input on the areas that have changed since the 7 March 2013 posting will be of particular help.

Staff Contact: 
Samantha Eisner, Senior Counsel
Detailed Information
Section I: Description, Explanation, and Purpose: 

After an extended period of negotiations, ICANN is posting a proposed 2013 Registrar Accreditation Agreement (RAA) for public comment.

On 7 March 2013, ICANN posted its version of the 2013 RAA for public comment, noting some areas of disagreement between ICANN and the Registrar Negotiating Team (NT). In addition, some of the specifications posted for comment were ICANN versions only. Since the 7 March posting, the Registrar NT has engaged in frequent negotiation sessions with ICANN in order to bring to closure to all of the open negotiation topics and to consider the community comments received from the 7 March posting. As a result, at ICANN's public meeting in Beijing, ICANNand the Registrar NT announced that they had reached agreement in principle on each of the outstanding items highlighted in the March posting version. The documents posted today reflect ICANN and the Registrar NT's agreements and are the Proposed Final 2013 RAA. This proposed 2013 RAA is a cornerstone of ICANN's efforts to work to improve the image of the domain industry and to protect registrants through a further updated contractual framework. It is ICANN's intention to have the 2013 RAA completed and approved in the near future for use in the NewgTLD Program.

To allow for transparency into the proposed final version of the 2013 RAA and community input on the changes from the 7 March posting,ICANN is opening a full comment forum.

ICANN thanks the Registrar Negotiating Team (NT) for its continued engagement in good faith negotiations on the RAA. The RAA posted today reflects hard-fought concessions on many of key issues raised throughout the negotiations.

A fuller discussion of the status of negotiations and areas of difference is available in ICANN's RAA Posting Memorandum [PDF, 65 KB].

Update on 8 May 2013: On 6 May 2013 ICANN hosted a webinar to provide further information on the 2013 RAA. The recording of the webinar can be accessed here and the presentation from the webinar can be accessed here.

Section II: Background: 

The current round of negotiations over the RAA began in October 2011. ICANN and the Registrar Negotiation Team have presented updates to the community at each of ICANN’s public meetings since that time. Information on the history of the negotiations, including previously released documentation, is available at the community wiki at https://community.icann.org/display/RAA/Negotiations+Between+ICANN+and+Registrars+to+Amend+the+Registrar+Accreditation+Agreement. This includes the group of documents posted in June 2012, which demonstrated the progress to date in the negotiations.

Section III: Document and Resource Links: 

There are multiple documents for review as part of this posting. The new RAA is anticipated to be a base document with a series of specifications attached. Each specification is an integral, enforceable component of the RAA. This posting includes all documents that are currently anticipated to be part of the 2013 RAA. As noted above, a fuller discussion of the status of negotiations and areas of difference is available in ICANN's RAA Posting Memorandum [PDF, 65 KB]. A summary [PDF, 59 KB] of how the 12 law enforcement recommendations are incorporated into the RAA is also provided.

The base RAA documents:

The Proposed Specifications and Addendums:

 

Section IV: Additional Information: 

A Report of the Public Comments submitted in response to the 7 March 2013 posting of the RAA is available here [PDF, 178 KB].


(*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses.

FINAL VERSION TO BE SUBMITTED IF RATIFIED

Please click here to download a copy of the PDF below.

 

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, we regret that some areas, such as the Privacy/Proxy Specifications, did not go further in defining registrant rights and obligations that would conserve the public interest.

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 bottom-up multi-stakeholder model on which ICANN is built. 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.

  • No labels

8 Comments

  1. I have redone my comments - particularly after looking at Steve Metalitz' contribution, plus some feedback from Garth. So apologies for those who read the first version.  I like this better IAlso, I have only commented on the RAA, tne Accuracy and Privacy/Proxy Specifications.  I think they are the main ones, but please - anyone who has thoughts about the others, have a look.

     

    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.

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

  2. Dear Carlton and Holly,

    Great work!  I support the contents of your contribution.

    I find Carlton's overview of the key issues of concern (together with the ALAC position on each) to be on point and provides an excellent frame for the statement. 

    Holly's more detailed contribution is consistent with Calton's and clarifies the situation for those not well versed with the issue.  Furthermore, I think it fits within Carlton's frame perfectly and easily.

    A request: Can you integrate your content at the overlapping points and present it as one statement, please?  I think those who may want to comment may be somewhat flummoxed in terms of whether your contributions are 2 separate statements or 1 statement with an addendum or 1 statement that draws from the 2nd contribution.

    An integrated version would make it easier for others to comment.

    Best regards,

    Rinalia

  3. It is not clear if the DRAFT statement is the 8 paragraphs following that title, or the entire text all the way down to the start of comments. I am assuming the former.

    Overall, a good statement.  Some specific comments follow.

    Paragraph 1

    • I don't understand the reference to Heads of Agreement and Final Contract.
    • The Privacy/Proxy Specification that I see (revised 24 April) seems to be complete. What is missing?

    Paragraph 2

    • Statements such as "we are unanimous" is premature given that the statement has not been voted on yet.

    Paragraph 4

    I am confused by  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. 

    Are you saying that is the registrant does not respond, but the Registrar verifies that the information is valid and correct, the registration should still be suspended?

    I would definitely say that we regret that the Spec calls for 1.f.i OR 1.f.ii instead of requiring both (I understand that this is one of the things that ICANN gave up on in order to get an agreement, but I think we should go on record that we would have liked both).

    Paragraph 5

    I have a problem with this entire section. The "Account Holder" is entity with whom the Registrar is dealing, regardless of what is listed in Whois. It is a MAJOR success of this agreement that although we do not have access to this information (it is what the registrar might us in their accounting system), we are forcing the registrar to assert to its accuracy. It incidentally as you allude may well be the identity hidden behind a proxy registration.

    It is specifically not necessarily the beneficial owner of the domain, but the one that the registrar is likely able to contact. (for instance, I may create a registration for a local club. The club is listed as the beneficial owner, but I show up in the registrars records as the person to contact for payment problems.

    Paragraph 6

    "Specification is short on details"? It is about as complete as it can be given that except for an in-house P/P service, the registrar has no knowledge of who is a P/P service. What is missing for an in-house provider?

     

     

  4. First, Rinalia, I will try to combine the two statements. Carlton and I both agree that the documents are an important step forward towards, and to be applauded.

    My comments reflect years as a public advocate. You must be very specific in saying what is wrong with something, along with concrete suggestions on fixing the problem.  Otherwise, it is too easy for the recipient to thank you for your comments, say they agree, and then totally ignore what you say.

    Next, specific responses to Alan's questions.

    Paragraph One: I agree with Carlton.  The privacy/proxy specification is a mess of black, blue and red type that do little more then spell out what a user must be told.  There are no requirements on a 'privacy' service provider to protect a user's personal information and no rules on who should have access to that information and under what conditions.  So in one sense, it is complete.  But in a very real sense, the specification does not have minimum requirements for a service to be considered as a 'privacy service'.  Same is true for proxy services.

    Paragraph Four: The way this is worded in the Accuracy Specification, if the information provided by the 'account holder' cannot be verified, there is no requirement on the registrar to suspend that registration. That is not the case for information on the Registered Name Holder which, if that information cannot be verified, the registrar must suspend the registration.

    Paragraph Five: The problem with the term 'account holder' is that it is not clear who that is.  Under the existing RAA, the admin and tech contact information are already required and now, must be verified (a very big win) either directly by the registrar or by the reselller - through tightened requirements on the registrar's responsibility for reseller compliance with the RAA (3.12 RAA).

    In the example Alan gives, if he creates a registration for a local club, he says he would be contacted for payment.  However, if I were Alan, I would make sure that the admin and contact information given to the registrar (or reselller) were on the club's staff.  Otherwise, Alan would be hunted down for payment when payment issues should be handled within the club's own administration (Alan - advice from a non-practicing lawyer - do not allow any club or whatever organisation you organise a domain name for to use your contact details either as an admin or tech contact)

    However, because the privacy/proxy servers ARE the registered name holder (3.7.7.3 RAA) there are no requirements on ensuring accuracy/verifying the data for the privacy/proxy services - a HUGE gap. And because the privacy/proxy server ARE the registered name holder, the place to fix that problem is in the privacy/proxy Specification.  Otherwise, the RAA would have to be changed so that anyone (not just registrars) who licences the use of a domain name to a third party must collect Whois data, and verify its accuracy - or revoke the licence to use the name.

    Paragraph Six: As I have already said, the P/P Specification does not go very far in its requirements.  There are useful definitions, and a requirement for an abuse point of contact.  But nothing requires someone setting up a privacy service without some minimum requirements to reasonably protect the privacy of the beneficial user.  Nor are there any requirements on the p/p service to ensure the details of the beneficial user are correct, verified - or the licence to use cacelled.

     

    Now to try to merge the what Carlton and I have to say....

     

     

     

     

     

  5. Hello,

    • Congratulations Carlton & Holly, good work!
    • Rinalia +1 on the need to merge the pieces into a single text, avoiding redundancies.
    • Alan + 1 on all his remarks. 2 reasons to delete any mention of unanimity: first, it has not yet been reached on this draft; second, and more generally, underlining a proportion of votes weakens the thrust of other ALAC statements or recommendations which may not have been acquired unanimously, and yet some are equally important.
    • As it is a rather long text, I would suggest summing up the points on which the ALAC will be the most vigilant, either at the end of each relevant section, or as a very brief general summary at the end.

    Regards,

    Jean-Jacques, 20130514.

    1. As I noted at the start of my comment, I was assuming that the formal ALAC statement ended at the line of equal signs. If it is the complete text, that is (in my opinion) far too long.

  6. This is my attemt at merging Carlton's and my contributions. (and yes, Alan, it is a long document.  But we are being asked to comment on both modifications to the RAA and several new documents.)

    The ALAC extends its congratulations to all parties on completion of the negotiations for the RAA and accompanying  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 qualified acceptance. While we are inclined to support all the major  accompanying documentswith 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 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. 

    That said, 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 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 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 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 ‘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 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  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.

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

  7. Holly did a bang-up job combining my draft with hers.  Actually reads like one voice. I have made a few cosmetic mends to the final draft.  I think it is ready for the vote.

     

    Carlton