[council] Adoption of IRTP Part B recommendations by ICANN Board

[Marika Konings <marika.konings@xxxxxxxxx>]

Dear All,

For your information, the ICANN Board adopted the IRTP Part B recommendations 
approved by the GNSO Council at its meeting on 25 August (see 
http://www.icann.org/en/minutes/resolutions-25aug11-en.htm or resolution below).

With best regards,

Marika

============

1.2. Approval of Recommendation of GNSO Council on IRTP Part B

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 
https://community.icann.org/display/gnsoirtpb/3.+WG+Charter;

Whereas the PDP followed the prescribed PDP steps as stated in the Bylaws, 
resulting in a Final Report delivered on 30 May 2011;

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;

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: 
http://gnso.icann.org/resolutions/#201106);

Whereas the GNSO Council vote met and exceeded the required voting threshold to 
impose new obligations on ICANN contracted parties.

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 
(http://www.icann.org/en/public-comment/irtp-b-recommendations-08jul11-en.htm).

Resolved (2011.08.25.02) the Board adopts the GNSO Council Policy 
Recommendations amending the Inter-Registrar Transfer Policy set forth at 
http://www.icann.org/en/transfers/policy-en.htm.

Resolved (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.

Resolved (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.

Resolved (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.

Rationale for Resolutions 2011.08.25.02-05

Why the Board is addressing the issue now?
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.

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.

What is the proposal being considered?
The following recommendations are being considered:

 *   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.
 *   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.
 *   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.
 *   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.

Which stakeholders or others were consulted?
Public comment forums were held on the initiation of the 
PDP<http://forum.icann.org/lists/irtp-b>, the Initial 
Report<http://forum.icann.org/lists/irtp-b-initial-report/>, the proposed Final 
Report<http://forum.icann.org/lists/irtp-b-proposed-final-report/> and the 
recommendations subject to Board 
Consideration<http://forum.icann.org/lists/irtp-b-recommendations/>, 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, Brussels Meeting<http://brussels38.icann.org/node/12502> and San 
Francisco Meeting<http://svsf40.icann.org/node/22083>). Constituency / 
Stakeholder Group Statements were submitted (see 
https://community.icann.org/display/gnsoirtpb/IRTP+Part+B). All comments 
received have been reviewed and considered by the IRTP Part B PDP WG (see 
section 6 of the IRTP Part B Final 
Report<http://gnso.icann.org/issues/transfers/irtp-b-final-report-30may11-en.pdf>
 [PDF, 972 KB]). In addition, as prescribed by the ICANN Bylaws, a public 
comment 
forum<http://www.icann.org/en/announcements/announcement-2-08jul11-en.htm> was 
held on the recommendations to be considered by the ICANN Board.

What concerns or issues were raised by the community?
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.

What significant materials did the Board review?
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.

What factors the Board found to be significant?
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.

Are there positive or negative community impacts?
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.

Are there fiscal impacts or ramifications on ICANN (strategic plan, operating 
plan, budget); the community; and/or the public?
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.

Are there any security, stability or resiliency issues relating to the DNS?
There are no security, stability, or resiliency issues related to the DNS if 
the Board approves the proposed recommendations.