Skip to main content
Resources

Minutes | Regular Meeting of the ICANN Board

A Regular Meeting of the ICANN Board of Directors was held publicly on 12 February 2015 at 14:00 local time in Singapore, Singapore.

Steve Crocker, Chair, promptly called the meeting to order.

The following Directors participated in all or part of the meeting: Rinalia Abdul Rahim, Cherine Chalaby, Fadi Chehadé (President and CEO), Chris Disspain, Asha Hemrajani, Wolfgang Kleinwächter, Markus Kummer, Bruno Lanvin, Erika Mann, Gonzalo Navarro, Ray Plzak, George Sadowsky, Mike Silber, Bruce Tonkin (Vice Chair), and Kuo-Wei Wu.

The following Board Liaisons participated in all or part of the meeting: Ram Mohan (SSAC Liaison), Thomas Schneider (GAC Liaison), Jonne Soininen (IETF Liaison), and Suzanne Woolf (RSSAC Liaison).

Secretary: John Jeffrey (General Counsel and Secretary)

  1. Consent Agenda:
    1. Approval of Board Meeting Minutes
    2. Delegation of the бел ("bel") domain representing Belarus in Cyrillic script to Reliable Software Inc
    3. Removal of the .TP top-level domain representing Portuguese Timor
    4. GNSO Council Policy Recommendations - Inter-Registrar Transfer Policy Part D
    5. Recommendations for the Collection of Metrics for the New gTLD Program to Support the future AoC Review on Competition, Consumer Trust and Consumer Choice
    6. Security and Stability Advisory Committee (SSAC) Member Reappointments
    7. Appointment of Geoff Huston to the Security and Stability Advisory Committee (SSAC)
    8. Thank You to Departing Community Members
    9. Thank You to Sponsors of ICANN 52 Meeting
  2. Main Agenda:
    1. Release of Two-Letter Codes at the Second Level in gTLDs

 

  1. Consent Agenda:

    The Chair introduced the items on the Consent Agenda. The Chair then called for a vote, and the Board then took the following action:

    Resolved, the following resolutions in this Consent Agenda are approved:

    1. Approval of Board Meeting Minutes

      Resolved (2012.02.12.01), the Board approves the minutes of the 17 November 2014 and 3 December 2014 meetings of the ICANN Board.

    2. Delegation of the бел ("bel") domain representing Belarus in Cyrillic script to Reliable Software Inc.

      Resolved (2015.02.12.02), as part of the exercise of its responsibilities under the IANA Functions Contract, ICANN has reviewed and evaluated the request to delegate the бел country-code top-level domain to Reliable Software Inc. The documentation demonstrates that the proper procedures were followed in evaluating the request.

      Resolved (2015.02.12.03), the Board directs that pursuant to Article III, Section 5.2 of the ICANN Bylaws, that certain portions of the rationale not appropriate for public distribution within the resolutions, preliminary report or minutes at this time due to contractual obligations, shall be withheld until public release is allowed pursuant to those contractual obligations.

      Rationale for Resolutions 2015.02.12.02 – 2015.02.12.03

      Why the Board is addressing the issue now?

      In accordance with the IANA Functions Contract, the ICANN staff has evaluated a request for ccTLD delegation and is presenting its report to the Board for review. This review by the Board is intended to ensure that ICANN staff has followed the proper procedures.

      What is the proposal being considered?

      The proposal is to approve a request to the IANA Department to create the country-code top-level domain and assign the role of sponsoring organization (also known as the manager or trustee) to Reliable Software Inc.

      Which stakeholders or others were consulted?

      In the course of evaluating a delegation application, ICANN staff consults with the applicant and other interested parties. As part of the application process, the applicant needs to describe consultations that were performed within the country concerning the ccTLD, and their applicability to their local Internet community.

      What concerns or issues were raised by the community?

      Staff is not aware of any significant issues or concerns raised by the community in relation to this request.

      What significant materials did the Board review?

      [REDACTED – Sensitive Delegation Information]

      What factors the Board found to be significant?

      The Board did not identify any specific factors of concern with this request.

      Are there positive or negative community impacts?

      The timely approval of country-code domain name managers that meet the various public interest criteria is positive toward ICANN's overall mission, the local communities to which country-code top-level domains are designated to serve, and responsive to ICANN's obligations under the IANA Functions Contract.

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

      The administration of country-code delegations in the DNS root zone is part of the IANA functions, and the delegation action should not cause any significant variance on pre-planned expenditure. It is not the role of ICANN to assess the financial impact of the internal operations of country-code top-level domains within a country.

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

      ICANN does not believe this request poses any notable risks to security, stability, or resiliency. This is an Organizational Administrative Function not requiring public comment.

    3. Removal of the .TP top-level domain representing Portuguese Timor

      Whereas, the "TP" two-letter code was removed from the ISO 3166-1 standard and superseded by the "TL" code representing Timor-Leste. Whereas the .TL domain name was delegated in 2005 to replace the .TP domain name, and a multi-year transition was conducted allowing .TP registrants to migrate to the new country-code top-level domain.

      Whereas ICANN received confirmation from the Government of Timor-Leste supporting the final removal of the .TP delegation from the DNS Root Zone.

      Resolved (2015.02.12.04), that the delegation of .TP be removed from the DNS Root Zone.

      Rationale for Resolution 2015.02.12.04

      Why the Board is addressing the issue now?

      The .TP top-level domain is planned for removal from the DNS Root Zone by 28 February 2015. The Government of Timor-Leste as the .TP operator confirmed their consent to the removal of .TP from the DNS Root Zone.

      What is the proposal being considered?

      The proposal is to approve a request to IANA to remove the delegation of the .TP (Portuguese Timor) top-level domain from the DNS Root Zone.

      Which stakeholders or others were consulted?

      In the course of evaluating a top-level domain removal request, ICANN staff consults with the current operator and other interested parties. As part of the removal process, the current operator needs to describe steps followed to ensure that the removal of the top-level domain does not have unplanned adverse impact on Internet stability.

      What concerns or issues were raised by the community?

      Staff is not aware of any significant issues or concerns raised by the community in relation to this request. The Government of Timor-Leste confirmed that that the .TP top-level domain is no longer in practical use.

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

      ICANN does not believe this request poses any notable risks to security, stability, or resiliency. This is an Organizational Administrative Function not requiring public comment.

    4. GNSO Council Policy Recommendations - Inter-Registrar Transfer Policy Part D

      Whereas, on 17 January 2013, the GNSO Council launched a Policy Development Process (PDP) on the Inter-Registrar Transfer Policy Part D (IRTP Part D) addressing six charter questions, set forth at https://community.icann.org/display/ITPIPDWG/3.+WG+Charter.

      Whereas, the PDP followed the prescribed PDP steps as stated in the Bylaws, resulting in a Final Report delivered on 25 September 2014.

      Whereas, the IRTP Part D Working Group (WG) reached full consensus on the recommendations in relation to each of the six issues outlined in the Charter.

      Whereas, the GNSO Council reviewed, and discussed the recommendations of the IRTP Part D WG, and adopted the Recommendations on 15 October 2014 by a unanimous vote  (see http://gnso.icann.org/en/council/resolutions#20141015-1).

      Whereas, the GNSO Council vote met and exceeded the required voting threshold (i.e. supermajority) to impose new obligations on ICANN contracted parties.

      Whereas, after the GNSO Council vote, a public comment period was held on the approved recommendations, and the comments have been summarized and considered (https://www.icann.org/public-comments/irtp-d-recommendations-2014-10-20-en).

      Resolved (2015.02.12.05), the Board adopts the GNSO Council Policy Recommendations amending the Inter-Registrar Transfer Policy set forth at http://www.icann.org/en/transfers/policy-en.htm and the Transfer Dispute Resolution Policy (TDRP) set forth at https://www.icann.org/resources/pages/tdrp-2012-02-25-en.

      Resolved (2015.02.12.06), the Board directs the President and CEO, or his authorized designee(s), to develop and complete an implementation plan for these Recommendations and continue communication and cooperation with the GNSO Implementation Review Team and community on the implementation work.

      Rationale for Resolutions 2015.02.12.05-2015.02.12.06

      Why the Board is addressing the issue now?

      The Inter-Registrar Transfer Policy (IRTP) is a consensus policy that was adopted in 2004 which provides for a straightforward process for registrants to transfer domain names between registrars. The GNSO Council established a series of five Working Groups (Parts A through D) to review and consider various revisions to this policy.

      The IRTP Part D PDP is the fourth and final in a series of PDPs addressing areas for improvements in the existing policy.

      The IRTP Part D PDP Final Report received unanimous consensus support from the IRTP Part D WG as well as the GNSO Council. Following the closing of the public comment period, the next step as outlined in Annex A of the ICANN Bylaws is consideration by the ICANN Board of the recommendations.

      What is the proposal being considered?

      The following policy recommendations are being adopted:

      Recommendation #1 - The WG recommends that reporting requirements be incorporated into the TDRP policy. Outcomes of all rulings by Dispute Resolution Providers (DRP) 1 should be published on Providers' websites, except in exceptional cases – in keeping with practices currently employed in the UDRP. Exceptions, if sought by the DRP, are to be granted by ICANN Contractual Compliance on a case-by-case basis. The Group recommends publishing reports that follow the example of the Asian Domain Name Dispute Resolution Centre (ADNDRC).2 These reports should include at a minimum:

      1. The domain name under dispute
      2. Relevant information about parties involved in the dispute;
      3. The full decision of the case;
      4. The date of the implementation of the decision

      The need for publication does not apply to TDRP rulings that have taken place prior to the implementation of this recommendation.

      Recommendation #2 - The WG recommends that the TDRP be amended to include language along the lines of this revised version of the UDRP:

      "The relevant Dispute Resolution Provider shall report any decision made with respect to a transfer dispute initiated under the TDRP. All decisions under this Policy will be published in full over the Internet except when the Panel, convened by the Dispute Resolution, in an exceptional case, determines to redact portions of its decision. In any event, the portion of any decision determining a complaint to have been brought in bad faith shall be published."

      Recommendation #3 - The WG recommends that the TDRP be amended to reflect the following wording, or equivalent: "Transfers from a Gaining Registrar to a third registrar, and all other subsequent transfers, are invalidated if the Gaining Registrar acquired sponsorship from the Registrar of Record through an invalid transfer, as determined through the dispute resolution process set forth in the Transfer Dispute Resolution Policy."

      Recommendation #4 - The WG recommends that a domain name be returned to the Registrar of Record and Registrant of Record directly prior to the non-compliant transfer if it is found, through a TDRP procedure, that a non-IRTP compliant domain name transfer occurred.

      Recommendation #5 - The WG recommends that the statute of limitation to launch a TDRP be extended from current 6 months to 12 months from the initial transfer.

      This is to provide registrants the opportunity to become aware of fraudulent transfers when they would no longer receive their registrar's annual WDRP notification.

      Recommendation #6 - The WG recommends that if a request for enforcement is initiated under the TDRP the relevant domain should be 'locked' against further transfers while such request for enforcement is pending. Accordingly, 'TDRP action' and 'URS action' are to be added to the second bullet point of the list of denial reasons in the IRTP (Section 3); the IRTP and TDRP should be amended accordingly. 3

      The TDRP as well as guidelines to registrars, registries and third party dispute providers should be modified accordingly. The WG notes that the locking should be executed in the way that the UDRP prescribes – once that the UDRP locking process is implemented.

      Recommendation #7 - The WG recommends to add a list of definitions (Annex F of Final Report) to the TDRP to allow for a clearer and more user-friendly policy.

      Recommendation #8 - The WG recommends not to develop dispute options for registrants as part of the current TDRP.

      Recommendation #9 - The WG recommends that staff, in close cooperation with the IRTP Part C Implementation Review Team, ensures that the IRTP Part C inter-registrant transfer recommendations are implemented and monitor whether dispute resolution mechanisms are necessary to cover the Use Cases in Annex C of the Final Report. Once such a policy is implemented, its functioning should be closely monitored, and if necessary, an Issues Report be called for to assess the need for an inter-registrant transfer dispute policy. See also Recommendations #17 and #18 below.

      Recommendation #10 - The WG recommends that the TDRP be modified to eliminate the First (Registry) Level of the TDRP. ICANN should monitor the use of TDRPs and if the discontinuation of the Registry layer as first level dispute provider seems to create a barrier to this dispute resolution mechanism, future policy work should be initiated to counter such development. See also #17 below.

      Recommendation #11 - The WG recommends that ICANN take the necessary steps to display information relevant to disputing non-compliant transfers prominently on its web site and assure the information is presented in a simple and clear manner and is easily accessible for registrants.

      This recommendation should be view in combination with Recommendation #12 (below).

      Recommendation #12 - The WG recommends that ICANN create and maintain a user-friendly, one-stop website containing all relevant information concerning disputed transfers and potential remedies to registrants. Such a website should be clearly accessible from or integrated into the ICANN Registrants' Benefits and Responsibilities page (https://www.icann.org/resources/pages/benefits-2013-09-16-en) or similar.

      This should include:

      • Information to encourage registrants to contact the registrar to resolve disputed transfers at the registrar level before engaging ICANN Compliance or third parties by launching a TDRP.

      • Improvements to the ICANN website regarding the display of information on the Inter Registrar Transfer Policy and the Transfer Dispute Resolution Policy is regularly updated (see 5.2.3.3 above).

      • Links to the relevant information for registrants on the ICANN website being clearly worded and prominently displayed on the ICANN home page. This will contribute to improving visibility and content of the ICANN website that is devoted to offering guidance to registrants with transfer issues.

      • ICANN Compliance clearly indicates on its FAQ/help section under which circumstances it can assist registrants with transfer disputes. This should include situations when registrants can ask ICANN Compliance to insist on registrars taking action on behalf of said registrant.

      • Improvements in terms of accessibility and user-friendliness should be devoted especially to these pages:

      Links to these registrant help-websites should also be prominently displayed on internic.net and iana.org in order to assure further that registrants have easy access to information.

      Recommendation #13 - The WG recommends that, as a best practice, ICANN accredited Registrars prominently display a link on their website to this ICANN registrant help site. Registrars should also strongly encourage any re-sellers to display prominently any such links, too. Moreover, the Group recommends that this is communicated to all ICANN accredited Registrars.

      Registrars may choose to add this link to those sections of their website that already contains Registrant-relevant information such as the Registrant Rights and Responsibilities, the WHOIS information and/or other relevant ICANN-required links as noted under 3.16 of the 2013 RAA.

      Recommendation #14 - The WG recommends that no additional penalty provisions be added to the existing IRTP or TDRP.

      Recommendation #15 - As a guidance to future policy development processes, this Working Group recommends that policy specific sanctions be avoided wherever possible. Rather, sanctions should be consistent throughout policies and be governed by applicable provisions within the RAA.

      Recommendation #16 - The WG does not recommend the elimination of FOAs. However, in light of the problems regarding FOAs, such as bulk transfers and mergers of registrars and/or resellers, the Group recommends that the operability of the FOAs should not be limited to email. Improvements could include: transmission of FOAs via SMS or authorization through interactive websites. Any such innovations must, however, have auditing capabilities, as this remains one of the key functions of the FOA.

      The WG notes that the implementation of this recommendation should not be affected by whether transfers take place in advance (for certain bulk transfers) or in real time.

      Recommendation #17 - The WG recommends that, once all IRTP recommendations are implemented (incl. IRTP-D, and remaining elements from IRTP-C), the GNSO Council, together with ICANN staff, should convene a panel to collect, discuss, and analyze relevant data to determine whether these enhancements have improved the IRTP process and dispute mechanisms, and identify possible remaining shortcomings.

      If, after a period of 12 months of such a review, the GNSO (with ICANN Staff) determine that the situation regarding transfers is not improved, then this WG recommends that a top-to-bottom reevaluation of the transfer process be undertaken. The goal of this is to create a simpler, faster, more secure policy that is more readily understood and more accessible to use for registrants."

      It is a further recommendation that a security expert be included in any such next review Working Group, should for example real 2-factor authentication be required, that it is implemented according to industry standards.

      Recommendation #18 - The WG recommends that contracted parties and ICANN should start to gather data and other relevant information that will help inform a future IRTP review team in its efforts, especially with regard to those issues listed in the Observations of the Final Report (4.2.7.1).

      To facilitate the gathering of relevant data, the Implementation Review Team should closely liaise with ICANN Staff to assure prompt access to necessary data.

      Which stakeholders or others were consulted?

      Regular consultation with stakeholders took place during the lifetime of this PDP. Details can be found in the Input Tracking List (Annex B of the Final Report).

      What concerns or issues were raised by the community?

      No community concerns have been raised in relation to the Final Report and its recommendations.

      What significant materials did the Board review?

      The Board reviewed the Final Report, the GNSO Council Recommendations Report to the Board, as well as the summary of public comments and the response to those comments.

      What factors did the Board find to be significant?

      The recommendations were developed following the GNSO Policy Development Process as outlined in Annex A of the ICANN Bylaws and have received the unanimous support from the GNSO Council. As outlined in the ICANN Bylaws, the Council's supermajority support for the motion (the Council voted unanimously in favor) obligates the Board to adopt the recommendation unless by a vote of more than two-thirds, the Board determines that the policy is not in the best interests of the ICANN community or ICANN.

      In addition, transfer related issues are the number two area of complaint according to data from ICANN Compliance. Improvements to the IRTP have the potential to reduce the number of complaints, in addition to providing clarity and predictability to registrants as well as registrars.

      Are there positive or negative community impacts?

      Improvements to the IRTP and TDRP have the potential to reduce the number of complaints, in addition to providing clarity and predictability to registrants as well as registrars. Adoption of the recommendations will require significant changes in processes for registrars as well as registrars and therefore it is expected that the implementation of these recommendations will require substantial time and resources, but these are considered necessary in order to address the issues that are part of this Policy Development Process. The recommendations, if implemented, are expected to usefully clarify and enhance the IRTP and TDRP, to the advantage of all parties concerned.

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

      In addition to those changes required in the process for registrars as outlined above, there will likely be fiscal impacts related to implementation of the policy, such as updates to the ICANN website - but these costs should be anticipated to be within the budget of the relevant departments.

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

      There are no security, stability, or resiliency issues related to the DNS if the Board approves the proposed recommendations.

    5. Recommendations for the Collection of Metrics for the New gTLD Program to Support the future AoC Review on Competition, Consumer Trust and Consumer Choice

      Whereas, in the Affirmation of Commitments (AoC), ICANN has committed to organizing a review that will examine the extent to which the New gTLD Program has promoted competition, consumer trust and consumer choice once new gTLDs have been in operation for one year.

      Whereas, on 10 December 2010 the ICANN Board requested that the At-Large Advisory Committee (ALAC), the Governmental Advisory Committee (GAC), the Generic Names Supporting Organization (GNSO) and the Country Code Names Supporting Organization (ccNSO) provide input on establishing the definition, measures, and three year targets for competition, consumer trust and consumer choice in the context of the domain name system. The Board received input in 2013 from the GNSO Council [PDF, 352 KB] and the ALAC [PDF, 491 KB], each offering recommendations on specific metrics.

      Whereas, the Board directed (in Resolutions 2013.07.18.05 – 2013.07.18.07 and 2013.09.28.13 – 2013.09.28.14) the President and CEO to convene a volunteer group (the Implementation Advisory Group for Competition, Consumer Trust and Consumer Choice [IAG-CCT]) in advance of a future AoC Competition, Consumer Trust and Consumer Choice Review Team, for several purposes, including evaluating and reporting to the Board on the feasibility, utility and cost-effectiveness of adopting the recommendations of the GNSO Council and the ALAC.

      Whereas, on 1 October 2014, the IAG-CCT submitted to the Board its final report on its recommendations for the collection of data to inform the review on competition, consumer choice and consumer trust.

      Resolved (2015.02.12.07), the ICANN Board thanks the IAG-CCT for its diligent work and its recommendations providing for collection of data as an input to the future reviews on competition, consumer trust, and consumer choice in the gTLD space;

      Resolved (2015.02.12.08), the ICANN President and CEO, or his designee, is hereby directed to immediately begin collecting data on the metrics recommended in the IAG-CCT Final Report, prioritizing those that are time-sensitive, and where data has been determined to be available.

      Resolved (2015.02.12.09), the ICANN President and CEO, or his designee, is hereby directed to collect data for metrics listed in Table 4 of the IAG-CCT Final Report [DOCX, 105 KB] as data is available, noting that these metrics are marked for possible collection at a later date, pending discussion by the Review Team to be convened.

      Rationale for Resolutions 2015.02.12.07 – 2015.02.12.09

      Why is the Board addressing the issue?

      This resolution is a continuation of the Board's resolutions (2013.07.18.05 – 2013.07.18.07 and 2013.09.28.13 – 2013.09.28.14) relating to evaluation of the metrics proposed by the community for use in a future review under the Affirmation of Commitments (AoC) of the impact of new gTLDs in the areas of competition, consumer trust, and consumer choice. It also builds upon Board resolutions (2014.03.27.22 - 2014.03.27.26) relating to the adoption of interim recommendations from the Implementation Advisory Group on a consumer survey and economic study. 

      What is the proposal being considered?

      The Board's resolution calls for ICANN to immediately begin collecting data on those metrics recommended by the IAG-CCT. The resolution adopts the majority of the IAG recommendations and allows for the Review Team to revisit certain metrics regarding costliness and usefulness, though data on those metrics will be collected as available.

      This work is to commence immediately, and involves authorizing staff time to collect the necessary data, or to purchase or otherwise acquire data from relevant third parties, including ICANN's contracted parties.

      What significant materials did the Board review?

      The Board reviewed the final report from the Implementation Advisory Group dated 1 October 2014 (https://community.icann.org/download/attachments/48349551/IAGCCT%20Final%20report.docx?version=1&modificationDate=1418863127000&api=v2 [DOCX, 105 KB]), the briefing materials submitted by staff, the resolutions adopted in March 2014 approving funding for a consumer survey and economic study, and the related prior advice letters from the ALAC [PDF, 491 KB] and the GNSO [PDF, 352 KB], including an updated version of said advice with the IAG-CCT's current recommendations.

      What factors did the Board find to be significant?

      The Board believes that the data to be collected for this evaluation is important to supporting an accurate examination of the extent to which the introduction of gTLDs has promoted competition, consumer trust, and consumer choice. By engaging in these activities now, ICANN is committing to ensuring that relevant data is available to the future Review Team, as well as the broader community, to support the future examination of the New gTLD Program that will occur under the AoC. The resolution calls for implementation work to proceed that is intended to facilitate the work of the AoC review at the appropriate time.

      Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, or budget)?

      The funds to implement this resolution are included in the 2015 Fiscal Year Budget, and are being accounted for in budget planning for FY2016.

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

      This resolution does not affect the security, stability, or resiliency of the DNS.

      Is public comment required prior to Board action?

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

    6. Security and Stability Advisory Committee (SSAC) Member Reappointments

      Whereas, Article XI, Section 2, Subsection 2 of the Bylaws governs the Security and Stability Advisory Committee (SSAC). Whereas, the Board, at Resolution 2010.08.05.07 approved Bylaws revisions that create three-year terms for SSAC members, require staggering of terms, and obligate the SSAC chair to recommend the reappointment of all current SSAC members to full or partial terms to implement the Bylaws revisions.

      Whereas, the Board, at Resolution 2010.08.05.08 appointed SSAC members to terms of one, two, and three years beginning on 01 January 2011 and ending on 31 December 2011, 31 December 2012, and 31 December 2013.

      Whereas, in June 2014 the SSAC Membership Committee initiated an annual review of SSAC members whose terms are ending 31 December 2014 and submitted to the SSAC its recommendations for reappointments.

      Whereas, on 24 November 2014, the SSAC members approved the reappointments.

      Whereas, the SSAC recommends that the Board reappoint the following SSAC members to three-year terms: Greg Aaron, Don Blumenthal, KC Claffy, Lyman Chapin, Steve Crocker, Mark Kosters, Russ Mundy, Rod Rasmussen, and Mark Seiden.

      Resolved (2015.02.12.10) the Board accepts the recommendation of the SSAC and reappoints the following SSAC members to three-year terms beginning 01 January 2015 and ending 31 December 2017: Greg Aaron, Don Blumenthal, KC Claffy, Lyman Chapin, Steve Crocker, Mark Kosters, Russ Mundy, Rod Rasmussen, and Mark Seiden

      Rationale for Resolution 2015.02.12.10

      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 naming and address allocation systems. The above-mentioned individuals provide the SSAC with the expertise and experience required for the Committee to fulfill its charter and execute its mission.

    7. Appointment of Geoff Huston to the Security and Stability Advisory Committee (SSAC)

      Whereas, the Security and Stability Advisory Committee (SSAC) reviews its membership and makes adjustments from time-to- time.

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

      Resolved (2015.02.12.11), the Board appoints Geoff Huston to the SSAC.

      Rationale for Resolution 2015.02.12.11

      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 naming and address allocation systems.

      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. Geoff Huston brings valuable skills to the SSAC. Mr. Huston is Chief Scientist at APNIC. He is generally involved in projects relating to measurement and network metrics. Recently he has been focused on studying the exhaustion of the remaining pool of unallocated IPv4 addresses, the related topic of the uptake of IPv6, the measurement of the DNS and the uptake of DNSSEC, and the design and operational stability of the Resource Public Key Infrastructure (RPKI). The SSAC believes he would be a significant contributing member of the SSAC.

    8. Thank You to Departing Community Members

      Whereas, ICANN wishes to acknowledge the considerable energy and skills that members of the stakeholder community bring to the ICANN process.

      Whereas, in recognition of these contributions, ICANN wishes to acknowledge and thank members of the community when their terms of service on Supporting Organizations and Advisory Committees end.

      Whereas, the following member of the Root Server System Advisory Committee (RSSAC) is concluding his term of service:

      • Dr. Jun Murai – RSSAC Founding Chair

      Resolved (2015.02.12.12), Dr. Jun Murai has earned the deep appreciation of the Board for his term of service, and the Board wishes him well in his future endeavors within the ICANN community and beyond.

      Whereas, the following Security and Stability Advisory Committee (SSAC) are concluding their terms of service:

      • Rodney Joffe – SSAC Member
      • Jason Livingood – SSAC Member
      • Bruce Tonkin – SSAC Member
      • Stefano Trumpy – SSAC Member
      • Paul Vixie – SSAC Member

      Resolved (2015.02.12.13), Rodney Joffe, Jason Livingood, Bruce Tonkin, Stefano Trumpy and Paul Vixie have earned the deep appreciation of the Board for their terms of service, and the Board wishes them well in their future endeavors within the ICANN community and beyond.

      Whereas, the following member of the Generic Names Supporting Organization (GNSO) are concluding her terms of service:

      • Kristina Rosette – GNSO Intellectual Property Constituency Chair

      Resolved (2015.02.12.14), Kristina Rosette have earned the deep appreciation of the Board for her terms of service, and the Board wishes them well in her future endeavors within the ICANN community and beyond.

      Whereas, the following members of the Governmental Advisory Committee (GAC) are concluding their terms of service:

      • Tracy Hackshaw – GAC Vice-Chair
      • Peter Nettlefold – GAC Vice-Chair

      Resolved (2015.02.12.15), Tracy Hackshaw and Peter Nettlefold have earned the deep appreciation of the Board for their terms of service, and the Board wishes them well in their future endeavors within the ICANN community and beyond.

    9. Thank You to Sponsors of ICANN 52 Meeting

      The Board wishes to thank the following sponsors: VeriSign, Inc., Public Interest Registry, Afilias Limited, CentralNic, Internet Domain Name System Beijing Engineering Research Center (ZDNS), Neustar, NCC Group, Trademark Clearinghouse, Uniregistry Corp., Minds + Machines Group, Iron Mountain, Inc., ION Magazine, Radix FZC, and ICANNWIKI, InterConnect Communications Ltd, and Sedo GmbH.

      The Board expresses its deepest appreciation to the scribes, interpreters, audiovisual team, technical teams, and the entire ICANN staff for their efforts in facilitating the smooth operation of the meeting.

      The Board would also like to thank the management and staff of the Fairmont Singapore and Swissôtel The Stamford, for providing a wonderful facility to hold this event. Special thanks are extended to:

      Ms. Dawn Ng, Manager, Conventions, Singapore Tourism Board; NG Pei Sze, Senior Sales Manager Meetings, Incentives, Conventions&Exhibitions; Ng Sok Hia, Executive Assistant Manager Sales and Marketing; Joanne Kaeli Phua, Conference Services Executive, Raffles City Convention Centre.

    All members of the Board present voted in favor of Resolutions 2012.02.12.01, 2012.02.12.02, 2012.02.12.03, 2012.02.12.04, 2012.02.12.05, 2012.02.12.06, 2012.02.12.07, 2012.02.12.08, 2012.02.12.09, 2012.02.12.10, 2012.02.12.11, 2012.02.12.12, 2012.02.12.13, 2012.02.12.14, and 2012.02.12.15. The Resolutions carried.

  2. Main Agenda:

    1. Release of Two-Letter Codes at the Second Level in gTLDs

      Bruce Tonkin moved and Cherine Chalaby seconded the proposed resolution.

      Bruce introduced the agenda item and provided an overview of the proposed resolution. This resolution results from the developments and activities relating to the release of two-character domain names at the second level. The New gTLD Registry Agreement provides two methods to release two-character domain names: (1) such names may be released to the extent that the registry operator reaches agreement with the related government and country code manager; or (2) the registry operator may propose the release of the names based on its implementation of measures to avoid confusion with country codes, subject to approval by ICANN. At its meeting in Los Angeles, the Board directed the staff to come up with a procedure whereby registry operators could apply for the release of these names. Subsequently, the Board received a letter from the chair of the GAC indicating some areas where that process could be improved. The Board also met with the GAC during this week, and obtained further advice from the GAC in its communiqué, which was received by the Board today. The Board also has heard from numerous speakers in the public forum today on this topic.

      Ray Plzak and Chris Disspain commented that certain text reflecting additional GAC advice should be added to the proposed resolution. Chris explained that the proposed amendment pertains to the final "Whereas" clause of the resolution and suggested that an additional piece of GAC advice be added—namely, that a list of the GAC members who intend to agree to all requests and do not require notification will be published on the GAC website. The Board discussed the amendment and all Board members voted in favor of the amendment.

      The Board then discussed the newly amended proposed resolution. Cherine Chalaby asked how long it would take to complete these changes and release the two-letter codes, noting that the community and registries are waiting for this change. Akram Atallah (President, Global Domains Division) explained that the comment periods could be put up very quickly after notifying the GAC members. Thomas Schneider commented that some governments are not yet members of the GAC and may need to be notified separately. Akram responded and explained that ICANN will endeavor to reach governments affected by the two-letter character releases that are not GAC members as well.

      The Chair called for a vote, and the Board took the following action:

      Whereas, the New gTLD Registry Agreement provides two methods to release two-character domain names: (1) such two-character names may be released to the extent that Registry Operator reaches agreement with the related government and country-code manager, or (2) the Registry Operator may propose the release of the names based on its implementation of measures to avoid confusion with the corresponding country codes, subject to approval by ICANN.

      Whereas, on 16 October 2014, the Board directed staff to develop and implement an efficient procedure for ICANN to consider requests for release of two-character names, taking into account the GAC's advice in the 16 October 2014 Los Angeles Communiqué.

      Whereas, ICANN published and implemented the process, effective 1 December 2014.

      Whereas, on 26 January 2015 the GAC Chair sent a letter to the ICANN Board raising concerns on behalf of some GAC members as users of the process. The GACprovided a list of suggestions for possible solutions to address its concerns.

      Whereas, on 11 February 2015, the GAC issued advice to the Board in the GAC Communiqué regarding the release of two-letter codes at the second level in gTLDs. The GAC advised the Board to amend the current process to establish an effective notification mechanism, so that relevant governments can be alerted as requests are initiated. Comments from relevant governments should be fully considered. The GAC also advised the Board to extend the comment period to 60 days. A list of GAC Members who intend to agree to all requests and do not require notification will be published on the GAC website.

      Resolved (2015.02.12.16), the Board accepts the advice of the GAC from the 11 February 2015 GAC Communiqué regarding the release of two-letter codes at the second level in gTLDs. The Board directs the President and CEO, or his designee(s), to revise the Authorization Process for Release of Two-Character ASCII Labels and proceed immediately as follows:

      • Implement improvements to the process to alert relevant governments when requests are initiated. Comments from relevant governments will be fully considered.
      • For new requests, the comment period will be for 60 days.
      • For requests with pending or completed comment periods, extend or re-open the comment period so that each request will undergo 60 days of comment period in total.

      Rationale for Resolution 2015.02.12.16

      The Board is taking action at this time to accept the advice of the GAC from the 11 February 2015 GAC Singapore Communiqué regarding the release of two-letter codes at the second level in gTLDs. Article XI, Section 2.1 of the ICANN Bylaws 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 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.

      The Board's action today to accept the GAC's advice follows on from its 16 October 2014 resolution where the Board authorized the President and CEO to develop and implement an efficient procedure for the release of two-character domains currently required to be reserved in the New gTLD Registry Agreement, taking into account the GAC's advice in the Los Angeles Communiqué.

      ICANN developed the Authorization Process for Release of Two-Character ASCII Labels to implement the Board's resolution. On 12 November 2014 ICANN issued a blog explaining the new process to release the two-character domains, which it also provided to the GAC. The process became effective on 1 December 2014. On 26 January 2015 the GAC Chair sent a letter to the ICANN Board raising concerns on behalf of some GAC members, as users of the process. The GAC provided a list of suggestions for possible solutions to address its concerns with the process.

      To date, ICANN has received requests from over 300 registries in total. As a result of the Board's action today, ICANN will extend or re-open the comment period required by the process so that requests are the subject of 60 days of comment in total. For requests that have completed or are in the process of completing the existing 30-day requirement, the comment period will be extended or re-opened so that each request will satisfy the new 60-day requirement. For example, a request that has completed 30 days of comments, will have a new additional 30-day comment period. A request that has been under comment for 15 days will have its current comment period extended by 30 days, so that it will run for a total of 60 days. All new requests going forward will likewise undergo a 60-day comment period.

      The Board reviewed several materials and also considered several significant factors during its deliberations on the action being taken. The significant materials and factors that the Board considered as part of its deliberations, included, but are not limited to the following:

      The overall impact on the community is anticipated to be positive as new opportunities for diversification and competition in the gTLD namespace are created, while no specific risk of user confusion has been identified. The implementation of the Board's action is not anticipated to have a significant fiscal impact on ICANN, the community or the public. As determined by the ICANN Registry Services Technical Evaluation Panel in a 4 December 2006 report on proposed release of two-character domains in the .name gTLD, the release of two-character second level domains does not create a reasonable risk of a meaningful adverse effect on security and stability. The Board's action is not a defined policy process within ICANN's Supporting Organization or ICANN's Organizational Administrative Function decision requiring public comment.

    All members of the Board present voted in favor of Resolution 2015.02.12.16. The Resolution carried.

    The Chair then called the meeting to a close.

Published on 27 April 2015


1 The Working Group recommends in Charter question C to remove the Registry as the first dispute resolution layer of the TDRP. Therefore, despite wording of Charter question A, no reporting requirements for the Registries are included here.

2 See four ADNDRC Reports on TDRP decisions: http://www.adndrc.org/mten/TDRP_Decisions.php?st=6

3 https://www.icann.org/resources/pages/policy-transfers-2014-07-02-en

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