The Staff comments on the Draft Report were posted to the public comment
forum yesterday. See below.
Regards,
Denise
Denise Michel
ICANN
Advisor to the President & CEO
denise.michel(a)icann.org
+1.408.429.3072 mobile
+1.310.578.8632 direct
From: Denise MIchel <denise.michel(a)icann.org>
Date: Sat, 17 Mar 2012 22:59:38 -0700
To: "whois-rt-draft-final-report(a)icann.org" <
whois-rt-draft-final-report(a)icann.org>
Subject: Initial Staff input on the WHOIS Policy Review Team Draft Report
Recommendations
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 thecomplaint 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
theapparent 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] <#136246471c91bdc1__ftn1> 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 forcancellation 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 tocommunicate 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]<#136246471c91bdc1__ftn2>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] <#136246471c91bdc1__ftnref1> 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] <#136246471c91bdc1__ftnref2> 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. ****
