The Staff comments on the Draft Report were posted to the public comment forum yesterday. See below.<div><br></div><div>Regards,</div><div>Denise</div><div><br clear="all">Denise Michel<br>ICANN <br>Advisor to the President & CEO<br>
<a href="mailto:denise.michel@icann.org" target="_blank">denise.michel@icann.org</a><br>+1.408.429.3072 mobile<br>+1.310.578.8632 direct<br>
<br><br><div class="gmail_quote"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div><br></div><span><div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">
<span style="font-weight:bold">From: </span> Denise MIchel <<a href="mailto:denise.michel@icann.org" target="_blank">denise.michel@icann.org</a>><br><span style="font-weight:bold">Date: </span> Sat, 17 Mar 2012 22:59:38 -0700<br>
<span style="font-weight:bold">To: </span> "<a href="mailto:whois-rt-draft-final-report@icann.org" target="_blank">whois-rt-draft-final-report@icann.org</a>" <<a href="mailto:whois-rt-draft-final-report@icann.org" target="_blank">whois-rt-draft-final-report@icann.org</a>><br>
<span style="font-weight:bold">Subject: </span> Initial Staff input on the WHOIS Policy Review Team Draft Report Recommendations<br></div><div><br></div><div><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div><p class="MsoNormal" style="margin-top:6.0pt;background:white"><span style="font-size:12.0pt">Dear
WHOIS Policy Review Team:<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><span style="font-size:12.0pt">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.</span><span style="font-size:12.0pt;color:blue"><u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white">
<b><span style="font-size:12.0pt">Recommendation
1. Single WHOIS Policy</span></b><span style="font-size:12.0pt"> -- 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. <u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt"><span style="font-size:12.0pt;color:blue">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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><b><span style="font-size:12.0pt">Recommendation
2. Policy Review – WHOIS Data Reminder Policy (WDRP)</span></b><span style="font-size:12.0pt"><span> </span>-- 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). <u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><span style="font-size:12.0pt;color:blue">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.<span> </span>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. <u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><span style="font-size:12.0pt;color:blue">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.</span><span style="font-size:12.0pt;color:blue"><u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><b><span style="font-size:12.0pt">Recommendation
3. Strategic Priority</span></b><span style="font-size:12.0pt"> -- 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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><span style="font-size:12.0pt;color:blue">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.<span> </span>Mr. Jeffrey is an
Officer of ICANN and is a senior member of ICANN’s Executive Team.<span> </span>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.<span> </span>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 <span> </span>more
effectively.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><b><span style="font-size:12.0pt">Recommendation
4. Outreach</span></b><span style="font-size:12.0pt"> -- ICANN should ensure that WHOIS policy issues are
accompanied by cross-community outreach, including outreach to interested
communities outside of ICANN.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><span style="font-size:12.0pt;color:blue">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.</span><span style="font-size:12.0pt;color:blue"><u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><b><span style="font-size:12.0pt">Recommendation
5. Data Accuracy -- </span></b><span style="font-size:12.0pt">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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><span style="font-size:12.0pt;color:blue">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:<u></u><u></u></span></p><p style="margin-top:6.0pt;text-autospace:none"><span style="color:blue"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="color:blue">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.<u></u><u></u></span></p><p style="margin-top:6.0pt;text-autospace:none"><span style="color:blue"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="color:blue">Does the Team intend
for Staff to determine </span>the extent of a study based on what is a
statistically valid sample size given the overall market? <span style="color:blue">The NORC Accuracy Study involved a sample size of 1400
registrations, and cost ICANN approximately US$200,000. <u></u><u></u></span></p><p style="margin-top:6.0pt;text-autospace:none"><span style="color:blue"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="color:blue">What level of accuracy
is desired?<span> </span>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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">Advancing
the goal of the Recommendation is feasible, assuming that the RAA can be
amended through the negotiations underway or through a GNSO PDP.<span> </span>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.<span> </span>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.<span>
</span>Consultations with the GNSO constituencies, especially the registrars,
on the Recommendation would be helpful. <u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:0in;background:white"><b><span style="font-size:12.0pt">Recommendation
6. & 7.</span></b><span style="font-size:12.0pt"> <b>Data Accuracy -- </b>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. <u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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.<span> </span>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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><b><span style="font-size:12.0pt">Recommendation 8.</span></b><span style="font-size:12.0pt"> <b>Data Accuracy -- </b>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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><span style="font-size:12.0pt;color:blue">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.<span> </span>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. </span><span style="font-size:12.0pt;color:blue">Staff
needs to investigate public policy, legal issues and implementation optionsinvolved in the Recommendation. </span><span style="font-size:12.0pt;color:blue">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.<span> </span><u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><span style="font-size:12.0pt;color:blue">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.<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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.<a href="#136246471c91bdc1__ftn1" name="136246471c91bdc1__ftnref1" title=""><span><span><span><span style="font-size:12pt;color:blue;font-family:'Times New Roman'">[1]</span></span></span></span></a>
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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><b><span style="font-size:12.0pt">Recommendation
9.</span></b><span style="font-size:12.0pt"><b>Data Accuracy -- </b>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. </span><span style="font-size:12.0pt;color:#3366ff"><u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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. <u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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.”<span> </span>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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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.</span><span style="font-size:12.0pt"> 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.</span><span style="font-size:12.0pt;color:blue"><u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt"><b><span style="font-size:12.0pt">Recommendation
10.</span></b><span style="font-size:12.0pt"><b>Data Access -- Privacy Services</b> --
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.<span> </span>These should include:</span><span style="font-size:12.0pt"><u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;margin-right:0in;margin-bottom:0in;margin-left:.75in;margin-bottom:.0001pt;background:white">
<span><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:12.0pt">WHOIS entry must clearly label that this is a private
registration.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;margin-right:0in;margin-bottom:0in;margin-left:.75in;margin-bottom:.0001pt;background:white"><span><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:12.0pt">Privacy services must provide full contact details as
required by the WHOIS that are available and responsive as required by the
framework mentioned above.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;margin-left:.75in;background:white"><span><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:12.0pt">Standardized relay and reveal processes and timeframes.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;margin-left:.75in;background:white"><span><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:12.0pt">Rules for the appropriate level of publicly available
information on the Registrant.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;margin-left:.75in;background:white"><span><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:12.0pt">Maintenance of a dedicated abuse point of contact for the
privacy service provider.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;margin-left:.75in;background:white"><span><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:12.0pt">Privacy service provider shall conduct periodic due
diligence checks on registrant contact information.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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.<span> </span>Specifically, Staff
has proposed creating an accreditation program for privacy services, which
could provide a framework for implementing the Recommendation. <u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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.<span> </span>Since ICANN does not have direct
contracts with registrants, ICANN has limited ability to identify all privacy
services in use.<span> </span>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.<span> </span>Also, implementation would
involve amendments to the RAA, or the adoption of consensus policies by theGNSO, in order to create enforceable obligations against registrars.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none">
<span style="font-size:12.0pt;color:blue">Staff
continues to analyze the elements of an accreditation program for privacy
services, and community discussion of the Recommendation will be useful.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><b><span style="font-size:12.0pt">Recommendation 11.</span></b><span style="font-size:12.0pt"> <b>Data Access -- Privacy Services</b> -- 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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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.<span> </span>Community input will be
needed on various aspects of the Recommendation, including the following:<u></u><u></u></span></p><p style="margin-top:6.0pt;text-autospace:none"><span style="color:blue"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="color:blue">What types of penalties
should apply?<span> </span><u></u><u></u></span></p><p style="margin-top:6.0pt;text-autospace:none"><span style="color:blue"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="color:blue">If a privacy service is
de-accredited, what should happen to the customers of the service?<span> </span>Would their underlying information be
unmasked?<span> </span>Since there is no obligation
to escrow information of privacy services, it may be difficult to protect the
customers of such privacy providers.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">ICANN’s
ability to implement this recommendation is dependent upon entering into direct
contracts with privacy service providers.<span>
</span>Without contracts, there may be no applicable enforcement
mechanism.<span> </span><u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">Staff
continues to analyze the elements of an accreditation program for privacy
services, and community discussion of the Recommendation will be useful.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><b><span style="font-size:12.0pt">Recommendation
12. Data Access - Proxy Services -- </span></b><span style="font-size:12.0pt">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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:0in;background:white"><b><span style="font-size:12.0pt">Recommendation
13. Data Access - Proxy Services -- </span></b><span style="font-size:12.0pt">Registrars should be required to
disclose to ICANN their relationship with any Affiliated Retail proxy service
provider.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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).<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:0in;background:white"><b><span style="font-size:12.0pt">Recommendation
14. Data Access - Proxy Services -- </span></b><span style="font-size:12.0pt">ICANN should develop a set of
voluntary best practice guidelines for appropriate proxy services<a href="#136246471c91bdc1__ftn2" name="136246471c91bdc1__ftnref2" title=""><span><span><span><span style="font-size:12pt;font-family:'Times New Roman'">[2]</span></span></span></span></a>
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: <u></u><u></u></span></p><p style="margin-top:6.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:1.0in;background:white"><span><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span>Proxy
services provide full contact details as required by WHOIS;<u></u><u></u></span></p><p style="margin-top:6.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:1.0in;background:white"><span><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span>Publication
by the proxy service of its process for revealing and relaying information;<u></u><u></u></span></p><p style="margin-top:6.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:1.0in;background:white"><span><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span>Standardization
of reveal and relay processes and timeframes, consistent with national laws;<u></u><u></u></span></p><p style="margin-top:6.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:1.0in;background:white"><span><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span>Maintenance
of a dedicated abuse point of contact for the proxy service provider;<u></u><u></u></span></p><p style="margin-top:6.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:1.0in;background:white"><span><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><span>Due
diligence checks on licensee contact information.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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.<span> </span>Staff continues to
analyze potential implementation of the Recommendation, and the GNSO may beable to assist with implementation analysis.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:0in;background:white">
<b><span style="font-size:12.0pt">Recommendation
15. Data Access - Proxy Services -- </span></b><span style="font-size:12.0pt">ICANN should encourage and incentivize
registrars to interact with the retail service providers that adopt the best
practices.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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.</span><span style="font-size:12.0pt"> <u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><b><span style="font-size:12.0pt">Recommendation 16. Data Access - Proxy Services -- </span></b><span style="font-size:12.0pt">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.</span><span style="font-size:12.0pt;color:blue"> <u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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.<u></u><u></u></span></p><p style="margin-top:6.0pt;margin-left:0in;background:white"><b><span>Recommendation
17. Data Access – Common Interface</span></b><span> -- 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. <u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">The Recommendation
seems feasible and Staff looks forward to further investigating implementation
once the Recommendation is finalized. <u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt"><span style="font-size:12.0pt;color:blue">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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt"><span style="font-size:12.0pt;color:blue">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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt"><span style="font-size:12.0pt;color:blue">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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt"><span style="font-size:12.0pt;color:blue">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.<span> </span>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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt"><span style="font-size:12.0pt;color:blue">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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><b><span style="font-size:12.0pt">Recommendation
18. Internationalized Domain Names</span></b><span style="font-size:12.0pt"> -- 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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">Staff is
pursuing the Recommendation -- with some clarifications.<span> </span>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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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.” <span> </span>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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:0in;background:white"><b><span style="font-size:12.0pt">Recommendation
19. Internationalized Domain Names</span></b><span style="font-size:12.0pt"> -- 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). <u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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.<span> </span>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.<u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;background:white"><b><span style="font-size:12.0pt">Recommendation
20. Internationalized Domain Names</span></b><span style="font-size:12.0pt"> -- 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. <u></u><u></u></span></p><p class="MsoNormal" style="margin-top:6.0pt;text-autospace:none"><span style="font-size:12.0pt;color:blue">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.<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><div><br clear="all"><hr align="left" size="1" width="33%"><div><p><a href="#136246471c91bdc1__ftnref1" name="136246471c91bdc1__ftn1" title=""><span><span><span><span style="font-size:12pt;font-family:'Times New Roman'">[1]</span></span></span></span></a> <span style="font-size:10.0pt">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</span> <span style="font-size:10.0pt">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.</span><u></u><u></u></p></div><div><p><a href="#136246471c91bdc1__ftnref2" name="136246471c91bdc1__ftn2" title=""><span><span><span><span style="font-size:12pt;font-family:'Times New Roman'">[2]</span></span></span></span></a> <span style="font-size:10.0pt;font-family:Arial">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. <u></u><u></u></span></p></div></div></div></div></div></span></div>
</div><br></div>