ICANN news
Security is at the core of what we do at ICANN to facilitate the global technical coordination of the Internet’s unique identifier systems. This post attempts to provide some clarity and context to the Security terms we use at ICANN. This baseline understanding will help the community improve discussions with ICANN’s counterparts and stakeholders in the greater Internet ecosystem.
In May, Markus Kummer wrote on the Internet Society blog about the history of the term “multistakeholder.” 1 Reading his paper triggered an idea that an article reflecting on the historical context for security terms at ICANN may help provide a basic understanding for how we use these terms and how these uses may differ from others in the ecosystem. If you are interested in the historical perspective, see the inset at the end of the article [click here].
This post focuses on the terms:
- Security – providing the capacity to protect Internet unique identifiers and prevent misuse
- Stability – the capacity to ensure that the system operates as expected, and that users of the unique identifiers have confidence that the system operates as expected.
- Resiliency – the capacity of the unique identifier system to effectively withstand/tolerate/survive malicious attacks and other disruptive events without disruption or cessation of service.
Security
At ICANN “providing capacity” is a particularly important function of the Security Team: we provide expertise and contribute resources to assist, educate, train others in the Internet ecosystem to protect unique identifiers and share practices for preventing their misuse. This is done through Security’s technical engagement function.
A key part of ICANN’s Security role is focused on operational integrity and the mitigation of threats. ICANN has responsibilities for maintaining the security (“safe operation”) of L-root, the DNSSEC key signing functions, IANA functions, new gTLD operations, Time Zone Database Management, and organizational functions such as Finance, Personnel, Facilities and Meetings. This role is proactive toward minimizing risk to these operational functions, including detection and mitigation of threats across these and other areas where identifiers are put at risk.
Stability
A related element to Security is the concept of affording grounds for confidence. This element has been incorporated into our definition for stability. Stability relates to consistency, from a technical standpoint with name servers and data, between delegations and the appropriate zone in the name space. Maintaining stability was and remains an important part of ICANN’s mission.
Resiliency
The definitions of resiliency and resilience in the ICANN context relate to the original design objectives of the Internet protocols, i.e., to be adaptive to change and resilient to failure.
Resiliency relates to the overall ecosystem and its “ability to maintain its structure and function over time in the face of external stress.” This is a concept adapted from the discipline of ecological economics. The Stockholm Resilience Centre has a good overview of the concept of resilience 2. A resilient DNS and unique identifier system is one that will help support a healthy and sustainable Internet ecosystem.
Examples of programs to support resilience of the unique identifier system are registrar data escrow and emergency backend registry operators. Resiliency includes continuity and contingency testing and exercises.
ICANN is a signatory to the World Economic Forum’s Principles for Cyber Resilience 3 (pdf). The WEF Principles acknowledge that cyber resilience requires trusted dialogue and collaboration between parties in the Internet ecosystem.
Coordination and Collaboration
ICANN’s coordination and collaboration functions are foundational and relate to ensuring interoperability and preserving the security, stability and resiliency of the Internet’s unique identifier system. ICANN performs a coordinating role for Internet stakeholders, inclusive of governments and private industry, but with an independent governance structure. This function is non-regulatory, providing a distinction from those functions appropriately handled by governments and law enforcement.
Coordination is the heart of allocation processes for the Internet’s unique identifiers, technical engagement and policy making associated with the Internet’s unique identifiers. Coordination among and between different parties and different community functions helps to ensure that decisions related to technical functions are made in the public interest in a clear, fair, accountable and transparent manner.
An example is the coordinated disclosure guidelines published in March 2013. The guidelines define the role ICANN will perform in circumstances where vulnerabilities are reported and explain how a party should disclose information on a vulnerability discovered in a system or network operated by ICANN.
Collaboration is related to coordination but a separate concept. It is often defined as one who works in conjunction with another or others; especially in literary, artistic or scientific work 4. The original Memorandum of Understanding with the US Department of Commerce used “collaborate” to refer to ICANN and the Department of Commerce working together to ensure the functions and procedures for transition of the coordination functions for the Internet’s unique identifiers to ICANN. In the past 15 years, this coordination function has grown to include the broad range of stakeholders in the Internet ecosystem.
Collaboration relates to the activities and ways that ICANN participates as peers with others in the Internet ecosystem as well. For example, ICANN Security team members regularly participate in events such as the Internet Governance Forum and regional IGFs, the annual IISI security forum in Garmisch-Partenkirchen, Germany, at the Interpol Underground Economy Conference, Forum of Incident Response Security Teams, and other events. This also relates to ICANN’s involvement in response to Conficker 5 and other malicious attacks against the DNS.
We hope this provides a common understanding for how these terms are used in ICANN security, and we look forward to continuing dialogue with the Internet community in support of these functions.
Historical Uses
The Security terms in this blog post predate the formation of ICANN, and have been associated with the early days of computing to the advent of networking. Computer and information security was identified as a concern with the creation of the ARPANET. As early as the late 1960s, security was viewed in terms of protecting information in resource-sharing systems among a number of simultaneous users 6.
The need for coordination relates to uniqueness of the assignment of identifiers (see the development of the concept of Domain Names 7 and updated through subsequent RFCs).
Evolving from the ARPANET and academic network to the set of functions coordinated by Jon Postel as the Internet Assigned Numbers Authority, the early Internet technical community recognized the need for an organization with the responsibility for gathering and registering information about networks to which identifiers have been assigned and for the Internet to become available for global use 8.
The terms stability and coordination were key principles in the 1998 US Department of Commerce Statement of Policy on the Management of Internet Names and Addresses, (commonly referred to as the White Paper), which recognized that global commercial importance of the Internet necessitated “operation of the DNS and operation of the authoritative root server system should be secure, stable and robust”. 9
The White Paper also describes Coordination as the set of functions to be performed to ensure that the Internet runs smoothly. Coordination was viewed as a mechanism for preserving the stability of the Internet, and also as a process that would be flexible to meet the changing needs of the Internet and global Internet users.
The stability principle was described in connection with private sector coordination “without disruption to the functioning of the DNS” 10.
Security, stability and coordination are reflected in the Bylaws of ICANN as part of the Mission and Core Values, and were adopted into the Affirmation of Commitments.
RFC 1591 published by Jon Postel in March 1994 to describe the Domain Name System’s structure and the delegation for top-level domains, uses the term resilience in describing the duties of a TLD manager. These include “responding to requests in a timely manner, and operating the database with accuracy, robustness and resilience.” 11
There are limited references to resilience between 1999-2008. In November 2001, Bruce Schneier delivered a keynote at the ICANN Meeting devoted to security and stability of the Internet Naming and Address Allocation Systems focused on “Resilient Security”. In 2003, resiliency appeared in the 8th status report to the US Department of Commerce related to an SSAC study of “an evaluation of the redundancy and resiliency of the major domain name servers to withstand distributed denial of service attacks.” 12.
In 2008, ICANN’s Security team was formed, and resiliency became a key term for ICANN in association with security and stability. For more information, ICANN Security team documents can be found in the Security document archive 13.
1 http://www.internetsociety.org/blog/2013/05/multistakeholder-cooperation-reflections-emergence-new-phraseology-international
2 http://www.stockholmresilience.org/21/research/what-is-resilience.html
3 World Economic Forum’s Principles for Cyber Resilience, http://www3.weforum.org/docs/WEF_IT_PathwaysToGlobalCyberResilience_Report_2012.pdf [PDF, 2.09 MB]
4 https://en.wikipedia.org/wiki/Collaboration
5 http://www.icann.org/en/about/staff/security/conficker-summary-review-07may10-en.pdf [PDF, 386 KB]
6 Security Controls for Computer Systems, RAND Report R-609, 1970, http://www.rand.org/pubs/reports/R609-1/index2.html
7 RFC 1034, http://www.ietf.org/rfc/rfc1034.txt, as implemented in RFC 1035, http://www.ietf.org/rfc/rfc1035.txt
8 RFC 1174, http://tools.ietf.org/html/rfc1174
9 1998 US Department of Commerce Statement of Policy on the Management of Internet Names and Addresses, 63 Fed. Reg. 31741 (commonly referred to as the White Paper, see http://www.icann.org/en/about/agreements/white-paper)
10 Memorandum of Understanding with the US Department of Commerce, http://www.icann.org/en/about/agreements/mou-jpa/icann-mou-25nov98-en.htm)
11 RFC 1591, http://www.ietf.org/rfc/rfc1591.txt
12 http://www.icann.org/en/about/agreements/mou-jpa/status-report-01aug03-en.htm
13 http://www.icann.org/en/about/staff/security/archive
3 July 2013
On 2 July 2013, the the ICANN Board New gTLD Program Committee (NGPC) had its seventh meeting to discuss the GAC Beijing advice on New gTLDs. The Committee took the following actions:
-
Initial Protections for IGO Protections
In the Beijing Communiqué, the GAC reiterated previous advice that "appropriate preventative initial protection for the IGO names and acronyms on the provided list be in place before any new gTLDs would launch." In response to a number of issues raised by the Board, the GAC noted in the Beijing Communiqué that it is "mindful of outstanding implementation issues" and that it is committed to "actively working with IGOs, the Board, and ICANN Staff to find a workable and timely way forward. In a 6 June 2013 response letter to the GAC on the IGO GAC Advice, the ICANN Board Chairman proposed that a small number of NGPC members and ICANN staff begin a dialogue with the GAC on these issues
At its 2 July 2013 meeting, the NGPC passed a resolution confirming that the New gTLD Registry Agreement will require operators to provide appropriate preventative initial protection for the IGO identifiers. These protections will remain in place while the GAC, NGPC, ICANN Staff and community continue to actively work through outstanding implementation issues. More specifically, registry operators will implement temporary protections for the IGO names and acronyms on the "IGO List dated 22/03/2013" until the first meeting of the NGPC following the ICANN 47 Meeting in Durban. The Resolution provides temporary protections for IGOs while respecting the ongoing work on implementation issues. The IGO List is attached to the Resolution as Annex 1.
If the NGPC and GAC do not reach an agreement on outstanding implementation issues for protecting IGO names and acronyms by the first meeting of the NGPC following the ICANN 47 meeting in Durban, and subject to any matters that arise during the discussions, registry operators will be required to protect only the IGO names (and not the acronyms) identified on the GAC's IGO List.
-
Category 1 Advice
In the Beijing Communiqué, the GAC proposed Category 1 safeguard advice, which includes recommended restrictions and consumer protections for sensitive strings and regulated markets. The Category 1 Safeguard Advice is divided into three main sections. The first section provides five (5) items of advice that apply to "strings that are linked to regulated or professional sectors." The Beijing Communiqué identified a list of strings to which this advice applies. The second section provides three (3) additional pieces of advice that should apply to a limited subset of the strings noted in the GAC's list that are "associated with market sectors which have clear and/or or regulated entry requirements (such as: financial, gambling, professional services, environmental, health and fitness, corporate identifiers, and charity) in multiple jurisdictions…." The third section includes an additional requirement for applicants for the following strings: .fail, .gripe, .sucks and .wtf.
On 23 April 2013, ICANN initiated a public comment forum to solicit input on how the NGPC should address GAC advice regarding safeguards applicable to broad categories of new gTLD strings http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en.htm. The public comment forum closed on 4 June 2013. While many commenters voiced support for the Category 1 safeguard advice, many others submitting opposing comments. One overarching theme from the public comments was the need for additional clarity on the scope and intent of the Category 1 Safeguard Advice.
After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
-
New gTLD Registry Agreement
Finally, the NGPC considered the revised New gTLD Registry Agreement that will be entered into between ICANN and successful new gTLD applicants. The revised agreement is the result of several months of negotiations, formal community feedback (most recently during public comment forums initiated on 5 February 2013 on 29 April 2013), and meetings with various stakeholders and communities. The revisions include feedback from the ICANN community at the ICANN 46 Meeting on 7-11 April 2013 in Beijing as well as GAC advice issued in its Beijing Communiqué.
After considering the comments received from the community, the NGPC determined that the revised New gTLD Registry Agreement included significant improvements in response to the concerns raised by the community. The Committee also noted that in response to the GAC's Beijing Communiqué, revisions were made to Specification 11 to implement the non-Category 1 safeguard advice (i.e., safeguards applicable to all strings and Category 2 safeguards). The revisions to Specification 11 incorporate standardized language to address the safeguard advice. Applicant-specific PICs will be included on a case-by-case basis to the extent not superseded by or inconsistent with the standard PICs included to address the GAC's Beijing Communiqué.
The NGPC approved the form of the New gTLD Registry Agreement and authorized ICANN staff to take all necessary steps to implement it and to move forward with implementation of the New gTLD Program. The Agreement is attached to the Resolution as Annex 1; the complete Summary of Changes to the New gTLD Registry Agreement is attached to the Resolution as Annex 2; a redline of the current agreement as compared to the previous version dated 29 April 2013 is attached to the Resolution as Annex 3; and the Summary and Analysis of Public Comments is available at http://www.icann.org/en/news/public-comment/report-comments-base-agreement-01jul13-en.pdf [PDF, 338 KB].
All of the resolutions adopted at the 2 July 2013 NGPC meeting are posted at http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm. A table summarizing NGPC Consideration of the GAC's Beijing Advice appears below.
3 July 2013
On 2 July 2013, the the ICANN Board New gTLD Program Committee (NGPC) had its seventh meeting to discuss the GAC Beijing advice on New gTLDs. The Committee took the following actions:
-
Initial Protections for IGO Protections
In the Beijing Communiqué, the GAC reiterated previous advice that "appropriate preventative initial protection for the IGO names and acronyms on the provided list be in place before any new gTLDs would launch." In response to a number of issues raised by the Board, the GAC noted in the Beijing Communiqué that it is "mindful of outstanding implementation issues" and that it is committed to "actively working with IGOs, the Board, and ICANN Staff to find a workable and timely way forward. In a 6 June 2013 response letter to the GAC on the IGO GAC Advice, the ICANN Board Chairman proposed that a small number of NGPC members and ICANN staff begin a dialogue with the GAC on these issues
At its 2 July 2013 meeting, the NGPC passed a resolution confirming that the New gTLD Registry Agreement will require operators to provide appropriate preventative initial protection for the IGO identifiers. These protections will remain in place while the GAC, NGPC, ICANN Staff and community continue to actively work through outstanding implementation issues. More specifically, registry operators will implement temporary protections for the IGO names and acronyms on the "IGO List dated 22/03/2013" until the first meeting of the NGPC following the ICANN 47 Meeting in Durban. The Resolution provides temporary protections for IGOs while respecting the ongoing work on implementation issues. The IGO List is attached to the Resolution as Annex 1.
If the NGPC and GAC do not reach an agreement on outstanding implementation issues for protecting IGO names and acronyms by the first meeting of the NGPC following the ICANN 47 meeting in Durban, and subject to any matters that arise during the discussions, registry operators will be required to protect only the IGO names (and not the acronyms) identified on the GAC's IGO List.
-
Category 1 Advice
In the Beijing Communiqué, the GAC proposed Category 1 safeguard advice, which includes recommended restrictions and consumer protections for sensitive strings and regulated markets. The Category 1 Safeguard Advice is divided into three main sections. The first section provides five (5) items of advice that apply to "strings that are linked to regulated or professional sectors." The Beijing Communiqué identified a list of strings to which this advice applies. The second section provides three (3) additional pieces of advice that should apply to a limited subset of the strings noted in the GAC's list that are "associated with market sectors which have clear and/or or regulated entry requirements (such as: financial, gambling, professional services, environmental, health and fitness, corporate identifiers, and charity) in multiple jurisdictions…." The third section includes an additional requirement for applicants for the following strings: .fail, .gripe, .sucks and .wtf.
On 23 April 2013, ICANN initiated a public comment forum to solicit input on how the NGPC should address GAC advice regarding safeguards applicable to broad categories of new gTLD strings http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en.htm. The public comment forum closed on 4 June 2013. While many commenters voiced support for the Category 1 safeguard advice, many others submitting opposing comments. One overarching theme from the public comments was the need for additional clarity on the scope and intent of the Category 1 Safeguard Advice.
After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
-
New gTLD Registry Agreement
Finally, the NGPC considered the revised New gTLD Registry Agreement that will be entered into between ICANN and successful new gTLD applicants. The revised agreement is the result of several months of negotiations, formal community feedback (most recently during public comment forums initiated on 5 February 2013 on 29 April 2013), and meetings with various stakeholders and communities. The revisions include feedback from the ICANN community at the ICANN 46 Meeting on 7-11 April 2013 in Beijing as well as GAC advice issued in its Beijing Communiqué.
After considering the comments received from the community, the NGPC determined that the revised New gTLD Registry Agreement included significant improvements in response to the concerns raised by the community. The Committee also noted that in response to the GAC's Beijing Communiqué, revisions were made to Specification 11 to implement the non-Category 1 safeguard advice (i.e., safeguards applicable to all strings and Category 2 safeguards). The revisions to Specification 11 incorporate standardized language to address the safeguard advice. Applicant-specific PICs will be included on a case-by-case basis to the extent not superseded by or inconsistent with the standard PICs included to address the GAC's Beijing Communiqué.
The NGPC approved the form of the New gTLD Registry Agreement and authorized ICANN staff to take all necessary steps to implement it and to move forward with implementation of the New gTLD Program. The Agreement is attached to the Resolution as Annex 1; the complete Summary of Changes to the New gTLD Registry Agreement is attached to the Resolution as Annex 2; a redline of the current agreement as compared to the previous version dated 29 April 2013 is attached to the Resolution as Annex 3; and the Summary and Analysis of Public Comments is available at http://www.icann.org/en/news/public-comment/report-comments-base-agreement-01jul13-en.pdf [PDF, 338 KB].
All of the resolutions adopted at the 2 July 2013 NGPC meeting are posted at http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm. A table summarizing NGPC Consideration of the GAC's Beijing Advice appears below.
GAC Register #
Summary of GAC Advice
NGPC Position
NGPC Response
- 2013-04-11-Obj-Africa (Communiqué §1.a.i.1)
The GAC Advises the ICANN Board that the GAC has reached consensus on GAC Objection Advice according to Module 3.1 part I of the Applicant Guidebook on the following application: .africa (Application number 1-1165-42560)
Accept
- 2013-04-11-Obj-GCC (Communiqué §1.a.i.2)
The GAC Advises the ICANN Board that the GAC has reached consensus on GAC Objection Advice according to Module 3.1 part I of the Applicant Guidebook on the following application: .gcc (application number: 1-1936-2101)
Accept
- 2103-04-11-Religious Terms (Communiqué §1.a.ii)
The GAC Advises the Board that with regard to Module 3.1 part II of the Applicant Guidebook, the GAC recognizes that Religious terms are sensitive issues. Some GAC members have raised sensitivities on the applications that relate to Islamic terms, specifically .islam and .halal. The GAC members concerned have noted that the applications for .islam and .halal lack community involvement and support. It is the view of these GAC members that these applications should not proceed.
Accept
- 2013-04-11-gTLDStrings (Communiqué §1.c)
In addition to this safeguard advice, the GAC has identified certain gTLD strings where further GAC consideration may be warranted, including at the GAC meetings to be held in Durban. Consequently, the GAC advises the ICANN Board to not proceed beyond Initial Evaluation with the following strings : .shenzhen (IDN in Chinese), .persiangulf, .guangzhou (IDN in Chinese), .amazon (and IDNs in Japanese and Chinese), .patagonia, .date, .spa, . yun, .thai, .zulu, .wine, .vin
Accept
- Request for Written Briefing (Communiqué §1.d)
The GAC requests a written briefing about the ability of an applicant to change the string applied for in order to address concerns raised by a GAC Member and to identify a mutually acceptable solution.
Provided
Written briefing provided at
https://gacweb.icann.org/download/attachments/28278832/NGPC%20Scorecard%20of%201As%20Regarding%20Non-%C2%ADSafeguard%20Advice%20in%20the%20GAC%20Beijing%20Communique%CC%81.pdf?version=1&modificationDate=1372384291000&api=v2 [PDF, 2.68 MB]
- 2013-04-11-CommunitySupport (Communiqué §1.e)
The GAC advises the Board that in those cases where a community, which is clearly impacted by a set of new gTLD applications in contention, has expressed a collective and clear opinion on those applications, such opinion should be duly taken into account, together with all other relevant information.
Accept
- 2013-04-11-PluralStrings (Communiqué §1.f)
The GAC believes that singular and plural versions of the string as a TLD could lead to potential consumer confusion. Therefore the GAC advises the Board to reconsider its decision to allow singular and plural versions of the same strings.
Accept
- After careful consideration of the issues, review of the comments raised by the community, the process documents of the expert review panels, and deliberations by the NGPC, the NGPC determined that no changes to the ABG are needed to address potential consumer confusion specifically resulting from allowing singular and plural versions of the same strings.
- The NGPC considered several significant factors during its deliberations about whether to allow singular and plural version of the same strings. The NGPC had to balance the competing interests of each factor to arrive at a decision.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.d.
- 2013-04-11-IGO (Communiqué §1.g)
GAC reiterates its advice to the ICANN Board that appropriate preventative initial protection for the IGO names and acronyms on the provided list be in place before any new gTLDs would launch.
Dialogue
- The New gTLD Registry Agreement will require operators to provide appropriate preventative initial protection for the IGO identifiers. These protections will remain in place while the GAC, NGPC, ICANN Staff and community continue to actively work through outstanding implementation issues.
- If the NGPC and GAC do not reach an agreement on outstanding implementation issues for protecting IGO names and acronyms by the first meeting of the NGPC following the ICANN 47 meeting in Durban, and subject to any matters that arise during the discussions, registry operators will be required to protect only the IGO names (and not the acronyms) identified on the GAC's IGO List.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-RAA (Communiqué §2)
The GAC advises the ICANN Board that the 2013 Registrar Accreditation Agreement should be finalized before any new gTLD contracts are approved.
Accept
- 2013-04-11-WHOIS (Communiqué §3)
The GAC urges the ICANN Board to ensure that the GAC Principles Regarding gTLD WHOIS Services, approved in 2007, are duly taken into account by the recently established Directory Services Expert Working Group.
Accept
- 2013-04-11-IOCRC (Communiqué §4)
The GAC advises the ICANN Board to amend the provisions in the new gTLD Registry Agreement pertaining to the IOC/RCRC names to confirm that the protections will be made permanent prior to the delegation of any new gTLDs.
Accept
- The NGPC accepted the GAC advice.
- The Registry Agreement includes protection for an indefinite duration for IOC/RCRC names. Specification 5 of this version of the Registry Agreement includes a list of names (provided by the IOC and RCRC Movement) that "shall be withheld from registration or allocated to Registry Operator at the second level within the TLD."
- This protection was added pursuant to a NGPC resolution to maintain these protections "until such time as a policy is adopted that may require further action" (204.11.26.NG03).
- The resolution recognized the GNSO's initiation of an expedited PDP. Until such time as the GNSO approves recommendations in the PDP and the Board adopts them, the NGPC's resolutions protecting IOC/RCRC names will remain in place.
- Should the GNSO submit any recommendations on this topic, the NGPC will confer with the GAC prior to taking action on any such recommendations.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-04jun13-en.htm and http://www.icann.org/en/groups/board/documents/new-gtld-resolution-annex-1-04jun13-en.pdf [PDF, 564 KB]
- 2013-04-11-PIC SPEC (Communiqué §5, Annex 2)
The GAC requests more information on the Public Interest Commitments Specifications on the basis of the questions listed in annex II.
Provided
NGPC responses to the Annex 2 questions available at https://gacweb.icann.org/display/GACADV/2013-04-11-PICSPEC
- 2013-04-11-Safeguards 1 (Communiqué Annex 1, 1)
1. WHOIS verification and checks —Registry operators will conduct checks on a statistically significant basis to identify registrations in its gTLD with deliberately false, inaccurate or incomplete WHOIS data at least twice a year. Registry operators will weight the sample towards registrars with the highest percentages of deliberately false, inaccurate or incomplete records in the previous checks. Registry operators will notify the relevant registrar of any inaccurate or incomplete records identified during the checks, triggering the registrar's obligation to solicit accurate and complete information from the registrant.
Accept
- ICANN (instead of Registry Operators) will implement the GAC's advice that checks identifying registrations in a gTLD with deliberately false, inaccurate or incomplete WHOIS data be conducted at least twice a year.
- ICANN will perform a periodic sampling of WHOIS data across registries in an effort to identify potentially inaccurate records.
- ICANN will also maintain statistical reports that identify the number of inaccurate WHOIS records identified.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 2 (Communiqué Annex 1, 2)
2. Mitigating abusive activity—Registry operators will ensure that terms of use for registrants include prohibitions against the distribution of malware, operation of botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law.
Accept
- A provision in the proposed New gTLD Registry Agreement (as a mandatory Public Interest Commitment in Specification 11) obligates Registry Operators to include a provision in their Registry-Registrar Agreements that requires Registrars to include in their Registration Agreements a provision prohibiting Registered Name Holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences for such activities including suspension of the domain name.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 3 (Communiqué Annex 1, 3)
3. Security checks— While respecting privacy and confidentiality, Registry operators will periodically conduct a technical analysis to assess whether domains in its gTLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets. If Registry operator identifies security risks that pose an actual risk of harm, Registry operator will notify the relevant registrar and, if the registrar does not take immediate action, suspend the domain name until the matter is resolved.
Accept
- A provision in the New gTLD Registry Agreement (as a mandatory Public Interest Commitment in Specification 11) requires Registry Operators periodically to conduct a technical analysis to assess whether domains in its gTLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets.
- The provision also requires Registry Operators to maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks. Registry Operators will maintain these reports for the agreed contracted period and provide them to ICANN upon request. The contents of the reports will be publically available as appropriate.
- Because there are multiple ways for a Registry Operator to implement the required security checks, ICANN will solicit community participation (including conferring with the GAC) in a task force or through a policy development process in the GNSO, as appropriate, to develop the framework for Registry Operators to respond to identified security risks that pose an actual risk of harm, notification procedures, and appropriate consequences, including a process for suspending domain names until the matter is resolved, while respecting privacy and confidentiality.
- The language included in Paragraph 3 of the attached PIC Specification provides the general guidelines for what Registry Operators must do, but omits the specific details from the contractual language to allow for the future development and evolution of the parameters for conducting security checks. This will permit Registry Operators to enter into agreements as soon as possible, while allowing for a careful and fulsome consideration by the community on the implementation details.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 4 ((Communiqué Annex 1, 4)
4. Documentation—Registry operators will maintain statistical reports that provide the number of inaccurate WHOIS records or security threats identified and actions taken as a result of its periodic WHOIS and security checks. Registry operators will maintain these reports for the agreed contracted period and provide them to ICANN upon request in connection with contractual obligations.
Accept
- As detailed in item 13 above, ICANN will maintain statistical reports that identify the number of inaccurate WHOIS records identified as part of the checks to identify registrations with deliberately false, inaccurate or incomplete WHOIS data.
- As detailed in item 15 above, Registry Operators will be required to maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks.
- Registry Operators will maintain these reports for the agreed contracted period and provide them to ICANN upon request. The contents of the reports will be publically available as appropriate.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 5 ((Communiqué Annex 1, 5)
5. Making and Handling Complaints – Registry operators will ensure that there is a mechanism for making complaints to the registry operator that the WHOIS information is inaccurate or that the domain name registration is being used to facilitate or promote malware, operation of botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law.
Accept
- Registry Operators are required to ensure that there is a mechanism for making complaints to the Registry Operator regarding malicious conduct in the TLD.
- Section 4.1 of Specification 6 of the New gTLD Registry Agreement provides that, "Registry Operator shall provide to ICANN and publish on its website its accurate contact details including a valid email and mailing address as well as a primary contact for handling inquires related to malicious conduct in the TLD, and will provide ICANN with prompt notice of any changes to such contact details."
- Section 2.8 of the New gTLD Registry Agreement provides that a, "Registry Operator shall take reasonable steps to investigate and respond to any reports from law enforcement and governmental and quasi-governmental agencies of illegal conduct in connection with the use of the TLD."
- ICANN operates the WHOIS Data Problem Reports System <http://www.icann.org/en/resources/compliance/complaints/whois/inaccuracy-form>, which is a mechanism for making complaints that WHOIS information is inaccurate.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 6 (Communiqué Annex 1, 6)
6. Consequences – Consistent with applicable law and any related procedures, registry operators shall ensure that there are real and immediate consequences for the demonstrated provision of false WHOIS information and violations of the requirement that the domain name should not be used in breach of applicable law; these consequences should include suspension of the domain name.
Accept
- Consequences for the demonstrated provision of false WHOIS information are set forth in Section 3.7.7.2 of the 2013 RAA <http://www.icann.org/en/resources/registrars/raa/proposed-agreement-22apr13-en.pdf> [PDF, 311 KB]: "A Registered Name Holder's willful provision of inaccurate or unreliable information, its willful failure to update information provided to Registrar within seven (7) days of any change, or its failure to respond for over fifteen (15) days to inquiries by Registrar concerning the accuracy of contact details associated with the Registered Name Holder's registration shall constitute a material breach of the Registered Name Holder-registrar contract and be a basis for suspension and/or cancellation of the Registered Name registration."
- Paragraph 1 of the PIC Specification includes a requirement that Registry Operator will use only ICANN accredited registrars that are party to the 2013 RAA so that these consequences are contractually required.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 1)
1. Registry operators will include in its acceptable use policy that registrants comply with all applicable laws, including those that relate to privacy, data collection, consumer protection (including in relation to misleading and deceptive conduct), fair lending, debt collection, organic farming, disclosure of data, and financial disclosures.
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 2)
2. Registry operators will require registrars at the time of registration to notify registrants of this requirement.
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 3)
3. Registry operators will require that registrants who collect and maintain sensitive health and financial data implement reasonable and appropriate security measures commensurate with the offering of those services, as defined by applicable law and recognized industry standards.
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 4)
4. Establish a working relationship with the relevant regulatory, or industry self-regulatory, bodies, including developing a strategy to mitigate as much as possible the risks of fraudulent, and other illegal, activities.
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 5)
5. Registrants must be required by the registry operators to notify to them a single point of contact which must be kept up-to-date, for the notification of complaints or reports of registration abuse, as well as the contact details of the relevant regulatory, or industry self-regulatory, bodies in their main place of business.
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 6)
6. At the time of registration, the registry operator must verify and validate the registrants' authorisations, charters, licenses and/or other related credentials for participation in that sector
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 7)
In case of doubt with regard to the authenticity of licenses or credentials, Registry Operators should consult with relevant national supervisory authorities, or their equivalents.
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 8)
The registry operator must conduct periodic post-registration checks to ensure registrants' validity and compliance with the above requirements in order to ensure they continue to conform to appropriate regulations and licensing requirements and generally conduct their activities in the interests of the consumers they serve.
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-2 (Communiqué Annex 1, Category 2, 1)
1. Restricted Access
As an exception to the general rule that the gTLD domain name space is operated in an open manner registration may be restricted, in particular for strings mentioned under category 1 above. In these cases, the registration restrictions should be appropriate for the types of risks associated with the TLD. The registry operator should administer access in these kinds of registries in a transparent way that does not give an undue preference to any registrars or registrants, including itself, and shall not subject registrars or registrants to an undue disadvantage.
Dialogue
- Safeguards-Categories-2 (Communiqué Annex 1, Category 2, 2)
2. Exclusive Access
For strings representing generic terms, exclusive registry access should serve a public interest goal.
Accepted in part, dialogue on remainder
- For applicants seeking to impose exclusive registry access for "generic strings", the NGPC directed staff to defer moving forward with the contracting process for these applicants, pending a dialogue with the GAC.
- The term "generic string" is defined to mean "a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others."
- Exclusive registry access is defined as limiting registration of a generic string exclusively to a single person or entity and their affiliates.
- For applicants not seeking to impose exclusive registry access, a provision in the in the New gTLD Registry Agreement requires TLDs to operate in a transparent manner consistent with general principles of openness and non-discrimination.
- A PIC Specification also includes a provision to preclude registry operators from imposing eligibility criteria that limit registration of a generic string exclusively to a single person or entity and their "affiliates."
- All applicants will be required to respond by a specified date indicating whether (a) the applicant is prepared to accept the proposed PIC Specification that precludes exclusive registry access or (b) the applicant is unwilling to accept the proposed PIC Specification because the applicant intends to implement exclusive registry access.
- The NGPC will enter into a dialogue with the GAC to seek clarification on their advice with respect to exclusive registry access.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.c.
ICANN Board Approves 2013 Registry Agreement
3 July 2013
ICANN's New generic Top-Level Domain (gTLD) program has reached another milestone with passage of the 2013 Registry Agreement [PDF, 2.15 MB] (RA).
The new baseline agreement was approved by the New gTLD Program Committee of the ICANN Board of Directors.
"New gTLDs are now on the home stretch," said Fadi Chehadé, ICANN President and Chief Executive Officer. "This new Registry Agreement means we've cleared one of the last hurdles for those gTLD applicants who are approved and eagerly nearing that point where their names will go online."
Among the key points in the new Registry Agreement:
- Includes a Trademark Clearinghouse that will serve as a one-stop shop where trademark holders can protect their rights.
- Provides for a process for a rapid, efficient way to take down infringing domain names.
- Provides a procedure where trademark rights holders can assert claims directly against a registry operator for domain name abuse if that operator has played an active role in the abuse.
- Requires registry operators to have a single point of contact responsible for handling abuse complaints.
"We're getting to the point now where new gTLD applicants can see the finish line," said Akram Atallah, President of the ICANN's Generic Domains Division. "Much like the 2013 Registrar Accreditation Agreement approved by the Board last week, this new Registry Agreement is the culmination of input from a wide range of stakeholders and marks a dramatic improvement over the previous baseline agreement."
The New gTLD Registry Agreement is intended to enhance the security and stability of the Domain Name System while bolstering competition in domain name industry. The security provisions include:
- A requirement that registry operators implement Domain Name System Security Extensions (DNSSEC), reducing so-called "man-in-the-middle" attacks and spoofed DNS records.
- A requirement of enhanced WHOIS service at the registry level with a common interface, and more rapid search capabilities, facilitating efficient resolution of malicious activities.
"This isn't just a gradual step forward," said Atallah. "This is a major move that translates to far greater security protections."
To read the 2013 Registry Agreement, go here: http://newgtlds.icann.org/en/applicants/agb/agreement-approved-02jul13-en.pdf [PDF, 2.15 MB]
UPDATE: View Redline Comparing Revised Version of RyA to 29 April 2013 Version [PDF, 1.62 MB].
I am delighted to report that we have achieved yet another major milestone in empowering the New gTLD program. The NGPC has now approved the New Registry Agreement [PDF, 2.15 MB] following on the heels of the adoption of the 2013 Registrar Accreditation Agreement (RAA) a few days ago. We now have the infrastructural tools and the means to start the contracting process, and continue the march toward delegation of New gTLDs. You can view the redline version of the Agreement here [PDF, 1.62 MB].
These recent accomplishments are very significant on their own, and additionally for a variety of other reasons. As the ICANN community prepares for ICANN 47 in Durban, I sense an added level of energy and a tinge of jubilation in our community. It’s as though the summit is finally coming into view, after a long and at times exhausting voyage.
As we assemble all the moving parts that are required for the proverbial lift off, I reflect on how far we have come together and how much ground we have covered. My sincere congratulations to all the stakeholders of our community for this achievement, and gratitude for all their contributions and constructive input.
Further Reading
What industry leaders are saying about the new RA…
Jon Nevett, Donuts, Inc.
“This agreement, which requires consumer protections not present in the current namespace, reflects the hard work of ICANN, applicants, and the community, and is another step toward new gTLD delegation. Donuts looks forward to resolving — prior to the Durban meeting — the enforcement issue related to the GAC safeguards and beginning the contracting process forthwith so that we can fulfill our and ICANN’s mission to bring variety, choice and competition to the namespace.”
Jeff Neuman Neustar, Inc.
“Neustar is pleased that ICANN continues to move forward to make new gTLDs a reality. There is still a lot of work to do, and we look forward to working in good faith with ICANN staff in Durban to identify PIC enforcement mechanisms that give responsible gTLD operators the chance to compete and succeed. We think it is also critical to identify a clear path forward that avoids unreasonable delay on the applications that have been deferred.”
2 July 2013
Dr. Elham Ibrahim, the African Union Commissioner for Infrastructure and Energy, will address the welcoming session of ICANN47 on 15 July in Durban, South Africa.
The participation of the honorable Commissioner in the opening session of ICANN47 reflects the partnership between the African Union and ICANN that began at ICANN42 in Dakar, Senegal. This partnership has continued to grow and strengthen since it began in 2011, especially over the past year. The African Union has been one of the strongest supporters of ICANN's African strategy, and the results of this strategy's implementation will be shared during our Durban meeting.
Dr. Ibrahim has over thirty years of experience in electrical interconnection, energy strategy, network design and renewable energy. Prior to her position with the African Union, she served as the First Under Secretary of State in the Ministry of Electricity and Energy in Egypt, as well as the General Manager for training and promotion in Egypt's New and Renewable Energy Authority (NREA).
We are honored to have Dr. Ibrahim address the global ICANN community as it gathers in Africa.
To read more about Dr. Ibrahim, you can go to http://ie.au.int/en/commissioner/biography.
For more information about ICANN's upcoming meeting in Durban, South Africa, please visit http://durban47.icann.org.
2 July 2013
Deadline: 15 July 2013
The Affirmation of Commitments (AOC) signed by ICANN establishes ongoing reviews of ICANN's Accountability and Transparency - http://www.icann.org/en/about/agreements/aoc/affirmation-of-commitments-30sep09-en.htm. Review of ICANN's execution of core tasks is undertaken by "review teams." The second Accountability and Transparency Review Team (ATRT2) is examining ICANN's activities to ensure they are accountable, transparent, and undertaken consistent with the public interest.1
The ATRT2's activities are focused on paragraph 9.1 of the AoC where ICANN commits to maintain and improve robust mechanisms for public input, accountability, and transparency so as to ensure that the outcomes of its decision-making will reflect the public interest and be accountable to all stakeholders. The ATRT2 will make recommendations, as needed, to the ICANN Board for improvements by December 31, 2013.
As part of its review effort, the ATRT 2 now issues a Request for Proposals [PDF, 93 KB] (RfP) in order to appoint an independent expert. The purpose of this assignment is to assess the effectiveness of ICANN Generic Names Supporting Organization (GNSO) Policy Development Process (PDP) and whether the current GNSO PDP process satisfies the needs of the multi stakeholder model and Internet users.
Interested parties are invited to provide relevant background material, written methodology for execution of this task, views on the tentative timeline, a proposed budget, resumes, references and financial information about the party by 15 July 2013 -23:59 UTC to Alice E. Jansen, ICANN, Strategic Initiatives Manager at alice.jansen@icann.org.
The ATRT 2 will conduct conference calls with candidates on 22-23 July and expects to make its final selection of the independent expert on 26 July 2013.
In its examination of ICANN's activities, the ATRT 2 recently published Questions to the Community for Public Comment. The questions and the responses are available at http://www.icann.org/en/news/public-comment/atrt2-02apr13-en.htm
1 For information on the membership of ATRT and its activities including meeting schedules, agendas, minutes, etc. see https://community.icann.org/x/mQllAg.
2 July 2013
Forum Announcement:
Comment Period Opens on
Date:
2 July 2013
Categories/Tags:
- Top-Level Domains
- Policy Processes
- Transparency/Accountability
Purpose (Brief):
The treatment of country and territory names as Top Level Domains is a topic that has been discussed by the ccNSO, GAC, GNSO, ALAC and the ICANN Board for a number of years.
Issues regarding the treatment of representations of country and territory names have arisen in a wide range of ICANN policy processes, including the IDN fast track, IDN ccPDP, and the development of the new gTLD Applicant guidebook.
It is in recognising the absence of the importance of country and territory names to a wide range of stakeholders, that the ccNSO Council convened the Study Group on the use of Country and Territory Names. The Study Group has completed its work and is now seeking feed-back and input from the ICANN community.
Public Comment Box Link:
http://www.icann.org/en/news/public-comment/unct-final-02jul13-en.htm
brightcove.createExperiences();
Many believed it couldn’t be done- achieve consensus on a solution to the WHOIS issue, after nearly a decade of debate in the ICANN community. In fact, that is what the Expert Working Group (EWG) has done in a remarkably short amount of time.
When the Board embarked on this effort to produce the next generation of data directory services to replace the current WHOIS system, it did so by bringing together a widely divergent group of industry experts, as well as some seasoned executives from outside the ICANN community. Together they have produced an Initial Report [PDF, 1.7 MB] that provides a solid foundation for replacing WHOIS by identifying the permissible purposes for registration data, and recommending the design features and principles to keep in mind when developing a next generation registration directory service. The EWG also proposed a radically new model for the ICANN community to consider, referred to as the Aggregated Registration Data Service (ARDS), that demonstrates how such a new system might be deployed.
The EWG is very interested in your views on its Initial Report [PDF, 1.7 MB], to be considered as it finalizes its recommendations after the Durban Meeting. To help you understand their current thinking, members of the EWG have recorded a video, or you can attend the EWG’s Webinar on July 8th, or public session at the Durban Meeting on July 15th. You can also answer the discussion questions posed by the EWG to solicit community input on open areas.
Did the EWG get it right? Is the ARDS the best replacement for WHOIS? Make sure to share your views on this important development.
We are finally there. After a long and extensive period of discussions, negotiations and revisions, the 2013 Registrar Accreditation Agreement [PDF, 913 KB] is finally a reality. Here is a summary of the changes [PDF, 158 KB] made since the RAA was posted for public comment on April 22.
This accomplishment marks yet another significant milestone in the process of empowering New gTLDs and provides a robust mechanism for continued improvements for the entire DNS ecosystem. I dare say that for the first time we have an agreement that incorporates many significant provisions that our stakeholders have been asking for.
Yet, much work still lies ahead. This new agreement requires many new services and systems to be put in place by the industry. ICANN is fully committed to facilitate trainings and webinars to help the global Registrar community better understand these new requirements. To that end, we are planning onsite trainings in China to be conducted in Chinese, as well as in Los Angeles, sometime in August. We plan to do similar trainings in other regions as necessary.
Once again, I salute the Registrar Negotiating Team for all of its contributions to this process and for being true partners in accomplishing this monumental task. These dedicated individuals delivered on their commitment to help raise the industry’s standards for the benefit of the community. In short, a job well done!
What industry leaders are saying about the new RAA…
James Bladel, GoDaddy
“The new 2013 RAA represents a milestone achievement for our industry, thanks to almost two years of work on the part of Registrar Negotiators and ICANN Staff. But finalizing the language of the agreement was actually the easy part, and now the real work of implementing the new RAA can begin. Registrants and customers should see these changes in the coming months.”
Volker Greimann, Key-Systems GmbH
“The approval of the 2013 RAA by the ICANN board clears one of the final obstacles for the long-awaited launch of the new gTLDs. The changes contained in the new agreement will have a lasting and noticeable effect on the domain name industry and the registration process in general for all registrations in the existing and the new generic top level domains. Registrars and ICANN have worked hard to create this document in response to the problems put before us and we appreciate the willingness of ICANN to work with registrars in addressing and implementing them in a realistic and workable manner. Going forward, we will continue to work together to fine-tune and expand upon the existing agreement as the new RAA is intended and designed to be a living document.”
Rob Hall, Momentous
“The new registrar agreement clears that way for market success in the launching of new Internet domain names. By committing to a single set of requirements, businesses — registrars and registries alike — can now more decisively make investment and business decisions with winners and losers determined by those actions, not by rule or regulation.”
Jeff Eckhaus, Demand Media
“The 2013 RAA is the product of a great deal of work by both Registrars and ICANN, but the direction of the changes were driven directly from the ICANN Community. With input from the GAC, Law Enforcement, GNSO and the public comment system, this negotiation had the feeling of everyone in the room and their voices heard, but above all we always worried about the most important person, the registrants of domain names.”
27 June 2013
On 25 June 2013, the ICANN Board New gTLD Program Committee (NGPC) had its sixth meeting to discuss the GAC Beijing advice on New gTLDs. The Committee adopted two resolutions concerning portions of the GAC's Safeguard Advice. It also adopted a resolution regarding the GAC's advice on singular and plural versions of the same string. These resolutions are posted at http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm.
The NGPC will meet again on 2 July 2013. The agenda is available at http://www.icann.org/en/groups/board/documents/agenda-new-gtld-02jul13-en.htm. Among other things, the NGPC is expected to consider resolutions regarding the proposed registry agreement and IGO names and acronyms.
The New gTLD evaluation and objection processes remain on track. ICANN has posted initial evaluation results on approximately one half of the applications received. The remaining evaluations are expected to be completed on time. The NGPC continues to prioritize its work in order to allow the greatest number of applications to move forward as soon as possible.
|
