ICANN announcements
News and Announcements from ICANN.org
Updated: 40 min 12 sec ago
Mon, 2013-07-15 10:59
Strategy Panels Unveiled at ICANN 47 in Durban
15 July 2013
During today's opening ceremony of ICANN 47 in Durban, South Africa, President and CEO Fadi Chehadé announced the creation of five new ICANN Strategy Panels that will serve as an integral part of a framework for cross-community dialogue on strategic matters. The ICANN Strategy Panels will convene subject matter experts, thought leaders and industry practitioners to support development of ICANN's strategic and operational plans, in coordination with many other global players, and will be comprised of up to seven members including the chair for an anticipated one-year timeframe.
Designed to conduct work in critical strategic areas identified by the community, Board and staff, the ICANN Strategy Panels will build on public input being generated to inform a new, overarching vision and five-year strategic plan, and subsequent operating plan, for the organization. Advisory in nature, the ICANN Strategy Panels will report to Chehadé; will operate in a manner consistent with ICANN's commitment to transparency and accountability; and will channel all views, guidance and advice produced into the standard community and Board processes that guide ICANN's activities.
In its fourteen-year history, ICANN has grown to reflect a changing landscape of continued innovation, interconnectedness, and unprecedented growth in the DNS ecosystem, one that transcends groups and borders to serve the public interest. Yet, the Internet is at a critical inflection point as billions of new people are expected to join the global network in the next few years and as the nature of its usage matures dramatically. With this in mind, the ICANN Strategy Panels are expected to help catalyze transformation and advance ICANN's role in the context of a dynamic, increasingly complex global environment.
Schedules and Operations
The ICANN Strategy Panels will conduct their activities, starting in September 2013, primarily online and through conference calls, although face-to-face meetings are expected to take place according to the needs of each panel. The ICANN Strategy Panels will also provide public updates on their progress that will be linked to ICANN's overall strategic and operational planning activities. Dedicated ICANN executive liaisons have been assigned to and will support each of the ICANN Strategy Panels throughout the process.
Members and Objectives
The ICANN Strategy Panels will focus specifically on identifier technology innovation; ICANN's role in the Internet organizations' ecosystem; ICANN multistakeholder innovation; the public responsibility framework; and the role of ICANN in the future of Internet governance. Chairs who will lead the panels in their respective concentrations and who will guide the panels in their groundbreaking efforts have been identified; however, qualified individuals interested in serving as committee members are still being sought. Potential panel members need not originate directly from ICANN structures, but should have a deep understanding of and concern for the work being undertaken by ICANN, and an ability to think strategically, globally, and creatively about the challenges inherent in the ICANN Strategy Panels' mandate. Interested individuals should send their resume/CV to the email addresses affiliated with each of the specialty areas by 29 July 2013. Members will be selected by ICANN's President & CEO, in coordination with each ICANN Strategy Panel Chair.
Strategy Panel on Identifier Technology Innovation
Chair: Paul V. Mockapetris
Contact: itipanel@icann.org
Key Deliverables:
• Engage with the ICANN community and public on technology matters;
• Develop a technology roadmap for DNS and other identifiers; and
• Provide a technology roadmap for ICANN technical and security operations, including best practice recommendations and reference systems.
Strategy Panel on ICANN's Role in the Internet Organizations' Ecosystem
Chair: Vinton G. Cerf
Contact: ioepanel@icann.org
Key Deliverables:
• Facilitate review of the assumptions, linkages and frameworks that underlie ICANN's responsibilities in the current Internet ecosystem;
• Seek insights on ways to maintain and enhance ICANN's stewardship in an evolving ecosystem; and
• Cultivate thought leadership on ways in which ICANN can serve a complex set of Internet constituencies.
Strategy Panel on ICANN Multistakeholder Innovation
Chair: Beth Simone Noveck
Contact: msipanel@icann.org
Key Deliverables:
• Examine how Internet policy related to unique identifiers might be best managed in the future;
• Propose new models for broad, inclusive engagement, consensus-based policymaking and institutional structures to support such enhanced functions; and
• Design processes, tools and platforms that enable the global ICANN community to engage in these new forms of participatory decision-making.
Strategy Panel on the Public Responsibility Framework
Chair: Nii Quaynor
Contact: prfpanel@icann.org
Key Deliverables:
• Propose ICANN's role and five-year strategic objectives and milestones for promoting the global public interest vis-à-vis ICANN's mission and core values and for building out the base of internationally diverse, knowledgeable and engaged ICANN stakeholders, especially within the developing world;
• Propose a framework for implementation of ICANN's role, objectives and milestones for promoting the global public interest, building capacity within the ICANN community, and increasing the base of internationally diverse, knowledgeable and engaged ICANN stakeholders; and
• Provide advice on programs and initiatives that help achieve the above objectives.
Strategy Panel on the Role of ICANN in the Future of Internet Governance
Chair: TBD
Contact: figpanel@icann.org
Key Deliverables:
• Provide a set of guiding principles to ensure the successful evolution of ICANN's transnational multistakeholder model in cooperation with national and international bodies;
• Propose a roadmap for evolving and globalizing ICANN's role in the Internet governance ecosystem in consultation with global players; and
• In coordination with the many other global players and ICANN stakeholders, propose a framework for implementation of ICANN's role, objectives and milestones in global Internet governance.
As the ICANN Strategy Panels get underway, additional information will be available via ICANN's strategic planning portal.
Sat, 2013-07-13 14:58
13 July 2013
Deadline: 19 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 issued a Request for Proposals [PDF, 93 KB] (RfP) on 2 July 2013 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.
On 2 July, interested parties were 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. To provide bidders with sufficient time to prepare and compile their responses, the Review Team now extends the response deadline to 19 July 2013 – 23:59 UTC.
The ATRT 2 will conduct conference calls with candidates on 25-26 July 2013 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.
Thu, 2013-07-11 23:53
11 July 2013
Today, ICANN takes the next step in the implementation of the IDN Root Zone Label Generation Rules Procedure by publishing the Call for Generation Panels to develop Root Zone Label Generation Rules [PDF, 150 KB].
The IDN Root Zone LGR project will undertake work to develop the rules that identify the valid repertoire of code points for IDN TLDs, as well as the rules for identifying and possibly delegating any IDN variant TLDs. The work is carried out as specified in the Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels [PDF, 1.39 MB] and involves an Integration Panel, (to be staffed by paid experts), a set of Advisors to all Panels (formed of paid consultants, ICANN staff, or volunteers), and a set of Generation Panels (consisting of volunteers). This call concerns the latter.
Successful development of the IDN Root Zone LGR depends on having Generation Panels for each script represented in the Root Zone. Generation Panels are expected to represent their communities and to have members with the appropriate skills to perform the substantive work of creating the LGR for the script used by their community.
Each Generation Panel will be comprised of a chair and a number of community representatives, as well as members with technical expertise in the following areas: DNS, IDNA, Unicode, and linguistics of the relevant script. The Call for Generation Panels to develop Root Zone Label Generation Rules [PDF, 150 KB] describes the details of expertise needed, as well as the details of the selection process. Interested volunteers are invited to submit their CV and an expression of interest statement demonstrating how they meet the qualifications to serve as members or chairs. Communities that already have a working group dealing with IDN and Variant issues are solicited to contact ICANN if interested in forming a Generation Panel, partially or entirely based on such an existing working group.
Initially, Generation Panel formation is expected to cover the following scripts, already represented in existing applications from both New gTLD and IDN ccTLD Programs: Arabic, Hebrew, Chinese, Japanese, Korean, Cyrillic, Greek, Latin, Bengali, Devanagari, Gujarati, Gurmukhi, Sinhala, Tamil, Telugu, Thai and Georgian. However, the call will remain open for those interested in serving on Generation Panels for other scripts.
Expressions of interest can be sent to idnvarianttlds@icann.org.
Tue, 2013-07-09 01:19
8 July 2013
As part of the process to implement WHOIS review team recommendations related to Internationalized Domain Name registration data requirements, ICANN seeks volunteers who are community representatives with expertise in linguistics, IDNA, policy and registry/registrar operations to participate in a working group to determine appropriate Internationalized Domain Name registration data requirements and data model for Registration Data Directory Services (aka WHOIS services).
Interested experts are invited to submit their résumé and an expression of interest statement demonstrating how they meet the qualifications for one or more of the expertise areas specified. The call for volunteers document [PDF, 143 KB] that describes the type of expertise needed, as well as the process for selecting members.
Applications should be sent to whois-rt-12@icann.org no later than 16 August 2013.
The working group is expected to:
- Determine the requirements for internationalized registration data
- Produce a data model for the IRD that matches the requirement
In doing so the working group is expected to build on previous community efforts related to this issue, most notably:
The result of the WG product will go through a public comment process to ensure broad input is received. It will form the basis for further policy development and/or contractual framework for generic Top-level domains, as well as ideally becoming a best practice for country code top-level domains.
Successful completion of the project depends on having team members with the right skills. Therefore ICANN, through its Supporting Organizations and Advisory Committees, and through its contacts with the international Internet community, is soliciting the participation of community volunteers.
The formation of the working group is part of the process to implement the internationalized registration data recommendations of the ICANN WHOIS Policy Review Team Final Report [PDF, 1.44 MB] as adopted by the ICANN Board.
Wed, 2013-07-03 22:38
3 July 2013
On 2 July 2013, the the ICANN Board New gTLD Program Committee (NGPC) had its seventh meeting to discuss the GAC Beijing advice on New gTLDs. The Committee took the following actions:
-
Initial Protections for IGO Protections
In the Beijing Communiqué, the GAC reiterated previous advice that "appropriate preventative initial protection for the IGO names and acronyms on the provided list be in place before any new gTLDs would launch." In response to a number of issues raised by the Board, the GAC noted in the Beijing Communiqué that it is "mindful of outstanding implementation issues" and that it is committed to "actively working with IGOs, the Board, and ICANN Staff to find a workable and timely way forward. In a 6 June 2013 response letter to the GAC on the IGO GAC Advice, the ICANN Board Chairman proposed that a small number of NGPC members and ICANN staff begin a dialogue with the GAC on these issues
At its 2 July 2013 meeting, the NGPC passed a resolution confirming that the New gTLD Registry Agreement will require operators to provide appropriate preventative initial protection for the IGO identifiers. These protections will remain in place while the GAC, NGPC, ICANN Staff and community continue to actively work through outstanding implementation issues. More specifically, registry operators will implement temporary protections for the IGO names and acronyms on the "IGO List dated 22/03/2013" until the first meeting of the NGPC following the ICANN 47 Meeting in Durban. The Resolution provides temporary protections for IGOs while respecting the ongoing work on implementation issues. The IGO List is attached to the Resolution as Annex 1.
If the NGPC and GAC do not reach an agreement on outstanding implementation issues for protecting IGO names and acronyms by the first meeting of the NGPC following the ICANN 47 meeting in Durban, and subject to any matters that arise during the discussions, registry operators will be required to protect only the IGO names (and not the acronyms) identified on the GAC's IGO List.
-
Category 1 Advice
In the Beijing Communiqué, the GAC proposed Category 1 safeguard advice, which includes recommended restrictions and consumer protections for sensitive strings and regulated markets. The Category 1 Safeguard Advice is divided into three main sections. The first section provides five (5) items of advice that apply to "strings that are linked to regulated or professional sectors." The Beijing Communiqué identified a list of strings to which this advice applies. The second section provides three (3) additional pieces of advice that should apply to a limited subset of the strings noted in the GAC's list that are "associated with market sectors which have clear and/or or regulated entry requirements (such as: financial, gambling, professional services, environmental, health and fitness, corporate identifiers, and charity) in multiple jurisdictions…." The third section includes an additional requirement for applicants for the following strings: .fail, .gripe, .sucks and .wtf.
On 23 April 2013, ICANN initiated a public comment forum to solicit input on how the NGPC should address GAC advice regarding safeguards applicable to broad categories of new gTLD strings http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en.htm. The public comment forum closed on 4 June 2013. While many commenters voiced support for the Category 1 safeguard advice, many others submitting opposing comments. One overarching theme from the public comments was the need for additional clarity on the scope and intent of the Category 1 Safeguard Advice.
After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
-
New gTLD Registry Agreement
Finally, the NGPC considered the revised New gTLD Registry Agreement that will be entered into between ICANN and successful new gTLD applicants. The revised agreement is the result of several months of negotiations, formal community feedback (most recently during public comment forums initiated on 5 February 2013 on 29 April 2013), and meetings with various stakeholders and communities. The revisions include feedback from the ICANN community at the ICANN 46 Meeting on 7-11 April 2013 in Beijing as well as GAC advice issued in its Beijing Communiqué.
After considering the comments received from the community, the NGPC determined that the revised New gTLD Registry Agreement included significant improvements in response to the concerns raised by the community. The Committee also noted that in response to the GAC's Beijing Communiqué, revisions were made to Specification 11 to implement the non-Category 1 safeguard advice (i.e., safeguards applicable to all strings and Category 2 safeguards). The revisions to Specification 11 incorporate standardized language to address the safeguard advice. Applicant-specific PICs will be included on a case-by-case basis to the extent not superseded by or inconsistent with the standard PICs included to address the GAC's Beijing Communiqué.
The NGPC approved the form of the New gTLD Registry Agreement and authorized ICANN staff to take all necessary steps to implement it and to move forward with implementation of the New gTLD Program. The Agreement is attached to the Resolution as Annex 1; the complete Summary of Changes to the New gTLD Registry Agreement is attached to the Resolution as Annex 2; a redline of the current agreement as compared to the previous version dated 29 April 2013 is attached to the Resolution as Annex 3; and the Summary and Analysis of Public Comments is available at http://www.icann.org/en/news/public-comment/report-comments-base-agreement-01jul13-en.pdf [PDF, 338 KB].
All of the resolutions adopted at the 2 July 2013 NGPC meeting are posted at http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm. A table summarizing NGPC Consideration of the GAC's Beijing Advice appears below.
Wed, 2013-07-03 22:17
3 July 2013
On 2 July 2013, the the ICANN Board New gTLD Program Committee (NGPC) had its seventh meeting to discuss the GAC Beijing advice on New gTLDs. The Committee took the following actions:
-
Initial Protections for IGO Protections
In the Beijing Communiqué, the GAC reiterated previous advice that "appropriate preventative initial protection for the IGO names and acronyms on the provided list be in place before any new gTLDs would launch." In response to a number of issues raised by the Board, the GAC noted in the Beijing Communiqué that it is "mindful of outstanding implementation issues" and that it is committed to "actively working with IGOs, the Board, and ICANN Staff to find a workable and timely way forward. In a 6 June 2013 response letter to the GAC on the IGO GAC Advice, the ICANN Board Chairman proposed that a small number of NGPC members and ICANN staff begin a dialogue with the GAC on these issues
At its 2 July 2013 meeting, the NGPC passed a resolution confirming that the New gTLD Registry Agreement will require operators to provide appropriate preventative initial protection for the IGO identifiers. These protections will remain in place while the GAC, NGPC, ICANN Staff and community continue to actively work through outstanding implementation issues. More specifically, registry operators will implement temporary protections for the IGO names and acronyms on the "IGO List dated 22/03/2013" until the first meeting of the NGPC following the ICANN 47 Meeting in Durban. The Resolution provides temporary protections for IGOs while respecting the ongoing work on implementation issues. The IGO List is attached to the Resolution as Annex 1.
If the NGPC and GAC do not reach an agreement on outstanding implementation issues for protecting IGO names and acronyms by the first meeting of the NGPC following the ICANN 47 meeting in Durban, and subject to any matters that arise during the discussions, registry operators will be required to protect only the IGO names (and not the acronyms) identified on the GAC's IGO List.
-
Category 1 Advice
In the Beijing Communiqué, the GAC proposed Category 1 safeguard advice, which includes recommended restrictions and consumer protections for sensitive strings and regulated markets. The Category 1 Safeguard Advice is divided into three main sections. The first section provides five (5) items of advice that apply to "strings that are linked to regulated or professional sectors." The Beijing Communiqué identified a list of strings to which this advice applies. The second section provides three (3) additional pieces of advice that should apply to a limited subset of the strings noted in the GAC's list that are "associated with market sectors which have clear and/or or regulated entry requirements (such as: financial, gambling, professional services, environmental, health and fitness, corporate identifiers, and charity) in multiple jurisdictions…." The third section includes an additional requirement for applicants for the following strings: .fail, .gripe, .sucks and .wtf.
On 23 April 2013, ICANN initiated a public comment forum to solicit input on how the NGPC should address GAC advice regarding safeguards applicable to broad categories of new gTLD strings http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en.htm. The public comment forum closed on 4 June 2013. While many commenters voiced support for the Category 1 safeguard advice, many others submitting opposing comments. One overarching theme from the public comments was the need for additional clarity on the scope and intent of the Category 1 Safeguard Advice.
After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
-
New gTLD Registry Agreement
Finally, the NGPC considered the revised New gTLD Registry Agreement that will be entered into between ICANN and successful new gTLD applicants. The revised agreement is the result of several months of negotiations, formal community feedback (most recently during public comment forums initiated on 5 February 2013 on 29 April 2013), and meetings with various stakeholders and communities. The revisions include feedback from the ICANN community at the ICANN 46 Meeting on 7-11 April 2013 in Beijing as well as GAC advice issued in its Beijing Communiqué.
After considering the comments received from the community, the NGPC determined that the revised New gTLD Registry Agreement included significant improvements in response to the concerns raised by the community. The Committee also noted that in response to the GAC's Beijing Communiqué, revisions were made to Specification 11 to implement the non-Category 1 safeguard advice (i.e., safeguards applicable to all strings and Category 2 safeguards). The revisions to Specification 11 incorporate standardized language to address the safeguard advice. Applicant-specific PICs will be included on a case-by-case basis to the extent not superseded by or inconsistent with the standard PICs included to address the GAC's Beijing Communiqué.
The NGPC approved the form of the New gTLD Registry Agreement and authorized ICANN staff to take all necessary steps to implement it and to move forward with implementation of the New gTLD Program. The Agreement is attached to the Resolution as Annex 1; the complete Summary of Changes to the New gTLD Registry Agreement is attached to the Resolution as Annex 2; a redline of the current agreement as compared to the previous version dated 29 April 2013 is attached to the Resolution as Annex 3; and the Summary and Analysis of Public Comments is available at http://www.icann.org/en/news/public-comment/report-comments-base-agreement-01jul13-en.pdf [PDF, 338 KB].
All of the resolutions adopted at the 2 July 2013 NGPC meeting are posted at http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm. A table summarizing NGPC Consideration of the GAC's Beijing Advice appears below.
GAC Register #
Summary of GAC Advice
NGPC Position
NGPC Response
- 2013-04-11-Obj-Africa (Communiqué §1.a.i.1)
The GAC Advises the ICANN Board that the GAC has reached consensus on GAC Objection Advice according to Module 3.1 part I of the Applicant Guidebook on the following application: .africa (Application number 1-1165-42560)
Accept
- 2013-04-11-Obj-GCC (Communiqué §1.a.i.2)
The GAC Advises the ICANN Board that the GAC has reached consensus on GAC Objection Advice according to Module 3.1 part I of the Applicant Guidebook on the following application: .gcc (application number: 1-1936-2101)
Accept
- 2103-04-11-Religious Terms (Communiqué §1.a.ii)
The GAC Advises the Board that with regard to Module 3.1 part II of the Applicant Guidebook, the GAC recognizes that Religious terms are sensitive issues. Some GAC members have raised sensitivities on the applications that relate to Islamic terms, specifically .islam and .halal. The GAC members concerned have noted that the applications for .islam and .halal lack community involvement and support. It is the view of these GAC members that these applications should not proceed.
Accept
- 2013-04-11-gTLDStrings (Communiqué §1.c)
In addition to this safeguard advice, the GAC has identified certain gTLD strings where further GAC consideration may be warranted, including at the GAC meetings to be held in Durban. Consequently, the GAC advises the ICANN Board to not proceed beyond Initial Evaluation with the following strings : .shenzhen (IDN in Chinese), .persiangulf, .guangzhou (IDN in Chinese), .amazon (and IDNs in Japanese and Chinese), .patagonia, .date, .spa, . yun, .thai, .zulu, .wine, .vin
Accept
- Request for Written Briefing (Communiqué §1.d)
The GAC requests a written briefing about the ability of an applicant to change the string applied for in order to address concerns raised by a GAC Member and to identify a mutually acceptable solution.
Provided
Written briefing provided at
https://gacweb.icann.org/download/attachments/28278832/NGPC%20Scorecard%20of%201As%20Regarding%20Non-%C2%ADSafeguard%20Advice%20in%20the%20GAC%20Beijing%20Communique%CC%81.pdf?version=1&modificationDate=1372384291000&api=v2 [PDF, 2.68 MB]
- 2013-04-11-CommunitySupport (Communiqué §1.e)
The GAC advises the Board that in those cases where a community, which is clearly impacted by a set of new gTLD applications in contention, has expressed a collective and clear opinion on those applications, such opinion should be duly taken into account, together with all other relevant information.
Accept
- 2013-04-11-PluralStrings (Communiqué §1.f)
The GAC believes that singular and plural versions of the string as a TLD could lead to potential consumer confusion. Therefore the GAC advises the Board to reconsider its decision to allow singular and plural versions of the same strings.
Accept
- After careful consideration of the issues, review of the comments raised by the community, the process documents of the expert review panels, and deliberations by the NGPC, the NGPC determined that no changes to the ABG are needed to address potential consumer confusion specifically resulting from allowing singular and plural versions of the same strings.
- The NGPC considered several significant factors during its deliberations about whether to allow singular and plural version of the same strings. The NGPC had to balance the competing interests of each factor to arrive at a decision.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.d.
- 2013-04-11-IGO (Communiqué §1.g)
GAC reiterates its advice to the ICANN Board that appropriate preventative initial protection for the IGO names and acronyms on the provided list be in place before any new gTLDs would launch.
Dialogue
- The New gTLD Registry Agreement will require operators to provide appropriate preventative initial protection for the IGO identifiers. These protections will remain in place while the GAC, NGPC, ICANN Staff and community continue to actively work through outstanding implementation issues.
- If the NGPC and GAC do not reach an agreement on outstanding implementation issues for protecting IGO names and acronyms by the first meeting of the NGPC following the ICANN 47 meeting in Durban, and subject to any matters that arise during the discussions, registry operators will be required to protect only the IGO names (and not the acronyms) identified on the GAC's IGO List.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-RAA (Communiqué §2)
The GAC advises the ICANN Board that the 2013 Registrar Accreditation Agreement should be finalized before any new gTLD contracts are approved.
Accept
- 2013-04-11-WHOIS (Communiqué §3)
The GAC urges the ICANN Board to ensure that the GAC Principles Regarding gTLD WHOIS Services, approved in 2007, are duly taken into account by the recently established Directory Services Expert Working Group.
Accept
- 2013-04-11-IOCRC (Communiqué §4)
The GAC advises the ICANN Board to amend the provisions in the new gTLD Registry Agreement pertaining to the IOC/RCRC names to confirm that the protections will be made permanent prior to the delegation of any new gTLDs.
Accept
- The NGPC accepted the GAC advice.
- The Registry Agreement includes protection for an indefinite duration for IOC/RCRC names. Specification 5 of this version of the Registry Agreement includes a list of names (provided by the IOC and RCRC Movement) that "shall be withheld from registration or allocated to Registry Operator at the second level within the TLD."
- This protection was added pursuant to a NGPC resolution to maintain these protections "until such time as a policy is adopted that may require further action" (204.11.26.NG03).
- The resolution recognized the GNSO's initiation of an expedited PDP. Until such time as the GNSO approves recommendations in the PDP and the Board adopts them, the NGPC's resolutions protecting IOC/RCRC names will remain in place.
- Should the GNSO submit any recommendations on this topic, the NGPC will confer with the GAC prior to taking action on any such recommendations.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-04jun13-en.htm and http://www.icann.org/en/groups/board/documents/new-gtld-resolution-annex-1-04jun13-en.pdf [PDF, 564 KB]
- 2013-04-11-PIC SPEC (Communiqué §5, Annex 2)
The GAC requests more information on the Public Interest Commitments Specifications on the basis of the questions listed in annex II.
Provided
NGPC responses to the Annex 2 questions available at https://gacweb.icann.org/display/GACADV/2013-04-11-PICSPEC
- 2013-04-11-Safeguards 1 (Communiqué Annex 1, 1)
1. WHOIS verification and checks —Registry operators will conduct checks on a statistically significant basis to identify registrations in its gTLD with deliberately false, inaccurate or incomplete WHOIS data at least twice a year. Registry operators will weight the sample towards registrars with the highest percentages of deliberately false, inaccurate or incomplete records in the previous checks. Registry operators will notify the relevant registrar of any inaccurate or incomplete records identified during the checks, triggering the registrar's obligation to solicit accurate and complete information from the registrant.
Accept
- ICANN (instead of Registry Operators) will implement the GAC's advice that checks identifying registrations in a gTLD with deliberately false, inaccurate or incomplete WHOIS data be conducted at least twice a year.
- ICANN will perform a periodic sampling of WHOIS data across registries in an effort to identify potentially inaccurate records.
- ICANN will also maintain statistical reports that identify the number of inaccurate WHOIS records identified.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 2 (Communiqué Annex 1, 2)
2. Mitigating abusive activity—Registry operators will ensure that terms of use for registrants include prohibitions against the distribution of malware, operation of botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law.
Accept
- A provision in the proposed New gTLD Registry Agreement (as a mandatory Public Interest Commitment in Specification 11) obligates Registry Operators to include a provision in their Registry-Registrar Agreements that requires Registrars to include in their Registration Agreements a provision prohibiting Registered Name Holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences for such activities including suspension of the domain name.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 3 (Communiqué Annex 1, 3)
3. Security checks— While respecting privacy and confidentiality, Registry operators will periodically conduct a technical analysis to assess whether domains in its gTLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets. If Registry operator identifies security risks that pose an actual risk of harm, Registry operator will notify the relevant registrar and, if the registrar does not take immediate action, suspend the domain name until the matter is resolved.
Accept
- A provision in the New gTLD Registry Agreement (as a mandatory Public Interest Commitment in Specification 11) requires Registry Operators periodically to conduct a technical analysis to assess whether domains in its gTLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets.
- The provision also requires Registry Operators to maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks. Registry Operators will maintain these reports for the agreed contracted period and provide them to ICANN upon request. The contents of the reports will be publically available as appropriate.
- Because there are multiple ways for a Registry Operator to implement the required security checks, ICANN will solicit community participation (including conferring with the GAC) in a task force or through a policy development process in the GNSO, as appropriate, to develop the framework for Registry Operators to respond to identified security risks that pose an actual risk of harm, notification procedures, and appropriate consequences, including a process for suspending domain names until the matter is resolved, while respecting privacy and confidentiality.
- The language included in Paragraph 3 of the attached PIC Specification provides the general guidelines for what Registry Operators must do, but omits the specific details from the contractual language to allow for the future development and evolution of the parameters for conducting security checks. This will permit Registry Operators to enter into agreements as soon as possible, while allowing for a careful and fulsome consideration by the community on the implementation details.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 4 ((Communiqué Annex 1, 4)
4. Documentation—Registry operators will maintain statistical reports that provide the number of inaccurate WHOIS records or security threats identified and actions taken as a result of its periodic WHOIS and security checks. Registry operators will maintain these reports for the agreed contracted period and provide them to ICANN upon request in connection with contractual obligations.
Accept
- As detailed in item 13 above, ICANN will maintain statistical reports that identify the number of inaccurate WHOIS records identified as part of the checks to identify registrations with deliberately false, inaccurate or incomplete WHOIS data.
- As detailed in item 15 above, Registry Operators will be required to maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks.
- Registry Operators will maintain these reports for the agreed contracted period and provide them to ICANN upon request. The contents of the reports will be publically available as appropriate.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 5 ((Communiqué Annex 1, 5)
5. Making and Handling Complaints – Registry operators will ensure that there is a mechanism for making complaints to the registry operator that the WHOIS information is inaccurate or that the domain name registration is being used to facilitate or promote malware, operation of botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law.
Accept
- Registry Operators are required to ensure that there is a mechanism for making complaints to the Registry Operator regarding malicious conduct in the TLD.
- Section 4.1 of Specification 6 of the New gTLD Registry Agreement provides that, "Registry Operator shall provide to ICANN and publish on its website its accurate contact details including a valid email and mailing address as well as a primary contact for handling inquires related to malicious conduct in the TLD, and will provide ICANN with prompt notice of any changes to such contact details."
- Section 2.8 of the New gTLD Registry Agreement provides that a, "Registry Operator shall take reasonable steps to investigate and respond to any reports from law enforcement and governmental and quasi-governmental agencies of illegal conduct in connection with the use of the TLD."
- ICANN operates the WHOIS Data Problem Reports System <http://www.icann.org/en/resources/compliance/complaints/whois/inaccuracy-form>, which is a mechanism for making complaints that WHOIS information is inaccurate.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 6 (Communiqué Annex 1, 6)
6. Consequences – Consistent with applicable law and any related procedures, registry operators shall ensure that there are real and immediate consequences for the demonstrated provision of false WHOIS information and violations of the requirement that the domain name should not be used in breach of applicable law; these consequences should include suspension of the domain name.
Accept
- Consequences for the demonstrated provision of false WHOIS information are set forth in Section 3.7.7.2 of the 2013 RAA <http://www.icann.org/en/resources/registrars/raa/proposed-agreement-22apr13-en.pdf> [PDF, 311 KB]: "A Registered Name Holder's willful provision of inaccurate or unreliable information, its willful failure to update information provided to Registrar within seven (7) days of any change, or its failure to respond for over fifteen (15) days to inquiries by Registrar concerning the accuracy of contact details associated with the Registered Name Holder's registration shall constitute a material breach of the Registered Name Holder-registrar contract and be a basis for suspension and/or cancellation of the Registered Name registration."
- Paragraph 1 of the PIC Specification includes a requirement that Registry Operator will use only ICANN accredited registrars that are party to the 2013 RAA so that these consequences are contractually required.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 1)
1. Registry operators will include in its acceptable use policy that registrants comply with all applicable laws, including those that relate to privacy, data collection, consumer protection (including in relation to misleading and deceptive conduct), fair lending, debt collection, organic farming, disclosure of data, and financial disclosures.
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 2)
2. Registry operators will require registrars at the time of registration to notify registrants of this requirement.
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 3)
3. Registry operators will require that registrants who collect and maintain sensitive health and financial data implement reasonable and appropriate security measures commensurate with the offering of those services, as defined by applicable law and recognized industry standards.
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 4)
4. Establish a working relationship with the relevant regulatory, or industry self-regulatory, bodies, including developing a strategy to mitigate as much as possible the risks of fraudulent, and other illegal, activities.
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 5)
5. Registrants must be required by the registry operators to notify to them a single point of contact which must be kept up-to-date, for the notification of complaints or reports of registration abuse, as well as the contact details of the relevant regulatory, or industry self-regulatory, bodies in their main place of business.
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 6)
6. At the time of registration, the registry operator must verify and validate the registrants' authorisations, charters, licenses and/or other related credentials for participation in that sector
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 7)
In case of doubt with regard to the authenticity of licenses or credentials, Registry Operators should consult with relevant national supervisory authorities, or their equivalents.
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 8)
The registry operator must conduct periodic post-registration checks to ensure registrants' validity and compliance with the above requirements in order to ensure they continue to conform to appropriate regulations and licensing requirements and generally conduct their activities in the interests of the consumers they serve.
Dialogue
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC's Category 2.1 Safeguard Advice regarding "Restricted Access" since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-2 (Communiqué Annex 1, Category 2, 1)
1. Restricted Access
As an exception to the general rule that the gTLD domain name space is operated in an open manner registration may be restricted, in particular for strings mentioned under category 1 above. In these cases, the registration restrictions should be appropriate for the types of risks associated with the TLD. The registry operator should administer access in these kinds of registries in a transparent way that does not give an undue preference to any registrars or registrants, including itself, and shall not subject registrars or registrants to an undue disadvantage.
Dialogue
- Safeguards-Categories-2 (Communiqué Annex 1, Category 2, 2)
2. Exclusive Access
For strings representing generic terms, exclusive registry access should serve a public interest goal.
Accepted in part, dialogue on remainder
- For applicants seeking to impose exclusive registry access for "generic strings", the NGPC directed staff to defer moving forward with the contracting process for these applicants, pending a dialogue with the GAC.
- The term "generic string" is defined to mean "a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others."
- Exclusive registry access is defined as limiting registration of a generic string exclusively to a single person or entity and their affiliates.
- For applicants not seeking to impose exclusive registry access, a provision in the in the New gTLD Registry Agreement requires TLDs to operate in a transparent manner consistent with general principles of openness and non-discrimination.
- A PIC Specification also includes a provision to preclude registry operators from imposing eligibility criteria that limit registration of a generic string exclusively to a single person or entity and their "affiliates."
- All applicants will be required to respond by a specified date indicating whether (a) the applicant is prepared to accept the proposed PIC Specification that precludes exclusive registry access or (b) the applicant is unwilling to accept the proposed PIC Specification because the applicant intends to implement exclusive registry access.
- The NGPC will enter into a dialogue with the GAC to seek clarification on their advice with respect to exclusive registry access.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.c.
Wed, 2013-07-03 13:12
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].
Wed, 2013-07-03 02:55
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.
Wed, 2013-07-03 02:35
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.
Tue, 2013-07-02 21:57
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
Fri, 2013-06-28 03:30
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.
|