Skip to main content
Resources

Minutes | Meeting of the New gTLD Program Committee

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

A Special Meeting of the New gTLD Program Committee of the ICANN Board of Directors was held telephonically on 10 September 2013 at 13:00 UTC.

Committee Chairman Cherine Chalaby promptly called the meeting to order.

In addition to the Chair the following Directors participated in all or part of the meeting: Fadi Chehadé (President and CEO, ICANN), Chris Disspain, Bill Graham, Olga Madruga-Forti, Erika Mann, Ray Plzak, George Sadowsky, Mike Silber, and Kuo-Wei Wu.

Gonzalo Navarro sent apologies.

Jonne Soininen (IETF Liaison) and Francisco da Silva (TLG Liaison) were in attendance as non-voting liaisons to the Committee. Heather Dryden was in attendance as an observer to the Committee. Bruce Tonkin was in attendance as an invited (non-voting) observer for Item 1 on the Main Agenda.

ICANN Staff in attendance for all or part of the meeting: Akram Atallah, President, Generic Domains Division; John Jeffrey, General Counsel and Secretary; Megan Bishop; Michelle Bright; Samantha Eisner; Allen Grogan; Dan Halloran; Jamie Hedlund; Elizabeth Le; Karen Lentz; Cyrus Namazi; Olof Nordling; David Olive; Karine Perset; Erika Randall; Amy Stathos; Christine Willett; and Mary Wong.

These are the Minutes of the Meeting of the New gTLD Program Committee, which took place on 10 September 2013.

  1. Consent Agenda
    1. Approval of NGPC Meeting Minutes
  2. Main Agenda
    1. Update on String Similarity
    2. BGC recommendation on Reconsideration Request 13-5
    3. GAC Communiqué Durban – Comprehensive Review of the Scorecard
    4. GAC Communiqué Beijing – Scorecard
    5. GAC Communiqué Beijing – Category 1
    6. ALAC Statement on the Preferential Treatment for Community Applications in String Contention
    7. ALAC Statement on Community Expertise in Community Priority Evaluation
    8. AOB

 

  1. Consent Agenda

    1. Approval of NGPC Meeting Minutes

      The Chair introduced the item on the Consent Agenda. George Sadowsky moved and Chris Disspain seconded the resolution in the Consent Agenda and the Committee took the following action:

      Resolved (2013.09.10.NG01), the NGPC approves the minutes of the 13 July 2013 and 17 July 2013 New gTLD Program Committee Meetings.

      All members of the Committee present voted in favor of Resolution 2013.09.10.NG01. Gonzalo Navarro was not available to vote on the Resolution. The Resolution carried.

  2. Main Agenda

    1. Update on String Similarity

      The Chair provided an overview of the items on the main agenda to be considered by the Committee, and noted that ICANN Board Member Bruce Tonkin would participate in the discussion on the first agenda item to provide input on the string similarity review process.

      Bruce Tonkin provided the Committee with an overview of how the string similarity standards were developed, explaining that string similarity is based on the GNSO Policy Recommendation Number 2, which states that strings must not be confusingly similar to an existing or applied-for top-level domain.

      Bruce noted that when developing the string similarity standards, the GNSO considered the "confusingly similar" standard used in trademark law in various jurisdictions, and the Paris Convention for protection of intellectual property.

      Bruce provided the Committee with a summary of the string similarity review process in initial evaluations, which focuses on visual similarity, and the string confusion objection process. Bruce noted that there was a key decision made early on in the iterations of the Applicant Guidebook that ICANN, in the initial evaluation stage, would only examine strings for visual confusion.

      Bruce also explained the role of the string confusion objections in the process, and noted that the policy was to allow for a broader look at confusion – not just visual confusion. Bruce commented that that the string similarity objection is a dispute between two parties, and ICANN is not involved.

      Bruce commented that some applicants who have received unfavorable determinations from the string similarity review process or the string similarity objection process have proceeded to invoke the Reconsideration Request process provided for in the ICANN Bylaws.

      Mike Silber noted three key issues for the Committee to consider with regard to the string similarity decisions. Mike asked the Committee to consider what, if anything, should be done to address the perceived inconsistency between the findings of the various string confusion objection panels. Mike stated that the Committee also should consider the decisions of the string similarity review panel and whether there are changes needed in future rounds in light of the concerns raised in the current round. Mike noted that staff would prepare a briefing paper providing more details about these concerns for discussion at the Committee's next meeting.

      The Chair inquired whether Mike was suggesting that any action would only impact future rounds. Erika Mann asked whether Mike recommended that the Committee should ask the experts to provide consistent opinions. Mike clarified that the Committee should first understand whether there is a genuine problem before it takes action. Additionally, Mike recommended that the Committee needs to better understand the consequences of taking action to impact the current round.

      Akram Atallah recommended that the Committee keep separate the issues of the string similarity review, which looked only at visual similarity, from the string confusion objection. Akram indicated that staff would prepare a paper regarding these issues for future conversation.

      After the conclusion of the discussion, Bruce excused himself from the remainder of the meeting.

    2. BGC recommendation on Reconsideration Request 13-5

      The Chair introduced the item to the Committee and Amy Stathos presented an overview of Reconsideration Request 13-5, including the Board Governance Committee's (BGC) recommendation to the Committee. Amy noted that the requester argued that the decision of the string similarity review panel should be reversed so that "hotels" and "hoteis" are not in a contention set with each other. Amy also reminded the Committee of the basis in the Bylaws for Reconsideration Requests. The BGC determined that the requester had not stated proper grounds for reconsideration.

      George Sadowsky stated that he understood that the BGC did the right thing, but thought the end result that was contrary to ICANN's and the user's best interests. George noted he intended to abstain from voting as a result.

      Olga Madruga-Forti noted that she intended to abstain from the vote because there was not sufficient rationale provided for why the string similarity review panel made its determination.

      The Chair noted the party submitting the Reconsideration Request essentially just disagrees with the decision. Because the process was followed, the Chair noted that the Committee should not accept the Reconsideration Request.

      Ray Plzak agreed that the process was followed, but noted that the process needs to be reviewed to potentially add a mechanism that would allow persons who don't agree with the outcome to make an objection, other than using a Reconsideration Request. Ray recommended the Committee send a strong signal to the BGC, or adopt a resolution recommending that a the BGC consider development of a different mechanism to provide an avenue for the community to appeal the outcome of a decision based on the merits. Olga recommended that in the future, a remand or appeals mechanism may help alleviate the concerns noted.

      Bill Graham agreed with Ray's suggestion, and noted that generally, there is a considerable level of discomfort and dissatisfaction with the process as expressed by Committee members. The Chair agreed with Bill's sentiment.

      The General Counsel and Secretary noted that ICANN has tried to encourage more use of the ombudsman, or other accountability mechanisms for these types of concerns.

      The President and CEO moved and Ray Plzak seconded the resolution.

      The Committee then took the following action:

      Whereas, Booking.com B.V.'s ("Booking.com") Reconsideration Request, Request 13-5, sought reconsideration of the ICANN staff action of 26 February 2013, when the results of the String Similarity Panel were posted for the New gTLD Program, placing the applications for .hotels and .hoteis into a string similarity contention set.

      Whereas, the BGC considered the issues raised in Reconsideration Request 13-5.

      Whereas, the BGC recommended that Reconsideration Request 13-5 be denied because Booking.com has not stated proper grounds for reconsideration.

      Resolved (2013.09.10.NG02), the New gTLD Program Committee adopts the BGC Recommendation on Reconsideration Request 13-5, which can be found at http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-booking-01aug13-en.pdf [PDF, 117 KB].

      The Chair took a voice vote of Resolution 2013.09.10.NG02. Cherine Chalaby, Fadi Chehadé, Chris Disspain, Bill Graham, and Mike Silber voted in favor of Resolution 2013.09.10.NG02. Olga Madruga-Forti, Ray Plzak, George Sadowsky and Kuo-Wei Wu abstained from voting on Resolution 2013.09.10.NG02. Erika Mann and Gonzalo Navarro were not available to vote on Resolution 2013.09.10.NG02. The Resolution carried.

      Rationale for Resolution 2013.09.10.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 BGC Recommendation on Reconsideration Request 13-5 and finds the analysis sound.

      Having a reconsideration process whereby the BGC reviews and, if it chooses, makes a recommendation to the Board/NGPC 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.

      The Request seeks a reversal of the 26 February 2013 decision of the String Similarity Review Panel (the "Panel") to place Booking.com's application for .hotels in the same contention set as .hoteis. Specifically, Booking.com asserted that its applied for string of .hotels can co-exist in the root zone with the applied for string .hoteis without concern of confusability, and therefore, .hotels should not have been placed in the same contention set with .hoteis.

      The Request calls into consideration: (1) whether the Panel violated any policy or process in conducting its visual similarity review of Booking.com's application; and (2) whether the NGPC has the ability to overturn the Panel's decision on .hotels/.hoteis on the basis that the decision was provided as an "advice to ICANN" and that ICANN made the ultimate decision to accept that advice.

      The BGC noted that a similar reconsideration request was previously submitted by Booking.com on 28 March 2013 and placed on hold pending the completion of a request pursuant to ICANN's Documentary Information Disclosure Policy. Therefore, this Request relates back to the date of the original filing and should be evaluated under the Bylaws that were in effect from 20 December 2012 through 10 April 2013.

      In consideration of the first issue, the BGC reviewed the grounds stated in the Request, including the attachments, and concluded that Booking.com failed to adequately state a Request for Reconsideration of Staff action because they failed to identify any policy or process that was violated by Staff. The BGC noted that Booking.com does not suggest that the process for String Similarity Review set out in the Applicant Guidebook was not followed, or that ICANN staff violated any established ICANN policy in accepting the Panel's decision to place .hotels and .hoteis in the same contention set. Rather, Booking.com seeks to supplant what it believes the review methodology for assessing visual similarity should have been as opposed to the methodology set out in Section 2.2.1.1.2 of the Applicant Guidebook and asks that the BGC (and the Board through the New gTLD Program Committee) retry the 26 February 2013 decision based upon its proposed methodology. The BGC concluded that this is not sufficient ground for Reconsideration because the Reconsideration process is not available as a mechanism to re-try the decisions of the evaluation panels.

      With respect to Booking.com's contention that the 26 February 2013 decision was taken without material information, such as that of Booking.com's linguistic expert's opinion or other "information that would refute the mistaken contention that there is likely to be consumer confusion between '.hotels' and '.hoteis'", the BGC concluded that there is no process in the String Similarity Review for applicants to submit additional information. As ICANN has explained to Booking.com in response to its DIDP requests for documentation regarding the String Similarity Review, the Review was based upon the methodology in the Applicant Guidebook, supplemented by the Panel's process documentation; the process does not allow for additional inputs. The BGC noted that Booking.com's disagreement as to whether the methodology should have resulted in a finding of visual similarity does not mean that ICANN (including the third party vendors performing String Similarity Review) violated any policy in reaching the decision (nor does it support a conclusion that the decision was actually wrong).

      In consideration of the second issue, the BGC determined that Booking.com's suggestion that the Board (through the NGPC) has the ability to overturn the Panel's decision on .hotels/.hoteis because the Panel merely provided "advice to ICANN" and that ICANN made the ultimate decision to accept that advice is based upon inaccurate conclusions of the String Similarity Review process. As such, the BGC concluded that Booking.com has not stated sufficient grounds for reconsideration. The BGC noted that all applied for strings are reviewed the Panel according to the standards and methodology of the visual string similarity review set out in the Applicant Guidebook. The Guidebook clarifies that once contention sets are formed by the Panel, ICANN will notify the applicants and will publish results on its website. (AGB, Section 2.2.1.1.1.) Whether the results are transmitted as "advice" or "outcomes" or "reports", ICANN had always made clear that it would rely on the advice of its evaluators in the initial evaluation stage of the New gTLD Program, subject to quality assurance measures. The subsequent receipt and consideration of GAC advice on singular and plural strings does not change the established process for the development of contention sets based on visual similarity as the ICANN Board is required under the Bylaws to consider GAC Advice on issues of public policy, such as singular and plural strings. The BGC concluded that Booking.com is actually proposing a new and different process when it suggests that ICANN should perform substantive review (instead of process testing) over the results of the String Similarity Review Panel's outcomes prior to the finalization of contention sets.

      In addition to the above, the full BGC Recommendation that can be found at http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-booking-01aug13-en.pdf [PDF, 117 KB] and that is attached to the Reference Materials to the Board Submission supporting this resolution, shall also be deemed a part of this Rationale.

      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.

      Members of the Committee who abstained from voting offered voting statements. Ray Plzak noted that he abstained from voting because he is disappointed in what is being done to remedy the situation. Ray would like to see more resolve to fix the process.

      Olga Madruga-Forti stated that the BGC has done an appropriate job of applying a limited review standard to the application for reconsideration, but unfortunately, in this circumstance, to apply that limited review accompanied by a lack of information regarding the rationale of the string similarity review panel is not possible in a logical and fair manner. The public interest would not be served by applying the limited review standard without proper information on the basis and reasoning for the decision of the panel. In my opinion, the public interest would be better served by abstaining and continuing to explore ways to establish a better record of the rationale of the string similarity review panel in circumstances such as this.

      Kuo-Wei Wu agreed with the voting statements of Ray and Olga.

      George Sadowsky provided the following voting statement: I have a strong concern regarding the ratification of the BGC recommendation to deny the reconsideration request regarding string contention between .hoteis and .hotels, and I therefore have therefore abstained when the vote on this issue was taken.

      The reconsideration process is a very narrowly focused instrument, relying solely upon investigating deviations from established and agreed upon process. As such, it can be useful, but it is limited in scope. In particular, it does not address situations where process has in fact been followed, but the results of such process have been regarded, sometimes quite widely, as being contrary to what might be best for significant or all segments of the ICANN community and/or Internet users in general.

      The rationale underlying the rejection of the reconsideration claim is essentially that the string similarity process found that there was likely to be substantial confusion between the two, and that therefore they belonged in a contention set. Furthermore, no process has been identified as having been violated and therefore there is nothing to reconsider.

      As a Board member who is aware of ICANN's Bylaws, I cannot vote against the motion to deny reconsideration. The motion appears to be correct based upon the criteria in the Bylaws that define the reconsideration process and the facts in this particular case.

      However, I am increasingly disturbed by the growing sequence of decisions that are based upon a criterion for user confusion that, in my opinion, is not only both incomplete and flawed, but appears to work directly against the concept that users should not be confused. I am persuaded by the argument made by the proponents of reconsideration in this case that users will in fact not be confused by .hoteis and .hotels, since if they enter the wrong name, they are very likely to be immediately confronted by information in a language that they did not anticipate.

      Confusion is a perceptual issue. String similarity is only one consideration in thinking about perceptual confusion and in fact it is not always an issue. In my opinion, much more perceptual confusion will arise between .hotel and .hotels than between .hotels and .hoteis. Yet if we adhere strictly to the Guidebook and whatever instructions have or have not been given to string similarity experts, it is my position that we work against implementing decisions that assist in avoiding user confusion, and we work in favor of decisions that are based upon an incorrect, incomplete and flawed ex ante analysis of the real issues with respect to user confusion.

      The goal of the string similarity process is the minimization of user confusion and ensuring user trust in using the DNS. The string similarity exercise is one of the means in the new gTLD process to minimize such confusion and to strengthen user trust. In placing our emphasis, and in fact our decisions, on string similarity only, we are unwittingly substituting the means for the goal, and making decisions regarding the goal on the basis of a means test. This is a disservice to the Internet user community.

      I cannot and will not vote in favor of a motion that reflects, directly or indirectly, an unwillingness to depart from what I see as such a flawed position and which does not reflect In my opinion an understanding of the current reality of the situation.

      The Committee agreed to discuss the process further at its meeting in Los Angeles.

    3. GAC Communiqué Durban – Comprehensive Review of the Scorecard

      Chris Disspain led the Committee through a discussion of each of the items on the proposed scorecard to address the GAC's advice in the Durban Communiqué. Chris noted that the window for applicants to respond to the GAC's advice had closed and the comments were available for consideration by the Committee.

      The Committee discussed that additional time was needed to consider its position on the GAC consensus objection advice concerning .AMAZON given the information presented in the applicant's response.

      Chris noted that recently, a series of communications concerning the .THAI application were provided to the Committee, which assert that the GAC's advice was not valid. Chris clarified that GAC's position in respect to its consensus advice on the application for .THAI is supported by the government of Thailand.

      Chris discussed the proposed position in the scorecard for .SPA, .YUN, .GUANGZHOU, and .SHENZHEN. Kuo-Wei Wu asked whether the proposed response in the scorecard applied to all strings with geographic indicators. Chris clarified that the scorecard only considers the strings for which the GAC issued advice.

      The Committee also discussed the new correspondence from the GAC regarding .WINE and .VIN. Heather Dryden acknowledged the complexity of the issue, and noted that even though the GAC did not arrive at consensus agreement, there is benefit in increasing the Committee's understanding about the reasons for the differing views that exist among the members in the GAC on the applications for .VIN and .WINE. The Committee decided to consider the advice at its next meeting in Los Angeles.

      The Committee considered the remaining items in the scorecard.

      Chris Disspain moved and George Sadowsky seconded the resolution.

      The Committee then took the following action:

      Whereas, the GAC met during the ICANN 47 meeting in Durban and issued a Communiqué on 18 July 2013 ("Durban Communiqué").

      Whereas, on 1 August 2013, ICANN posted the Durban Communiqué and officially notified applicants of the advice <http://newgtlds.icann.org/en/announcements-and-media/announcement-01aug13-en>, triggering the 21-day applicant response period pursuant to the Applicant Guidebook Module 3.1.

      Whereas, the NGPC met on 12 August 2013 to consider a plan for responding to the GAC's advice on the New gTLD Program, transmitted to the Board through its Durban Communiqué.

      Whereas, the NGPC has considered the applicant responses submitted during the 21-day applicant response period, and the NGPC has identified items of advice in the attached scorecard where its position is consistent with the GAC's advice in the Durban Communiqué.

      Whereas, the NGPC developed a scorecard to respond to the GAC's advice in the Durban Communiqué similar to the one used to address the Beijing Advice as well as during the GAC and the Board meetings in Brussels on 28 February and 1 March 2011, and has identified where the NGPC's position is consistent with GAC advice, noting those as "1A" items.

      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.09.10.NG03), the NGPC adopts the "ICANN Board New gTLD Program Committee Scorecard in response to GAC Durban Communiqué" (10 September 2013), attached as Annex 1 [PDF, 119 KB] to this Resolution, in response to the items of GAC advice in the Durban Communiqué as presented in the scorecard.

      All members of the Committee present voted in favor of Resolution 2013.09.10.NG03. Erika Mann and Gonzalo Navarro were not available to vote on Resolution 2013.09.10.NG03. The Resolution carried.

      Rationale for Resolution 2013.09.10.NG03

      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> permit 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 Durban Communiqué dated 18 July 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 accepting the GAC's Durban advice as described in the attached ICANN Board New gTLD Program Committee Scorecard in response to GAC Durban Communiqué" (10 September 2013). As noted in the scorecard, most items of advice are scored as "1A," which indicates that the NGPC's position is consistent with GAC advice as described in the scorecard.

      Which stakeholders or others were consulted?

      On 1 August 2013, ICANN posted the GAC advice and officially notified applicants of the advice <http://newgtlds.icann.org/en/announcements-and-media/announcement-01aug13-en>, triggering the 21-day applicant response period pursuant to the Applicant Guidebook Module 3.1. The complete set of applicant responses are provided at: http://newgtlds.icann.org/en/applicants/gac-advice/durban47. The NGPC has considered the applicant responses in formulating its response to the GAC advice as applicable.

      What concerns or issues were raised by the community?

      As part of the 21-day applicant response period, several of the applicants indicated that they have entered into dialogue with the affected parties, and they anticipated reaching agreement on the areas of concern. Some of the applicants noted that they have proposed additional safeguards to address the concerns of the relevant governments are unsure as to whether a settlement can be reached. These applicants asked that the ICANN Board allow their applications to proceed even if an agreement among the relevant parties cannot be reached. Additionally, inquiries have been made as to whether applicants and the relevant governments will have the opportunity to comment on conversations among the GAC, ICANN Board, and ICANN staff. There have been requests that that the GAC, NGPC, and ICANN staff consult with applicants before decisions regarding any additional safeguards are made.

      Other applicants noted the important role of governments in the multi-stakeholder model, but advised the NGPC that it should not allow governments to exercise veto power over ICANN policies adopted through the multi-stakeholder process.

      What significant materials did the Board review?

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

      What factors did the Board find to be significant?

      In adopting its response to the GAC's advice in the Durban Communiqué, the NGPC considered the applicant comments submitted, the GAC's advice transmitted in the Durban Communiqué, and the procedures established in the AGB.

      Are there positive or negative community impacts?

      The adoption of the GAC advice as provided in the attached scorecard 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.

      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?

      ICANN posted the GAC advice and officially notified applicants of the advice on 1 August 2013. This triggered the 21-day applicant response period pursuant to the Applicant Guidebook Module 3.1.

    4. GAC Communiqué Beijing – Scorecard

      The Committee engaged in a discussion on the open items of GAC advice in the Beijing Communiqué, including the Category 1 and Category 2 safeguard advice, and the protections for IGOs.

      Chris Disspain provided the Committee with an update on the current proposal to address protections for IGOs, which would leverage the functionality of the current Trademark Clearinghouse claims function and the rapid take-down process of the URS. Chris noted that there might be a session among the NGPC and IGOs at the end of September to discuss a proposed approach to providing the protections.

      With respect to the Category 2 safeguard advice, Christine Willet provided the Committee with an update of responses received from the applicants of strings identified in the GAC's advice regarding exclusive access for a generic string. Akram Atallah noted that the applicant responses received to date indicate that only a handful of the applicants intended to provide exclusive registry access.

      The Committee agreed to discuss the path forward for the Category 2 safeguard advice at its next meeting.

    5. GAC Communiqué Beijing – Category 1

      Chris Disspain provided the Committee an update on the proposed approach to respond to the GAC's advice in the Beijing Communiqué regarding the Category 1 safeguards, and the Committee engaged in a discussion regarding a path forward. The discussion included consideration of how the safeguards could be implemented as contractual provisions, and distinguishing the list of Category 1 strings between those strings associated regulated industries, and all other listed strings.

      Chris recommended a strategy for continued progress on the Category 1 safeguard advice, which included preparing a paper describing the proposed framework to address the advice, and socializing the paper among a small number of GAC members before it is communicated to the GAC.

      Jonne Soininen recommended that GAC members from non-English speaking nations be included in the discussions. Olga Madruga-Forti concurred with the recommendation.

      Heather Dryden commented that the full GAC membership should be able to participate in the process, as appropriate, before the Committee finalizes the proposal.

      Jonne inquired whether there are national variations that could cause concern from the GAC about what is considered regulated industry and what is not. Olga noted the importance of beginning to consider the consequences if there is non-compliance with a contractual obligation related to the Category 1 safeguards.

      The Committee acknowledged the difficulty in scheduling an intersessional meeting with the GAC on this matter given the timing of the Buenos Aires meeting, and discussed how to move forward in advance of the Buenos Aires meeting.

    6. ALAC Statement on the Preferential Treatment for Community Applications in String Contention

      George Sadowsky provided the Committee with an overview of the concern expressed by the ALAC in its Statement on the Preferential Treatment for Community Applications in String Contention, noting that ALAC requested the Committee to provide preferential treatment to applications that meet the characteristics of community applications even if not submitted as a community application.

      George indicated that he had discussions with the drafter of the ALAC Statement to better understand the concerns underlying the ALAC's letter.

      The Committee discussed the concerns with implementing the ALAC's recommendation. Chris Disspain highlighted the need to be consistent with the position the Committee communicated to the GAC on this issue.

      George noted that it may be difficult to accept the recommendation in the ALAC Statement, and Ray Plzak agreed.

      George agreed to work with staff to prepare a response to the ALAC, and noted that the response should include consideration of the additional questions sent by the ALAC after it submitted the statement at hand.

    7. ALAC Statement on Community Expertise in Community Priority Evaluation

      George Sadowsky presented the concerns expressed in the ALAC Statement on Community Expertise in Community Priority Evaluation, noting that the ALAC questions the ability of the chosen community priority evaluator to evaluate with respect to a mind-set that is more community-focused as opposed to business-focused.

      The Committee considered whether it would be appropriate to accept the ALAC's advice for ALAC to supply evaluators from the community to the panel, and George recommended against adopting this approach. Ray Plzak agreed, and commented that the Committee should not set a precedent in terms of inviting other people into assist with the work of panels, outside of the established process the exists to form the panels.

      George proposed that the Committee direct staff to alert the panel of the concerns expressed in the ALAC statement. George also outlined a proposed response to the ALAC and agreed to work with staff on a formal response.

      George commented that upon completion of the community priority evaluation process, it may be beneficial to do an informal audit to look for any egregious violations of understanding about the community priority evaluation.

    8. AOB

      The Committee did not discuss any other business, and the Chair called then called the meeting to a close.

Published on 30 September 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."