Skip to main content

Welcome to the new ICANN.org! Learn more, and send us your feedback. Dismiss

Resources

Preliminary Issue Report on Uniformity of Reporting

Comment/Reply Periods (*) Important Information Links
Comment Open: 20 February 2013
Comment Close: 22 March 2013
Close Time (UTC): 23:59 UTC Public Comment Announcement
Reply Open: Cancelled – No Comments To Submit Your Comments (Forum Closed)
Reply Close:   View Comments Submitted
Close Time (UTC):   Report of Public Comments
Brief Overview
Originating Organization: GNSO
Categories/Tags: Policy Processes
Purpose (Brief): At its October meeting last year the GNSO Council requested an Issue Report on the current state of uniformity in the mechanisms to initiate, track, and analyze policy-violation reports. ICANN Staff is also explicitly requested to provide its recommendation(s) on how this issue can be further addressed outside of a PDP if recommendations in relation to this issue do not require consensus policies to implement.
Current Status: This Report is designated as "preliminary" to allow for community input and dialogue prior to the publication of the Final Issue Report.
Next Steps: The Preliminary Issue Report will be updated to reflect community feedback submitted through this forum. A Final Issue Report will then be presented to the GNSO Council for its consideration.
Staff Contact: Marika Konings Email: policy-staff@icann.org
Detailed Information
Section I: Description, Explanation, and Purpose

This Preliminary Issue Report is published in response to a request by the GNSO Council for an Issue Report on the topic of Uniformity of Reporting, as a required preliminary step before a Policy Development Process (PDP) may be initiated.

The 2009 Registration Abuse Policies Working Group (RAPWG) identified in its Final Report the 'need for more uniformity in the mechanisms to initiate, track, and analyze policy-violation reports' and as a result recommended in its Final Report that "the GNSO and the larger ICANN community in general, create and support uniform reporting processes."

In March of 2012 based on the GNSO Council request, the ICANN Contractual Compliance Department presented its findings on existing systems that:

  • report and track violations and/or complaints;
  • detail improvements / changes made since the RAPWG Report or foreseen in the near future
  • identify gaps and any improvements that might be desirable but not foreseen at this stage;

Further, the GNSO Council discussed the RAPWG recommendation in light of the feedback received from the ICANN Contractual Compliance Department and former members of the RAPWG volunteered to provide additional information on how the RAPWG recommendation could be implemented. Alumni members created and presented the findings to the GNSO Council in September of 2012.

During GNSO Council deliberations in October 2012, The GNSO Council requested an Issue Report on the current state of uniformity in the mechanisms to initiate, track, and analyze policy-violation reports. ICANN Staff is also explicitly requested to provide its recommendation(s) on how this issue can be further addressed outside of a PDP if recommendations in relation to this issue do not require consensus policies to implement.

ICANN Staff welcome community input on the findings as well as conclusions of this Preliminary Issue Report.

Section II: Background
The request for an Issue Report on this topic follows the work of the Registration Abuse Policies Working Group (RAPWG). The RAPWG was tasked by the GNSO Council with defining abuse, making a determination between registration abuse versus use abuse, defining the most common forms of abuse, and understanding the effectiveness of abuse provisions within agreements in order to identify and recommend specific policy issues and processes for further consideration by the GNSO Council. The RAPWG identified a total of 14 recommended actions that could address various forms of registration abuse. Some recommendations addressed WHOIS access issues, fake renewal notices, UDRP Review, malicious use of domain names and several others. The specific recommendation ultimately prompting this Issue Report stated: "the need for more uniformity in the mechanisms to initiate, track, and analyze policy-violation reports and that the GNSO and the larger ICANN community in general, create and support uniform reporting processes."
Section III: Document and Resource Links
Preliminary Issue Report on Uniformity of Reporting [PDF, 1.49 MB]
Section IV: Additional Information

(*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."