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