Skip to main content
Resources

Fake Renewal Notices Report

Comment/Reply Periods (*) Important Information Links
Comment Open: 21 March 2012
Comment Close: 20 April 2012
Close Time (UTC): 23:59 UTC Public Comment Announcement
Reply Open: 21 April 2012 To Submit Your Comments (Forum Closed)
Reply Close: 11 May 2012 View Comments Submitted
Close Time (UTC): 23:59 UTC Report of Public Comments
Brief Overview
Originating Organization: GNSO Council
Categories/Tags: Top-Level Domains
Purpose (Brief): On 6 March 2012, the Fake Renewal Notices Drafting Team submitted its report [PDF, 559 KB] to the GNSO Council. Prior to considering this report [PDF, 559 KB] and its recommendations, the GNSO Council is requesting community input.
Current Status: The GNSO Council is requesting input on the Fake Renewal Notices Report.
Next Steps: The GNSO Council will review the comments received and consider next steps to address the issue of fake renewal notices.
Staff Contact: Marika Konings Email: policy.staff@icann.org
Detailed Information
Section I: Description, Explanation, and Purpose

Fake renewal notices are misleading correspondence sent to registrants from an individual or organization claiming to be or to represent the current registrar. These are sent for a variety of deceptive purposes. The desired action as a result of the deceptive notification is:

  • Pay an unnecessary fee (fraud)
  • Get a registrant to switch registrars unnecessarily ("slamming", or illegitimate market-based switching)
  • Reveal credentials or provide authorization codes to facilitate theft of the domain

The Registration Abuse Policies Working Group discussed this type of abuse in its Final Report [PDF, 1.73 MB] and recommended that 'the GNSO initiate a Policy Development Process by requesting an Issues Report to further investigate this abuse'. In order to help inform its deliberations on this recommendation, the GNSO Council requested that a small group of volunteers prepare a request for information concerning Fake Renewal Notices for the Registrar Stakeholder Group. The Fake Renewal Notices Drafting Team (DT) which was formed subsequently has submitted its report [PDF, 559 KB] to the GNSO Council in which it presents the results of the survey it conducted as well as offering the following options for possible next steps:

  • Add a section to the RAA that addresses Business Practices
  • Add the issue to the current or one of the upcoming Inter-Registrar Transfer Policy (IRTP) PDPs
  • Add this issue to the upcoming PDP on the RAA
  • Refer the issue to the At-Large Advisory Committee (ALAC) to encourage better education and awareness of this type of abuse amongst the end-user community
  • Raise this issue with the Federal Trace Commission (FTC) in the United States to see if the registrar is in compliance with relevant law
  • Initiate a Policy Development Process on Fake Renewal Notices
  • Do not proceed with any action at this time

As the report was developed by a small group of volunteers, the Fake Renewal Notices DT recommended that the GNSO Council put this report out for public comment in order to obtain community input on the findings and potential next steps. Following the presentation of the report, the GNSO Council decided to follow the DT's recommendation and put the report [PDF, 559 KB] out for community input.

Section II: Background

Prior to acting on the recommendation of the Registration Abuse Policies (RAP) Working Group to request an Issue Report on fake renewal notices, the GNSO Council decided it would be desirable to gather further information on this issue and it therefore resolved: 'The GNSO Council hereby requests that the Registrar Stakeholder Group provide further information and data on the nature and scope of the issue of Fake Renewal Notices to help inform the GNSO Council's and its RAP WG deliberations no whether an Issue Report should be requested. A small group of volunteers consisting of registrar representatives and others interested (including former RAP WG members) should be formed to prepare such a request, work with the Registrar Stakeholder Group to obtain the information requested and report back to the GNSO Council accordingly'.

Section III: Document and Resource Links
Section IV: Additional Information
None

(*) 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."