Consent Agenda:

Approval of Board Meeting Minutes

Resolved (2013.09.28.01), the Board approves the minutes of the 17 July, 18 July and 22 August 2013 Meetings of the ICANN Board.

Delegation of a ccTLD for Iran in Arabic script

Resolved (2013.09.28.02), as part of the exercise of its responsibilities under the IANA Functions Contract, ICANN has reviewed and evaluated the request to delegate the ایران ("Iran") countrycode top-level domain to the Institute for Research in Fundamental Sciences. The documentation demonstrates that the proper procedures were followed in evaluating the request.

Resolved (2013.09.28.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 2013.09.28.02 – 2013.09.28.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 ICANN's IANA Department to create the country-code top-level domain and assign the role of sponsoring organisation (also known as the manager or trustee) to the Institute for Research in Fundamental Sciences.

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 are not aware of any significant issues or concerns raised by the community in relation to this request.

[Rationale Redacted]

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.

GNSO Locking of a Domain Name Subject to UDRP Proceedings PDP Recommendations

Whereas, on 15 December 2011, the GNSO Council launched a Policy Development Process (PDP) on the Locking of a Domain Name subject to UDRP Proceedings addressing five charter questions, set forth at https://community.icann.org/x/ma-bAQ.

Whereas, the PDP followed the prescribed PDP steps as stated in the Bylaws resulting in a Final Report delivered on 5 July 2013.

Whereas, the Locking of a Domain Name subject to UDRP Proceedings Working Group (WG) reached full consensus on the recommendations in relation to the issues outlined in the Charter.

Whereas, the GNSO Council reviewed, and discussed the recommendations of the Locking of a Domain Name subject to UDRP Proceedings WG, and adopted the Recommendations on 1 August 2013 by a Supermajority and unanimous vote (see http://gnso.icann.org/en/council/resolutions#201308).

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

Resolved (2013.09.28.05), the President and CEO is directed to develop and complete an implementation plan for these Recommendations and continue communication with the community on such work.

Rationale for Resolution 2013.09.28.04 – 2013.09.28.05

Why is the Board addressing this issue now?

Currently there is no requirement to lock names in the period between filing of the complaint and commencement of proceedings, and no definition of 'status quo', which has resulted in different interpretations and confusion of the policy. To address this issue, the GNSO Council decided to initiate a Policy Development Process (PDP) on 15 December 2011. As part of its deliberations, the WG was required to consider the following questions:

Whether the creation of an outline of a proposed procedure, which a complainant must follow in order for a registrar to place a domain name on registrar lock, would be desirable.

Whether the creation of an outline of the steps of the process that a registrar can reasonably expect to take place during a UDRP dispute would be desirable.

Whether the time frame by which a registrar must lock a domain after a UDRP has been filed should be standardized.

a. Whether what constitutes a "locked" domain name should be defined.

b. Whether, once a domain name is 'locked' pursuant to a UDRP proceeding, the registrant information for that domain name may be changed or modified.

Whether additional safeguards should be created for the protection of registrants in cases where the domain name is locked subject to a UDRP proceeding.

The Working Group published its Initial Report for public comment on 15 March 2013, followed by its Final Report on 5 July 2013, which received the unanimous consensus support from the PDP 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 recommendations are being considered:

Recommendation #1: In this context, the term "lock" means preventing any changes of registrar and registrant. This "lock" should not impair the resolution of the domain name solely on the basis of the fact that a complaint under the UDRP has been filed or solely on the basis of the fact that that a UDRP proceeding is ongoing.1

Recommendation #2: Modify the provision from the UDRP rules that specifies that upon submission of the complaint to the UDRP provider the complainant should also 'state that a copy of the complaint […] has been sent or transmitted to the respondent' (section 3, b – xii) and recommend that, as a best practice, complainants need not inform respondents that a complaint has been filed to avoid cyberflight. The UDRP Provider will be responsible for informing the respondent once the proceedings have officially commenced.

Recommendation #3: Following receipt of the complaint, the UDRP Provider will, after performing a preliminary deficiency check2, send a verification request to the Registrar, including the request to prevent any changes of registrar and registrant for the domain name registration ("lock"). The registrar is not allowed to notify the registrant of the pending proceeding until such moment that any changes of registrar and registrant have been prevented, but may do so once any changes of registrar and registrant have been prevented. In the case of accredited privacy / proxy providers3 or a privacy / proxy provider affiliated with the registrar, the registrar may contact the accredited / affiliated privacy / proxy provider to allow for the reveal of the proxy customer data. However, such contact may only be established after an initial lock has been applied preventing any changes of registrar and registrant.

Recommendation #4: Within 2 business days4 at the latest following receipt of the verification request from the UDRP Provider, the Registrar will modify the status of the registration to prevent any changes of registrar and registrant ("lock"). The Registrar must continue to prevent changes through the remaining pendency of the UDRP Proceeding, except in case of the suspension of a UDRP proceeding (see recommendation #10). Pendency is defined as from the moment a UDRP complaint, or relevant document initiating a court proceeding or arbitration, regarding a domain name, has been submitted by the Complainant to the UDRP Provider, as the case may be. Any updates5 as a result of a request by the accredited / affiliated privacy / proxy provider to reveal the underlying proxy customer data must be made before the 2 business day timeframe ends or before the registrar verifies the information requested and confirms the lock to the UDRP Provider, which ever occurs first.

A registrar may not permit transfer to another registrant6 or registrar after a request for verification is received by the Registrar from the UDRP Provider, except in limited situations involving an arbitration not conducted under the Policy or involving litigation as provided by the UDRP Policy Paragraphs 8(a) or 8(b). For the purposes of the UDRP, the Registrant listed in the Whois record at the time of the lock will be recorded as the Respondent(s). Any changes to Whois information during the pendency of the administrative proceeding under the Policy may be permitted or prohibited based on the Registrar's applicable policies and contracts, however, it is the responsibility of the Registrant (UDRP Rule 2(e) and UDRP Rule 5(b)(ii) to inform the Provider of any relevant updates that may affect Provider notices and obligations to Respondent under the UDRP.

Depending on the terms of service of the Proxy / Privacy service, a Registrar may opt to reveal underlying data as a result of privacy/proxy services to the Provider or in Whois, or both, if it is aware of such. This will not count as a "transfer" in violation of the above, if it occurs in accordance with draft recommendation #2. If a privacy/proxy service is revealed or proxy customer information released after the Lock is applied and the Provider is notified, the Provider is under no obligation to require the Complainant to amend its complaint accordingly, but may do so in its discretion. It is the responsibility of the Registrant (UDRP Rule 2(e) and UDRP Rule 5(b)(ii)) to inform the Provider of any relevant updates that may affect Provider notices and obligations to Respondent under the UDRP and the Provider shall, in accordance with the UDRP, provide Respondent with case information at the details it prefers once the Provider is aware of the update (UDRP 5(b)(iii) requires Provider to send communications to the preferred email address of Respondent, for instance).

Recommendation #5: As a best practice, registrars and UDRP Providers are encouraged to provide a means that allows third parties to identify what their respective opening hours / days are, during which UDRP related tasks can be expected to be carried out.

Recommendation #6: The registrar must confirm to the UDRP Provider within 2 business days following receipt of the verification7 request from the UDRP Provider that any changes of registrar and registrant have been prevented and will be prevented during the pendency of the proceeding, and the Registrar must verify8 the information requested by the UDRP Provider.

Recommendation #7: If deemed compliant, the UDRP Provider shall forward the complaint to the Registrar and Respondent and notify them of the commencement of the administrative proceeding no later than 3 business days9 following receipt of the fees paid by the complainant.

Recommendation #810: Participating UDRP Respondents be granted an express option to request a four day extension should they so choose, with any such received four day extension request to be automatically granted, and the corresponding deadline extended by the UDRP Provider, at no cost to the Respondent. The availability of such automatic four-day extension option on request should also be flagged by the UDRP Provider for the Respondent's information on commencement of the proceedings and does not preclude any additional extensions that may be granted by the UDRP Provider as per article 5d of the UDRP Rules.

Recommendation #9: If the complaint should remain non-compliant, or fees unpaid, after the period for the administrative deficiency check per UDRP Para 4 has passed, or if the complainant should voluntarily withdraw during that period, the UDRP Provider informs the Registrar that the proceeding is withdrawn. The Registrar shall, within one business day of the transmission of the notice of withdrawal, release the "lock".

Recommendation #10: As part of its notification to the Registrant (Notification of Complaint – see section 4 of the UDRP Rules), the UDRP Provider informs the Registrant that any corrections to the Registrant's contact information during the remaining pendency of the proceedings are also required to be communicated to the UDRP Provider as per UDRP Rule 5(ii) and (iii).

Recommendation #11: This notification would also include information that any changes as a result of lifting of proxy / privacy services, following the 'locking', would need to be discussed / addressed by the UDRP Panel directly. The WG recommends that this issue is further reviewed as part of the privacy / proxy accreditation program development work.

Recommendation #12: Upon receipt and communication of a decision from the Provider, the Registrar must within 3 business days communicate to each Party, the Provider, and ICANN the date for the implementation of the decision in accordance with the Policy (UDRP Rule 16 and UDRP Paragraphs 4(k) and Paragraph 8(a). If the Complainant has prevailed, the Registrar shall implement the Panel order immediately after 10 business days have elapsed (UDRP Paragraph 4(k)). The Complainant or its authorized representative is required to provide the Registrar with the required information to support the implementation of the Panel decision; this should include the information that should be in the Whois. If the Respondent has prevailed, the Registrar shall prohibit transfer of the domain name to another registrar or registrant for 15 business days from the date the decision is transmitted from the Provider (UDRP Paragraph 8).

Recommendation #13: In the case of suspension of a proceeding (when the parties are trying to reach a settlement), the UDRP Provider informs the Registrar of the Suspension, including the expected duration of the suspension. Should both parties come to a settlement, which would involve a transfer, cancellation or agreement that the registration will remain with the Respondent, the registrar must remove any lock preventing a transfer or cancellation within 2 Business days of confirmation of the settlement by the UDRP Provider, unless the disputed domain name registration is otherwise the subject of a court proceeding that has been commenced concerning that disputed domain name.

Recommendation #14: The settlement process must follow these steps: (1) parties ask for suspension from the UDRP Provider, (2) parties settle, (3) parties submit a standardized "settlement form" to UDRP provider, (4) UDRP provider confirms to the registrar, copying both the Complainant and the Respondent, whether the terms of the settlement indicate Respondent agreement to the transfer or cancellation of the disputed domain name(s) to the complaint, or Complainant agreement that domain name(s) remain with the Respondent (5) settlement agreement is implemented by registrar (6) Complainant confirms the implementation to the UDRP Provider and (7) UDRP Provider dismisses the case.

Recommendation #15: ICANN, in collaboration with UDRP Providers, Registrars and other interested parties, will develop educational and informational materials that will assist in informing affected parties of these new requirements and recommended best practices following the adoption by the ICANN Board of these recommendations.

Which stakeholders or others were consulted?

As required by its charter, the PDP WG was required as 'as a first step, [to] request public input on this issue in order to have a clear understanding of the exact nature and scope of issues encountered with the locking of a domain name subject to UDRP Proceedings'. As a result, the WG conducted a survey amongst registrar as well as UDRP Providers as outlined in section 5.1. of the Final Report. In addition to specific questions concerning the practices and experiences of registrars and UDRP Providers, respondents were also asked to provide input on the charter questions. Furthermore, the WG opened a public comment forum to obtain community input on 25 July 2012.

Constituency / Stakeholder Group Statements were requested as well as input from other ICANN Supporting Organizations and Advisory Committees at an early stage of the process. No input was received in response to those requests. The Chair of the PDP Working Group did meet with the ccNSO at the ICANN meeting in Prague for an exchange of views on this topic (see http://ccnso.icann.org/meetings/toronto/summary.htm#neylon-greenberg for further details).

All comments received have been reviewed and considered by the Locking of a Domain Name subject to UDRP Proceedings PDP WG (see section 6 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. All other comments received were reviewed and addressed by the PDP WG as outlined in section 6 of the Final Report.

What significant materials did the Board review?

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

What factors the Board found 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 unanimous (supermajority) support for the motion obligates the Board to adopt the recommendation unless by a vote of more than 66%, the Board determines that the policy is not in the best interests of the ICANN community or ICANN.

Are there positive or negative community impacts?

Adoption of the recommendations is expected to clarify and standardize the process for the locking of a domain name subject to UDRP Proceedings for all parties involved including complainants, respondents, registrars as well as UDRP Providers. Implementation of the recommendations will require certain changes in some registrar processes as currently no standardized process is in place to deal with the locking of a domain name subject to UDRP proceedings, as well as certain modifications to the practices of UDRP Providers. For complainants, the main change is that at the time of filing, the complainant is no longer required to notify the respondent which is expected to reduce the instances of cyberflight (notification of the respondent is carried out by the UDRP Provider at the time of the official commencement of the proceedings). As a result of the change to no longer require notification of the respondent by the complainant at the time of filing, the respondent may see a reduction of informal response time. However, in order to compensate for this potential loss of informal response time, the recommendations foresee that participating UDRP Respondents be granted an express option to request a four day extension should they so choose, with any such received four day extension request to be automatically granted, and the corresponding deadline extended by the UDRP Provider, at no cost to the Respondent.

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 process for registrars and UDRP Providers as outlined above, there will likely be fiscal impacts related to implementation of the policy, but these costs are anticipated to be within the current budget.

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.

Whereas, on 21 April 2011, the Board resolved to direct ICANN staff, in coordination with the Structural Improvements Committee (SIC), to develop a proposed implementation plan and timeline for the recommendations in the Final Report of the ccNSO Review Board Working Group [PDF, 294 KB] and to submit these to the Structural Improvements Committee for review and Board approval (Resolution 2011.04.21.06).

Whereas, at its 18 June 2011 meeting, the SIC acknowledged receipt from staff of an implementation plan, titled "ccNSO Improvements Implementation Project Plan", dated 9 June 2011, and resolved to recommend it to the ICANN Board for approval.

Whereas, on 27 September 2013, the SIC acknowledged receipt of a letter from the ccNSO Chair announcing completion of the ccNSO review implementation in complement of a final ccNSO implementation Project Plan update, dated September 2013.

Whereas, on 27 September 2013, the SIC agreed to recommend that the ICANN Board receive the final ccNSO implementation Project Plan update [PDF, 170 KB], dated September 2013, note the implementation phase of the ccNSO review as complete, and commence the assessment phase inherent in the review cycle.

Resolved (2013.09.28.06), the Board receives the final ccNSO implementation Project Plan update, dated September 2013, and notes the completion of the implementation of the ccNSO review recommendations.

Resolved (2013.09.28.07), the Board directs the ICANN President and CEO to assess the improvements arising out of the ccNSO review in accordance with the assessment phase of the organizational review cycle.

Resolved (2013.09.28.08), the Board thanks the ccNSO for its implementation work.

Rationale for Resolution 2013.09.28.06 – 2013.09.28.08

In compliance with ICANN Bylaws, a periodic review of ICANN SO/ACs is required to assess the performance and operational effectiveness of the entity under review. The purpose of the review is to determine: (i) whether that organization has a continuing purpose in the ICANN structure; and (ii) if so, whether any change in structure or operations is desirable to improve its effectiveness.

This action is in direct response to a request from the Board to implement the recommendations arising out of the ccNSO review effort and serves to enable the assessment of the ccNSO review improvements in a timely manner.

This action does not involve any complex structural changes or budgetary consequences. No impact on the security, stability and resiliency of the domain name system is foreseen as a result of this action.

This is an Organizational Administrative Function not requiring public comment.

GNSO Review

Whereas, under ICANN's Bylaws the next review of the GNSO was due to commence in 2013.

Whereas, the SIC solicited and considered public comments on whether the review should be postponed and a new schedule for the review be established within the next six months.

Whereas, it is important that the review of the GNSO take into account the outcomes of ICANN's strategic planning efforts and the Accountability and Transparency Review Team 2's work, which can only be achieved through the initiation of a GNSO review in 2014.

Resolved (2013.09.28.09), that the Board directs the SIC to schedule the review of the Generic Names Supporting Organization (GNSO), which is mandated by ICANN Bylaws Article IV, Section 4, to commence in 2014, and that preparations for this Review commence as soon as feasible.

Rationale for Resolution 2013.09.28.09

The ICANN Bylaws require that structures within ICANN are reviewed on a regular basis as part of ICANN's continued accountability. To that end, the first organizational review of the GNSO was initiated in 2006. As part of that review, a report by LSE Public Policy Group and Enterprise LSE, an independent reviewer engaged to conduct that review, was published in September 2006 and the Report of the Board Governance Committee GNSO Review Working Group on GNSO Improvements was issued on 3 February 2008. In accordance with ICANN Bylaws Article IV, Section 4, the next review would commence five years after the issuance of the final report, which would require the review to commence in the early part of 2013. The Structural Improvements Committee (SIC) recommended to the Board that ICANN would benefit from delaying the initiation of this new GNSO review in order to factor in valuable inputs from the ICANN's Strategic Planning Process and the ongoing work of the second Accountability and Transparency Review Team convened under the Affirmation of Commitments (ATRT 2). Public comment period was initiated on 15 July 2013 to gather input to inform the SIC action on the Potential Postponement of the GNSO Review. Community response to the Public Comment yielded eight responses and seven responders indicated that the GNSO review should not be postponed. The reasons cited included:

The expansion of the TLD space has increased the number and variety of stakeholders participating in GNSO policy making and a review needs to take place on schedule to examine whether the current model meets the needs of a new generation of stakeholders.

GNSO Structure is unlikely to accommodate the anticipated new stream of stakeholders resulting from the expansion of the TLD space. The GNSO Review will be an important vehicle for considering and addressing this issue. The unbalance that is already occurring needs to be addressed by the GNSO Review.

The prior review took many years to implement. Responders stressed the need to minimize the length of the GNSO Review process in general, to provide a more efficient, responsive and effective review of the GNSO for the entire ICANN community.

The work being undertaken by the ATRT 2 in assessing the policy development process or the Strategic Planning process will not address the stated issues in any substantive way.

The proposed approach is intended to be responsive to the community's feedback urging no further delay, while also establishing a timeline for commencing a review that is suitable for the complexity of work and importance of careful planning, including considerations of the methodology of the review and community involvement in the process. Recognizing the importance of a thorough and well-organized review that takes into consideration relevant inputs from current work underway, as well as the diverse opinions of the community, the SIC balanced these considerations with the feedback from the community.

To fulfill the Board's obligation under the Bylaws to "cause a periodic review of the performance and operation of each Supporting Organization, each Supporting Organization Council," the SIC recommends that the planning for the next review of the GNSO begin in earnest in preparation for the Review, which will commence as soon as feasible in 2014.

The goal of the structural review is "to determine (i) whether that organization has a continuing purpose in the ICANN structure, and (ii) if so, whether any change in structure or operations is desirable to improve its effectiveness." Given the changing environment, the increased number of participating stakeholders and their diversity and the lessons gleaned from the last review of the GNSO, the SIC considers the planning of the review to be of paramount importance in order to ensure that the recommendations for improvement are useful and implementable. The SIC will develop and implement a review schedule that takes into consideration the sense of urgency articulated within public comments, while ensuring that ample time is allocated to the planning effort. The additional time allotted to community consultations will ensure that the community has ample time to consider and provide input on how the second GNSO Review should be conducted, thus enhancing ICANN's accountability and transparency.

No impact is expected on the security or stability of the DNS. There will be fiscal and resource impacts associated with the GNSO Review when it is initiated. These resources and costs will be anticipated and allotted for within ICANN's budget for the relevant fiscal year(s) within which the review is commenced and completed.

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

Main Agenda:

Appointment of 2014 Nominating Committee Chair and Chair-Elect

Whereas, the BGC reviewed the Expressions of Interest from candidates for the 2014 Nominating Committee ("NomCom") Chair and Chair-Elect, interviewed those candidates and considered the results of a 360-degree evaluation of the 2013 NomCom leadership.

Whereas, the BGC has recommended that Cheryl Langdon-Orr be appointed as the 2014 NomCom Chair and Stéphane Van Gelder be appointed as the 2014 NomCom Chair-Elect.

Rationale for Resolution 2013.09.28.10

ICANN's Bylaws require the Board to appoint the Nominating Committee (NomCom) Chair and NomCom Chair-Elect. See Article VII, sections 2.1 and 2.2 at http://www.icann.org/en/general/bylaws.htm#VII. The Board has delegated the responsibility for recommending the NomCom Chair and Chair-Elect for Board approval to the Board Governance Committee. See BGC Charter at http://www.icann.org/en/committees/board-governance/charter.htm. The BGC posted a call for expressions of interest (EOI), reviewed the received EOIs, conducted interviews with the candidates, and oversaw a 360 degree evaluation of the 2013 NomCom leadership before making a recommendation. The Board has considered and agrees with the BGC's recommendation. The Board also would like to thank all who expressed interest in becoming part of the NomCom leadership.

Appointing a NomCom Chair and Chair-Elect identified through a public EOI process positively affects the transparency and accountability of ICANN. Adopting the BGC's recommendation has no financial impact on ICANN that was not otherwise anticipated, and will not negatively impact the security, stability and resiliency of the domain name system.

This is an Organizational Administrative Function not requiring public comment.

Treatment of New gTLD Historical Costs

Whereas, ICANN incurred costs over several years to design and prepare the launch of the New gTLD Program.

Whereas, the costs incurred from October 2007 (the date of the GNSO recommendation on the New gTLD Program) to the launch of the program ("Historical Development Costs") are to be repaid to ICANN from a portion of the New gTLD Program application fees.

Whereas, the Historical Development Costs are charged to the Program progressively as the evaluation work advances and the fees become non-refundable, which began in July 2012.

Whereas, the Board Finance Committee has recommended that the amount of Historical Development Costs repaid to ICANN's operating fund from the New gTLD Program be transferred to the Reserve Fund.

Resolved (2013.09.28.11), the Board authorizes the President and CEO, or his designee(s), to take all actions necessary to transfer, when and as appropriate, from ICANN's operating fund to ICANN's Reserve Fund all amounts, whether already paid or to be repaid in the future, that constitute Historical Development Costs.

Rationale for Resolution 2013.09.28.11

ICANN has incurred costs to define, design and prepare the launch of the New gTLD Program throughout the years preceding the launch of the Program in January 2012 ("Historical Development Costs"). (See Appendix 1.)

As part of the design of the Program, the Historical Development Costs, were advanced by ICANN's operating fund and were to be recouped through a portion of the application fee collected from applicants in the New gTLD Program. In order to ensure sufficient funds were received, the application fee included $25,000 per application to allow for the repayment of the Historical Development Costs to ICANN. The $25,000 amount resulted from an historical estimation of the total development costs of the Program divided by 500 applications. It was also determined that the costs incurred by ICANN that would be repaid through a portion of the application fee would be those incurred between October 2007, the approximate date of the GNSO policy recommendations on new gTLDs, and the launch of the Program in January 2012.

ICANN staff has estimated the Historical Development Costs to be approximately $32.5 million. This amount has been communicated as part of the FY13 Budget presentation in June 2012. Its detailed documentation is currently being finalized for auditing and communication to the community.

The amount of Historical Development Costs covered through the $25,000 collected from actual applications received amounts to approximately $48 million (25k * 1930 applications), before the impact of refunds. The difference between $48 million (less refunds) and the approximately $32.5 million contributes to the net remaining balance of the Program.

The amount of repayment of the Historical Development Costs is being charged to the New gTLD Program, starting in July 2012, as the evaluation work advances and application fees become non-refundable.

Approximately $17 million of costs charged to the New gTLD Program from July 2012 through June 2013, with a corresponding revenue to ICANN, was transferred into ICANN's operating account in August 2013.

Although it has always been the intention that the funds resulting from the repayment of the Historical Development Costs be transferred into ICANN's Reserve Fund, this intention was never formalized in a Board resolution. (See Appendix 1.)

Following the imminent initial transfer to the Reserve Fund of the already recovered Historical Development Costs now sitting in ICANN's operating account, for practical purposes ICANN intends to make quarterly transfers to the Reserve Fund as amounts are charged to the New gTLD Program account.

This resolution will have a positive impact in that it provides clarity on the management of ICANN's resources. This will have a fiscal impact on ICANN and the community as intended. This should not have any impact on the security, stability and resiliency of the domain name system (DNS).

This is an Organizational Administrative Function that does not need public comment at this stage, but the nature and method of handling the Historical Development Costs and the fact that they be transferred to the Reserve Fund have previously been posted and subject to public comment.

Proposed Process for GNSO Stakeholder Group and Constituency Charter Amendments

Whereas, it is important that GNSO Stakeholder Groups and Constituencies have the flexibility to update, modify and evolve their organizational charters to reflect community changes while balancing the need for validation by the Board.

Whereas, there is currently no procedure for a GNSO Stakeholder Group or Constituency to obtain approval by the ICANN Board of Directors for an amendment of its charter.

Whereas, the Structural Improvements Committee of the ICANN Board has formulated and recommended a process by which GNSO Stakeholder Groups and Constituencies can amend their charters with the Board maintaining its appropriate validation responsibilities for recognition of those GNSO groups.

Whereas, the community has had the opportunity to review and comment on the proposed process and changes have been made to the proposed process to address community suggestions.

Resolved (2013.09.28.12), the Board approves the process formulated and recommended by the Structural Improvements Committee and directs ICANN Staff to notify the leadership of the various GNSO Stakeholder Groups and Constituencies of the process and post a copy of the approved process on the GNSO web site within seven calendar days.

Rationale for Resolution 2013.09.28.12

In July 2009, as part of the comprehensive GNSO Improvements program, the ICANN Board approved the formal Charters of four new GNSO Stakeholder Groups (see ICANN Board Resolution 2009.30.07.09).

The ICANN Bylaws (Article X, Section 5.3) state, "Each Stakeholder Group … and each of its associated Constituencies shall maintain recognition with the ICANN Board." Because the original GNSO organizational charters approved in 2009 were subject to exhaustive and rigorous negotiations and discussions between the community and Board members, it is appropriate that the Board have an opportunity to review and approve subsequent charter amendments. Further, the Board believes that review of GNSO charter amendments maintained by GNSO Stakeholder Groups and the Constituencies that populate those groups is an important obligation in maintaining recognition of formally approved GNSO Structures consistent with ICANN Bylaw principles.

The Board's Structural Improvements Committee (SIC) developed this process and the proposal was shared with the community for review and comment. The final version approved by the Board reflects adjustments to the original SIC proposal after consideration of helpful community feedback regarding the timing of staff notifications and the timeline and process for Board review of community charter amendments.

This action will have no immediate or substantial impact on ICANN's resources. At certain times, it will demand additional community work, staff support work and Board review time, but those efforts should be of limited duration and they will improve the transparency and ultimate efficiency of ICANN's structural and management processes.

This action is not expected to have any impact on the security, stability or resiliency of the DNS.

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

Clarification Regarding the Competition, Consumer Trust and Choice Metrics for the New gTLD Program per the AoC Review

Whereas, on 18 July 2013, the ICANN Board directed the CEO to commence the process for convening the Competition, Consumer Trust and Consumer Choice (CCT) Review Team to facilitate preliminary work on the feasibility, utility and cost-effectiveness of adopting the recommendations of the GNSO Council and the ALAC, as well as analyzing other potential metrics to be made available for the CCT review.

Whereas, the Board wishes to clarify its Resolutions 2013.07.18.06 and 2013.07.18.07 to identify that the actual CCT review is not being commenced at this time, rather that an Implementation Advisory Group for Competition, Consumer Trust and Consumer Choice is approved for empanelment. The work of this Advisory Group is intended to be an input to the CCT review at the point in the future when the CCT review is commenced according to the schedule set forth in the Affirmation of Commitments (AoC).

Resolved (2013.09.28.13), the Board directs the CEO to convene a volunteer group (the Implementation Advisory Group for Competition, Consumer Trust and Consumer Choice) in advance of a future AoC Competition, Consumer Trust and Consumer Choice Review Team, for the purpose of: (i) evaluating and reporting to the Board on the feasibility, utility and cost-effectiveness of adopting the recommendations of the GNSO Council and the ALAC; (ii) evaluating other inputs, including historical data regarding metrics used to evaluate earlier rounds of new gTLDs (2000, 2004); (iii) engaging with the GNSO, ALAC and staff in an effort to reach agreement on the metrics; and (iv) proposing a set of metrics to be compiled by ICANN to be made available to a future AoC Review Team examining the New gTLD Program.

Resolved (2013.09.28.14), the portions of Resolutions 2013.07.18.06 and 2013.07.18.07 suggesting that the CCT review was being commenced prior to the time called for within the AoC are retracted.

Rationale for Resolution 2013.09.28.13 – 2013.09.28.14

The Board's resolution clarifies its prior resolution 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.

The Board's resolution calls for the President and CEO to convene a group of volunteers to provide implementation advice in advance of the convening of a future Competition, Consumer Trust and Consumer Choice Review Team to: evaluate and report on the feasibility, utility and cost-effectiveness of implementing the various consumer metrics recommended by the community; evaluating other inputs, including historical data regarding metrics used to evaluate earlier rounds of new gTLDs (2000, 2004); engage with the GNSO and ALAC to identify agreement on metrics; and ultimately to propose a series of metrics for the Board to approve, to be collected and made available for use by the future review to be conducted under the AoC in its discretion. If, after discussing this with the GNSO and ALAC, the Implementation Advisory Group for Competition, Consumer Trust and Consumer Choice ultimately recommends against using a metric proposed by the GNSO Council and/or ALAC, the Advisory Group is expected to provide an explanation.

This work is to commence immediately, and involves engaging the community, as well as ICANN, evaluating and reporting on metrics proposed by the GNSO Council and ALAC, and recommending the metrics to be collected by ICANN in preparation for a future review of the New gTLD Program.

The review called for under the AoC is to occur if and when new gTLDs have been in operation for one year and involves examining the extent to which the introduction or expansion of gTLDs has promoted competition, consumer trust, and consumer choice. This review is not yet ripe to commence. Today, the Board is calling for implementation work to proceed that is intended to facilitate the work of the AoC review at the appropriate time.

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

Bylaws Revisions Re TLG (Published on 30 October 2013)

Whereas, the ICANN Bylaws currently call for the Technical Liaison Group (TLG) to appoint a non-voting liaison to the ICANN Board as well as a voting member to the Nominating Committee.

Whereas, the Bylaws also set out areas of responsibility for the TLG in providing advice to the Board, including the appointment of a group of experts from whom the ICANN Board can seek advice on relevant matters. This group of experts has not yet been identified.

Whereas, in 2011, ICANN, through the Structural Improvements Committee, commissioned a review of the TLG and its continuing purpose in the ICANN structure and identified that focus was needed to establish effective mechanisms to provide the Board with the technical advice that it may need, noting that the current form of operation of the TLG has not achieved this goal.

Whereas, the Board is renewing its focus on the organization of its activities, including the introduction of better tracking of advice received across the advisory mechanisms available to the Board, and refining the technical advice role of the TLG is an important part of this Board organizational work. The proposed Bylaws revisions to remove the TLG liaison to the Board and the voting member to the Nominating Committee are intended to allow the component entities of the TLG to focus instead on their advisory functions.

Resolved (2013.09.28.15), the Chair of the ICANN Board, in coordination with the President and CEO, is directed to initiate communications with the component entities of the TLG to facilitate their identification of experts in fulfillment of Article XI-A, Section 2, Paragraph 6 of the ICANN Bylaws and the resulting strengthening of the TLG advisory mechanism.

Resolved (2013.09.28.16), after the communications take place, the Board directs the President and CEO to publish for public comment proposed Bylaws revisions relating to the TLG liaison to the Board and the appointment of a voting member of the Nominating Committee.

Resolved (2013.09.28.17), these resolutions and accompanying rationale shall remain confidential as a matter that the Board has determined as not appropriate for public distribution in the resolutions, preliminary report or minutes, pursuant to Article III, section 5.2 of the ICANN Bylaws, pending determination by the President and CEO that the non-confidential portion can be made public.

RATIONALE FOR RESOLUTIONS 2013.09.28.15 – 2013.09.28.17:

The Board's action today, addressing how to improve the advisory function of the Technical Liaison Group (TLG), is part of the Board's has renewed focus on organizing and strengthening its activities. One core of that work is addressing how the Board receives the advice that it needs, and how the advice arising out of ICANN's advisory mechanisms is better tracked. Considering how the TLG fits into this advisory structure is a natural extension of this work, and also follows the work initiated in 2011 with the review commissioned regarding the TLG.

What is the proposal being considered?

The action being approved today is to first direct the ICANN Board Chair and the President and CEO to communicate with the component entities on renewing their focus on their advisory capacities, and to initiate work to develop the group of eight experts that the Bylaws anticipate will be available to provide advice to the Board. Further, the Board is asking the component entities of the TLG to

The use of the TLG liaison to the Board as a mechanism for provision of advice has not been an optimal method of providing advice. Under the Bylaws, the TLG is prohibited from forming collective advice, therefore the use of the TLG liaison can only provide advice from the entity making the selection during that year. The proposal at hand today would encourage each of the TLG's component entities to focus on the selection of experts – instead of focusing on annual appointments – and these experts could then provide ICANN with a range of expertise representing each of the TLG entity viewpoints.

The need to alter how the TLG/its component entities currently provide advice to the ICANN Board (and meet the existing Bylaws requirements) has been the subject of conversation within the ICANN community for years. A review through the Structural Improvements Committee resulted in a recommendation that the TLG be disbanded, and that recommendation was supported. That review also resulted in recommendations that different engagement methods with the component entities of the TLG need to considered in order to give the Board the advice that it needs. This action today is a first step in modifying ICANN's engagement, and is also one of the first steps ICANN has taken in formally identifying how it would like to evolve and enhance its receipt of advice on technical matters.

After the communications take place regarding the improvement of provision of advice, the Board is approving that proposed Bylaws changes to be posted for public comment. The effect of these revisions, and the issue that is likely to be before the Board after the close of comments, is to consider the removal of the TLG's appointing a liaison to the Board, as well as the removal of the TLG's appointment of a voting member to the ICANN Nominating Committee. The removal of these appointment obligations is anticipated to allow the entities of the TLG to focus their attention on the provision of advice to ICANN, as opposed to the appointment of singular liaisons that are not authorized to represent the panoply of views within the TLG.

This action is not anticipated to have a fiscal impact on ICANN. The anticipated evolution and enhancement of how ICANN receives advice on technical matters could have a positive impact on how ICANN addresses matters relating to the security, stability or resiliency of the DNS.

The posting of Bylaws revisions for public comment is an Organizational Administrative Action not requiring public comment, however follow on consideration of the revisions require public comment.

Resolution Re Internet Coordination (Published on 17 November 2013)

Whereas, the existing, global, open, multi-stakeholder Internet governance system is under increasing pressure to evolve and adapt to global concerns.

Whereas, such pressures and concerns, if not addressed, may negatively impact many, including ICANN stakeholders and the stability and effectiveness of the open Internet system.

Whereas ICANN has a responsibility to act in the global public interest.

Whereas these increasing pressures cannot be addressed by ICANN alone, but only by a group of similarly concerned organizations and entities acting in concert, ICANN should participate in an effort to form an Internet cooperation agenda ("Coalition").

Resolved (2013-09-28-C1), the ICANN Board authorizes its CEO to allocate necessary and sufficient time and resources of ICANN and work with other key organizations and leaders to establish a coalition towards the formation of a movement or initiative. The financial resources for building the coalition must be allocated from the already established Strategic Plan funds.

ICANN's involvement shall be consistent with ICANN's purpose. The CEO shall provide regular reports to the Board of Directors regarding the status of these discussions.

Resolved (2013-09-28-C2), the Board directs the CEO to: (1) assess the potential for success of the Coalition; (2) in the event of a positive assessment, should the CEO recommend an additional longer term strategy based on Coalition results, the CEO shall present such a plan of action, including any additional financial resources required, for further consideration by the Board.

Confidentiality Resolution

Resolved (2013-09-28-C3), the Board directs that pursuant to Article III, Section 5.2 of the ICANN Bylaws, this resolution and rationale be kept confidential. Such resolution shall be held confidentially, without publication, until such time as the Board determines that such a resolution shall be published.

RATIONALE FOR RESOLUTIONS 2013-09-28-C1 – 2013-09-28-C2

ICANN uses a multi-stakeholder governance model to coordinate, at the overall level, the global Internet's systems of unique identifiers. This governance model is derived from the approach of global multi-stakeholder cooperation that has been used over time in the development of the Internet and World Wide Web. As ICANN has been participating in discussion regarding Internet Governance, there has been continuing debate on whether to use conventional governance models or a global multi-stakeholder governance model to address broader governance coordination issues. This action by the Board is an initial step in moving towards how ICANN can assist the global community in addressing these issues through global multi-stakeholder cooperation without compromising or increasing ICANN's mandate. The potential for the formation of a Coalition to address these Internet coordination issues appears to be the most promising path forward to starting this work.

Taking this action allows ICANN to remain responsive to those in the Internet community that wish to continue to use a global multi-stakeholder to address broader Internet governance issues, while remaining accountable to its core mission. The development of a coalition will allow for community participation and input into this coordination work, while not relying solely on ICANN or ICANN processes to move coordination issues to the forefront. Achieving this balance is key for ICANN in its role in acting in the public interest.

As this resolution directs that all of this initial work be performed within the Board approved budget for Strategy Panels of US$3.5 million this action is not anticipated to have a significant financial impact on ICANN. Similarly, directing ICANN to initiate coordination exercises is not anticipated to have any impact on the security, stability or resiliency of the DNS, though the outcomes of any Coalition could have positive benefits on how these issues are coordinated in the future.

This is an Organizational Administrative Function for which public comment is not required.

Published on 1 October 2013

1 It should be noted that such a lock should not prevent the renewal of a domain name subject to UDRP proceedings, as per the Expired Domain Deletion Policy (EDDP).

2 This is an initial check the UDRP Provider performs to ensure it does not concern a bogus complaint. This check should not be confused with the administrative compliance check as described in the UDRP which is performed as per step 4 of this proposal.

3 To apply to accredited privacy / proxy providers following finalization of the privacy / proxy accreditation program by ICANN.

4 Business days are defined as business days in the jurisdiction of the entity required to undertake the action, in this case the registrar.

5 The revealed data may only include data held on record by the accredited / affiliated privacy / proxy provider.

6 For clarity, this includes any transfer to a privacy or proxy service other than reveals of the proxy customer data as provided for in the following paragraph.

7 The UDRP Provider will send a request to the registrar to verify amongst others that the named Respondent is the actual registrant of the domain name(s) in issue, language of the registration agreement as well as checking the Respondent's contact details.

8 This verification request relates to the requirement for the Registrar to provide the Provider with a verification of the items requested.

9 This change to the UDRP Rules (currently it says 'calendar' days) is recommended to ensure that this is in line with the 2 business day requirement to lock as otherwise there may be a situation whereby 2 business days are longer than 3 calendar days, not allowing the UDRP Provider to perform the administrative checks within the allocated timeframe.

10 The rationale for adding this recommendation is to address the concerns expressed during the public comment forum concerning the loss of informal response time as a result of the proposed change to no longer require the Complainant to notify the Respondent at the time of filing and would give those participating Respondents that actually need the extra four days the comfort of cost-neutral certainty where requested, without impacting the UDRP timelines overall.

ICANN is not responsible for profile content or verification of user details.

Data Protection

A note about our privacy policies and terms of service:

We have updated our privacy policies and certain website terms of service to provide greater transparency, promote simplification, and align with recent changes in privacy laws applicable to us. Learn more.

This site uses cookies to deliver an efficient user experience and to help us see how the site is used. Learn more.OK

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