Skip to main content
Resources

Approved Resolutions | Meeting of the New gTLD Program Committee

  1. Main Agenda

 

  1. Main Agenda:

    1. Revised BGC Recommendation on Reconsideration Request 13-3

      Whereas, the Noncommercial Users Stakeholders Group's ("NCSG") Reconsideration Request, Request 13-3, sought reconsideration of the staff action of 20 March 2013 regarding "Trademark Claims Protections for Previously Abused Names".

      Whereas, the BGC considered the issues raised in Reconsideration Request 13-3, as well as the issues brought to and discussed by the GNSO Council regarding some of the language in the BGC's Recommendation.

      Whereas, the BGC revoked its initial recommendation, and issued a Revised BGC Recommendation on Reconsideration Request 13-3, which ultimately recommended that no further action was warranted with respect to Request 13-3.

      Resolved (2013.07.02.NG01), the New gTLD Program Committee adopts the Revised BGC Recommendation on Reconsideration Request 13-3 <http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-ncsg-25jun13-en.pdf> [PDF, 142 KB].

      Resolved (2013.07.02.NG02), the New gTLD Program Committee directs ICANN's President and CEO to assure that the issues raised within Request 13-3 are brought to the ongoing community discussion on policy versus implementation within ICANN.

      Rationale for Resolutions 2013.07.02.NG01 – 2013.07.02.NG02

      ICANN's Bylaws call for the Board Governance Committee to evaluate and make recommendations to the Board with respect to Reconsideration Requests. See Article IV, section 3 of the Bylaws. The New gTLD Program Committee ("NGPC"), bestowed with the powers of the Board in this instance, has reviewed and thoroughly considered the revised BGC Recommendation on Reconsideration Request 13-3 and finds the analysis sound.

      Having a Reconsideration process whereby the BGC reviews and makes a recommendation to the Board/New gTLD Program Committee for approval positively affects ICANN's transparency and accountability. It provides an avenue for the community to ensure that staff and the Board are acting in accordance with ICANN's policies, Bylaws and Articles of Incorporation.

      This Request asserted that a staff action allowing up to 50 names that were previously determined registered or used abusively to be included in verified trademark records in the Clearinghouse created policy or was in contradiction of existing policy or process. The BGC considered the specific issue raised in the Request, and determined that the staff action here was implementation of existing policy, namely Recommendation 3 of the GNSO Council's policy recommendations on the introduction of new gTLDs. (See ICANN Generic Names Supporting Organization Final Report Introduction of New Generic Top-Level Domains, at http://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm, adopted by the Board at http://www.icann.org/en/groups/board/documents/resolutions-26jun08-en.htm.) The BGC further determined that there were no other policies or procedures that were alleged to be violated by this staff action.

      Upon making its determination, the BGC issued a Recommendation to the NGPC for consideration. Before the NGPC took up the matter, one GNSO Councilor raised some concerns over some of the language in BGC's Recommendation. The GNSO Council held a lengthy discussion regarding the BGC's Recommendation and asked that the BGC reconsider some of the language in the Recommendation, although not the ultimate conclusion. The BGC carefully considered the GNSO Council's request and stated concerns, and ultimately determined to revise its Recommendation. In doing so, the BGC properly noted that the Recommendation should not be seen as against the ongoing, community-wide discussion about policy and implementation. The BGC also noted that its revised Recommendation should not be construed as discounting the importance of consulting with community members. Community consultation is at the heart of the multistakeholder model, and is critical whether the community is acting as a policy development body or during the implementation of policy.

      Request 13-3 demonstrates the import of the ongoing work within the ICANN community regarding issues of policy versus implementation, and the need to have clear definitions of processes and terms used when seeking community guidance and input. The Committee recognizes that the GNSO Council continues to address some of these issues, and agrees with the BGC that it is advisable to pay close attention to the policy/implementation debate, and to make sure that the issues raised within this Request be part of that community work.

      Adopting the BGC's recommendation has no financial impact on ICANN and will not negatively impact the systemic security, stability and resiliency of the domain name system.

      This decision is an Organizational Administrative Function that does not require public comment.

    2. Initial Protection for IGO Identifiers

      Whereas, the GAC met during the ICANN 46 meeting in Beijing and issued a Communiqué on 11 April 2013 ("Beijing Communiqué");

      Whereas, the Beijing Communiqué reiterated the GAC's previous advice to the 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" (the "IGO GAC Advice"). The IGO GAC Advice is identified in the GAC Register of Advice as 2013-04-11-IGO;

      Whereas, 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";

      Whereas, the NGPC met on 8 and 18 May and 4, 11 and 18 June 2013 to consider a plan for responding to the advice on the New gTLD Program, including the IGO GAC Advice;

      Whereas, 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 http://www.icann.org/en/news/correspondence/crocker-to-dryden-2-06jun13-en;

      Whereas, the NGPC met on 25 June 2013 to further discuss and consider its plan for responding the GAC's advice in the Beijing Communiqué on the IGO GAC Advice;

      Whereas, the final draft of the New gTLD Registry Agreement posted for public comment on 29 April 2013 <http://www.icann.org/en/news/public-comment/base-agreement-29apr13-en.htm> includes IGO protections, but does not yet specify the names and acronyms to be protected;

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

      Resolved (2013.07.02.NG03), the NGPC confirms that appropriate preventative initial protection for the IGO identifiers will continue to be provided as presented in the proposed New gTLD Registry Agreement posted for public comment on 29 April 2013 <http://www.icann.org/en/news/public-comment/base-agreement-29apr13-en.htm> while the GAC, NGPC, ICANN Staff and community continue to actively work through outstanding implementation issues.

      Resolved (2013.07.02.NG04), the NGPC determines that pursuant to Specification 5 in the proposed New gTLD Registry Agreement posted for public comment on 29 April 2013 <http://www.icann.org/en/news/public-comment/base-agreement-29apr13-en.htm>, registry operators will implement temporary protections for the IGO names and acronyms on the "IGO List dated 22/03/2013" attached to this Resolution as Annex 1 [PDF, 541 KB] until the first meeting of the NGPC following the ICANN 47 Meeting in Durban.

      Resolved (2013.07.02.NG05), the NGPC will dialogue with the GAC prior to its first meeting following the ICANN 47 meeting in Durban to work through outstanding implementation issues concerning protections for IGO names and acronyms.

      Resolved (2013.07.02.NG06), 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, the NGPC determines that registry operators will be required to protect only the IGO names identified on the GAC's "IGO List dated 22/03/2013" attached to this Resolution as Annex 1 [PDF, 541 KB].

      Rationale for Resolutions 2013.07.02.NG03 – 2013.07.02.NG06

      Why the NGPC is addressing the issue?

      Article XI, Section 2.1 of the ICANN Bylaws http://www.icann.org/en/about/governance/bylaws#XI permits the GAC to "put issues to the Board directly, either by way of comment or prior advice, or by way of specifically recommending action or new policy development or revision to existing policies." The GAC issued advice to the Board on the New gTLD Program through its Beijing Communiqué dated 11 April 2013. The ICANN Bylaws require the Board to take into account the GAC's advice on public policy matters in the formulation and adoption of the polices. If the Board decides to take an action that is not consistent with the GAC advice, it must inform the GAC and state the reasons why it decided not to follow the advice. The Board and the GAC will then try in good faith to find a mutually acceptable solution. If no solution can be found, the Board will state in its final decision why the GAC advice was not followed.

      What is the proposal being considered?

      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." The NGPC is being asked to consider accepting this advice, while being mindful of the outstanding implementation issues. This advice is identified in the GAC Register of Advice as 2013-04-11-IGO.

      The proposed final draft of the New gTLD Registry Agreement includes protections for IGO but does not yet specify the names and acronyms to be protected. The current draft of the New gTLD Registry Agreement provides the following protections in Specification 5, Section 6:

      As instructed from time to time by ICANN, Registry Operator will implement the protections mechanism determined by the ICANN Board of Directors relating to the protection of identifiers for Intergovernmental Organizations. Any such protected identifiers for Intergovernmental Organizations may not be activated in the DNS, and may not be released for registration to any person or entity other than Registry Operator. Upon conclusion of Registry Operator's designation as operator of the registry for the TLD, all such protected identifiers shall be transferred as specified by ICANN….

      To address the GAC advice regarding IGO names and acronyms, the NGPC is considering providing temporary protections for the IGO names and acronyms previously identified by the GAC on its "IGO List dated 22/03/2013," which is attached as Annex 1 [PDF, 541 KB] until a date certain, so that the GAC and the NGPC will have time to work out outstanding implementation issues, as noted in the Beijing Communiqué. The NGPC proposes the temporary protections to remain in place until the first meeting of the NGPC following the ICANN Meeting in Durban, South Africa. If the NGPC and the GAC do not reach agreement on the issues, and subject to any matters that arise during the discussions, the NGPC would require registry operators only to protect the names, but not the acronyms, identified on the GAC's IGO List dated 22/03/2013. The proposed Resolution would provide temporary protections for IGOs while respecting the ongoing work on implementation issues.

      Which stakeholders or others were consulted?

      On 29 April 2013, ICANN initiated a public comment forum to solicit input on the proposed final draft of the New gTLD Registry Agreement <http://www.icann.org/en/news/public-comment/base-agreement-29apr13-en.htm>. The public comment forum closed on 11 June 2013. The NGPC has considered the community comments on the New gTLD Registry Agreement in formulating its response to the IGO GAC Advice as it relates to the New gTLD Registry Agreement <http://forum.icann.org/lists/comments-base-agreement-29apr13/>.

      Additionally, on 14 June 2013, the GNSO Policy Development Process Working Group tasked with addressing the issue of protecting the identifiers of certain IGOs and International Non-Governmental Organizations ("INGOs") in all gTLDs published its Initial Report for public comment. The public comment period is scheduled to close 7 August 2013. <http://www.icann.org/en/news/public-comment/igo-ingo-initial-14jun13-en.htm> The Issue Report was initiated as a result of a recommendation by the GNSO Drafting Team formed to provide a GNSO Council response to the Board and GAC on the protection of IOC and RCRC names in new gTLDs. After community review, the scope of the Final GNSO Issue Report included an evaluation of whether to protect the names of both IGOs and non-government organizations at the top level and second level in all gTLDs.

      What concerns or issues were raised by the community?

      ICANN received several responses from the community during the course of the public comment forum on the proposed final draft of the New gTLD Registry Agreement; however, none of the responses specifically relates to the provisions in the New gTLD Registry Agreement to provide protections for IGO identifiers. <http://forum.icann.org/lists/comments-base-agreement-29apr13/>

      What significant materials did the NGPC review?

      As part of its deliberations, the NGPC reviewed the following significant materials and documents:

      What factors did the Board find to be significant?

      The Beijing Communiqué generated significant interest from the community and stimulated many comments. The NGPC considered the community comments, the GAC's advice transmitted in the Beijing Communiqué, and the ongoing work of the GNSO PDP Working Group on the Protection of IGO and INGO Identifiers in all gTLDs.

      Are there positive or negative community impacts?

      The response to the GAC advice as provided in the NGPC's Resolution will assist with resolving the GAC advice in manner that permits the greatest number of new gTLD applications to continue to move forward as soon as possible, while being mindful of the ongoing efforts to work through the outstanding implementation issues.

      Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

      There are no foreseen fiscal impacts associated with the adoption of this resolution.

      Are there any security, stability or resiliency issues relating to the DNS?

      Approval of the proposed resolution will not impact security, stability or resiliency issues relating to the DNS.

      Is this either a defined policy process within ICANN's Supporting Organizations or ICANN's Organizational Administrative Function decision requiring public comment or not requiring public comment?

      On 29 April 2013, ICANN initiated a public comment forum to solicit input on the proposed final draft of the New gTLD Registry Agreement. The public comment forum closed on 11 June 2013.

      On 14 June 2013, the GNSO Policy Development Process Working Group tasked with addressing the issue of protecting the identifiers of certain IGOs and INGOs in all gTLDs published its Initial Report for public comment. The public comment period is scheduled to close 7 August 2013. <http://www.icann.org/en/news/public-comment/igo-ingo-initial-14jun13-en.htm>

    3. Category 1 Safeguard Advice from GAC

      Whereas, the GAC met during the ICANN 46 meeting in Beijing and issued a Communiqué on 11 April 2013 ("Beijing Communiqué");

      Whereas, the Beijing Communiqué included Category 1 safeguard advice, which is identified in the GAC Register of Advice as 2013-04-11-Safeguards-Categories-1 (the "Category 1 Safeguard Advice");

      Whereas, on 23 April 2013, ICANN initiated a public comment forum to solicit the community's 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>;

      Whereas, the NGPC met on 8 and 18 May and 4, 11, 18 and 25 June 2013 to consider a plan for responding to the GAC's advice on the New gTLD Program, including the Category 1 Safeguard Advice;

      Whereas, the NGPC met on 2 July 2013 to further discuss and consider its plan for responding the GAC's advice in the Beijing Communiqué on the New gTLD Program;

      Whereas, the NGPC has considered the public comments on the Category 1 Safeguard Advice submitted during the public comment forum; and

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

      Resolved (2013.07.02.NG07), the NGPC agrees 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. (Note: 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.)

      Resolved (2013.07.02.NG08), the NGPC directs staff to defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC's Category 1 Safeguard Advice, pending a dialogue with the GAC.

      Rationale for Resolutions 2013.07.02.NG07 – 2013.07.02.NG08

      Why the NGPC is addressing the issue?

      Article XI, Section 2.1 of the ICANN Bylaws http://www.icann.org/en/about/governance/bylaws#XI permits the GAC to "put issues to the Board directly, either by way of comment or prior advice, or by way of specifically recommending action or new policy development or revision to existing policies." The GAC issued advice to the Board on the New gTLD Program through its Beijing Communiqué dated 11 April 2013. The ICANN Bylaws require the Board to take into account the GAC's advice on public policy matters in the formulation and adoption of the polices. If the Board decides to take an action that is not consistent with the GAC advice, it must inform the GAC and state the reasons why it decided not to follow the advice. The Board and the GAC will then try in good faith to find a mutually acceptable solution. If no solution can be found, the Board will state in its final decision why the GAC advice was not followed.

      What is the proposal being considered?

      The NGPC is being asked to consider its response to the Category 1 Safeguard Advice identified in the GAC Register of Advice as "2013-04-11-Safeguards-Categories-1." The NGPC proposes to begin a dialogue with the GAC in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice.

      Which stakeholders or others were consulted?

      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. The NGPC has considered the community comments in adopting this Resolution.

      What concerns or issues were raised by the community?

      ICANN received several responses from the community during the course of the public comment forum on broad categories of GAC safeguard advice. The full set of comments and a summary are available at <http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en.htm>. Of those commenters voicing support, the commenters expressed general agreement with the Category 1 safeguards but some also indicated they require additional clarity. Those expressing opposition suggested that this advice is untimely, ill-conceived, overbroad, and too vague to implement. There was also concern expressed over the inherent lack of fairness and predictable treatment of strings with respect to their placement in the respective sectors/sub-categories of Category 1 and some comments pointed out that the list itself is inconsistent. One commenter expressed that the GAC's advice proposes to "make registrars and registries authoritative licensing validation entities for 200 jurisdictions and an innumerable number of sectors and professions."

      One overarching theme from the public comments was the need for additional clarity on the scope and intent of the Category 1 Safeguard Advice. In particular, the community noted the following concerns, which the NGPC considered in adopting this Resolution:

      1. Categories of Strings
        1. The list of strings is inconsistent. The categories are broad and undefined. This creates issues of fairness and predictable treatment of new gTLD applications. Specifically:

          • The list places many generic words in the same categories as highly regulated industries. For example:

            Generic Highly Regulated
            SAVE BANK
            CARE LAWYER
            HEART PHARMACY
          • Some of the strings identified apply to a range of individuals, businesses and associations and has segments that are both licensed and unlicensed.

            • Example: .ENGINEER could apply to software engineers as well as civil engineers. Also, engineers are regulated in some parts of the world, but not others. In some cases, only specific disciplines require licenses or certificates.

            • Example: .LEGAL could apply to lawyers, paralegals, legal research services and publishers, and court reporting and transcribing services often used in the legal profession. Not all of these businesses and associations require licenses.

          • It is difficult to determine the relevant industry self-regulation organizations. If the relevant organizations could be identified, it is not feasible to establish working relationships with them all.

            • Example: In the United States, some engineering disciplines are regulated at the state level- not the national level. This would require the registry operator for .ENGINEER to form relationships with all 50 state regulators in the United States, in addition to regulators across the world. This could easily amount to hundreds of relationships.

            • Example: For .HIPHOP, it is not clear who the relevant regulatory body is for purposes of complying with the Category 1 Safeguards.

          • Many of the strings are generic terms which may be sensitive or regulated in a single or a few jurisdictions, but it is not appropriate to limit their use in other jurisdictions.

        2. There is no principled basis for distinguishing between certain categories and strings. Examples provided by the community include:

          GAC Category 1 Includes Does Not Include
          Children .school .camp
          Intellectual Property .fashion .style; .clothing
          Intellectual Property .author .actor
          Education .degree, .mba, and .university .college; .education; .phd; .training; .science
          Financial .discount .cheap or .bargain
          Charity .charity .foundation
          Financial .financialaid .scholarships
          Professional Services .lawyer and .doctor .contractors
        3. In some instances the safeguards are related to the content of websites, which is outside the scope of ICANN's remit.

      2. Comments and other concerns regarding Category 1 Safeguards

        1. Safeguards 1 & 2

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

          Safeguard #2: Registry operators will require registrars at the time of registration to notify registrants of this requirement.

          1. No concerns. Safeguards 1 and 2 require registrants to comply with applicable law, which all registrants are already required to do.

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

          1. The safeguard is not specific enough, and thus it is not possible to implement it.

          2. The registry operator is not the appropriate entity to carry out the safeguard. Instead, it should be handled by appropriate legislative, law enforcement and industry expert bodies.

          3. It is not clear whether the phrase "reasonable and appropriate security measures commensurate with the offering of those services, as defined by applicable law and recognized industry standards" is intended to simply require registrants to abide by applicable law (which would be feasible), or if the GAC is intending to create a new standard (reasonable and appropriate…) that registries would be required to develop and enforce;

          4. It is not clear how "recognized industry standards" would be identified and applied in the context of hundreds of different sectors.

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

          1. The safeguard raises contract enforcement questions (e.g., how are the relevant regulatory agencies and industry self-regulatory organizations identified; who determines which industry self-regulation organizations bodies are "relevant" to a particular string and which governmental body is the competent regulatory agency).

          2. Some regulatory bodies or industry self-regulatory bodies may not be responsive to collaboration with registry operators.

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

          1. Let's say that an individual wants to register myname.health in order to keep his friends informed of his progress in eating better and exercising more. How would he determine which regulatory agencies and self-regulatory organizations around the globe are relevant?

          2. Registry operators already have a point of contact for a registrant as a result of the accurate WHOIS data requirements. The advice does not acknowledge the existing standards, such as RFC 2142, that mandates abuse@domain as the standard point of contact for "inappropriate public behavior."

          3. For unrestricted TLDs, the appropriate way to implement this safeguard would be via registrars and the RAA.

        5. Safeguard #s 6-8

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

          Category 1 Safeguard #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.

          Category 1 Safeguard #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.

          1. Implementation would change the nature of some new gTLDs from being open to uses that are not regulated into restricted TLDs open only to registrants that can prove their status or credentials.

          2. Implementation would potentially discriminate against users in developing nations whose governments do not have regulatory bodies or keep databases which a registry/registrar could work with to verify credentials.

          3. Implementation would potentially discriminate against users in developed nations whose governments have developed different regulatory regimes. For example, in Australia, anyone can claim to be an accountant but anyone holding themselves out as a chartered accountant is subject to regulation.

        The complete set of public comments can be reviewed at: http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en.htm.

      What significant materials did the NGPC review?

      As part of its deliberations, the NGPC reviewed the following significant materials and documents:

      What factors did the Board find to be significant?

      The Beijing Communiqué generated significant interest from the community and stimulated many comments. The NGPC considered the community comments, the GAC's advice transmitted in the Beijing Communiqué, and the procedures established in the AGB for addressing GAC advice to the New gTLD Program.

      Are there positive or negative community impacts?

      The adoption of the Resolution will assist with moving forward to resolve the GAC advice in a manner that provides clarity to applicants on the scope and implementation of the Category 1 Safeguard Advice.

      Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

      There are no foreseen fiscal impacts or ramifications on ICANN associated with the adoption of this resolution.

      Are there any security, stability or resiliency issues relating to the DNS?

      Approval of the proposed resolution will not impact security, stability or resiliency issues relating to the DNS.

      Is this either a defined policy process within ICANN's Supporting Organizations or ICANN's Organizational Administrative Function decision requiring public comment or not requiring public comment?

      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.

    4. Registry Agreement

      Whereas, the new generic Top-Level Domain (New gTLD) Program was developed to increase competition and choice by introducing new gTLDs into the Internet's addressing system;

      Whereas, the Applicant Guidebook (AGB) was produced to define the New gTLD Program, and included a draft New gTLD Registry Agreement to be entered into by successful applicants and ICANN before proceeding to delegation;

      Whereas, on 5 February 2013, ICANN posted for public comment a proposed "Revised New gTLD Registry Agreement Including Additional Public Interest Commitments Specification," which announced proposed revisions to the agreement in response to developments since the last posting of the AGB in June 2012 and a general review of the contractual needs of the New gTLD Program;

      Whereas, on 29 April 2013, ICANN posted for public comment the "Proposed Final New gTLD Registry Agreement," which included certain updates and changes to the New gTLD Registry Agreement in response to community feedback on the version of the New gTLD Registry Agreement posted for public comment on 5 February 2013 and discussions of the agreement at the ICANN 46 meeting in Beijing, China;

      Whereas, ICANN and a group selected by the Registry Stakeholder Group, the Registry Negotiating Team, have continued negotiating the proposed terms of the New gTLD Registry Agreement;

      Whereas, the GAC met during the ICANN 46 meeting in Beijing and issued advice in a Communiqué on 11 April 2013 ("Beijing Communiqué");

      Whereas, on 23 April 2013, ICANN initiated a public comment forum to solicit the community's input on how the NGPC should address GAC advice in the Beijing Communiqué regarding safeguards applicable to broad categories of New gTLD strings <http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en.htm>;

      Whereas, the Beijing Communiqué included advice, which if implemented as suggested by the community, in some cases would require revisions to the New gTLD Registry Agreement;

      Whereas, on 25 June 2013, the NGPC adopted resolutions to revise the New gTLD Registry Agreement to respond to certain elements of the GAC's safeguard advice in the Beijing Communiqué <http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2>;

      Whereas, the NGPC has considered all of the comments received from the community from the various public comment forums, and has determined that the revised New gTLD Registry Agreement attached to this Resolution as Annex 1 [PDF, 1.46 MB] includes significant improvements in response to the concerns raised by the community; and

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

      Resolved (2013.07.02.NG09), the NGPC approves the form of the New gTLD Registry Agreement attached to this Resolution as Annex 1 [PDF, 1.46 MB].

      Resolved (2013.07.02.NG10), the President and CEO is authorized to take all necessary steps to implement the revised New gTLD Registry Agreement and to move forward with implementation of the New gTLD Program.

      Rationale for Resolutions 2013.07.02.NG09 – 2013.07.02.NG10

      Why the NGPC is addressing the issue?

      After the NGPC approves the revised terms of the New gTLD Registry Agreement, it will serve as the contract between successful New gTLD Applicants and ICANN, and will govern the rights and obligations of New gTLD registry operators. Successful New gTLD applicants would be expected to enter into this agreement before proceeding to the next phase of delegation of the TLD.

      What is the proposal being considered?

      The NGPC is considering approving the revised New gTLD Registry Agreement for the New gTLD Program. The New gTLD Registry Agreement reflects months of negotiations on many key issues raised by the community during various public comment forums. In addition, the New gTLD Registry Agreement addresses GAC advice issued on the New gTLD Program, including its most recent advice issued through the Beijing Communiqué.

      Some of the changes to the New gTLD Registry Agreement include:

      • Publication of Registration Data; Personal Data (Sections 2.5 and 2.18): In response to comments advising that the publication of registration data should be subject to all applicable data protection and regulations (including European Data Protection laws), the latest version of the Registry Agreement (Section 7.13) provides that ICANN and the Working Group (as defined in the Registry Agreement) will mutually cooperate to develop an ICANN procedure for ICANN's review and consideration of alleged conflicts between applicable laws and provisions of the Registry Agreement. In the meantime, ICANN will review and consider alleged conflicts between applicable laws and the provisions of the registry in a manner similar to ICANN's Procedure For Handling WHOIS Conflicts with Privacy Law.

      • Public Interest Commitments (Specification 11): Revisions were made to Specification 11 to implement the non-Category 1 safeguard advice in the GAC's Beijing Communiqué (i.e. safeguards applicable to all strings and Category 2 safeguards). The revisions to Specification 11 will incorporate standardized language that would be included in every New gTLD's Specification 11 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é.

      • Adjustment to Fees (Section 6.5): Taking the public comment into consideration, the fees section was revised to provide that adjustments to fees will become effective as of the first day of the first calendar quarter following ICANN's notice of the adjustment.

      • Referrals to Competition Authorities: In response to the public comments, the agreement was modified to provide that ICANN will, when feasible and appropriate, provider registry operators with advance notice prior to referring arrangement to competition authorities. (Section 2.9)

      • Brand gTLDs: ICANN is currently considering alternative provisions for inclusion in the Registry Agreement for .brand and closed registries, and is working with members of the community to identify appropriate alternative provisions. Following this effort, alternative provisions may be included in the Registry Agreement.

      The complete Summary of Changes to the New gTLD Registry Agreement is attached to this Resolution as Annex 2 [PDF, 898 KB]. A redline of the current agreement as compared to the prevision version dated 29 April 2013 is attached to this Resolution as Annex 3 [PDF, 1.62 MB]. 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]. In adopting this Resolution, the NGPC considered the comments and rationale provided for the changes as presented in the Annexes and the Report of Public Comments.

      What significant materials did the NGPC review?

      As part of its deliberations, the NGPC reviewed the following significant materials and documents:

      What factors did the NGPC find to be significant?

      The NGPC took into consideration the public comments form the community submitted during the various public comment forums on the New gTLD Registry Agreement. In addition, the NGPC considered the advice offered by the GAC in its Beijing Communiqué and the public comments on the safeguard advice in the GAC's Beijing Communiqué. The NGPC also considered the New gTLD Program as established in the Applicant Guidebook.

      Are there positive or negative community impacts?

      The adoption of the Resolution will permit successful New gTLD applicants to move forward to the contracting phase of the New gTLD Program. This progress will mark another milestone toward the goal of delegating new gTLDs into the root.

      Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

      There is no fiscal impact. The fee provisions in the New gTLD Registry Agreement will provide substantial additional resources for ICANN's compliance and registry engagement services in furtherance of ICANN's ongoing coordination, security and stability role. The revised agreement clarifies that registry fees will become due upon delegation, which will help fund expected expenditures to support the roll out of new gTLDs.

      Are there any security, stability or resiliency issues relating to the DNS?

      Approval of the proposed resolution will not impact security, stability or resiliency issues relating to the DNS. The NGPC previously considered issues of security, stability and resiliency of the DNS issue when adopting the New gTLD Program.

      Is this either a defined policy process within ICANN's Supporting Organizations or ICANN's Organizational Administrative Function decision requiring public comment or not requiring public comment?

      On 29 April 2013, ICANN initiated a public comment forum to solicit input on the proposed final draft of the New gTLD Registry Agreement. The public comment forum closed on 11 June 2013. 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.

    5. ALAC Statement on TMCH/Variants – Discussion of letter

      No resolution taken.

Published on 3 July 2013

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."