<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); "><div><span class="Apple-style-span" style="font-size: 14px; font-family: Calibri, sans-serif; ">Dear All,</span></div><div><span class="Apple-style-span" style="font-size: 14px; font-family: Calibri, sans-serif; "><br></span></div><div><span class="Apple-style-span" style="font-size: 14px; font-family: Calibri, sans-serif; ">For your information, the ICANN Board adopted the IRTP Part B recommendations approved by the GNSO Council at its meeting on 25 August (see </span><span class="Apple-style-span" style="font-size: 14px; font-family: Calibri, sans-serif; "><a href="http://www.icann.org/en/minutes/resolutions-25aug11-en.htm">http://www.icann.org/en/minutes/resolutions-25aug11-en.htm</a></span><span class="Apple-style-span" style="font-size: 14px; font-family: Calibri, sans-serif; "> or resolution below).</span></div><span id="OLK_SRC_BODY_SECTION" style="font-size: 14px; font-family: Calibri, sans-serif; "><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div><br></div><div>With best regards,</div><div><br></div><div>Marika</div></div></div></span><div><br></div><div>============</div><div><br></div><span id="OLK_SRC_BODY_SECTION" style="font-size: 14px; font-family: Calibri, sans-serif; "><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div><span class="Apple-style-span" style="font-weight: bold; ">1.2. Approval of Recommendation of GNSO Council on IRTP Part B</span></div><div>
<p>Whereas on 24 June 2009, the GNSO Council launched a Policy
Development Process (PDP) on the Inter-Registrar Transfer Procedure Part
B (IRTP Part B) addressing five charter questions, set forth at <a href="https://community.icann.org/display/gnsoirtpb/3.+WG+Charter">https://community.icann.org/display/gnsoirtpb/3.+WG+Charter</a>;</p>
<p>Whereas the PDP followed the prescribed PDP steps as stated in the Bylaws, resulting in a Final Report delivered on 30 May 2011;</p>
<p>Whereas the IRTP Part B Working Group (WG) reached full consensus
on the recommendations in relation to each of the five issues outlined
in the Charter;</p>
<p>Whereas the GNSO Council reviewed, and discussed the
recommendations of the IRTP Part B WG, and adopted the Recommendations
on 22 June 2011 by a Supermajority and unanimous vote (see: <a href="http://gnso.icann.org/resolutions/#201106">http://gnso.icann.org/resolutions/#201106</a>);</p>
<p>Whereas the GNSO Council vote met and exceeded the required voting
threshold to impose new obligations on ICANN contracted parties.</p>
<p>Whereas after the GNSO Council vote, a 30-day public comment period
was held on the approved recommendations, and the comments have been
summarized and considered (<a href="http://www.icann.org/en/public-comment/irtp-b-recommendations-08jul11-en.htm">http://www.icann.org/en/public-comment/irtp-b-recommendations-08jul11-en.htm</a>).</p>
<p><strong>Resolved</strong> (2011.08.25.02) the Board adopts the GNSO
Council Policy Recommendations amending the Inter-Registrar Transfer
Policy set forth at <a href="http://www.icann.org/en/transfers/policy-en.htm">http://www.icann.org/en/transfers/policy-en.htm</a>.</p>
<p><strong>Resolved</strong> (2011.08.25.03) the CEO is to develop and
complete an implementation plan for these Recommendations and continue
communication with the community on such work.</p>
<p><strong>Resolved</strong> (2011.08.25.04) the CEO is directed to
undertake the studies identified by the GNSO Council at [identify
resolutions here] to facilitate further work on this issue.</p>
<p><strong>Resolved</strong> (2011.08.25.05) the Board encourages the
GNSO, the ALAC and all other parts of the ICANN community to work
together to promote the measures outlined in the SSAC's report A
Registrant's Guide to Protecting Domain Name Registration Accounts (SAC
044), as identified within the GNSO Council Resolutions.</p>
<blockquote>
<h4><a name="1.2.rationale"></a>Rationale for Resolutions 2011.08.25.02-05</h4>
<p><em><strong>Why the Board is addressing the issue now?</strong><br>
The Inter-Registrar Transfer Policy (IRTP) is a consensus policy
that was adopted in 2004 which provides for a straightforward process
for registrants to transfer domain names between registrars. The GNSO
Council established a series of five Working Groups (Parts A through E)
to review and consider various revisions to this policy.</em></p>
<p><em>The IRTP Part B PDP is the second in a series of five
scheduled PDPs addressing areas for improvements in the existing policy.
The IRTP Part B Working Group has addressed five issues focusing on
domain hijacking, the urgent return of an inappropriately transferred
name, and lock status. The IRTP Part B PDP Final Report received
unanimous consensus support from the IRTP Part B Working Group as well
as the GNSO Council. Following the closing of the public comment period
on 8 August, the next step as outlined in Annex A of the ICANN Bylaws is
consideration by the ICANN Board of the recommendations.</em></p>
<p><em><strong>What is the proposal being considered?</strong><br>
The following recommendations are being considered:</em></p>
<ul>
<li><em>Requiring Registrars to provide a Transfer Emergency Action
Contact (TEAC). To this end proposed language to modify section 4
(Registrar Coordination) and Section 6 (Registry Requirements) of the
Inter-Registrar Transfer Policy has been provided (see Annex for further
details). The Transfer Emergency Action Contact (TEAC) is a mechanism
to facilitate urgent communications relating to transfers. The goal of
the TEAC is to quickly establish real time communication between
registrar representatives in case of emergency such as a transfer as a
result of a domain name hijacking so that the registrar can take steps
to resolving the issue. The TEAC only addresses establishing that
communication not resolving any disputes that may arise for which other
policies and procedures apply.</em></li>
<li><em>Modifying section 3 of the IRTP to require that the
Registrar of Record/Losing Registrar be required to notify the
Registered Name Holder/Registrant of the transfer out. The Registrar of
Record has access to the contact information for the Registrant and
could modify their systems to automatically send out the Standardized
Form for Losing Registrars ("Confirmation FOA") to the Registrant.
Requiring this notification would alert the registrant at an earlier
stage that a transfer has been requested, which as a result would bring
any potential conflicts to light before a transfer has been completed
and therefore might reduce the number of conflicts between the admin
contact and registrant that would require undoing a transfer.</em></li>
<li><em>Modifying Reason for Denial #6 as follows: Express objection
to the transfer by the authorized Transfer Contact. Objection could
take the form of specific request (either by paper or electronic means)
by the authorized Transfer Contact to deny a particular transfer
request, or a general objection to all transfer requests received by the
Registrar, either temporarily or indefinitely. In all cases, the
objection must be provided with the express and informed consent of the
authorized Transfer Contact on an opt-in basis and upon request by the
authorized Transfer Contact, the Registrar must remove the lock or
provide a reasonably accessible method for the authorized Transfer
Contact to remove the lock within five (5) calendar days. The current
language of denial reason #6 is not clear and leaves room for
interpretation especially in relation to the term ‘voluntarily' and it
is therefore recommended that this language is expanded and clarified to
tailor it more to explicitly address registrar-specific (i.e. non-EPP)
locks in order to make it clear that the registrant must give some sort
of informed opt-in express consent to having such a lock applied, and
the registrant must be able to have the lock removed upon reasonable
notice and authentication.</em></li>
<li><em>Deleting denial reason #7 as a valid reason for denial under
section 3 of the IRTP as it is technically not possible to initiate a
transfer for a domain name that is locked, and hence cannot be denied,
making this denial reason obsolete.</em></li>
</ul>
<p><em><strong>Which stakeholders or others were consulted?</strong><br> Public comment forums were held on the <a href="http://forum.icann.org/lists/irtp-b">initiation of the PDP</a>, <a href="http://forum.icann.org/lists/irtp-b-initial-report/">the Initial Report</a>, the <a href="http://forum.icann.org/lists/irtp-b-proposed-final-report/">proposed Final Report</a> and <a href="http://forum.icann.org/lists/irtp-b-recommendations/">the recommendations subject to Board Consideration</a>,
in additional to regular updates to the GNSO Council as well as
workshops to inform and solicit the input from the ICANN Community at
ICANN meetings (see for example, <a href="http://brussels38.icann.org/node/12502">Brussels Meeting</a> and <a href="http://svsf40.icann.org/node/22083">San Francisco Meeting</a>). Constituency / Stakeholder Group Statements were submitted (see <a href="https://community.icann.org/display/gnsoirtpb/IRTP+Part+B">https://community.icann.org/display/gnsoirtpb/IRTP+Part+B</a>). All comments received have been reviewed and considered by the IRTP Part B PDP WG (see section 6 of the <a href="http://gnso.icann.org/issues/transfers/irtp-b-final-report-30may11-en.pdf">IRTP Part B Final Report</a> [PDF, 972 KB]). In addition, as prescribed by the ICANN Bylaws, a <a href="http://www.icann.org/en/announcements/announcement-2-08jul11-en.htm">public comment forum</a> was held on the recommendations to be considered by the ICANN Board.</em></p>
<p><em>What concerns or issues were raised by the community?<br>
The only concern raised as part of the public comment forum on the
recommendations to be considered by the ICANN Board was with regard to
the four hour response time required as part of the Transfer Emergency
Action Contact (TEAC) recommendation. The commenter noted that it would
put ‘too much burden on small and medium sized registrars'. However, the
commenter seemed to assume that a resolution is required within four
hours (‘A final solution/ settlement can take place also after 1 or 2
days') instead of an initial response, which is the only requirement
under the proposed TEAC. As the IRTP Part B PDP Working Group explained
it in its Final Report ‘the goal of the TEAC is to quickly establish real time communication between registrar representatives who can take
steps to resolving the issue, but this policy only addresses
establishing that communication not resolving any disputes that may
arise'. With regard to the four hour response time, the IRTP Part B PDP
Working Group noted that ‘even the smallest of registrars can simply rotate this function among operational staff, just as they rotate other
"emergency" aspects of their business. The number of TEAC requests is
likely to be very small and quite infrequent, but when they occur there
is a genuine emergency that needs to be dealt with quickly'. It should
be noted that both small as well as big registrars participated in the
deliberations of the IRTP Part B Working Group and supported the
recommendations.</em></p>
<p><em><strong>What significant materials did the Board review?</strong><br>
The Board reviewed the GNSO Council Report to the Board, as well as
the summary of public comments and Staff's response to those comments.</em></p>
<p><em><strong>What factors the Board found to be significant?</strong><br>
The recommendations were developed following the GNSO Policy
Development Process as outlined in Annex A of the ICANN Bylaws and have
received the unanimous support from the GNSO Council. As outlined in the
ICANN Bylaws, the Council's unanimous (supermajority) support for the
motion obligates the Board to adopt the recommendation unless by a vote
of more than 66%, the Board determines that the policy is not in the
best interests of the ICANN community or ICANN. In addition, transfer
related issues are the number one area of complaint according to data
from ICANN Compliance. Improvements to the IRTP have the potential to
reduce the number of complaints, in addition to providing clarity and
predictability to registrants as well as registrars.</em></p>
<p><em><strong>Are there positive or negative community impacts?</strong><br>
Improvements to the IRTP have the potential to reduce the number of
complaints, in addition to providing clarity and predictability to
registrants as well as registrars. Adoption of the recommendations will
require changes in processes for registrars, but these are considered to
have a minimum impact and necessary in order to address the issues that
are part of this Policy Development Process. The recommendations, if
implemented, would usefully clarify and enhance the IRTP, to the
advantage of all parties concerned.</em></p>
<p><em><strong>Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?</strong><br>
Apart from those changes required in process for registrars as
outlined above, no other fiscal impacts or ramifications on ICANN; the
community; and/or the public are expected.</em></p>
<p><em><strong>Are there any security, stability or resiliency issues relating to the DNS?</strong><br>
There are no security, stability, or resiliency issues related to
the DNS if the Board approves the proposed recommendations.</em></p></blockquote></div></div></div></span></body></html>