Skip to main content
Resources

Approved Board Resolutions | Special Meeting of the ICANN Board

  1. Consent Agenda
    1. Approval of Board Meeting Minutes
    2. Appointment of Ben Butler to SSAC
    3. Approval of AROS Contract Agreement
  2. Main Agenda
    1. Update to IDN ccTLD Fast Track Implementation
    2. Approval of 2013 RAA
  3. Executive Session
    1. Confidential Resolution

 

  1. Consent Agenda:

    1. Approval of Board Meeting Minutes

      Resolved (2013.06.27.01), the Board approves the minutes of the 18 May 2013 Regular Meeting of the ICANN Board.

    2. Appointment of Ben Butler to SSAC

      Whereas, the Security and Stability Advisory Committee (SSAC) does review its membership and make adjustments from time-to- time.

      Whereas, the SSAC Membership Committee, on behalf of the SSAC, requests that the Board should appoint Ben Butler to the SSAC.

      It is resolved (2013.06.27.02) that the Board appoints Ben Butler to the SSAC.

      Rationale for Resolution 2013.06.27.02

      The SSAC is a diverse group of individuals whose expertise in specific subject matters enables the SSAC to fulfill its charter and execute its mission. Since its inception, the SSAC has invited individuals with deep knowledge and experience in technical and security areas that are critical to the security and stability of the Internet's domain name system.

      The SSAC's continued operation as a competent body is dependent on the accrual of talented subject matter experts who have consented to volunteer their time and energies to the execution of the SSAC mission. Ben Butler brings valuable skills to the SSAC. Specifically, he brings his experience as Director of Network Abuse at GoDaddy, a large registrar. Also, Mr. Butler brings experience as a host provider and contacts with other host providers, both of which are needed additions to the SSAC. Finally, he brings his strong knowledge of DNS abuse issues.

    3. Approval of AROS Contract Agreement

      Whereas, ICANN and Street Solutions have negotiated in good faith the terms for a proposed statement of work for the development of the Automated Registrar Onboarding System (AROS);

      Whereas, the Board has reviewed the terms of the proposed Statement of Work for ICANN;

      Whereas, approval is required to commit ICANN funds in the amount of USD $650,450;

      Whereas, execution of the agreement enables the development of this tool to support Registries and Registrars accreditation;

      Resolved (2013.06.27.03), the Board authorizes the President and CEO to enter into the proposed agreement with Solutions Street.

      Resolved (2013.06.27.04), the request to approve the contract with Solutions Street for the development of the Automated Registrar Onboarding System (AROS) is approved.

      Rationale for Resolutions 2013.06.27.03 – 2013.06.27.04

      ICANN's Disbursement Policy limits ICANN officers from contracting for or disbursing more than US $500,000.00 per obligation. ICANN is therefore adhering to its policy in seeking the Board's approval to enter into these contractual obligations that exceed the $500,000 per obligation item. ICANN identified a vendor to build the AROS system and the contract with the vendor is estimated at $650,450, including license.

      The proposed solution is an Automated Registrar Onboarding System (AROS) for ICANN accredited Registrars. The system described in this document is intended to provide Registrars with a consistent user interface for managing information about their Registrar and when requesting accreditation by (primarily) Generic Top-Level Domain Registries, a workspace in which Registries can manage accreditation requests from Registrars, and an administrative interface that allows an ICANN-designated Administrator to manage AROS.

      The requirements for the system were developed by the Working Group (WG) composed of representatives from the Registry and Registrar stakeholder groups, ICANN staff and an outside consultant specialized in requirements. The representatives from the registry and registrar groups (three of each) are volunteers identified by the respective stakeholder chairs. In addition to the working team described, staff has conducted surveys with registries and registrars on two occasions to validate the requirements. 

      The Board's approval of entering into this contractual obligation will have a positive impact on the community because it will allow for a more timely and efficient way for the registries and registrars to contract. By doing that, ICANN is empowering a more competitive and efficient environment. There are fiscal impacts on ICANN but all of those impacts have been anticipated in the approved FY 2013 and draft FY 2014 budgets. There will not be any security, stability or resiliency issues relating to the domain names system.

  2. Main Agenda:

    1. Update to IDN ccTLD Fast Track Implementation

      Whereas, the ICANN Board of Directors approved the Fast Track Implementation Plan on 30 October 2009 (http://www.icann.org/en/minutes/resolutions-30oct09-en.htm#2);

      Whereas, under the IDN ccTLD Fast Track process, one independent panel performs both the technical and string similarity evaluation (the DNS Stability Evaluation);

      Whereas, the ccNSO developed and the ccNSO Council passed the recommendations for the IDN ccTLD String Selection Policy to include a two-panel process for string similarity evaluation (http://ccnso.icann.org/node/38787 [PDF, 119 KB]);

      Whereas, ICANN has received multiple inputs and advice from the community calling for additional transparency and consistency of the string similarity evaluation, including Advice from the Governmental Advisory Committee;

      Whereas, the ccNSO chairperson sent a request to the ICANN Board of Directors to implement the two-panel process for string similarity review in the IDN ccTLD Fast Track Process;

      RESOLVED (2013.06.27.05), the ICANN Board of Directors approves amending the Fast Track Implementation Plan to implement the two-panel process for string similarity review in the IDN ccTLD Fast Track Process. The President and CEO is directed to incorporate the amendment into the Fast Track Implementation Plan previously adopted by the ICANN Board on 30 October 2009 (amended on 8 December 2011) and implement the amendment as soon as practicable.

      RESOLVED (2013.06.27.06), the ICANN Board of Directors approves amending the Fast Track Implementation Plan to allow for all pending requests for IDN ccTLD strings under the Fast Track Process to have the option to request evaluation by the new Extended Process Similarity Review Panel (EPSRP) once the EPSRP is comprised.

      Rationale for Resolutions 2013.06.27.05 – 2013.06.27.06

      Why is the Board addressing this issue now?

      The ccNSO IDN ccTLD PDP is nearing its completion. One of the proposals under the expected policy recommendation is to introduce a two–panel mechanism for the confusing similarity review of requested IDN ccTLD strings. As one of the purposes for the introduction of the IDN ccTLD Fast Track is to experiment with a methodology for the selection of IDN ccTLD strings, thereby, informing the ccNSO Policy Development Process while meeting near-term demand for the introduction of IDN ccTLDs. The introduction of the two-panel mechanism as a test bed within the Fast Track Process allows for testing and refining, if needed, of the proposed two-panel mechanism and methodology. Modifying the Fast Track Process in this way is also expected to achieve the goal of meeting near-term demands for the continued introduction of IDN ccTLDs. Finally, the community has long been calling for a modification to the string similarity review within the Fast Track Process, and following the ccNSO's guidance here will enhance ICANN's accountability.

      What is the proposal being considered?

      The proposed modification to the Fast Track Implementation Plan is to introduce a second, independent expert Panel to review IDN ccTLD Fast Track strings regarding confusing similarity. This is in addition to the existing string similarity review panel. The proposal also calls for all pending Fast Track IDN ccTLD string requests, including those that have previously failed the string similarity review, to have the option of requesting that their application be reviewed by the EPSRP. This will allow all pending and future applications to go through consistent evaluations, while having no impact on those applications have already successfully passed through the Fast Track Process. Those that successfully passed would never have needed to proceed to the EPSRP in any event.

      Which stakeholders or others were consulted?

      The string similarity topic was the focus of the two annual reviews of the IDN ccTLD Fast Track Process to date. It has been discussed at public sessions held during ccNSO meetings since the ICANN San Francisco meeting in March 2011.

      In April 2013, the ccNSO Council adopted the Final Report on the IDN country code Policy development process (http://ccnso.icann.org/workinggroups/idn-ccpdp-final-29mar13-en.pdf [PDF, 376 KB]).

      This Report includes the proposals of IDN ccPDP working group 1(IDN ccPDP WG 1), which have gone through extensive public consultations. IDN ccPDP WG 1 focused on the development of draft policy recommendations for the selection of IDN ccTLDs associated with the territories listed in the ISO 3166-1 list, which in time should replace the IDN ccTLD Fast Track methodology. The proposals include the introduction of two panels for the string confusion similarity validation, whereby the second panel provides a final and definite review of the string, based on scientific research. Public comment received during both annual reviews, support the introduction of the second panel. In addition the Governmental Advisory Committee advised, among others, the ICANN Board to:

      • Reconsider recently refused IDNs under the Fast Track Process, in particular those nominated by public or national authorities.
      • To create a mechanism of appeal that will allow challenging the decisions on confusability related to proposed IDN ccTLDs, without prejudice to the previous bullet and for transparency and accountability purposes.

      While the EPSRP is not an appeals process, it will serve to provide a different type of string similarity review on a separate basis from the existing string similarity panel. The introduction of the EPSRP will also provide a path for review of those IDN ccTLD Fast Track Applicants that did not successfully pass the existing string similarity panel review. In this way, taking this action will address the ccNSO's community-built recommendations as well as GAC advice.

      Are there fiscal impacts or ramifications on ICANN?

      This amendment will have a budgetary implication in that ICANN will have to empanel a second group of experts to perform a second and final validation of the requested IDN ccTLD string. This amendment is not expected to have an impact on the security or stability of the DNS.

    2. Approval of 2013 RAA

      Whereas, ICANN and a group selected by the Registrar Stakeholder Group, the Registrar Negotiating Team, have been negotiating amendments to ICANN's 2009 Registrar Accreditation Agreement (RAA) since 2011.

      Whereas, the negotiations have resulted in the proposed 2013 RAA, that addresses all 12 recommendations provided in 2009 from law enforcement, as well as other revisions.

      Whereas, ICANN is committed to having the 2013 RAA in place before the delegation of gTLDs through the New gTLD Program.

      Whereas, ICANN and Registrars require sufficient time to transition to the terms of the 2013 RAA, and Board approval will provide the necessary surety of the applicable terms.

      Resolved (2013.06.27.07), the Board approves the form of the 2013 RAA.

      Resolved (2013.06.27.08), the President and CEO is directed to take all necessary steps to proceed to execution of the 2013 RAA with all eligible Registrars and registrar applicants.

      Resolved (2013.06.27.09), the Board thanks the Registrar Stakeholder Group, and particularly the members of the Registrar Negotiating Team, for their dedication, time and effort in the negotiation process.

      Rationale for Resolutions 2013.06.27.07 – 2013.06.27.09

      Why is the Board addressing this issue now?

      The long-standing negotiations on the 2013 RAA have come to a successful close, and a proposed 2013 RAA was presented to the Board. It is important for the 2013 RAA to be approved at this time, as the Board has accepted the GAC Advice in the Beijing Communiqué that the "the 2013 Registrar Accreditation Agreement should be finalized before any new gTLD contracts are approved." Approving the 2013 RAA now allows the Board to meet this advice. In addition, ICANN has made multiple representations to the community that the 2013 RAA will be in place prior to the delegation of new gTLDs. Approving the 2013 RAA now also gives ICANN and the registrars certainty of the new terms that will be applicable, and allows both ICANN and the registrars to move forward with implementation work to meet the heightened obligations. Finally, the ICANN community has been long awaiting the new RAA after following the negotiations since the end of 2011.

      What is the proposal being considered?

      The 2013 RAA includes provisions addressed to protect registrants through a further updated contractual framework. The 2013 RAA reflects hard-fought concessions on many of key issues raised throughout the negotiations, as well as issues raised within public comment. The 2013 RAA, represents a significant improvement over the current 2009 version, and significantly raises performance requirements for every ICANN accredited registrar, thereby bringing dramatic improvements to the domain name ecosystem.

      The highlights of this proposed 2013 RAA include:

      • The 12 Law Enforcement Recommendations that served as the impetus for these negotiations are all addressed in this proposed draft. The attached Law Enforcement Summary Chart identifies the section or specification of the 2013 RAA that addressed each recommendation. Some of the highlights include the creation of an abuse point of contact at each registrar, Whois verification and validation requirements at the registrant and the account holder levels, stronger language on registrar obligations for resellers, and new data retention obligations.

      • Enhanced Compliance Tools including broader suspension and termination tools, clarification of audit rights and access to information to facilitate ongoing investigations, and annual certification requirements.

      • A Registrant Rights and Responsibilities Document that sets out, in clear and simple language, the rights and responsibilities that are set out in the 2013 RAA, such as the types of information that registrants can expect to be made available to them about terms and conditions of registrations, fees and customer service processes. The document also emphasizes the registrant's role in providing accurate contact information, and responsibilities in maintaining domain name registrations. These enumerated rights and responsibilities are not comprehensive of all registrant rights and responsibilities set out in consensus policies, however this document is closely tied to the terms of the 2013 RAA.

      • Registrar Responsibility for Reseller Compliance with all appropriate terms of the RAA.

      • Consolidation with the Registry Agreement for New gTLDs. Where appropriate, ICANN and the Registrar NT have agreed to mirror language from the Registry Agreement, to allow for contracts that are better aligned. The New gTLD Registry Agreement and the 2013 RAA are anticipated to complement each other as Registries and Registrars move towards agreements that better reflect the changing marketplace.

      • Proxy and Privacy Provider Interim Requirements. ICANN and the Registrar NT have agreed to interim protections that will be in place for proxy and privacy services offered through registrars. These interim protections will require that information is made available on items such as customer service processes and when a provider will relay information on the underlying user of the domain name registration. While these are not comprehensive of the protections that some have requested to be put in place for proxy and privacy providers, these interim protections will provide a more responsible marketplace until a formal accreditation program is developed.

      Which stakeholders or others were consulted?

      The RAA negotiations were initiated because of proposals raised by the law enforcement community. Throughout the negotiations, ICANN and the Registrar NT consulted with representatives of law enforcement and the Governmental Advisory Committee (GAC) regarding how the 12 law enforcement recommendations were implemented. A summary of how the law enforcement recommendations were integrated into the 2013 RAA is available at http://www.icann.org/en/news/public-comment/proposed-raa-22apr13-en.htm. The GAC noted its appreciation for the improvements to the RAA that incorporate the 2009 GAC-Law Enforcement Recommendations, and also noted that it is pleased with the progress on providing verification and improving accuracy of registrant data and supports continuing efforts to identify preventative mechanism that help deter criminal or other illegal activity.

      In addition to consultations with law enforcements and the GAC, ICANN has hosted public, interactive sessions on the RAA negotiations at the Costa Rica, Prague, Toronto and Beijing meetings. Upon request, representatives from ICANN staff also made presentations to the GNSO Council, At-Large working groups, various constituencies and stakeholder groups in the GNSO, and law enforcement representatives. In addition, ICANN has posted three versions of the RAA publicly, with public comment sought in March 2013 and April 2013. The 22 April 2013 public comment was over the proposed final 2013 RAA, which included all agreements between ICANN and the Registrar NT. Nineteen commenters participated in the 22 April 2013 comment forum, including representatives of the Registrar Stakeholder Group, the ALAC, the Intellectual Property Constituency and the Business Constituency. In support of the posting of the proposed final 2013 RAA, ICANN hosted an interactive webinar in May 2013 that was attended by more than 100 attendees on the phone and in Adobe Connect.

      After review of the public comments, ICANN also consulted with the Registrar Negotiating Team again to confirm the Registrars' support for identified changes.

      What concerns or issues were raised by the community?

      Throughout the course of the negotiations, concerns have been raised on variety of issues within the proposed RAA, which were taken into the account in the negotiations. For example, there was significant concern raised in parts of the community regarding over-development of proxy and privacy service standards outside of the policy development process. As a result, ICANN and the Registrar NT identified a solution that set out minimum standards for registrars to impose on proxy and privacy services offered at registration, while setting out a path to community involvement in the development of a Proxy/Privacy Accreditation Program. However, this did not alleviate all concerns in this area, nor were all concerns able to be handled in this fashion.

      With this last posting of the proposed 2013 RAA, the main areas of concern raised were the following:

      • For Whois Accuracy, the IPC, BC and other commenters supported the use of pre-resolution verification, as opposed to allowing a 15-day window after resolution within which the verification could occur. This request for pre-resolution verification has been raised previously in the negotiations, and because of the potential for large change to the domain name registration process, as well as the ongoing work to create a new method of dealing with gTLD Registration Data, it was determined – and explained to the community – that the pre-resolution verification was not feasible for introduction at this time, without further community work and development.

      • Similarly there have been requests for verification of both an email and phone number, over registrar and other's concerns that it is not always feasible – and in some areas of the world nearly impossible – to perform phone verification. Further changes in this areas were also deferred in favor of the ongoing work on gTLD Registration Data.

      • For registrations through proxy and privacy service providers, multiple commenters called for (as they had been calling for throughout the RAA development process) verification of the data of the underlying customer. As we previously explained to the community, the forthcoming policy work on a Proxy and Privacy Accreditation Program will be place to develop these sorts of requirements, as the lines of enforcement will be clearer in that situation. In addition, many in the community opposed the introduction of this type of requirement at this time. Similarly, the community is currently not in consensus on the mechanism for more explicit requirements for the reveal and relay of underlying customer data, and though many have commented that ICANN should put those types of requirements in place now, that work has also been deferred to the larger community-based policy work on Accreditation. One common concern recently raised in regards to the proxy/privacy obligations set forth in the 2013 RAA was that we needed to be clearer about the applicability to resellers, and ICANN has taken that change on and it is reflected in the 2013 RAA as approved by the Board.

      • Some commenters raised concerns about the new Registrant Rights and Responsibilities document, suggesting that it does not go far enough in recognizing more general rights and responsibilities. Because of the specific purpose of the Registrant Rights and Responsibilities specification – which is to track to the terms of the 2013 RAA – we have clarified the title of the document. If the community wishes to produce a broader declaration of the rights and responsibilities, nothing within the 2013 RAA would preclude that work.

      • Some commenters noted concerns that the amendment processes put in place were too onerous for ICANN in the event that it wished to put an amendment in place over the objection of the Registrars. However, ICANN believes that the Board-approved amendment process reflected in the 2013 RAA is a balance that recognizes the role of policy development in the multistakeholder model, and though complex, provides a powerful mechanism in the event it ever needs to be invoked.

      • While commenters were generally supportive of the 2013 RAA and the advancements that it brings, many of those same commenters noted dissatisfaction with the process that led to the development of the 2013 RAA. Many were dissatisfied that the negotiations were bilateral, without even an opportunity for community observation of the negotiation sessions, let alone the ability to propose language during the negotiations. While it is too late to modify the process used previously, it is important to recall that the RAA itself did not include any path to negotiation; the process to be used was not clear. To help assure that the community will have a voice in future amendments to the RAA, the RAA now incorporates specific public comment requirements when amendments are under consideration or negotiations have been initiated.

      Included here is a summary of some of key concerns raised. A full summary and analysis of the comments on the proposed final RAA (posted at http://www.icann.org/en/news/public-comment/report-comments-proposed-raa-21jun13-en.pdf [PDF, 188 KB]) has also been considered as part of the decision on the RAA. That summary and analysis also identified areas where the 2013 RAA reflects modifications in response to comments received.

      What significant materials did the Board review?

      The Board reviewed the:

      • 2013 RAA and incorporated Specifications

      • Summary of Changes between the 2013 RAA and the 22 April 2013 Version

      • Final Clarifications to RAA after Consultation with Registars

      • 22 April 2013 Public Comment Summary and Analysis

      • March 2013 Public Comment Summary and Analysis

      • Summary of Addressing Law Enforcement Recommendations

      • GAC's Beijing Communiqué

      What factors the Board found to be significant?

      The Board found that many factors significant in reaching this decision. First is the intense participation of the Registrar NT and the statements of support that have been made by the Registrar community for this 2013 RAA. Second, the fact that the 2013 RAA incorporates the 12 GAC-Law Enforcement Recommendations, which was the basis for opening the negotiations, as well as the GAC's support for the results of the negotiations is a major factor in support of the 2013 RAA. Further, though there are areas where the ICANN community would like to see changes to the 2013 RAA, the community statements are overwhelmingly in favor of the advancements achieved in this new RAA. The fact that there are paths for the continuation of work on the major areas that the community has identified as concerns, including the Expert Working Group on the gTLD Registration Data and the work towards a Privacy/Proxy Accreditation Program, allows community discussion to continue on some of the more challenging issues raised within this negotiation that have not been solved to the level that some in the community wish. The improvements in the 2013 RAA, including the enhanced compliance tools, advancements in Whois, clearer obligations of resellers, are timely and should be in place prior to delegation of new gTLDs, so that all gTLDs entered through the New gTLD Program will be covered by these terms.

      Finally, the Board found significant that the Registrar Stakeholder Group is supportive of the 2013 RAA.

      What alternatives were considered by the Board?

      Because of the path that the 2013 RAA took to come to the Board, the Board has not considered any alternatives other than the alternative of delaying the approval of the agreement. However, the Board did review the community recommendations of the items that should be added to or removed from the 2013 RAA as alternatives.

      Are there positive or negative community impacts?

      The introduction of the 2013 RAA is expected to have positive impacts, as the changes that are going to be put in place with the enhanced obligations are expected to result in a maturing of the role of registrars within the DNS. The 2013 RAA will give tools to ICANN, Registrars and registrants for clearer understanding of obligations, rights and access to information. The biggest risk for the development of negative impacts will come from lack of understanding of the new obligations – registrants and registrars alike will face new requirements. Educational efforts can help counter these negative impacts.

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

      The new obligations under the 2013 RAA will impose fiscal ramifications on registrars, as they have new operational obligations to meet under the agreement and they will need to revise systems and processes to meet these obligations. The 2013 RAA includes a transitional term to give time for implementation. ICANN similarly will have to revise its contractual enforcement efforts, which may have a minimal fiscal impact, as the growth of the Contractual Compliance Team has already been included with the budget. The educational outreach necessary to help assure that Registrars and registrants alike understand these new obligations will also impose require fiscal resources from ICANN. There is a potential that increases in registrar operational costs will result in increase of prices to consumers, but there is no documentation available at this time to support that this will occur.

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

      The 2013 RAA, which includes technical requirements such as support of IDNs and DNSSEC, will contribute to the maintenance of the security, stability and resiliency of the DNS.

      This is an Organizational Administrative Function for which public comment was received.

  3. Executive Session

    1. Confidential Resolution

      [Resolutions Redacted]

      Resolved (2013.06.27.13), specific items of this resolution shall remain confidential as an "action relating to personnel or employment matters", pursuant to Article III, section 5.2 of the ICANN Bylaws, and the entire resolution shall remain confidential pursuant to this same Bylaws provision pending determination by the President and CEO that the non-confidential portion can be made public.

      Rationale for Resolutions 2013.06.27.10 – 2013.06.27.13

      [Rationale redacted]

Published on 28 June 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."