At-Large Proposed 2013 RAA Posted for Comment Workspace
Comment Close | Statement | Status | Assignee(s) and | Call for | Call for | Vote | Vote Open | Vote | Vote Close | Date of Submission | Staff Contact and Email | Statement Number |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
28.03.2013 | Adopted | @Alan Greenberg (NARALO) | 28.03.2013 | 09.04.2013 | n/a | 11.04.2013 | n/a | 11.04.2013 | 11.04.2013 | Samantha Eisner | AL/ALAC/ST/0413/3 |
Comment / Reply Periods (*)
Comment Open Date:
7 March 2013
Comment Close Date:
28 March 2013 - 23:59 UTC
Reply Open Date:
29 March 2013
Reply Close Date:
19 April 2013 - 23:59 UTC
Important Information Links
To Submit Your Comments (Forum)
Brief Overview
Originating Organization:
ICANN
Categories/Tags:
Contracted Party Agreements
Purpose (Brief):
ICANN is seeking public comments on a Proposed 2013 Registrar Accreditation Agreement (RAA), particularly on areas where ICANN and the Registrar Negotiating Team have not been able to reach agreement in principle. This represents the first time in the nearly 18 months of negotiations that community comment is formally sought on this document.
Current Status:
ICANN and the Registrar Negotiating Team commenced negotiation on amendments to the RAA in October 2011. While the documents posted today show many areas of agreement, there are differences between theICANN and Registrar positions are highlighted. In addition, further discussion is still ongoing regarding some of the specifications to the agreement.
Next Steps:
After review of the comment received, the proposed 2013 RAA will be reviewed to determine if further changes are warranted. In addition, ICANN and the Registrar NT are likely to continue discussions regarding the areas where the specifications remain open. The ultimate goal is to have a 2013 RAA completed and approved in the near future.
Staff Contact:
Samantha Eisner, Senior Counsel
Detailed Information
Section I: Description, Explanation, and Purpose:
After nearly 18 months of negotiations, ICANN is posting a new version of the proposed 2013 Registrar Accreditation Agreement (RAA) for public comment.
The Registrar Negotiating Team (NT) has continued to engage in good faith negotiations to understand ICANN's perspective with respect to the outstanding issues, and to share the often divergent positions within the Registrar Stakeholder Group. Recently, additional revisions were proposed by ICANN's Negotiating Team stemming from the call by ICANN's CEO, Fadi Chehadé, to work to improve the image of the domain industry and to protect registrants through a further updated contractual framework. The Registrar NT considered each of these new issues, and worked towards finding solutions where appropriate. The RAA posted today reflects hard-fought concessions on many of key issues raised throughout the negotiations, and highlights issues remaining in order for the final 2013 RAA agreement to be reached.
Throughout the RAA and its Specifications, there are portions where two versions of draft text appear side by side. These highlight areas whereICANN and the Registrars have not been able to reach agreement in principle on an issue, therefore both positions are provided for comment. Unless otherwise noted, the remainder of the document reflects agreements in principle among ICANN and the Registrar NT.
A fuller discussion of the status of negotiations and areas of difference is available in ICANN's RAA Posting Memorandum [PDF, 66 KB].
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 athttps://icann-community.atlassian.net/wiki/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. This posting includes all documents that are currently anticipated to be part of the 2013 a. As noted above, a fuller discussion of the status of negotiations and areas of difference is available in ICANN's RAA Posting Memorandum [PDF, 66 KB].
The base RAA documents:
Proposed 2013 RAA, Annotated to Show Differences Between ICANN and Registrar Positions [PDF, 281 KB]
Redline showing changes between Proposed 2013 RAA and the June 2012 RAA Posting [PDF, 205 KB]
Redline showing changes between Proposed 2013 RAA and the 2009 RAA [PDF, 259 KB]
A Summary of Changes from the June 2012 RAA Posting [PDF, 268 KB] is also available.
The Specifications and Addendums:
For the Consensus and Temporary Policy Specification, the Data Retention Specification, and the Whois Accuracy Program Specification, each is available in annotated format to show where differences remain with the registrars, as well as redlines showing the differences in the documents from the 2012 posting.
Redline showing changes between to the Consensus and Temporary Policy Specification and the June 2012 Version [PDF, 95 KB]
Proposed Data Retention Specification, Annotated to Show Differences Between ICANN and Registrar Positions [PDF, 113 KB]
Redline showing changes between to the Data Retention Specification and the June 2012 Version [PDF, 118 KB]
Proposed Whois Accuracy Program Specification, Annotated to Show Differences Between ICANN and Registrar Positions [PDF, 116 KB]
Redline showing changes between to the Whois Accuracy Program Specification and the June 2012 Version [PDF, 142 KB]
For the remaining specifications to the RAA, the versions below are provided as ICANN's latest proposal. The Registrar Negotiation Team is still considering each of these specifications:
Proposed Registrant Rights and Responsibilities Specification [PDF, 48 KB]
ICANN Proposed Specification on Proxy/Privacy Services [PDF, 70 KB]
ICANN Proposed Additional Registrar Operation Specification [PDF, 78 KB]
ICANN Proposed Registrar Information Specification [PDF, 76 KB]
ICANN Proposed Whois Specification [PDF, 160 KB]
ICANN Proposed Compliance Certificate [PDF, 64 KB]
ICANN Proposed Transition Addendum [PDF, 63 KB]
Section IV: Additional Information:
None
(*) 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
FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC
ALAC Statement on the RAA as posted 7 April 2013
The ALAC is generally supportive of the RAA and associated specifications as posted for comment. Moreover, the ALAC is generally in agreement with ICANN on the issues where ICANN and Registrars disagree.
The proposed RAA is much better than its predecessor. It provides clarity where previously obscurity and even obfuscation ruled, and many of the omissions of earlier RAAs have been addressed. All parties in the current round of negotiations are to be congratulated.
The ALAC is particularly pleased to see the new sections on Privacy and Proxy registrations; resellers; the Whois Accuracy Program Specification; uniformity of Whois; and a clear, concise simple-language statement of registrant rights and responsibilities.
On a process level, the ALAC wishes to commend ICANN staff for presenting this information in such a way and with multiple views so as to make this very complex set of documents and the differing viewpoints comprehensible.
That being said, there are a number of issues where:
- the ALAC is uncomfortable with the position that ICANN has taken;
- the ALAC believes that additional changes are necessary.
ALAC positions on disputed terms or sections requiring additional change
Issue | ALAC Position |
RAA 3.3.1 – Registrar port 43 access for thick registries | The ALAC does not have a strong position on this, but some members believe that in the absence of a compelling reason from ICANN as to why the port 43 service should be maintained for thick registries, the registrar position is reasonable. Given the current PDP on using a Thick Whois for all registries, the ALAC suggest a middle ground. Specifically, that RAA 3.3.1 require that Registrars provide port 43 access as long as there are Thin registries in existence. If and when there are no longer any Thin registries, Registrars will no longer be required to provide Port 43 access. |
RAA 6.3 – Special Amendment by ICANN without Registrar approval | The ALAC is sympathetic with the rationale for this clause. Specifically, the regular amendment process which can and apparently does take several years, followed by up to five years delay before all registrars are subject to the new RAA is simply too long to address issues that have “substantial and compelling need”. ICANN as the custodian of the domain name system cannot allow problems that undermine the public interest to exist without taking action. Although the ICANN Board already has the authority to enact policy where the stability or security of the DNS is impacted, not all problems that need addressing meet security/stability criteria. Although ICANN is not a formal “regulator” it is in a position where it must have the tools to act in ways similar to a regulator when the public interest is threatened. That being said, the concept of a unilateral change is not one that many in At-Large feel comfortable with. The ALAC urges ICANN and Registrars to find some common ground that will allow the RAA to be changed in the middle of five-year contracts, similar to how it does for formal Consensus Policies (CP), but for issues that are not subject to CP or where the PDP route is simply too long or unable to effectively address the problem. |
RAA 6.7.2 – Definition of Registrar Approval | The ALAC has no strong feelings on whether the proposed rules are reasonable or not. |
Whois Accuracy Program Specification 1, 2, 4 – Registrant identification and contact information | The ALAC supports the ICANN position of using all available information in addressing Whois Accuracy, not solely that which is in the current Whois record. |
Whois Accuracy Program Specification 1e – Information availability | The ALAC is unsure of the subtle difference in meaning between “made available” and “readily available”. If the issue being addressed by the Registrars is a matter of cost or effort required to avail oneself of the information, that should be made much clearer and not rely on the vague term “readily” which is too subject to varying definitions. |
Whois Accuracy Program Specification 5 – Whois inaccuracy remedy | The ALAC believes that the start of this section is too vague. In particular, the word “occurrence” is undefined subject to misinterpretation. The ALAC suggests replacing the beginning of the sentence with “Upon a validated report or discovery of a…”, or alternately, "Upon learning of a...". |
Whois Accuracy Program Specification 8 – Expert Working Group | The Rational for the Board resolution creating the Expert Working Group said “Directing the President and CEO to launch a new effort focused on the purpose and provision of gTLD directory services, to serve as the foundation of an upcoming Board-initiated GNSO PDP. The outcomes of this work should act as guidance to the Issue Report that will be presented as part of the GNSO's policy development work; as a result, the Issues Report is not expected to be produced until such time as the President and CEO determines that his work has progressed to a point that it can serve as a basis of work within the PDP. ” From this, it is clear that the intent was that the Expert Working Group’s conclusions be funneled into a PDP, and it seems premature to have the have the RAA use the Special Amendment process without at least starting the PDP. It would be reasonable to allow the Special Amendment process (or what may replace it in light out the earlier comments) to be used when and if it is apparent that the PDP was not progressing with a reasonable chance of a suitable outcome. |
Consensus Policies 1.2.4 – Taking into account use of domain name | Although the ALAC understand the possible difficulty of having a registrar analyse the usage of a particular domain, one cannot totally ignore such usage either. Any policy that includes the requirement to factor in use of a domain name may be difficult to craft so that it can be effective, but the RAA should not preclude such efforts. |
Consensus Policies 1.3.4 – Details of accuracy and up-to-date specification | It is unclear what the effect would be of the Registrar request to omit the detailed list of issues that are subject to Consensus/Special Policy. If the omission implies that such issues would be out-of-bounds for future policy, the ALAC does not agree. |
Data Retention Specification 1.1.8 – Card-on-File | The impact of this change is unclear. If it is referring to credit card information where a registrar or client choses to not have the registrar save the card number for future use, the issue is a difficult one. The ALAC understands the benefit of maintaining such information for forensic purposes, but at the same time believes strongly that a consumer should be able to require that such information not be stored and therefore subject to hacking and theft. |
Data Retention Specification 2 – Trigger for exemptions | The ALAC supports the Registrar position of allowing a contracted party to comply with local law before they are under investigation or cited. Although this puts a larger burden on ICANN to validate the claim, it is a reasonable request. This is particularly true in the case of a new entry into the field (something that ICANN desperately needs in many parts of the world) where it is completely unreasonable to expect an entity to invest in a new business that will implicitly be violating existing law when it starts. |
FIRST DRAFT SUBMITTED
ALAC Statement on the RAA as posted 7 March 2013
**DRAFT** 28 March 2013, slight addition on 30 March (see comment below)
The ALAC is generally supportive of the RAA and associated specifications as posted for comment. Moreover, the ALAC is generally in agreement with ICANN on the issues where ICANN and Registrars disagree.
The proposed RAA is much better than its predecessor. It provides clarity where previously obscurity and even obfuscation ruled, and many of the omissions of earlier RAAs have been addressed. All parties in the current round of negotiations are to be congratulated.
The ALAC is particularly pleased to see the new sections on Privacy and Proxy registrations; resellers; the Whois Accuracy Program Specification; uniformity of Whois; and a clear, concise simple-language statement of registrant rights and responsibilities.
On a process level, the ALAC wishes to commend ICANN staff for presenting this information in such a way and with multiple views so as to make this very complex set of documents and the differing viewpoints comprehensible.
That being said, there are a number of issues where:
- the ALAC is uncomfortable with the position that ICANN has taken;
- the ALAC believes that additional changes are necessary.
ALAC positions on disputed terms or sections requiring additional change
Issue | ALAC Position |
RAA 3.3.1 – Registrar port 43 access for thick registries | The ALAC does not have a strong position on this, but some members believe that in the absence of a compelling reason from ICANN as to why the port 43 service should be maintained for thick registries, the registrar position is reasonable. |
RAA 6.3 – Special Amendment by ICANN without Registrar approval | The ALAC is sympathetic with the rationale for this clause. Specifically, the regular amendment process which can and apparently does take several years, followed by up to five years delay before all registrars are subject to the new RAA is simply too long to address issues that have “substantial and compelling need”. ICANN as the custodian of the domain name system cannot allow problems that undermine the public interest to exist without taking action. Although the ICANN Board already has the authority to enact policy where the stability or security of the DNS is impacted, not all problems that need addressing meet security/stability criteria.
Although ICANN is not a formal “regulator” it is in a position where it must have the tools to act in ways similar to a regulator when the public interest is threatened.
That being said, the concept of a unilateral change is not one that many in At-Large feel comfortable with. The ALAC urges ICANN and Registrars to find some common ground that will allow the RAA to be changed in the middle of five-year contracts, similar to how it does for formal Consensus Policies (CP), but for issues that are not subject to CP or where the PDP route is simply too long or unable to effectively address the problem. |
RAA 6.7.2 – Definition of Registrar Approval | The LAC has no strong feelings on whether the proposed rules are reasonable or not. |
Whois Accuracy Program Specification 1, 2, 4 –Registrant identification and contact information | The ALAC supports the ICANN position of using all available information in addressing Whois Accuracy, not solely that which is in the current Whois record. |
Whois Accuracy Program Specification 1e –Information availability | The ALAC is unsure of the subtle difference in meaning between “made available” and “readily available”. If the issue being addressed by the Registrars is a matter of cost or effort required to avail oneself of the information, that should be made much clearer and not rely on the vague term “readily” which is too subject to varying definitions. |
Whois Accuracy Program Specification 5 – Whois inaccuracy remedy | The ALAC believes that the start of this section is too vague. In particular, the word “occurrence” is undefined subject to misinterpretation. The ALAC suggests replacing the beginning of the sentence with “Upon a validated report or discovery of a…” |
Whois Accuracy Program Specification 8 – Expert Working Group | The Rational for the Board resolution creating the Expert Working Group said “Directing the President and CEO to launch a new effort focused on the purpose and provision of gTLD directory services, to serve as the foundation of an upcoming Board-initiated GNSO PDP. The outcomes of this work should act as guidance to the Issue Report that will be presented as part of the GNSO's policy development work; as a result, the Issues Report is not expected to be produced until such time as the President and CEO determines that his work has progressed to a point that it can serve as a basis of work within the PDP. ”
From this, it is clear that the intent was that the Expert Working Group’s conclusions be funneled into a PDP, and it seems premature to have the have the RAA use the Special Amendment process without at least starting the PDP. It would be reasonable to allow the Special Amendment process (or what may replace it in light out the earlier comments) to be used when and if it is apparent that the PDP was not progressing with a reasonable chance of a suitable outcome. |
Consensus Policies 1.2.4 – Taking into account use of domain name | Although the ALAC understand the possible difficulty of having a registrar analyse the usage of a particular domain, one cannot totally ignore such usage either. Any policy that includes the requirement to factor in use of a domain name may be difficult to craft so that it can be effective, but the RAA should not preclude such efforts. |
Consensus Policies 1.3.4 – Details of accuracy and up-to-date specification | It is unclear what the effect would be of the Registrar request to omit the detailed list of issues that are subject to Consensus/Special Policy. If the omission implies that such issues would be out-of-bounds for future policy, the ALAC does not agree. |
Data Retention Specification 1.1.8 – Card-on-File | The impact of this change is unclear. If it is referring to credit card information where a registrar or client choses to not have the registrar save the card number for future use, the issue is a difficult one. The ALAC understands the benefit of maintaining such information for forensic purposes, but at the same time believes strongly that a consumer should be able to require that such information not be stored and therefore subject to hacking and theft. |
Data Retention Specification 2 – Trigger for exemptions | The ALAC supports the Registrar position of allowing a contracted party to comply with local law before they are under investigation or cited. Although this puts a larger burden on ICANN to validate the claim, it is a reasonable request. This is particularly true in the case of a new entry into the field (something that ICANN desperately needs in many parts of the world) where it is completely unreasonable to expect an entity to invest in a new business that will implicitly be violating existing law when it starts. |
Comments
Thanks Holly, Several comments
Access to Whois:
Not important, but the provision for a TLD to use alternate Whois elements was always there. What is new is a change in how it is presented in the RAA.
I don't think there is a problem. the items in 3.2.1 are those that are common to bother thick and thin registries. 3.3.1 includes the other items that may currently reside in just the registrar database (for thin) or both registry and registrar (for thick). What the elements are that a particular registry uses are set out in the registry agreement, so there is no danger that elements considered important to ICANN will disappear at the registry's whim.
Whether the 3.3.1 elements are transferred to the registry depends on thick vs thin.
As an example of differences that may occur, if I remember correctly, for .tel, the name servers are not provided by the registrant to the registrar and on to the registry, but the other way around, they originate with the registry. The RAA must allow this kind of differnet model of what a registry provides, and this these clauses allow for that.
Registrant as a Person
I'm not sure what you are getting at here. The section says that a registrant may be a person or legal entity (with some specific language related to the registrant being the registrar itself).
Whois Accuracy
The substance of the differences between ICANN and the registrars seems to be whether each "registrant" stands alone and is identifiable purely based on what is in Whois, or that information outside of Whois that a registrar has on the client must also be verified and used to long together multiple registrants.
The specific language suggested by Garth is the kind of suggestion that we should be making. Very targeted and specific.
I would like to see the following:
Explicitly endorse the RDDS Specification [Section 3.2.1.2 et. al.] and additional data elements included; Registrar Abuse Contact data, Reseller data and Domain Status data
Call for harmonisation of RDDS Specs across Registrar and Registry Agreements
Reject the registrar contention with respect to relaxation of public WHOIS access requirements in thin vis-a-vis thick registries [Section 3.3.1],
Endorse the adoption of the WHOIS Accuracy Program Specification [Section 1.25] and explicitly advise accuracy standards for the registrant identification and address data elements
Endorse Privacy and Proxy Accreditation Program and their requirements [Section 3.14.2] and advise addition of a clause that explicitly affirms strict liability of the provider for accuracy of WHOIS data
Endorse and advise an explicit connection of WHOIS Accuracy Program Specs to enforcement actions per Clause 3.7.8 by adding a clause 3.7.9 that binds the registrar to the possible responses to inaccurate WHOIS data as defined in Accuracy Program Specs.
Record the ALAC's disquiet regarding declared unilateral right to adjust contract but limit and spell out the conditions under which this is invoked.
-Carlton
Thanks Carlton. A few comments to ensure that I understand what you are saying.
I don't think there is much new related to RDDS (for those not familiar with the acronym - Registration Data Directory Services - what has generally been called Whois, although I think that the latter term is still used in the RAA (RDDS is used in the new Registry agreements)). BUt yes, endorse those thing you specifically call out.
Not sure how harmonization fits in the current public comment.
Can you explain why. Personally, I cannot really justify registrars having to maintain the port 45 service for data that is coming from the registry. But perhaps I am missing something.
Are you saying standards in addition to what in in thedraft Spec now. If so, exactly what are you asking for?
Can you be explicit (perhaps a sample RAA clause) on what you are asking for?
The accuracy sped is already explicitly cited in 3.7.8 saying that the registrar shall comply with it. What exactly are you asking for in addition to this?
Carlton
I don't understand your position about registrar whois.
Why would a registrar have to run whois servers to send back the data that the registry whois already does?
For example, if you do a look up on icann.org the data you get back comes from the registry NOT the registrar. But at the moment the registrar is expected to also provide the same data via whois.
They cannot proxy back the registry whois.
This is completely illogical, as the data will be identical. Remember the registrar is obliged to send the updates to the registry.
Michele
Hi Alan:
First, following on the conversation on the Ex-Com call, we are agreed that the approach to this statement should be to 'pile on' for one set of views or other. So let's specifically endorse the specific clauses that coincide with the At-Large positions. Where they differ, we should at least reiterate our views and possibly offer some guidance.
Responding now to specifics of your queries:
#2 & #3: VI makes it possible for the Registry operator to be a Registrar simultaneously. It may be that both operations are ring fenced but I think unlikely. Ensuring harmonisation of the RDDS requirements across both domains is not only practical but moots the concerns for asymmetric WHOIS data holdings.
#4: Split the difference between the negotiating parties by explicitly prioritizing accuracy requirements for some elements reasonable people would say 'yeah, that makes sense'.
#5: Even with the Accuracy Specs and some of the process details laid out for the acceptable responses to inaccurate data, some of our brethren are vociferous Clause 3.7.8 does not offer sufficiently unambiguous enforcement covenant. So maybe a Clause 3.7.9 could be. "When inaccurate WHOIS data is confirmed, the Registrar is required to <enumerate the actions>. Failure to act shall be a breach of contract and subject to compliance remedies previously agreed."
-Carlton
Thanks.
#2 & #3: VI makes it possible for the Registry operator to be a Registrar simultaneously. It may be that both operations are ring fenced but I think unlikely. Ensuring harmonisation of the RDDS requirements across both domains is not only practical but moots the concerns for asymmetric WHOIS data holdings.
On harmonization, for any given TLD, they are harmonized. That is the point of saying the specs in the RAA may need to vary by TLD.
How does this address registrar port 43?
#4: Split the difference between the negotiating parties by explicitly prioritizing accuracy requirements for some elements reasonable people would say 'yeah, that makes sense'.
We could do that. I admit it irks me that registrars will often have information that could improve accuracy and yet refuse to be compelled to use it though.
#5: Even with the Accuracy Specs and some of the process details laid out for the acceptable responses to inaccurate data, some of our brethren are vociferous Clause 3.7.8 does not offer sufficiently unambiguous enforcement covenant. So maybe a Clause 3.7.9 could be. "When inaccurate WHOIS data is confirmed, the Registrar is required to <enumerate the actions>. Failure to act shall be a breach of contract and subject to compliance remedies previously agreed."
We can suggest something like this, but I cannot see it being accepted. It is already there and repeating it does not make it stronger.
I have not made comments on all of the documents that are included as open for comment. I have only looked at the documents that I think directly impact on users. But I'd be delighted if others with a more technical background looked at the other documents for anything that I will have missed.
What is below are my thoughts - not text. But I hope it will held Alan (who has probably gone through the documents with a very fine tooth comb anyway) and others work your way through the documents we are supposed to respond to.
My first thoughts are that we should welcome many of the changes which amount to a significant improvement in the RAA and related documents.
We should also note, though, that most of the RAA changes have already been agreed to, so there would be little or no scope to make further changes. There is more opportunity to influence changes in documents where there are areas of dispute or where the document is still being considered.
My comments on the specific document changes are below: (and in many cases, sincerely ask for ALAC input)
REGISTRAR ACCREDITATION AGREEMENT (RAA)
Resellers:
Welcome expanded definition of Reseller (1.22) to cover any entity that participates in the Registrar’s distribution channel for domain name registrations.
Access to Whois
One area where agreement has not been reached is on the access registrars must provide to Whois data. Currently, they must provide access through a port 43 Whois service and an interactive webpage. ICANN wants both avenues of access maintained; what registrars want is to provide both avenues of access only for ‘thin’ registries, and not port 43 access for thick registries. What the registrars are arguing is that the provision of port 43 whois service duplicates a registry provided service and is not ‘meaningfully’ used by third parties.
This would be supported by a new provision (already agreed) that allows a registry operator and registrar operator (3.3.1) to agree on alternative data elements to the Whois elements (3.3.1.1-3.3.1.8) if approved by ICANN.
Comment: The immediate issue is whether we believe port 43 access should be retained. Given that registrars must provide an interactive webpage to the data anyway, which is also held in escrow, I do not believe we are concerned with the registrar’s position.
What the changes seem to envisage is a move away from registrars holding data to registries being the source of data. My issue is that the current requirement on registrars to provide data to registries (3.2.1) list data that is less than the Whois data (3.3.1.1-3.3.1.8) If we move towards the registry as the source of data, the data that must be given to registries must include all of the elements of Whois data (3.3.1.1-3.3.1.8), and not changed to the lesser requirements in 3.2.1.
Privacy/Proxy:
Welcome the new arrangements (3.4) (a two step process) for privacy/proxy accreditation. Until there is a Proxy Accreditation program, Whois information and contact data must be given to ICANN on reasonable notice and request, with reference to applicable national laws on accessing data. This must be in accordance with the Privacy and Proxy Specification. (see below - still being considered by Registrars) ICANN must not disclose such data except as expressly required by law, legal proceedings, specification or policy.
Comment
Query if we are happy with the level of protection for personal information under the interim Specification. Clearly, we should participate in the development of the Proxy Accreditation program.
Registrant as a person
Welcome the new requirement (3.7.7) that the registrant must be a legal person. NB, the requirement is on the registrant. Still, it may lessen the number of Donald Ducks registering??!!
Whois Accuracy – requirement
The requirement for registrar validation/verification of the accuracy of Whois information has been significantly strengthened through the specific requirement (3.7.8) for registrar compliance with the Whois Accuracy Program specification and the specification itself). The missing piece is registrar response to public complaints about inaccurate whois data. (see below)
Registrants Rights & Responsibilities
Registrars must now publish this document on their website.
Comment
This is a good requirement – but before we think it endorse it , we should review what will be in the document
Point of Abuse Contact
We should welcome the new requirement (3.18) for registrars to have an abuse point of contact including an email address and phone number available 24/7, and must review ‘well founded’ reports of illegal activity within 24 hours.
2. WHOIS ACCURACY PROGRAM SPECIFICATION
Validation of data now must happen within 15 days. ICANN wants validation for the elements below for both the Whois information and the corresponding customer account holder contact information. The registrars only want validation for the Whois information. Validation must include:
that there is data in all the Whois information fields,
that it is in proper format for the relevant country or territory,
that email addresses, and telephone numbers and postal addresses are in the proper format.
Postal addresses must also be consistent, but the point of disagreement between ICANN and the registrars is whether information for postal validation is only where 'made available to registrars', or is simply 'readily available'.
Verification must be either by calling the party – who must response with a unique code, or by SMS with response.
The Specification also says that when a registrant wilfully provides ‘inaccurate or unreliable’ information, or fails to respond for 15 days to registrar inquiries about the accuracy of contact details, the registrar must either suspend or terminate the registration until the registrar has validation of the information. (again, ICANN wants the requirements to apply to the registrant and, if different, the account holder. Registrars only want the requirements to apply for the registrant.)
Comment: While this amounts to a very significant strengthening of data accuracy verification and compliance, it does not cover situations where members of the public report inaccuracy of the data.
Garth suggests a change of language in the specification to read: Upon the report or discovery of a Registered Name Holder’s wilful provision of inaccurate or unreliable Whois information….
3. REGISTRAR INFORMATION SPECIFICATION
This document is still being considered by registrars. This sets out the basic information that should be supplied by registrars about themselves and their affiliates and resellers to ICANN. We should support this basic information about registrars, affiliates and resellers (and any privacy/proxy services) being available.
4. SPECIFICATION ON PRIVACY AND PROXY REGISTRATIONS
The basic requirements are that privacy/proxy services must only be offered in accordance with the specification, that there must be full disclosure of terms (including circumstances under which information will be revealed and the process followed), having an abuse point of contact available 24/7, and ‘well founded’ reports of illegal activity must be followed up within 24 hours. The contact details must be held in escrow and allegations of malicious conduct, cybersquatting and other illegal activities must be forwarded within 5 business days.