GNSO Council Policy Recommendations - Inter-Registrar Transfer Policy Part D

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 D) to review and consider various revisions to this policy.

The IRTP Part D PDP is the fourth and final in a series of PDPs addressing areas for improvements in the existing policy.

The IRTP Part D PDP Final Report received unanimous consensus support from the IRTP Part D WG as well as the GNSO Council. Following the closing of the public comment period, 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 policy recommendations are being adopted:

Recommendation #1 - The WG recommends that reporting requirements be incorporated into the TDRP policy. Outcomes of all rulings by Dispute Resolution Providers (DRP) 1 should be published on Providers' websites, except in exceptional cases – in keeping with practices currently employed in the UDRP. Exceptions, if sought by the DRP, are to be granted by ICANN Contractual Compliance on a case-by-case basis. The Group recommends publishing reports that follow the example of the Asian Domain Name Dispute Resolution Centre (ADNDRC).2 These reports should include at a minimum:

The domain name under dispute
Relevant information about parties involved in the dispute;
The full decision of the case;
The date of the implementation of the decision
The need for publication does not apply to TDRP rulings that have taken place prior to the implementation of this recommendation.

Recommendation #2 - The WG recommends that the TDRP be amended to include language along the lines of this revised version of the UDRP:

"The relevant Dispute Resolution Provider shall report any decision made with respect to a transfer dispute initiated under the TDRP. All decisions under this Policy will be published in full over the Internet except when the Panel, convened by the Dispute Resolution, in an exceptional case, determines to redact portions of its decision. In any event, the portion of any decision determining a complaint to have been brought in bad faith shall be published."

Recommendation #3 - The WG recommends that the TDRP be amended to reflect the following wording, or equivalent: "Transfers from a Gaining Registrar to a third registrar, and all other subsequent transfers, are invalidated if the Gaining Registrar acquired sponsorship from the Registrar of Record through an invalid transfer, as determined through the dispute resolution process set forth in the Transfer Dispute Resolution Policy."

Recommendation #4 - The WG recommends that a domain name be returned to the Registrar of Record and Registrant of Record directly prior to the non-compliant transfer if it is found, through a TDRP procedure, that a non-IRTP compliant domain name transfer occurred.

Recommendation #5 - The WG recommends that the statute of limitation to launch a TDRP be extended from current 6 months to 12 months from the initial transfer.

This is to provide registrants the opportunity to become aware of fraudulent transfers when they would no longer receive their registrar's annual WDRP notification.

Recommendation #6 - The WG recommends that if a request for enforcement is initiated under the TDRP the relevant domain should be 'locked' against further transfers while such request for enforcement is pending. Accordingly, 'TDRP action' and 'URS action' are to be added to the second bullet point of the list of denial reasons in the IRTP (Section 3); the IRTP and TDRP should be amended accordingly.3

The TDRP as well as guidelines to registrars, registries and third party dispute providers should be modified accordingly. The WG notes that the locking should be executed in the way that the UDRP prescribes – once that the UDRP locking process is implemented.

Recommendation #7 - The WG recommends to add a list of definitions (Annex F of Final Report) to the TDRP to allow for a clearer and more user-friendly policy.

Recommendation #8 - The WG recommends not to develop dispute options for registrants as part of the current TDRP.

Recommendation #9 - The WG recommends that staff, in close cooperation with the IRTP Part C Implementation Review Team, ensures that the IRTP Part C inter-registrant transfer recommendations are implemented and monitor whether dispute resolution mechanisms are necessary to cover the Use Cases in Annex C of the Final Report. Once such a policy is implemented, its functioning should be closely monitored, and if necessary, an Issues Report be called for to assess the need for an inter-registrant transfer dispute policy. See also Recommendations #17 and #18 below.

Recommendation #10 - The WG recommends that the TDRP be modified to eliminate the First (Registry) Level of the TDRP.

ICANN should monitor the use of TDRPs and if the discontinuation of the Registry layer as first level dispute provider seems to create a barrier to this dispute resolution mechanism, future policy work should be initiated to counter such development. See also #17 below.

Recommendation #11 - The WG recommends that ICANN take the necessary steps to display information relevant to disputing non-compliant transfers prominently on its web site and assure the information is presented in a simple and clear manner and is easily accessible for registrants.

This recommendation should be view in combination with Recommendation #12 (below).

Recommendation #12 - The WG recommends that ICANN create and maintain a user-friendly, one-stop website containing all relevant information concerning disputed transfers and potential remedies to registrants. Such a website should be clearly accessible from or integrated into the ICANN Registrants' Benefits and Responsibilities page (https://www.icann.org/resources/pages/benefits-2013-09-16-en) or similar.

This should include:

Information to encourage registrants to contact the registrar to resolve disputed transfers at the registrar level before engaging ICANN Compliance or third parties by launching a TDRP.
Improvements to the ICANN website regarding the display of information on the Inter Registrar Transfer Policy and the Transfer Dispute Resolution Policy is regularly updated (see 5.2.3.3 above).
Links to the relevant information for registrants on the ICANN website being clearly worded and prominently displayed on the ICANN home page. This will contribute to improving visibility and content of the ICANN website that is devoted to offering guidance to registrants with transfer issues.
ICANN Compliance clearly indicates on its FAQ/help section under which circumstances it can assist registrants with transfer disputes. This should include situations when registrants can ask ICANN Compliance to insist on registrars taking action on behalf of said registrant.
Improvements in terms of accessibility and user-friendliness should be devoted especially to these pages:
https://www.icann.org/resources/pages/dispute-resolution-2012-02-25-en#t...
https://www.icann.org/resources/pages/name-holder-faqs-2012-02-25-en
https://www.icann.org/resources/pages/text-2012-02-25-en
Links to these registrant help-websites should also be prominently displayed on internic.net and iana.org in order to assure further that registrants have easy access to information.

Recommendation #13 - The WG recommends that, as a best practice, ICANN accredited Registrars prominently display a link on their website to this ICANN registrant help site. Registrars should also strongly encourage any re-sellers to display prominently any such links, too. Moreover, the Group recommends that this is communicated to all ICANN accredited Registrars.

Registrars may choose to add this link to those sections of their website that already contains Registrant-relevant information such as the Registrant Rights and Responsibilities, the WHOIS information and/or other relevant ICANN-required links as noted under 3.16 of the 2013 RAA.

Recommendation #14 - The WG recommends that no additional penalty provisions be added to the existing IRTP or TDRP.

Recommendation #15 - As a guidance to future policy development processes, this Working Group recommends that policy specific sanctions be avoided wherever possible. Rather, sanctions should be consistent throughout policies and be governed by applicable provisions within the RAA.

Recommendation #16 - The WG does not recommend the elimination of FOAs. However, in light of the problems regarding FOAs, such as bulk transfers and mergers of registrars and/or resellers, the Group recommends that the operability of the FOAs should not be limited to email. Improvements could include: transmission of FOAs via SMS or authorization through interactive websites. Any such innovations must, however, have auditing capabilities, as this remains one of the key functions of the FOA.

The WG notes that the implementation of this recommendation should not be affected by whether transfers take place in advance (for certain bulk transfers) or in real time.

Recommendation #17 - The WG recommends that, once all IRTP recommendations are implemented (incl. IRTP-D, and remaining elements from IRTP-C), the GNSO Council, together with ICANN staff, should convene a panel to collect, discuss, and analyze relevant data to determine whether these enhancements have improved the IRTP process and dispute mechanisms, and identify possible remaining shortcomings.

If, after a period of 12 months of such a review, the GNSO (with ICANN Staff) determine that the situation regarding transfers is not improved, then this WG recommends that a top-to-bottom reevaluation of the transfer process be undertaken. The goal of this is to create a simpler, faster, more secure policy that is more readily understood and more accessible to use for registrants."

It is a further recommendation that a security expert be included in any such next review Working Group, should for example real 2-factor authentication be required, that it is implemented according to industry standards.

Recommendation #18 - The WG recommends that contracted parties and ICANN should start to gather data and other relevant information that will help inform a future IRTP review team in its efforts, especially with regard to those issues listed in the Observations of the Final Report (4.2.7.1).

To facilitate the gathering of relevant data, the Implementation Review Team should closely liaise with ICANN Staff to assure prompt access to necessary data.

Which stakeholders or others were consulted?

Regular consultation with stakeholders took place during the lifetime of this PDP. Details can be found in the Input Tracking List (Annex B of the Final Report).

What concerns or issues were raised by the community?

No community concerns have been raised in relation to the Final Report and its recommendations.

What significant materials did the Board review?

The Board reviewed the Final Report, the GNSO Council Recommendations Report to the Board, as well as the summary of public comments and the response to those comments.

What factors did the Board find 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 supermajority support for the motion (the Council voted unanimously in favor) obligates the Board to adopt the recommendation unless by a vote of more than two-thirds, 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 two 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 and TDRP 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 significant changes in processes for registrars as well as registrars and therefore it is expected that the implementation of these recommendations will require substantial time and resources, but these are considered necessary in order to address the issues that are part of this Policy Development Process. The recommendations, if implemented, are expected to usefully clarify and enhance the IRTP and TDRP, 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?

In addition to those changes required in the process for registrars as outlined above, there will likely be fiscal impacts related to implementation of the policy, such as updates to the ICANN website - but these costs should be anticipated to be within the budget of the relevant departments.

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.