ページ履歴

This Public Comment period aims at gathering Obtain community input on a proposed amendment to the .NEUSTAR Registry Agreement, to implement a request submitted through the RegistryServices Evaluation Policy (RSEP) process to allow the registration of all country and territory names currently required to be reserved by Section 4 of Specification 5 of the RegistryAgreementthe 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.

Section 4 of Specification 5 of the Registry Agreement addresses the required reservation of country and territory names. Registry Operators are required to reserve the country and territory names, but may propose their release, subject to review by the Governmental Advisory Committee and approval by ICANN. Specifically, the Registry Agreement provides as follows:

The country and territory names (including their IDN variants, where applicable) contained in the following internationally recognized lists shall be withheld from registration or allocated to Registry Operator at All Levels:

4.1. the short form (in English) of all country and territory names contained on theISO 3166-1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union <http://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3166-1_decoding_table.htm>;

4.2. the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and

4.3. the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names;

provided, that the reservation of specific country and territory names (including their IDN variants according to the registry operator IDN registration policy, where applicable) may be released to the extent that Registry Operator reaches agreement with the applicable government(s). Registry Operator must not activate such names in the DNS; provided, that Registry Operator may propose the release of these reservations, subject to review by ICANN's Governmental Advisory Committee and approval by ICANN. Upon conclusion of Registry Operator's designation as operator of the registry for the TLD, all such names that remain withheld from registration or allocated to Registry Operator shall be transferred as specified by ICANN. Registry Operator may self-allocate and renew such names without use of an ICANN accredited registrar, which will not be considered Transactions for purposes of Section 6.1 of the Agreement.

On 18 August 2014, NeuStar, Inc., the Registry Operator of the .NEUSTAR top-level domain (TLD), submitted a Registry Services Evaluation Policy (RSEP) request to allow the release of country and territory names defined in Section 4 of Specification 5 of the Registry Agreement at all levels of the .NEUSTAR TLD. The request is available for public information at: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

As provided by the Registry Services Evaluation Policy (RSEP), ICANN has undertaken a preliminary determination on whether the proposal might raise significant Competition, Security or Stability issues. ICANN's preliminary review (based on the information provided) did not identify any such issues for this request.

The implementation of the RSEP proposal would constitute a material change to the .NEUSTAR Registry Agreement, which requires an amendment to Exhibit A, Approved Services. In addition, as required per Section 4 of Specification 5 of the Registry Agreement, the proposal is also subject to a review by ICANN's Governmental Advisory Committee (GAC).

The proposed amendment to the .NEUSTAR Registry Agreement to implement the registry services as described in the RSEP proposal would be the first of its kind in the new gTLDspace. The current language in Specification 5 of the Registry Agreement regarding the required reservation of country and territory names was included in response to advice from the Governmental Advisory Committee (GAC) during the development of the New gTLDProgram (see this exchange of letters between the ICANN President and the GAC dated 17 March 2009 [PDF, 245 KB] and 24 April 2009 [PDF, 95 KB].

Furthermore, the GAC commented on this topic in the Singapore Communiqué [PDF, 449 KB] published on 27 March 2014. The GAC noted that it "discussed the Brand Registry Group proposal for a streamlined process under an addendum to the Registry Agreement for the approval of country names and 2-letter and character codes at the second level." The GACstated that it "has no major concerns about brand owners seeking approval for such names," but that the approval should be "done directly with the countries concerned rather than through a GAC-level operational process." The GAC noted that "individual GAC members could assist with proposals relevant to their particular country if requested," and further suggested that "consideration be given to establishing a register of countries that do not require individual requests to be made".

Subsequent to the GAC's Singapore Communiqué, on 8 August 2014, the Chair of the GACsubmitted a letter to the Chairman of the ICANN Board noting that some GAC members have raised concerns regarding the RSEP requests to release two-character labels, and as a result the GAC "intends to consider the matter at its next meeting during ICANN 51." The GACrequested that the Board take this timing into account as it considers the RSEP requests, and to continue to keep the GAC apprised of similar requests. In subsequent correspondence, the Board requested [PDF, 562 KB], and the GAC confirmed its intent to review the proposal for the release of country and territory names as well (see the reply sent by the Chair of the GACto the Chairman of the ICANN Board).

• Registry Agreement for .NEUSTAR: https://www.icann.org/resources/agreement/neustar-2013-12-05-en
• RSEP Request for the release of Country and Territory Name in .NEUSTAR :https://www.icann.org/en/system/files/files/neustar-country-territory-neustar-request-21aug14-en.pdf [PDF, 18 KB]
• RSEP Webpage:
  • 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

• .NEUSTAR Proposed Amendment [PDF, 58 KB]

/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)