Public participation site

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:

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

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

3. 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:

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

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

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

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

• Applicant was permitted to withdraw or seek relief according to ICANN's accountability mechanisms subject to the appropriate standing and procedural requirements.
• 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].

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

• Applicant was permitted to withdraw or seek relief according to ICANN's accountability mechanisms subject to the appropriate standing and procedural requirements.
• 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].

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

• Pursuant to the requirements of Section 3.1.ii of the AGB, NGPC and GAC members will enter into a dialogue on this matter in Durban.
• 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].

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

• ICANN has allowed evaluation and dispute resolution processes to go forward, but will not enter into registry agreements with applicants for the identified strings for now.
• NGPC expects GAC to consider these applications further in Durban.
• 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].

5. 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]

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

• Criterion 4 for the Community Priority Evaluation process takes into account "community support and/or opposition to the application" in determining whether to award priority to a community application in a contention set.
• If a contention set is not resolved by the applicants or through a community priority evaluation then ICANN will utilize an auction as the objective method for resolving the contention.
• 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].

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

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

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

• The Board approved the 2013 RAA at its 27 June 2013 Meeting.
• The 2013 RAA requires all new gTLD registries to only use 2013 RAA registrars.
• 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]

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

• The GAC Principles have been shared with the Expert Working Group.
• 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]

11. 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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• As noted above, the requested 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.
• See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.

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

• RyA Adopted by the NGPC [PDF, 1.46 MB]
• Redline Comparing Revised Version of RyA to 29 April 2013 Version [PDF, 1.62 MB]
• Summary of Changes to the RyA [PDF, 898 KB]
• Report of Public Comments on the 29 April 2013 RyA [PDF, 338 KB]

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.

ICANN bylaws mandate periodic reviews of the organisation's main structures. For the body that handles gTLD policy making, the GNSO, that review was due to start in February this year.

The review appears much needed. The GNSO Council is the manager of the gTLD policy process and as such, it has representatives of all GNSO groups. But according to repeated statements by many of those representatives, the Council's current bicameral structure has not lived up to expectations.

This two-house structure is the result of the last review and the recommendations that came out of it. Each GNSO Council house is divided in two sub-groups called stakeholder groups (SGs). But that's where the symmetry ends.

In the contracted parties house, the two SGs are the only entities. So the registry SG and the registrar SG are often able to find areas of common interests.

But in the non contracted parties house, the 2 SGs are made up of 5 sub-groups, called constituencies. Seeing eye to eye is not always so easy for the commercial SG (the business, internet service providers and intellectual property constituencies) and the non commercial SG (the non commercial users and the not for profit organizations constituencies).

The review would help evaluate whether the GNSO's current structure is well suited to ICANN's changing environment and policy making needs in a world that has already been dramatically changed by the new gTLD program. Its results would pave the way for any changes that are deemed necessary.

Yet it seems the review is unlikely to start anytime soon. On June 12, in an email to the GNSO Council, ICANN staff explained that the "Board Structural Improvements Committee (SIC) is considering postponing the GNSO Review (potentially for a year) while it evaluates options for streamlining the organizational review process and considers relevant discussions involving development of a new ICANN Strategic Plan. The SIC expects to make a recommendation to the Board in Durban and staff will keep you apprised of these developments."

Those who feel the current bicameral structure is unbalanced will not be happy to hear the GNSO may not be reviewed for another year. It's also unclear how such a decision, should it be confirmed, would fit with the ICANN bylaws requirement which states that "reviews shall be conducted no less frequently than every five years, based on feasibility as determined by the Board." (Article IV, section 4).

Obviously allowing the Board to determine feasibility gives the SIC the leeway to push the review back. But can a 2 year delay still be considered reasonable?

Written by Stéphane Van Gelder, Chairman, STEPHANE VAN GELDER CONSULTING

Follow CircleID on Twitter

More under: ICANN, Internet Governance, Top-Level Domains

Earlier this week dns.be launched Internationalized Domain Names (IDNs).

The Belgian registry opted to support the accented characters for Dutch, French and German. In so doing they've also ended up providing support for other European languages, such as Swedish, Finnish and Danish.

The characters supported are below:

ß*àáâãóôþüúðæåïçèõöÿýòäœêëìíøùîûñé

The registry reported quite a bit of interest in the launch with over 3000 IDN domains being registered in the first hour. That number had practically doubled by close of business on the first day.

So what domains are people registering?

The most popular requests were:

1. café.be
2. météo.be
3. hôtels.be
4. bébé.be
5. crédit.be
6. hôtel.be
7. één.be
8. italië.be
9. cinéma.be
10. château.be

The registry announced that close to 80% of the IDN domains registered were registered to Belgian residents, thus reinforcing the view that IDNs were in demand from the local market.

More details here.

Written by Michele Neylon, MD of Blacknight Solutions

Follow CircleID on Twitter

More under: Domain Names, Multilinguism

The success or failure of public cloud services can be measured by whether they deliver high levels of performance, security and reliability that are on par with, or better than, those available within enterprise-owned data centers. To emphasize the rapidly growing cloud market, IDC forecasts that public cloud IT spending will increase from $40 billion in 2012 to $100 billion in 2016. To provide the performance, security and reliability needed, cloud providers are moving quickly to build a virtualized multi-data center service architecture, or a "data center without walls."

This approach federate the data centers of both the enterprise customer and cloud service provider so that all compute, storage, and networking assets are treated as a single, virtual pool with optimal placement, migration, and interconnection of workloads and associated storage. This "data center without walls" architecture gives IT tremendous operational flexibility and agility to better respond and support business initiatives by transparently using both in-house and cloud-based resources. In fact, internal studies show that IT can experience resource efficiency gains of 35 percent over isolated provider data center architectures.

However, this architecture is not without its challenges. The migration of workload between enterprise and public cloud creates traffic between the two, as well as between clusters of provider data centers. In addition, transactional loads and demands placed on the backbone network, including self-service customer application operations (application creation, re-sizing, or deletion in the cloud) and specific provider administrative operations can cause variability and unpredictability to traffic volumes and patterns. To accommodate this variability in traffic, providers normally would have to over-provision the backbone to handle the sum of these peaks — an inefficient and costly approach.

Getting to Performance-on-Demand

In the future, rather than over-provisioning, service providers will employ intelligent networks that can be programmed to allocate bandwidth from a shared pool of resources where and when it is needed. This software-defined network (SDN) framework consists of virtualizing the infrastructure layer — the transport and switching network elements; a network control layer (or SDN controller) — the software that configures the infrastructure layer to accommodate service demands; and the application layer — the service-creation/delivery software that drives the required network connectivity — e.g. the cloud orchestrator.

SDN enables cloud services to benefit from performance-on-demand

The logically-centralized control layer software is the lynchpin to providing orchestrated performance-on-demand. This configuration allows the orchestrator to request allocation of those resources without needing to understand the complexity of the underlying network.

For example, the orchestrator may simply request a connection between specified hosts in two different data centers to handle the transfer of 1 TB with a minimum flow rate of 1 Gb/s and packet delivery ratio of 99.9999% to begin between the hours of 1:00 a.m. and 4:00 a.m. The SDN controller first verifies the request against its policy database, performs path computation to find the best resources for the request, and orchestrates the provisioning of those resources. It subsequently notifies the cloud orchestrator so that the orchestrator may initiate the inter-data center transaction.

The benefits to this approach include cost savings and operational efficiencies. Delivering performance-on-demand in this way can reduce cloud backbone capacity requirements by up to 50 percent compared to over-provisioning, while automation simplifies planning and operational practices, and reduces the costs associated with these tasks.

The network control and cloud application layers also can work hand-in-hand to optimize the service ecosystem as a whole. The network control layer has sight of the entire landscape of all existing connections, anticipated connections, and unallocated resources, making it more likely to find a viable path if one is possible — even if nodes or links are congested along the shortest route.

The cloud orchestrator can automatically respond to inter-data center workload requirements. Based on policy and bandwidth schedules, the orchestrator works with the control layer to connect destination data centers and schedule transactions to maximize the performance of the cloud service. Through communication with the network control layer, it can select the best combination of connection profile, time window and cost.

Summary

Whether built with SDN or other technologies, an intelligent network can transform a facilities-only architecture into a fluid workload orchestration workflow system, and a scalable and intelligent network can offer performance-on-demand for assigning network quality and bandwidth per application.

This intelligent network is the key ingredient to enable enterprises to inter-connect data centers with application-driven programmability, enhanced performance and at the optimal cost.

Written by Jim Morin, Product Line Director, Managed Services & Enterprise at Ciena

Follow CircleID on Twitter

More under: Cloud Computing, Data Center

Internet users are willing to navigate to, use, and trust new web addresses that will be flooding the Internet later this year, and brand name websites will carry more weight with Internet users than generic sites.

These are among the results of a public opinion survey commissioned by FairWinds Partners, a consultancy that specializes in domain name strategy.

The poll also found that the owners and operators of these new addresses should be technically prepared or risk driving away or losing traffic intended for their sites.

Hundreds of new gTLDs are expected to roll out later this year and a total of approximately 1,400 could be operational in a year or so.

Internet users are untethered to the past, broadminded, and based on this survey, receptive to new ways of doing things. Respondents prefer to take control of their Internet experiences, expect to find their favorite brands at intuitive sites, and will adapt to the new addresses without too much difficulty.

The online poll of 1,000 Internet users found that consumers have an open mind about new gTLDs even though they remain a largely unknown and abstract concept:

• 57 percent said they had no preference or would be willing to navigate to a new gTLD media website, while 43 percent said they would stick with a .COM media site
• 52 percent said they had no preference or would be willing to shop on a new gTLD, compared to 48 percent who preferred .COM
• 53 percent said they had no preference or would be willing to bank with a financial institution operating a new gTLD site, compared to 47 percent who would stick with .COM

The poll found that consumers trust the brands that they know and likely would embrace brand name gTLDs without much hesitation:

• 14 percent of respondents navigating to a media site would prefer a brand name site, such as .CBS compared to 9 percent who preferred a generic such as .NEWS
• 17 percent of respondents shopping online would navigate to a brand name site compared to 9 percent who preferred a generic gTLD, such as .SHOES
• 15 percent of those banking online said they would prefer a brand gTLD, for example .CITI compared to 10 percent who opted for a generic site such as .LOANS

Brand owners — whether they applied for a new gTLD or not — can draw valuable lessons from FairWinds' research. Internet users indicated they expect to see their favorite brands adopt and use new gTLDs and that poor online user experiences will lead to missed revenue and opportunities for brand owners.

The better brand owners understand consumer behavior, the better prepared they will be to optimize use of their new gTLDs and remain competitive in the new Internet space.

The poll, conducted by InsightsNow! in April, questioned Internet users between the ages of 13 and 64. This is the second in a series of polls FairWinds is undertaking to gauge the impact of new gTLDs on consumers and businesses. The first FairWinds market research survey may be read here.

Written by Josh Bourne, Managing Partner at FairWinds Partners

Follow CircleID on Twitter

More under: Domain Names, Top-Level Domains

National Cable & Telecommunications Association (NCTA) Cable Show Washington, DC – June 10-12, 2013 (Photo: NCTA)I had the opportunity this week to take part in the National Cable & Telecommunications Association (NCTA) Cable Show — a traveling show in the U.S. that took place in Washington, DC, this year. The Cable Show is one of the largest events of the cable industry and this year was also my first time attending.

In the U.S. capital, it's difficult to avoid the topic of politics and its effects on the telecommunications industry. This was especially true during The Cable Show in light of recent news around communication monitoring, wiretapping, and how far it's going. But while this was a hot topic on the minds of attendees, politics for the most part was left at the door when it came to the exhibition floor.

As expected, a wide variety of exhibitors brought their best efforts to The Cable Show, displaying tools, software, services, and content. From mega-sized displays showcasing the latest TV shows and series; to rubbing shoulders with famous actors, business celebrities, and reality TV cast members; to viewing the very precise equipment and software that allows all this to come true — this show had it all.

The number of companies in attendance and their technology categories are useful in identifying trends for where the cable industry is heading:

• Content was definitely at the core of the show, with 81 exhibitors involved in cable programming
• Multi-screen content and HDTV were also well represented, with more than 40 vendors each
• IPTV followed closely, with 37 exhibiting companies
• Mobile apps and cloud services also had a presence

This focus on content and new strategies indicates a disruption in traditional cable TV, the strengthening of over-the-top (OTT) services, and the adoption of IPTV. It also raises the question — how long before Quadrature Amplitude Modulation (QAM), which is the format used by cable providers to transmit content, is replaced by IP?

Even with all this on site, two displays placed strategically side-by-side caught my attention. One was called the "Observatory" and celebrated the history and evolution of the cable industry and its technologies. The other, "Imagine Park," looked at the path ahead of us. What is the cable industry working on to stay relevant, when competition is continuously increasing?

Technology is all about evolution and creating solutions to problems. That said, one cannot simply focus on the future and ignore the past, which is why these displays were so effective. It's good to see that someone is thinking of that — celebrating how far the cable industry has come and how far it will continue to take us.

Written by Rick Oliva, Sales Support Engineering Manager at Incognito Software

Follow CircleID on Twitter

More under: Access Providers, Broadband, IPTV, Telecom

The world is just waking up to the fact that the Internet Corporation for Assigned Names and Numbers (ICANN) has been accepting applications for new generic top-level domains, or gTLDs, since 2012 and that hundreds of these gTLDs have already been approved through Initial Evaluation, with more being approved every week. It is expected that the new extensions will begin appearing online in the second half of 2013, and over 1,000 new extensions will likely be added to the Internet by 2014.

But if you're reading this, you've known this for a long time. In fact, you may have just gotten word that your application is approved.

Congratulations! Awesome news… but, what now?

You've put all of this time, money and effort into getting a valuable domain extension, but even if your application has been approved, there is still a lot to be done before you're able to go out and start marketing and selling. Consider taking this time to hone in on your strategy and prepare for a successful launch.

You're not alone if this is the first time you, or your company, has launched a TLD — after all, ICANN has controlled the Doman Name System very tightly until now. So how do you know what to expect next? Once you've gotten the "go ahead," how do you know where you should focus your efforts to launch with a big splash and finally begin generating revenue?

As a company that has helped launch TLDs in the past, and as a neutral observer in the new TLD process (i.e. we did not apply for any TLDs of our own), here are a few tips that Sedo has gained over the last ten plus years in the industry.

When developing a launch strategy, it's important to place significant emphasis on your registry's premium names. Obviously they're the most valuable, so selling a few good names up front has the potential to jump start revenue. In addition, getting a few premium names in the hands of end users that have aggressive marketing plans (or budgets) is free advertising for your registry and could drive general interest. With that in mind, here are five things you need to think about when preparing your premium sales and auction strategy.

1. Data Gets You Started; Not All Premium Lists Are Created Equal – Identifying your most valuable domain assets is one of the first things you should do. But, at the same time, as you create a list of premium addresses, think about which ones you may want to place on reserve for later sales. Put simply, you need to know which possible addresses will be worth more to you than the others. You have one chance to do this correctly — and you don't want to leave money on the table or let a potential "category killer" slip through the cracks because you didn't correctly identify the opportunities in front of you.

A historical view is important in order to accurately crunch the numbers. What has been popular in the past? What types of domains have consistently sold or increased in value? Which ones have decreased? How about international opportunities — have you considered what domains wouldn't be successful in North America, but might be of huge interest in other parts of the world? What non-English domains could be valuable with your TLD?

History, as they say, offers lessons, and without access to historical data to make your decisions you will already be at a disadvantage. You need to use every advantage possible to ensure that you get the best possible list, so you don't miss out on potential revenue.

2. Auction Everything? Or Develop a Sales Strategy? Auctions are a good way to generate revenues quickly. However, many times the highest sale prices don't come in an auction. This is because it can be difficult for the 'perfect' buyer(s) to know that the auction is happening at X date. Many registries are neglecting the idea of using a longer term approach, including sales distribution channels and premium domain marketplaces.

It is important to understand, however, that there is no "one-size-fits-all" way to sell domains under your TLD:

• It's important to actively look for strategic deals early on, via the Brokerage and Business Development of your premium domains. Your focus should be finding end users that will develop, use and actively market their company or product under your new TLD.

• All new TLDs must hold a Sunrise period to give trademark holders an opportunity to pre-register related names. Sunrise is a key opportunity for early cash flow, but you need to properly drive awareness of when the period will begin and end and identify potential leads.

• A Landrush period is another excellent way to secure cash flow for your extension. It's customary to hold a Landrush so anyone can submit an application to get early access to the domains they really want. But did you know a Landrush is not something that's mandated by ICANN? It's optional, so it's worth carefully considering the benefits (quick cash flow, free publicity from usage of the domain) and drawbacks (potential for domain value to increase if extension is successful) to your new registry. Competition and conflict auctions give some high demand domains a strong chance at very high values (higher than you may ever have expected).

• Auctions are a key element to your success as well – and to auction domains successfully, you need to have global reach, a way to weed out fraudulent bidders and the international expertise to make sure the widest audience possible can bid. A good thing to remember is that there is a huge appetite for English language domains outside of North America, so make sure you can reach those buyers globally!

3. Take Your Marketing Strategy Seriously – Businesses today understand the power of a good domain name. Whether a premium "category killer" name or a company's own proper name, the right domain makes a company easy to find and helps it stand out in searches. Businesses will want to get in on names they may have had to pay six- or seven-figure sums for as a .com, or names that line up with their existing or planned products. This is why you need to start marketing now. Where is my market and how can I reach it?

The first step is developing a consistent message that will connect with your most valuable audience, be it a specific audience like skiers (.ski, for example), or a general one like business technology users (.web, for example). When it comes to executing, stick to that message across all channels to really drive it home. You need to take marketing seriously and pick your strategy wisely — and early.

4. Choose Your Registrar Distribution Strategy – Target registrars that make the most sense for distributing your new gTLD. You want to look for global reach and areas of activity — in short, who do I need to work with to reach the greatest amount of potential buyers in the shortest amount of time?

Registrars may actually come into the picture when you're considering premium name sales too. Many registrars are not set up to sell premium domains, while others have joined premium networks that have been in place for years, enabling end users that are looking for a "regularly priced" name to also see an option for a premium name that may suit them better. When choosing registrars and premium sales partners, it's worth looking into synergies between the two so all your domains get the best visibility in front of potential buyers. When doing so, make sure the partner you choose will act as a true partner, helping with launch, promotion and everything in between.

5. Data Keeps Your TLD Strong; Build Valuable Market Data and Harness it Moving Forward – Data is key, which is why it bookends a solid strategy. If you're successful with the above and have a solid sales and marketing strategy in place, then this will be a repeatable process and you'll want to track sales and customer data. It's important to retain and refine your data to help you grow as the TLD grows. A strong partner can help you to do this and re-market or continue marketing to the same groups in a way that keeps your premium domain strategy fresh.

The planning phase that you enter as soon as your application makes it through initial evaluation — if not sooner — is a critical period that will ultimately determine whether your new gTLD is a success or a failure. There are several steps that need to be undertaken correctly, from identifying which domains will be the most valuable under your new extension, to making sure that you find the audience most likely to purchase them. Taking the extra time to consider these steps carefully and begin executing on them immediately will give you a lasting advantage over other new gTLDs as they are approved and released.

Written by Kathy Nielsen, Head of Business Development, New gTLDs, Sedo

Follow CircleID on Twitter

More under: ICANN, Top-Level Domains

AGNA COM Exhibition and Congress 4-6 June 2013, Cologne/Germany (Photo: AGNA COM)The Association of German Cable Operators' annual trade show has a new name. Europe's principal cable industry exhibition and convention was previously known as ANGA Cable, but last week (June 4-6, 2013), the show launched as ANGA COM. This new title — an abbreviation of communication — highlights how the convergence of technologies and networks is blurring the line between cable operators and other communication and entertainment services providers.

This new focus was reflected in the many service-oriented sessions centered on broadband, video, and all forms of entertainment delivered to consumers via various modes of access technologies. The annual convention in Cologne, Germany, brought together broadband, cable, and satellite operators, as well as their vendor partners. For the first time, major telcos Deutsche Telekom and Vodafone were invited and took to the stage to discuss trends, technologies, and how broadband is working to deliver content.

Germany is a major player in the cable industry and holds the lion's share of cable homes in Europe, with 18 million households subscribed to cable. Digital transition has helped drive cable adoption, and today, about half of all German cable households use digital TV packages offered by broadband cable, especially HDTV, VOD, DVR, and TV sets with integrated digital receivers. The German cable industry is poised for further growth, with Europe's largest cable operator, UPC — which operates cable services in 13 European countries — citing Germany as its "growth engine" and the company's CEO stating that some 40% of the UPC's growth comes from this country.

Of course, cable faces fierce competition in Europe, as it does elsewhere in the world. Recent research from IHS Screen Digest shows that during the five-year period from 2007 to 2012, European cable operators lost 1.4 million subscribers. So where did the growth come from and why did convention attendees seem so upbeat about cable's future, as evidenced by the show's record number of 16,000 attendees and 450 exhibiting companies? The fact is, it's not all doom and gloom. The same IHS research shows that cable actually gained 17.8 million more revenue-generating units (RGU) during the same five year period that it lost subscribers. RGU drives total revenue growth and is a positive sign for an industry facing fierce competition from traditional telcos, satellite, and OTT players.

So, what's fueling this RGU growth? There are a few factors at play here:

• Digital transition
• "Triple-play" or bundling of data, voice, and video
• The multitude of new, value-added services

Value-added services have been made possible by the growing number of available consumer devices — tablets, laptops, PCs, and smartphones. These new services include home security and Wi-Fi, both in and around the house, as well as in public areas. Multi-screen services are also enabling cable operators to offer OTT-like, proprietary video services.

These offerings are becoming essential as consumers demand easy access to content as they move from room to room inside the home, as well as outside in public places such as stadiums, theaters, and shopping malls. It's not surprising, then, that multiscreen was a hot topic at ANGA COM, along with the usual topics of fiber expansion, IPTV, video on demand, smart TV, software solutions, and consumer electronics.

For an uninterrupted multi-screen experience, consumers need to be able to easily access content across devices, and device provisioning and service activation should occur seamlessly. This enables customers to enjoy the same quality of experience across multiple devices, both inside and outside the home. At the same time, service providers need to be aware of security concerns associated with the multi-device consumption of content — particularly security of content and consumer privacy.

Operators are also turning their attention to the monetization of services associated with multiple-device use. Clearly, the multi-screen experience is changing the dynamics of customer services and technical support. Consumers want ease of use and an uninterrupted experience, where they can simply order a service that is then provisioned so quickly that they don't even realized it's happened, and everything works without any issues. For operators, this type of experience requires network reliability and for customer service representatives (CSRs) to have all the necessary information and tools at their fingertips for fast issue resolution.

The demand for quality of experience puts pressure on service providers to understand subscriber usage behavior patterns. Solutions from vendors like Incognito offer operators ways to construct meaning out of the massive amount of bandwidth utilization data that they accumulate, and enable them to use that intelligence to improve the user experience.

ANGA COM provided an excellent opportunity for us to catch up with customers and partners, and strategize ways to take advantage of new technologies to provide a better service for customers and their subscribers. Bring on ANGA COM 2014!

Written by Will Yan, Senior VP, Worldwide Sales at Incognito Software

Follow CircleID on Twitter

More under: Broadband, IPTV

In an open letter published today, Google has asked the U.S. Attorney General and the Federal Bureau of Investigation for more transparency regarding national security request data in light of the NSA data collection controversy. The letter, signed by David Drummond, Google's Chief Legal Officer, states in part:

"We have always made clear that we comply with valid legal requests. And last week, the Director of National Intelligence acknowledged that service providers have received Foreign Intelligence Surveillance Act (FISA) requests.

Assertions in the press that our compliance with these requests gives the U.S. government unfettered access to our users' data are simply untrue. However, government nondisclosure obligations regarding the number of FISA national security requests that Google receives, as well as the number of accounts covered by those requests, fuel that speculation.

We therefore ask you to help make it possible for Google to publish in our Transparency Report aggregate numbers of national security requests, including FISA disclosures — in terms of both the number we receive and their scope. Google's numbers would clearly show that our compliance with these requests falls far short of the claims being made. Google has nothing to hide."

Follow CircleID on Twitter

More under: Internet Governance, Law, Policy & Regulation, Privacy

In an open letter published today, Google has asked the U.S. Attorney General and the Federal Bureau of Investigation for more transparency regarding national security request data in light of the NSA data collection controversy. The letter, signed by David Drummond, Google's Chief Legal Officer, states in part:

"We have always made clear that we comply with valid legal requests. And last week, the Director of National Intelligence acknowledged that service providers have received Foreign Intelligence Surveillance Act (FISA) requests.

Assertions in the press that our compliance with these requests gives the U.S. government unfettered access to our users' data are simply untrue. However, government nondisclosure obligations regarding the number of FISA national security requests that Google receives, as well as the number of accounts covered by those requests, fuel that speculation.

We therefore ask you to help make it possible for Google to publish in our Transparency Report aggregate numbers of national security requests, including FISA disclosures — in terms of both the number we receive and their scope. Google's numbers would clearly show that our compliance with these requests falls far short of the claims being made. Google has nothing to hide."

Follow CircleID on Twitter

More under: Internet Governance, Law, Policy & Regulation, Privacy