Skip to main content
Resources

Minutes | Meeting of the New gTLD Program Committee

Note: On 10 April 2012, the Board established the New gTLD Program Committee, comprised of all voting members of the Board that are not conflicted with respect to the New gTLD Program. The Committee was granted all of the powers of the Board (subject to the limitations set forth by law, the Articles of Incorporation, Bylaws or ICANN's Conflicts of Interest Policy) to exercise Board-level authority for any and all issues that may arise relating to the New gTLD Program. The full scope of the Committee's authority is set forth in its charter at http://www.icann.org/en/groups/board/new-gTLD.

A Regular Meeting of the New gTLD Program Committee of the ICANN Board of Directors was held telephonically on 30 July 2014 at 21:30 UTC.

Committee Chairman Cherine Chalaby promptly called the meeting to order.

In addition to the Chair the following Directors participated in all or part of the meeting: Fadi Chehadé (President and CEO, ICANN), Steve Crocker (Board Chairman), Chris Disspain, Ray Plzak, Mike Silber, and Kuo-Wei Wu.

Heather Dryden, Bill Graham, Bruno Lanvin, Olga Madruga-Forti, Erika Mann, Gonzalo Navarro, George Sadowsky, and Suzanne Woolf sent apologies.

Jonne Soininen (IETF Liaison) was in attendance as a non-voting liaison to the Committee.

Secretary: John Jeffrey (General Counsel and Secretary).

ICANN Executives and Staff in attendance for all or part of the meeting: Akram Atallah (President, Global Domains Division); Francisco Arias (Director, Technical Services – Global Domains Division); Megan Bishop (Board Support Coordinator); Michelle Bright (Board Support Manager); Samantha Eisner (Senior Counsel); Allen Grogan (Chief Contracting Counsel); Cyrus Namazi (Vice President, DNS Industry Engagement); Erika Randall (Counsel); Amy Stathos (Deputy General Counsel); and Christine Willett (Vice President, gTLD Operations).

These are the Minutes of the Meeting of the New gTLD Program Committee, which took place on 30 July 2014.

  1. Main Agenda:
    1. Name Collision Occurrence Management Framework

 

  1. Main Agenda:

    1. Name Collision Occurrence Management Framework

      The Committee continued its discussion from a prior meeting concerning a framework to address collision occurrences between new gTLDs and existing private uses of the same strings. Akram Atallah provided an overview of the Committee's previous discussion concerning name collisions, and summarized the proposed Name Collision Mitigation Framework.

      The Committee resumed its consideration of the possibility of engaging the GNSO to consider whether policy work on the developing the long-term plan to address the issue of name collisions should be undertaken. Ray Plzak noted that the proposed resolutions address this concern. Chris Disspain inquired about the timeline for registry operators to begin implementing the period of controlled interruption if the framework were adopted.

      Ray Plzak moved, and Kuo-Wei Wu seconded the proposed resolutions. The Committee took the following action:

      Whereas, on 7 October 2013 the NGPC directed the President, Global Domains Division to implement the proposal to manage the occurrence of collisions between new gTLDs and existing private uses of the same strings as presented in the "New gTLD Collision Occurrence Management Plan" (the "Collision Occurrence Management Plan"), and in doing so to take into account further advice that may be offered by Security and Stability Advisory Committee (SSAC) and other experts and stakeholders.

      Whereas, the Collision Occurrence Management Plan called for a follow-up study that would inform the development of a Name Collision Occurrence Management Framework.

      Whereas, on 26 February 2014, ICANN published the follow-up study called for in the NGPC's 7 October 2013 resolution, which was prepared by JAS Global Advisors (JAS) and entitled "Mitigating the Risk of DNS Namespace Collisions: A Study on Namespace Collisions in the Global Internet DNS Namespace and a Framework for Risk Mitigation, Phase One Report" [PDF, 322 KB] (the "JAS Study and Name Collision Framework"). The JAS Study and Name Collision Framework, which was posted for public comment, provided a set of recommendations that describe a comprehensive framework to reduce current and future DNS namespace collisions, alert operators of potential DNS namespace related issues, and provide emergency response capabilities in the event that critical (e.g., life safety) systems are adversely impacted. The JAS Study and Name Collision Framework was revised [PDF, 392 KB] in response to public comments.

      Whereas, on 6 June 2014, the ICANN Security and Stability Advisory Committee (SSAC) published SAC 066 [PDF, 306 KB]: SSAC Comment Concerning JAS Phase One Report on Mitigating the Risk of DNS Namespace Collisions, in which it offered advice and recommendations to the Board on the framework presented in the JAS Study and Name Collision Framework.

      Whereas, the proposed name collision framework being presented to the NGPC for consideration takes into account advice offered by SSAC in SAC066, and the advice of other experts and stakeholders, including the recommendations from JAS, public comments, and community discussions at ICANN meetings.

      Whereas, the NGPC acknowledges comments from the community concerning the need to ensure that all names, which registries blocked under their Alternate Path to Delegation Report, be subject to the rights protection mechanisms established by the New gTLD Program.

      Whereas, the ICANN Board previously adopted the NGPC's recommendation to direct the ICANN President and CEO to develop a long-term plan to management name collision at the root.

      Whereas, the NGPC is undertaking this action pursuant to the authority granted to it by the Board on 10 April 2012, to exercise the ICANN Board's authority for any and all issues that may arise relating to the New gTLD Program.

      Resolved (2014.07.30.NG01), the NGPC adopts the Name Collision Occurrence Management Framework <https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf> [PDF, 635 KB] to continue to manage the occurrence of collisions between new gTLDs and existing private uses of the same strings, and directs the President and CEO, or his designee(s), to take the necessary actions to implement the Name Collision Occurrence Management Framework. As part of implementation, registry operators will be provided with a Name Collision Occurrence Assessment (see Registry Agreement, Specification 6, Section 6), which will address, among other things, procedures to remove second level domains from the block list including measures to protect rights holders.

      Resolved (2014.07.30.NG02), the NGPC directs the President and CEO, or his designee(s), to consult with the community during the next 90 days from the publication of these resolutions to address appropriate rights protection mechanisms for names included in a registry operator's Alternate Path to Delegation Report and recorded in the Trademark Clearinghouse that registry operator withheld from allocation during its Sunrise period or Claims period.

      Resolved (2014.07.30.NG03), the NGPC directs the President and CEO, or his designee(s) to provide information to, and work with the GNSO to consider whether policy work on developing a long-term plan to manage gTLD name collision issues should be undertaken.

      Resolved (2014.07.30.NG04), the NGPC directs the President and CEO, or his designee(s), to continue to provide briefings and share information and best practices with ccTLD managers concerning name collision issues in light of the Name Collision Occurrence Management Framework.

      All members of the Committee present voted in favor of Resolutions 2014.07.30.NG01 – 2014.07.30.NG04. Bill Graham, Bruno Lanvin, Olga Madruga-Forti, Erika Mann, George Sadowsky, and Gonzalo Navarro were unavailable to vote on the Resolutions. The Resolutions carried.

      Rationale for Resolutions 2014.07.30.NG01 – 2014.07.30.NG04

      Why is the NGPC considering this issue now?

      The NGPC's action today follows on from its previous actions taken to address name collision issues. Specifically, on 7 October 2013, the NGPC took action directing the President, Global Domains Division to implement the proposal to manage the occurrence of collisions between new gTLDs and existing private uses of the same strings as presented in the "New gTLD Collision Occurrence Management Plan" (the "Collision Occurrence Management Plan"), and in doing so to take into account further advice that may be offered by Security and Stability Advisory Committee (SSAC) and other experts and stakeholders. A core feature of the Collision Occurrence Management Plan required ICANN to undertake additional study to develop a name collision occurrence management framework. The framework was intended to specify a set of collision occurrence assessments and corresponding mitigation measures if any, that ICANN or new gTLD applicants may need to implement.

      To implement the NGPC's 7 October 2013 action, on 24 February 2014, ICANN published a study prepared by JAS Global Advisors ("JAS") entitled "Mitigating the Risk of DNS Namespace Collisions: A Study on Namespace Collisions in the Global Internet DNS Namespace and a Framework for Risk Mitigation, Phase One Report" (the "JAS Study and Name Collision Framework"). The JAS Study and Name Collision Framework provided a set of recommendations that describe a comprehensive framework to reduce current and future DNS namespace collisions, alerting operators of potential DNS namespace related issues, and providing emergency response capabilities in the event that critical (e.g., life safety) systems are adversely impacted. Additionally, the SSAC offered advice and recommendations to the Board on the proposed name collision framework included in the JAS Report in SAC 066: SSAC Comment Concerning JAS Phase One Report on Mitigating the Risk of DNS Namespace Collisions [PDF, 306 KB].

      At this time, the NGPC is adopting the Name Collision Occurrence Management Framework dated 30 July 2014 <https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf> [PDF, 635 KB], which is a final version of the framework called for in the Collision Occurrence Management Plan (the "Final Name Collision Framework"). The Final Name Collision Framework builds off of the framework in the JAS Study and Name Collision Framework, and has been further refined in response to the recommendations in SAC066, public comments, and additional community feedback during the ICANN Meeting in London. Adoption and implementation of the Final Name Collision Framework will allow ICANN to continue to move forward with the delegation of new gTLDs in a secure and stable manner.

      What are the proposals being considered?

      The Final Name Collision Framework being adopted by the NGPC presents a plan to manage the collision occurrences between new gTLDs and existing private uses of the same strings. A summary of some of the key elements of the Final Name Collision Framework is as follows:

      General Requirements for Registries:

      • Required to act on name collision reports from ICANN within two hours of the report during the first two years of the life of the TLD measured from the time of delegation of the TLD.

      • Required to implement "controlled interruption" as the notification measure to alert parties that they may be leaking queries intended from private namespaces to the public DNS. Controlled interruption is required to be continuous interruption (i.e. not intermittent), and lasting for a 90-day period. Generally, if a TLD was delegated prior to a defined cut-off date, the registry operator would implement controlled interruption using MX, SRV, TXT, and A records for second level domains included in the block list. For TLDs delegated after a defined cut-off date, the registry operator would implement controlled interruption using a wildcard method. Controlled interruption (for IPv4) will use a loopback address (127.0.53.53)

      Requirements for ICANN:

      • Work within the IETF and with other relevant technical communities to identify a notification mechanism for IPv6 that provides similar functionality to that available in IPv4's "Loopback" reserved prefix.

      • Defer delegating .MAIL indefinitely, and collaborate with the technical and security community to identify the best way to handle .MAIL (e.g. permanent reservation through the IETF process). The JAS Study and Name Collision Framework identifies .MAIL as exhibiting "prevalent, widespread use at a level materially greater than all other applied-for TLDs" and thus its prevalent internal use is likely irreversible.

      • Produce new outreach and informational materials as needed to alert potentially affected parties about name collisions, and link to existing information regarding name collisions developed as part of the initial outreach campaign.

      The NGPC's action today also addresses concerns raised by community regarding the need to ensure that names, which registries blocked under their Alternate Path to Delegation Report, be subject to applicable rights protection mechanisms established by the New gTLD Program. To address this concern, the NGPC is directing the President and CEO, or his designee(s), to consult with the community during the next 90 days (from the publication of these resolutions) to address appropriate rights protection mechanisms for names included in a registry operator's Alternate Path to Delegation Report and recorded in the Trademark Clearinghouse that registry operator withheld from allocation during its Sunrise period or Claims period.

      To follow-up on a prior recommendation to the Board to direct the President and CEO to develop a long-term plan to management name collision at the root, the NGPC's action today directs the President and CEO, or his designee(s) to provide information to, and work with the GNSO to consider whether policy work on developing a long-term plan to manage gTLD name collision issues should be undertaken. The NGPC also is taking action to direct the President and CEO, or his designee(s), to continue to provide briefings and share information and best practices with ccTLD managers concerning name collision issues in light of the adoption of the Final Name Collision Framework.

      What Stakeholders or others were consulted?

      ICANN initiated a public comment forum from 26 February to 21 April 2014, inviting the community to provide feedback on the JAS Study and Name Collision Framework. During the public comment period, twenty-eight comments were received. The public comment report summarizing the comments, and the full comments can be found at: https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 230 KB].

      The SSAC also was consulted and offered advice and recommendations to the Board (via SAC066) on the proposed name collision framework included in the JAS Study and Name Collision Framework. Additionally, ICANN presented a version of the proposed Final Name Collision Framework during the ICANN Meeting in London.

      What concerns or issues were raised by the community?

      The JAS Study and Name Collision Framework received twenty-eight comments during the public comment period which were submitted by a full range of sources, including New gTLD applicants and those affiliated with applicants, corporations not directly affiliated with applicants, individual technology experts, and various DNS related industry organizations. Members of the community also submitted correspondence to ICANN regarding the intersection of name collision issues and rights protection mechanisms. Additionally, the SSAC raised some concerns in SAC066 regarding the name collision framework.

      Some key themes and concerns expressed by the SSAC and ICANN community included, but are not limited to the following:

      • Concerns related to the current use of the Second Level Domain (SLD) Block Lists and the Alternate Path to Delegation in general.

      • Concerns that the proposed 120-day "controlled interruption" period is too long and/or not justified – Some commenters suggested that there is no data to support having a 120-day controlled interruption period, and suggested that if there is a period, it should fall in the range of 45 days to 90 days.

      • Concerns for using a "loopback" approach instead of a "honeypot" approach – The SSAC recommended that using a honeypot approach allows better notification for HTTP cases, and provides support for IPv4 and IPv6. Some of the public comments also suggest that a honeypot approach would provide a better opportunity to inform users of impending problems. Some other commenters, however, note that a honeypot may expose personally identifiable or sensitive information outside of the local network or to potential attackers, among other issues.

      • Concerns about whether the controlled interruption should be continuous or intermittent – The SSAC recommended that instead of a single controlled interruption period, ICANN should introduce rolling interruption periods, broken by periods of normal operation, to allow affected end-user systems to continue to function during the test period with less risk of catastrophic business impact.

      • Concerns about what type of event would trigger an emergency response – The SSAC recommended that ICANN should expand the range of situations that would trigger an emergency response, for example national security, emergency preparedness, critical infrastructure, key economic processes, commerce, and the preservation of law and order. Some of the public comments also raised concern that a "clear a present danger to human life" standard draws an arbitrary line, and others suggest that certain significant dangers to the business and financial sectors of the global economy might also merit the use of emergency measures.

      • Concerns about the treatment of .CORP, .HOME, and .MAIL – Some of the public comments support the treatment of .CORP, .HOME, and .MAIL recommending in the JAS Study and Name Collision Framework, while others suggest that a final decision on this matter be postponed until a more comprehensive technical evaluation can be performed and a solution may be developed to allow for these strings to operate in the DNS.

      • Comments requesting the acceleration and closure of the collisions issue in general – Some members of the community noted a general concern that the name collision matter is being dealt with at such a late stage of the New gTLD process, and questioned why ICANN did not address the matter sooner. Commenters raising concerns about timing also requested that ICANN take action on the matter with deliberate speed so as not to cause further delay.

      • Comments expressing concern about the interaction between the name collision block lists and intellectual property rights protection mechanisms – Some public comments and correspondence to ICANN suggest that all names, which registries blocked under their alternative path to delegation plans, be subject to the Sunrise and Trademark Claims services outlined in the gTLD Applicant Guidebook, the Registry Agreement, and the Rights Protection Mechanism Requirements (RPMs), or other similar mechanism to protect rights holders. Additionally, some .BRAND TLD applicants note many of the "brand" terms included in the block lists are trademarks for the brand's products and services, and are seemingly generated at the root by the brand itself. These commenters suggest that ICANN consider an alternative process for .BRAND TLD applicants to expedite the release of such trademarked terms for their immediate use.

      What significant materials did NGPC review?

      The NGPC reviewed several materials, including, but not limited to the following:

      What factors did the NGPC find to be significant?

      The NGPC considered several significant factors during its deliberations over whether or not to adopt the Final Name Collision Framework. The following are among the factors the NGPC found to be significant:

      • The NGPC considered the recommendations of the SSAC, including those in SAC066.

      • As previously noted, several commenters, including the SSAC, raised concerns about using a "loopback" approach instead of a "honeypot" approach. In choosing the loopback approach in the Final Name Collision Framework, the NGPC took into consideration the privacy and legal risks associated with the honeypot approach described in SAC 062 and 066 and the JAS report. On balance, the NGPC notes that the notification features offered by using the loopback approach provides a better option to provide a notification system of name collisions while minimizing the issues inherent in using a honeypot approach. The NGPC also notes that while the honeypot approach has the benefit of offering a IPv6 solution, the Final Name Collision Framework includes a requirement that ICANN will work within the IETF and with other relevant technical communities to identify a mechanism for IPv6 that provides similar functionality to that available in IPv4's "Loopback" reserved prefix.

      • The NGPC also found to be significant comments concerning whether the controlled interruption should be continuous or intermittent. While the SSAC recommended an intermittent controlled interruption, it also acknowledged that every approach to controlled interruption involves balancing trade-offs and exercising judgment. From an operational perspective the intermittent approach presents more risk for registries and ICANN to implement and ensure correct functioning. On the other hand, continuous controlled interruption presents a more simple approach operationally and provides for an easier way to diagnose and troubleshoot. It also provides a more effective way to indicate the need for changes in an affected party's network configuration. Additionally, an intermittent controlled interruption approach in theory would allow an affected party to have temporary relief while the controlled interruption is in the "off" cycle. It should be noted that there is already a mechanism in place (name collision reporting) for affected parties to find temporary relief from name collision harm, if needed, making the intermittent approach an unnecessary burden.

      • The NGPC considered the concerns raised by the community regarding the need to ensure that names, which registries blocked under their Alternate Path to Delegation Report, be subject to the rights protection mechanisms established by the New gTLD Program. As previously noted, to address these concerns, the NGPC is directing the President and CEO, or his designee(s), to consult with the community during the next 90 days (from the publication of these resolutions) to address appropriate rights protection mechanisms for names included in a registry operator's Alternate Path to Delegation Report and recorded in the Trademark Clearinghouse that registry operator withheld from allocation during its Sunrise period or Claims period.

      • The NGPC considered the recommendations about what type of event would trigger an emergency response. The Final Name Collision Framework being adopted today will limit emergency response for name collision reports to situations where there is a reasonable belief that the name collision presents a clear and present danger to human life. The NGPC acknowledges SSAC advice with respect to expanding the range of situations that would trigger an emergency response. However, the NGPC notes that the severity of this risk (as in other cases) can be measured from multiple points of view; necessarily, there will be a decision between various impacted parties (i.e., the party that was using the domain name before it was delegated in the public DNS and the party that registered the name). Commercial interests could attempt to "game" a broader mechanism for competitive advantage. Concepts like "national security," "law and order", and "key economic processes" are not easily agreeable on a global basis. On the other hand, focusing on danger to human life is a more objective standard.

      Additionally, the Final Name Collision Framework includes an emergency response measure to address the unlikely case that a newly delegated gTLD creates a clear and present danger to human life as a result of colliding use as a dotless name. In this case, ICANN would work with the registry operator and ICANN's root zone management partners to reverse the new delegation. This would only happen during the 90-day wildcarded controlled interruption, during which there would be no names active (except "nic") under the TLD. Once the harm is mitigated, the gTLD registry operator may request again delegation. As indicated by SAC062 and the JAS Study and Name Collision Framework report, reversal of a new delegation is an extreme measure and should be exercised in an extreme circumstance where there is clear and present danger to human life during the wildcarded controlled interruption period.

      Are there Positive or Negative Community Impacts? Are there fiscal impacts/ramifications on ICANN (Strategic Plan, Operating Plan, Budget); the community; and/or the public? Are there any Security, Stability or Resiliency issues relating to the DNS?

      SAC057 and the Name Collision Study identified several security risks to the DNS. The Final Name Collision Framework, as revised in response to community comments, and recommendations of the SSAC in SAC066 provides a path forward to delegating new gTLDs in a secure and stable manner.

      The Final Name Collision Framework may have a fiscal impact on ICANN, the community or the public, as there may be additional costs associated with implementing the measures in the Final Name Collision Framework, including additional resources needed to continue the outreach campaign targeted to affected parties to help them identify and manage the name collision occurrences in their networks.

      As part of ICANN's organizational administrative function, ICANN posted for public the name collision framework as presented in the JAS Study. The report of public comments is available at: https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 230 KB].

    The Chair called the meeting to a close.

Published on 9 September 2014.

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."