ページ履歴

Obtain community input on the 18 recommendations of the Generic Names Supporting Organization (GNSO) Policy Development Process (PDP) on changes to the Inter-RegistrarTransfer Policy (IRTP) Part D prior to ICANN Board consideration.

The Generic Names Supporting Organization (GNSO) unanimously approved at its meeting on 15 October the following recommendations, which will be submitted to the Board for adoption after the conclusion of the public comment period:

Recommendation #1 – Reporting requirements to be incorporated into the TDRP policy.Outcomes of all rulings by Dispute Resolution Providers (DRP) 1 should be published on Providers' website, 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 GNSO recommends publishing reports that follow the example of the Asian Domain Name Dispute Resolution Centre (ADNDRC).2 These reports should include at a minimum:

1. The domain name under dispute

2. Relevant information about parties involved in the dispute;

3. The full decision of the case;

4. 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 TDRP to 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 TDRP to 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 – A domain name to be returned to the Registrar of Record andRegistrant of Record directly prior to the non-compliant transfer if it is found, through aTDRP procedure, that a non-IRTP compliant domain name transfer occurred.

Recommendation #5 – The statute of limitation to launch a TDRP to 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 – 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. It was noted that the locking should be executed in the way that theUDRP prescribes – once that the UDRP locking process is implemented.

Recommendation #7 – To add a list of definitions (see Annex F of the Final Report) to theTDRP to allow for a clearer and more user-friendly policy.

Recommendation #8 – Not to develop dispute options for registrants as part of the currentTDRP.

Recommendation #9 – Staff, in close cooperation with the IRTP Part C Implementation Review Team, to ensure 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. Once such a policy is implemented, its functioning should be closely monitored, and if necessary, an Issue 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 TDRP to 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 – ICANN to 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 – ICANN is to 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 theICANN 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 aTDRP.
• Improvements to the ICANN website regarding the display of information on the InterRegistrar 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#transfer
  • 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 – As a best practice, ICANN accredited Registrars to 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 containsRegistrant-relevant information such as the Registrant Rights and Responsibilities, the WHOISinformation and/or other relevant ICANN-required links as noted under 3.16 of the 2013 RAA.

Recommendation #14 – No additional penalty provisions to be added to the existing IRTPor TDRP.

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

Recommendation #16 – The elimination of FOAs is not recommended. However, in light of the problems regarding FOAs, such as bulk transfers and mergers of registrars and/or resellers, the GNSO Council 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 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 – 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 it is recommended 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 – 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 (4.2.7.1) above.

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

You are invited to submit your comments before final consideration of these recommendations by the ICANN Board. Especially, you are encouraged to submit comments that have not yet been raised during previous Public Comments on the IRTP Part D PDP (see Public Comment onPreliminary Issue Report; Initial Report) and considered by the PDP Working Group in Section 5 of the Final Report [PDF, 1.10 MB]).

1 The Working Group recommends in Charter question C to remove the Registry as the first dispute resolution layer of the TDRP. Therefore, despite wording of Charter question A, no reporting requirements for the Registries are included here.

2 See four ADNDRC Reports on TDRP decisions:http://www.adndrc.org/mten/TDRP_Decisions.php?st=6

3 https://www.icann.org/resources/pages/policy-transfers-2014-07-02-en

The Inter-Registrar Transfer Policy (IRTP) provides the policy framework for domain name transfers between registrars. The IRTP also provides standardized requirements for inter-registrar transfer disputes – through the Transfer Dispute Resolution Policy (TDRP). The policy is an existing community consensus policy that was implemented in late 2004 and has been revised numerous times since then.4 The IRTP Part D Policy Development Process (PDP) is the forth and final PDP of this series of revisions. The Generic Names Supporting Organization (GNSO) Council resolved at its meeting on 17 October 2012 to launch an Issue Report on IRTPPart D, "which should include all the remaining issues identified by the original transfers Working Groups as well as the additional issue identified by the IRTP Part C WG."

On 17 January 2013, the GNSO Council launched a Policy Development Process (PDP) on IRTPPart D [http://gnso.icann.org/en/council/resolutions#201301] addressing the following six Charter questions:

1. Whether reporting requirements for registries and dispute providers should be developed, in order to make precedent and trend information available to the community and allow reference to past cases in dispute submissions;

2. Whether additional provisions should be included in the TDRP (Transfer Dispute Resolution Policy) on how to handle disputes when multiple transfers have occurred;

3. Whether dispute options for registrants should be developed and implemented as part of the policy (registrants currently depend on registrars to initiate a dispute on their behalf);

4. Whether requirements or best practices should be put into place for registrars to make information on transfer dispute resolution options available to registrant;

5. Whether existing penalties for policy violations are sufficient or if additional provisions/penalties for specific violations should be added into the policy;

6. Whether the universal adoption and implementation of EPP AuthInfo codes has eliminated the need of FOAs.

This PDP has followed the prescribed PDP steps as stated in the Bylaws, resulting in a Final Report delivered on 25 September 2014. The IRTP Part D WG reached full consensus on the 18 recommendations in relation to the six issues outlined above.

4 IRTP A: http://gnso.icann.org/en/group-activities/inactive/2008/irtp; IRTP B:http://gnso.icann.org/en/group-activities/active/irtp-b; IRTP C: http://gnso.icann.org/en/group-activities/active/irtp-c

IRTP Part D PDP Final Report [PDF, 1.10 MB]

Inter-Registrar Transfer Policy (IRTP)