Initial Staff input on the WHOIS Policy Review Team Draft Report Recommendations

[Denise Michel <denise.michel@xxxxxxxxx>]

Dear WHOIS Policy Review Team:
This email responds to the WHOIS Policy Review Team's request that ICANN Staff 
provide input on clarifications and potential paths to implementation for the 
Review Team's draft Recommendations. A cross-functional ICANN Staff group is 
reviewing the draft recommendations and offers the following initial input for 
the Review Team's consideration.
Recommendation 1. Single WHOIS Policy -- ICANN's WHOIS policy is poorly defined 
anddecentralized; Team recommends Board oversee creation and publication of a 
single WHOIS policy document; include gTLD WHOIS policy in Registry & Registrar 
contracts, GNSO consensus policies & procedures.
Staff understands the Review Team’s intention to be collection and posting of 
all current gTLD WHOIS policies and procedures, and can implement the 
Recommendation expeditiously.
Recommendation 2. Policy Review – WHOIS Data Reminder Policy (WDRP)  -- Board 
should ensure that Compliance develops metrics to track impact of annual data 
reminder notices to registrants, and that these metrics be used to develop and 
publish performance targets to improve data accuracy over time (if not 
feasible, develop & implement an alternative policy).
As Staff recently discussed with the Review Team, the Recommendation may be 
based on a misunderstanding of the WDRP requirements, as ICANN currently has no 
contractual authority to require registrars to track changes or provide ICANN 
with the necessary data for the recommended metrics. Staff is exploring ways to 
help achieve significant improvements in gTLD WHOIS accuracy.  Potential paths 
to implementation include: changes to the Registrar Accreditation Agreement 
(RAA), which is currently under negotiation; adoption by Registrars of best 
practices that improve WHOIS accuracy; and/or creation of a new GNSO consensus 
policy that modifies the WDRP or creates a new policy to achieve improvements 
in WHOIS accuracy.  In addition, ICANN is involving additional levels of 
management in this area, increasing Compliance staffing levels, and building 
additional compliance tools. Staff is also assessing the costs and utility of 
measuring WHOIS accuracy on an annual basis, so that efforts to improve 
accuracy can be measured systematically over time, using a clear baseline to 
assess the effectiveness of enhancements that may be implemented.
Based on feedback from the Review Team, the 2011 WDRP audit questionnaire (the 
audit was conducted in early 2012) was amended to obtain information from 
registrars on how they verify WHOIS contact information upon registration and 
on an on-going basis. The audit results will be published soon to inform policy 
debate on effectiveness of the WDRP and WHOIS metrics.
Recommendation 3. Strategic Priority -- ICANN should make WHOIS a strategic 
priority, allocate sufficient resources to ensure Compliance is fully resourced 
to take a proactive regulatory role, and encourage a culture of compliance; 
Board should ensure that a senior member of the executive team is responsible 
for overseeing WHOIS compliance.
Staff agrees that WHOIS is a strategic priority and designating a senior member 
of the executive team to be responsible for overseeing WHOIS is feasible. With 
input from the community and guidance from the Board, Staff develops ICANN's 
strategic plans and fiscal year budgets for Board approval, and WHOIS remains a 
strategic priority that has been allocated increased resources. This annual 
budget development process would be followed to maintain this priority and 
budgetary support. In October 2010, ICANN's John Jeffrey,ICANN’s General 
Counsel and Secretary assumed responsibility for overseeing the Compliance 
function.  Mr. Jeffrey is an Officer of ICANN and is a senior member of ICANN’s 
Executive Team.  The General Counsel oversees three distinct departments, Board 
Support, Compliance and Legal. They have separate managers but report to the 
executive team through Mr. Jeffrey.  Staff understands the phrase “proactive 
regulatory role” to mean that Compliance and its Executive leader should be 
taking the initiative to identify and vigorously address contract violations, 
focusing on the most serious in a systematic and rigorous way, and is committed 
to doing so.. ICANN is increasing staff levels and creating new tools to assist 
in identifying contract violations  more effectively.
Recommendation 4. Outreach -- ICANN should ensure that WHOIS policy issues are 
accompanied by cross-community outreach, including outreach to interested 
communities outside of ICANN.
Staff would welcome additional guidance from the Team on its recommended 
outreach goals and targets. The Recommendation seems consistent with ICANN’s 
current global outreach strategies – including new initiatives for Stakeholder 
outreach, Compliance’s new outreach efforts, and the outreach required in the 
GNSO's new policy development process (PDP) – and it can be implemented 
expeditiously. Staff also agrees that outreach to additional stakeholders, such 
as national data protection authorities and consumer communities is both 
valuable and feasible.
Recommendation 5. Data Accuracy -- ICANN should take appropriate measures to 
reduce the number of unreachable WHOIS registrations (as defined by the 2010 
NORC Data Accuracy Study) by 50% within 12 months and by 50% again over the 
following 12 months.
Staff is pursuing the goal of increased WHOIS accuracy, and exploring new 
approaches to working with contracted parties outside the confines of the 
contract to increase WHOIS accuracy. It would be useful to have more 
information from the Team on the Recommendation to enable Staff to further 
investigate public policy, legal issues and implementation options. In 
particular, clarification on the following elements of the Recommendation would 
be helpful:

·      It is Staffs understanding that the Team means “undeliverable” (there is 
no way to reach the registrant) when it uses the term “unreachable” in the 
Recommendation. In determining whether a registrant cannot be reached, the 
legal and privacy implications would need to be fully explored.

·      Does the Team intend for Staff to determine the extent of a study based 
on what is a statistically valid sample size given the overall market? The NORC 
Accuracy Study involved a sample size of 1400 registrations, and cost ICANN 
approximately US$200,000.

·      What level of accuracy is desired?  Achieving 100% accuracy may involve 
intrusive verification methods that can raise privacy and cost concerns, and 
might be better addressed through a policy development process (PDP) that could 
solicit the input of the community.
Advancing the goal of the Recommendation is feasible, assuming that the RAA can 
be amended through the negotiations underway or through a GNSO PDP.  Amending 
the RAA to include additional accuracy or verification requirements is 
important because the current RAA does not require registrars to verify a 
registrant’s WHOIS information at the point of registration.  Improving 
accuracy is a key ICANN request in the ongoing negotiations with registrars to 
amend the RAA. In these negotiations, ICANN has proposed including an appendix 
to the RAA that commits registrars to enhancing WHOIS accuracy through various 
phases, including gradual improvements that can be updated from time to time. 
Should these WHOIS verification obligations not be included in the amended RAA, 
a GNSO PDP would need to be initiated to create appropriate consensus policies 
to be enforceable on the registrars.  Consultations with the GNSO 
constituencies, especially the registrars, on the Recommendation would be 
helpful.
Recommendation 6. & 7. Data Accuracy -- ICANN shall publish annually an 
accuracy report on measured reduction in “unreachable WHOIS registrations.” 
ICANN shall publish status reports (at least annually) (with figures) on its 
progress towards achieving goals set out by the Team, the first to be issued 
before next review.
As noted above, Staff is pursuing the goal and is investigating the public 
policy, legal issues and implementation options available to improve accuracy. 
ICANN is reviewing how to report WHOIS inaccuracy complaints, measure reduction 
overtime, and proactively engage with non-compliant registrars by leveraging 
the complaint intake system and resources currently available.  As noted above, 
Staff analysis is ongoing, and changes to improve accuracy are under discussion 
in the RAA negotiations, which also should be factored in. Community discussion 
also would be helpful on how the Recommendation can best be implemented.
Recommendation 8. Data Accuracy -- ICANN should ensure that there is a clear, 
unambiguous and enforceable chain of contractual agreements with Registries, 
Registrars, and Registrants to require the provision and maintenance of 
accurate WHOIS data; as part of this, ICANN should ensure that clear, 
enforceable and graduated sanctions apply to Registries, Registrars, 
Registrants that don’t comply with WHOIS policies, including de-registration 
and/or de-accreditation for serious or serial non-compliance.
Staff is pursuing the goal of increasing clarity on WHOIS accuracy obligations, 
and steps to better inform registrars, registrants, and users of the Internet 
at large could be beneficial.  Staff also is pursuing the use of graduated 
penalties, which should be helpful to improving WHOIS accuracy while not 
unfairly punishing parties for misunderstandings or mistakes. Staff needs to 
investigate public policy, legal issues and implementation optionsinvolved in 
the Recommendation. Under current agreements, registrars and registrants 
already have obligations to help ensure WHOIS data accuracy. Moreover, most 
agreements already have actual or implicit provisions for “graduated sanctions” 
for breaches of the agreements, generally. It would be helpful to understand, 
then, whether this is largely a request for better community education or if 
there is a perceived need for additional contractual tools.
Considerable work is already underway as part of the current round of RAA 
negotiations to strengthen and clarify WHOIS data accuracy obligations 
applicable to both registrars and registrants. Inaddition, ICANN and registrars 
have already agreed in principle that WHOIS data will require some form of data 
verification as a condition of registration and at other relevant times. 
Because this discussion is active, the framework for the verification 
requirement is still under development. It is anticipated that this new regime 
may require efforts by ICANN to help educate registrars andregistrants. 
Accordingly, it is anticipated that the Recommendation will besubstantially 
implemented upon adoption of a revised RAA, making at least the apparent aim of 
the Recommendation feasible to accomplish.
Currently, registrars and registrants are primarily responsible for maintaining 
WHOIS data accuracy. As noted, the 2009 version of the RAA provides for 
graduated sanctions for breaches, short of termination of the RAA.[1] This 
contractual framework generally allows registrars some flexibility in 
addressing inaccurate WHOIS data; for example, registrars may suspend a 
registration instead of deleting it or allow extra time for a registrant 
response if extenuating circumstances warrant it. If there were a desire by the 
community to require registrars to conform to a particular course of action in 
remedying WHOIS data inaccuracy, the RAA could be amended or a consensus policy 
(GNSO PDP) could be developed to specify, precisely, the steps a registrar must 
take. Enhanced WHOIS accuracy provisions also could be introduced through 
additional provisions in the New gTLD Program, such as through the 
Registry-Registrar Agreements, or a new RAA that would apply solely to New 
GTLDs.
Recommendation 9. Data Accuracy -- ICANN should ensure that requirements for 
accurate WHOIS data are widely and pro-actively communicated to current and 
prospective registrants, and should ensure that its Registrant Rights and 
Responsibilities document is pro-actively and prominently circulated to all new 
and renewing registrants.
Staff is engaged in advancing this goal, as a better understanding of WHOIS 
data among registrants can be expected to help improve data accuracy and help 
registrants avoid loss of the use of registrations caused by their (potentially 
unintended) failure to maintain accurate WHOIS data.
In terms of registrant education efforts, there are several educational 
resources available today For example, Section 3.15 of the 2009 RAA currently 
requires registrars to post links on their websites to the “Registrant Rights 
and Responsibilities” document developed by ICANN that is intended to describe 
the RAA in plainlyunderstood, non-legalistic language. Moreover, registrars are 
required to post the link “at least as clearly as [their] links to policies or 
notifications required to be displayed under ICANN Consensus Policies.”  Our 
initial studies have indicated that a vast majority of registrars have 
satisfied this requirement. Also, in addition to the registration agreement 
requirement that registrants provide accurateWHOIS data (Sections 3.7.7.1 and 
3.7.7.2), the WDRP requires registrars to remind registrants on an annual basis 
to verify the accuracy of their WHOISdata and that “provision of false WHOIS 
information can be grounds for cancellation of their domain name registration.” 
Is it the Review Team’s opinion that this is not an adequate communication to 
renewing registrants?Additionally, because this recommendation suggests 
communication of WHOIS obligations to prospective registrants (who have no 
WHOIS obligation nor presumably, much interest in WHOIS data until they become 
registrants), it would be helpful to understand the extent to which ICANN and 
registrars should, in the Review Team’s view, engage in educational efforts.
The RAAcould be amended or a GNSO consensus policy adopted to require 
registrars to communicate the Registrant Rights and Responsibilities document 
even more prominently, but some investigation should be undertaken as a part of 
the initiative to ascertain first whether the current scheme is ineffective. 
Additional educational efforts are feasible and could be initiated, but the 
costs and resources needed to perform this work will depend on the extent and 
scope of efforts expected by the Review Team. In addition, the creation of a 
Registrar “Code of Conduct” as referenced in the RAA (3.7.1) might be another 
way of implementing these recommendations if they are supported by a consensus 
of ICANN-accredited registrars.
Recommendation 10. Data Access -- Privacy Services -- ICANN should develop and 
manage a system of clear, consistent and enforceable requirements for all 
privacy services consistent with national laws, balancing between stakeholders 
with competing but legitimate interests, including, at a minimum, privacy, law 
enforcement and industry around law enforcement.  These should include:
·       WHOIS entry must clearly label that this is a private registration.
·       Privacy services must provide full contact details as required by the 
WHOIS that are available and responsive as required by the framework mentioned 
above.
·       Standardized relay and reveal processes and timeframes.
·       Rules for the appropriate level of publicly available information on 
the Registrant.
·       Maintenance of a dedicated abuse point of contact for the privacy 
service provider.
·       Privacy service provider shall conduct periodic due diligence checks on 
registrant contact information.
Staff is exploring measures to help achieve clear, consistent, and enforceable 
requirements for privacy services, and has made this topic a priority in the 
RAA negotiations.  Specifically, Staff has proposed creating an accreditation 
program for privacy services, which could provide a framework for implementing 
the Recommendation.
Although the Recommendation is in line with objectives being pursued by Staff, 
it will be difficult to ensure that all privacy services are covered by the 
proposed system.  Since ICANN does not have direct contracts with registrants, 
ICANN has limited ability to identify all privacy services in use.  However, by 
including an obligation in the RAA that a registrar may not knowingly accept 
registrations from unaccredited privacy services, a substantial portion of the 
privacy registrations available today could be covered by the obligations 
described in the Recommendation. Creation of an ICANN accreditation program for 
privacy services will have significant budgetary and operational impact, as it 
would likely require ICANN to hire additional resources to meet these new 
obligations.  Also, implementation would involve amendments to the RAA, or the 
adoption of consensus policies by theGNSO, in order to create enforceable 
obligations against registrars.
Staff continues to analyze the elements of an accreditation program for privacy 
services, and community discussion of the Recommendation will be useful.
Recommendation 11. Data Access -- Privacy Services -- ICANN should develop a 
graduated and enforceable series of penalties for privacy service providers who 
violate the requirements, with a clear path to de-accreditation for repeat, 
serial or otherwise serious breaches.
If an accreditation program were established by ICANN for privacy services, 
Staffwould expect that graduated and enforceable series of penalties for 
privacyservice providers who violate the requirements would be an integral part 
ofthis program.  Community input will be needed on various aspects of the 
Recommendation, including the following:

·      What types of penalties should apply?

·      If a privacy service is de-accredited, what should happen to the 
customers of the service?  Would their underlying information be unmasked?  
Since there is no obligation to escrow information of privacy services, it may 
be difficult to protect the customers of such privacy providers.
ICANN’s ability to implement this recommendation is dependent upon entering 
into direct contracts with privacy service providers.  Without contracts, there 
may be no applicable enforcement mechanism.
Staff continues to analyze the elements of an accreditation program for privacy 
services, and community discussion of the Recommendation will be useful.
Recommendation 12. Data Access - Proxy Services -- ICANN should facilitate the 
review of existing practices by reaching out to proxy providers to create a 
discussion that sets out current processes followed by these providers.
Staff can engage in voluntary discussions with proxy providers about their 
current processes, and use a variety of outreach mechanisms (including ICANN 
meetings) to advance such conversations. If the Review Team has additional 
guidance for Staff on intended targets, that would be useful. Proxy 
accreditation is being explored in the current RAA negotiations. The 
Recommendation may require amendments to the RAA, or adoption of a GNSO 
consensus policy, as Staff’s role with proxy services currently is limited. 
Staff continues to analyze the elements of an accreditation program for proxy 
services, and community discussion of the Recommendation will be useful.
Recommendation 13. Data Access - Proxy Services -- Registrars should be 
required to disclose to ICANN their relationship with any Affiliated Retail 
proxy service provider.
Staff is pursuing this objective, which is being addressed in the current RAA 
negotiations. While the Recommendation is feasible, Staff also needs to explore 
the various ways registrars can be affiliated with retail proxy service 
providers (and registrar input would be useful).
Recommendation 14. Data Access - Proxy Services -- ICANN should develop a set 
of voluntary best practice guidelines for appropriate proxy services[2] 
consistent with national laws, striking a balance between stakeholders 
withcompeting but legitimate interests, including, at a minimum, privacy, law 
enforcement and industry around LE. Voluntary guidelines may include:

·      Proxy services provide full contact details as required by WHOIS;

·      Publication by the proxy service of its process for revealing and 
relaying information;

·      Standardization of reveal and relay processes and timeframes, consistent 
with national laws;

·      Maintenance of a dedicated abuse point of contact for the proxy service 
provider;

·      Due diligence checks on licensee contact information.
Staff is pursuing a similar goal – relay and reveal issues are being addressed 
in the RAA negotiations. These efforts will be factored into Staff’s work on 
the Recommendation.  Staff continues to analyze potential implementation of the 
Recommendation, and the GNSO may beable to assist with implementation analysis.
Recommendation 15. Data Access - Proxy Services -- ICANN should encourage and 
incentivize registrars to interact with the retail service providers that adopt 
the best practices.
Staff continues to explore implementation details for the Recommendation, 
including addressing liability, auditing, and other issues, as well as 
implementation resource needs. Input from registrars, in particular, would be 
useful here.
Recommendation 16. Data Access - Proxy Services -- The published WHOIS Policy 
should include an affirmative statement that clarifies that a proxy means a 
relationship in which the Registrant is acting on behalf of another; the WHOIS 
data is that of the agent, and the agent alone obtains all rights and assumes 
all responsibility for the domain name and its manner of use.
The current RAA holds the Registered Name Holder responsible for adhering to 
registrantobligations regardless of whether the registration was made on behalf 
of a third party. A draft Registrar Advisory was issued for consideration on 14 
May 2010 to provide community guidance and clarification of this provision, but 
was never finalized. It would be helpful for Staff to receive community input 
on reconsidering this advisory. RAA negotiations also may affect implementation 
of the Recommendation.

Recommendation 17. Data Access – Common Interface -- To improve access to the 
WHOIS data of .COM & .NET gTLDs (the Thin Registries), ICANN should set-up a 
dedicated, multilingual interface website to provide thick WHOIS data for them. 
(An “Alternative for public comment” also is provided: to make WHOIS data more 
accessible for consumers, ICANN should set-up a dedicated, multilingual 
interface website to allow “unrestricted and public access to accurate and 
complete WHOIS information” to provide thick WHOIS data for all gTLD domain 
names.
The Recommendation seems feasible and Staff looks forward to further 
investigating implementation once the Recommendation is finalized.
A “single point of access” to domain name registration data is similar in 
objectives to the Centralized Zone File Access solution developed by Staff and 
the ICANN community to facilitate access to TLD zone file data, but different 
in technical, operational, business, and contractual aspects. Staff is prepared 
to study these implementation issues and offers the following comments and 
observations.
Currently, Staff and the Internet technical community are studying several of 
the technical implementation aspects that would define the technical framework 
for an improved WHOIS service. These include multilingual interfaces 
(internationalized registration data, through the IRD WG, a collaborative 
effort of the GNSO, SSAC, and CCNSO), normalization of data (analysis of query, 
response, display and error messages by the SSAC), the development of standard 
protocols (by both name and address registry members of the Internet community 
through IETF processes), and consideration of service requirements by the GNSO. 
Several of these participants, including Staff, have and continue to run 
technical experiments with this framework, and “proof of concept” as well as 
production services at ARIN offer promising results. These are necessary but 
may not be sufficient conditions to implementing the Team’s Recommendation.
The operation of a dedicated, multilingual WHOIS web site has technical and 
business implications. ICANN would require budget approval for acquisition of 
access bandwidth andinfrastructure, and for hiring of Staff sufficient to meet 
the demands of acommon entry point to a distributed database currently accessed 
through infrastructure provided by hundreds of registry and registrar WHOIS 
services. Capacity planning for an enterprise of this scale can only properly 
be doneafter a detailed implementation framework and plan is approved.
One technical solution is to have this web site act as a proxy that would relay 
queries between WHOISusers and registries or registrars. An alternative 
solution would be for ICANN to collect registration data from registries and 
registrars and maintain these locally, either cached or in permanent storage. 
Existing registry and registrar WHOIS services must change to satisfy the “back 
end” requirements for either solution.  For example, if a relay model is 
chosen, registry and registrar WHOIS services must satisfy availability and 
throughput requirements (and not rate limit), whereas if a cache or 
storageoption is chosen, a method for maintaining data synchronization and 
consistency must be developed. Lastly, any operational solution Staff is asked 
to consider must be evaluated and demonstrated to scale better than the 
existing solution.
Independent of the operational solution selected, the ICANN community may need 
to undertake a consensus policy development or engage in contractual 
negotiations to establish new registry and registrar contractual obligations 
that do not exist today.
Recommendation 18. Internationalized Domain Names -- The ICANN Community should 
task a working group within 6 months of publication to finalize (i) encoding, 
(ii) modifications to data model, and (iii) internationalized services, to give 
global access to gather, store and make available internationalized 
registration data.  Such working group should report no later than oneyear from 
formation, using existing IDN encoding.  The working group should aim for 
consistency of approach across gTLDs and – on a voluntary basis – the ccTLD 
space.
Staff is pursuing the Recommendation -- with some clarifications.  
Specifically, it is not within ICANN’s remitto select what encoding should be 
applied, or what signal mechanism should be established to support those 
encodings; this is the role of the IETF. From a technical perspective, 
mandating that encodings say UTF-8 would cause serious backward compatibility 
issues for the majority of the WHOIS clients today and Staff is not certain 
that is the right a to take. The approach Staff suggests is to defer this issue 
to the IETF, and ask that they create a protocol that supports 
internationalized registration data. This falls within IETF’s remit, and this 
group has the necessary technical expertise and broader participation from all 
of the relevant technical stakeholders.
Staff proposes the following revision to the Review Team’s Recommendation: “The 
ICANN Community should develop, in cooperation with the IETF and other 
technical standards organizations as needed, (i) a unified registration data 
model, and (ii) a solution for offering internationalized services.”  In 
addition, the draft report states, “Such working group should report no later 
than one year from formation, using existing IDN encoding.” Staff is not sure 
what “using existing IDN encoding” means and would appreciate clarification.
Recommendation 19. Internationalized Domain Names -- The final data model and 
services should be incorporated and reflected in Registrar and Registry 
agreements within 6 months of adoption of the working group’s recommendations 
by the ICANN Board.  If these recommendations are not finalized in time for the 
next revision of such agreements, explicit placeholders for this purpose should 
be put in place in the agreements for the new gTLD program at this time, and in 
the existing agreements when they come up for renewal (as is case for adoption 
of consensus policies).
As noted above, the Recommendation could be implemented if the IETF takes the 
necessary action. Implementation would require incorporation into the RAA and 
existing registry agreements, which would require negotiations and/or a GNSO 
PDP.  An increase in resources and expertise alsowould be needed. Staff has put 
a “placeholder” for internationalized services on the discussion list for the 
current RAA negotiations, and Staff has suggested that, if the IETF develops a 
new protocol, it should be automatically implemented. This recommendation also 
could be introduced through additional provisions in the New gTLD Program, such 
as through the Registry-Registrar Agreements, or a new RAA that would apply 
solely to New GTLDs.
Recommendation 20. Internationalized Domain Names -- Requirements for 
registration data accuracy and availability in local languages should be 
finalized (following initial work by IRD-WG and similar efforts, especially if 
translation or transliteration of data is stipulated) along with the efforts on 
internationalization of registration data. Metrics should be defined to measure 
accuracy and availability of data in local languages and (if needed) 
corresponding data in ASCII, and compliance methods and targets should be 
explicitly defined accordingly.
As noted above, Staff is pursuing the Recommendation -- with some 
clarifications/corrections. Staff continues to analyze the details involved in 
the Recommendation’s potential implementation.


________________________________

[1] See RAA Section 2.1, allowing ICANN to suspend a registrar’s ability to 
create new registrations and initiate inbound transfers for up to a 12-month 
period, and Section 5.7, requiring payment by the registrar of ICANN’s 
enforcement costs or sanctions of up to five times ICANN’s enforcement costs 
for repeated willful material breaches. Section 3.7.7.1 of the RAA obligates 
registrars to include in their registration agreements a provision requiring 
registrants to provide accurate and reliable registration contact details. 
Section 3.7.7.2 of the RAA obligates registrars to include in their 
registration agreements a provision making it a material breach for a 
registrant to willfully provide inaccurate or unreliable information, willfully 
fail to promptly update contact information provided to the registrar, or fail 
to respond for over 15 calendar days to inquiries from the registrar concerning 
the accuracy of contact details. Section 3.7.8 of the RAA requires registrars 
to take “reasonable steps” to investigate and correct allegedly inaccurate 
WHOIS data.

[2] As “guidance to the community” and as useful background for the Proxy 
Service Recommendations, the Team provides its working definitions of proxy 
service and different types of proxy service providers.