Skip to main content
Resources

Approved Board Resolutions | Special Meeting of the ICANN Board

* Note: Where available, draft Rationale of the Board's actions is presented under the associated Resolution. The draft Rationale is not final until approved with the minutes of the Board meeting.

  1. Consent Agenda
  2. Delegation of the .қаз ("kaz") domain representing Kazakhstan in Cyrillic
  3. Public Comment Posting: Further Bylaws Changes for Revised PDP
  4. Reaffirmation of second round of applications in New gTLD Program

 

  1. Consent Agenda

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

    1.1. Approval of Minutes of 8 December 2011 ICANN Special Board Meeting

    Resolved (2012.02.07.01), the Board approves the minutes of the 8 December ICANN Regular Board Meeting.

    1.2. Redelegation of the .BY domain representing Belarus to Reliable Software Inc.

    Whereas, BY is the ISO 3166-1 two-letter country-code designated for Belarus;

    Whereas, ICANN has received a request for the redelegation of .BY to Reliable Software Inc.;

    Whereas, ICANN has reviewed the request, and has determined that the proposed redelegation would be in the interests of the local and global Internet communities.

    Resolved (2012.02.07.02), the proposed redelegation of the .BY domain to Reliable Software Inc. is approved.

    Rationale for Resolution 2012.02.07.02

    Why the Board is addressing the issue now?

    Staff present delegation and redelegation requests for country-code domains to the Board for decision, once staff are satisfied the applicant has provided a sufficiently complete application that has a reasonable prospect of a positive Board decision. In line with ICANN's commitments to perform timely processing of requests relating to the IANA function, and the DNS root zone in particular, the ICANN Board seeks to evaluate such requests at its next scheduled Special Meeting.

    What is the proposal being considered?

    The proposal is to approve a request to IANA to change or designate the sponsoring organisation (also known as the manager or trustee) of a country-code top-level domain. In line with established practice, the ICANN Board is involved in making the decision to proceed with such requests as one step of this multi-step process.

    Which stakeholders or others were consulted?

    In the course of evaluating a delegation application, ICANN staff consults with the applicant, the current operator (if applicable), and other directly connected parties. In line with ICANN's practice of keeping incomplete root zone change requests in confidence, ICANN has not performed open consultation on this matter.

    What concerns or issues were raised by the community?

    Any concerns or issues are raised within the public report that will be published in conjunction with this action. This report will be published on the IANA website at http://www.iana.org/ should the root zone change request has successfully completed final processing, usually 1-2 months after the Board's decision.

    What significant materials did the Board review?

    The Board is involved in assessing requests against a variety of public interest criteria. This criteria includes establishing the country-code is eligible (e.g. listed in the ISO 3166-1 standard); establishing the proposed manager is supported by the local Internet community; establishing the proposed operator is operationally and technically competent; establishing the proposed manager is based locally and bound under local law; establishing the proposed manager operates fairly and equitably; establishing that in cases there is a transfer of operations that an appropriate plan is in place to preserve ongoing stability of the domain; and establishing that the action is compatible with any applicable local laws and regulations. During the staff compilation process, the applicant is asked to provide a variety of materials in support of these various aspects. Pertinent information from these supplied materials and other staff research is provided to the Board, and published in a public report at the end of implementing an approved request.

    What factors the Board found to be significant?

    The Board considers factors described in the public report, in relation to the basic principles of country-code domain delegation described earlier.

    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, and the local communities to which country-code top-level domains are designated to serve.

    Are there fiscal 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 fiscal impact of the internal operations of country-code top-level domains within a country, other than ensuring the operator is based in country and has the appropriate mechanisms to allow the local Internet community to properly oversee the domain's ongoing operation.

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

    For country-code top-level domain delegations, ICANN seeks to approve only such requests where reasonable concerns have been satisfactorily addressed, and the proposed new manager has demonstrated a sufficient level of operational and technical competency where such concerns should be minimal.

  2. Delegation of the .қаз ("kaz") domain representing Kazakhstan in Cyrillic

    Whereas, .қаз ("kaz"), encoded as "xn--80ao21a" is a string that has been deemed to appropriately represent Kazakhstan through the IDN Fast Track process.

    Whereas, ICANN has received a request for delegation of .қаз to the Association of IT companies of Kazakhstan.

    Whereas, ICANN has reviewed the request, and has determined that the proposed delegation would be in the interests of the local and global Internet communities.

    Resolved (2012.02.07.03), the proposed delegation of the .қаз domain to the Association of IT companies of Kazakhstan is approved.

    Rationale for Resolution 2012.02.07.03

    Why the Board is addressing the issue now?

    Staff present delegation and redelegation requests for country-code domains to the Board for decision, once staff are satisfied the applicant has provided a sufficiently complete application that has a reasonable prospect of a positive Board decision. In line with ICANN's commitments to perform timely processing of requests relating to the IANA function, and the DNS root zone in particular, the ICANN Board seeks to evaluate such requests at its next scheduled Special Meeting.

    What is the proposal being considered?

    The proposal is to approve a request to IANA to change or designate the sponsoring organisation (also known as the manager or trustee) of a country-code top-level domain. In line with established practice, the ICANN Board is involved in making the decision to proceed with such requests as one step of this multi-step process.

    Which stakeholders or others were consulted?

    In the course of evaluating a delegation application, ICANN staff consults with the applicant, the current operator (if applicable), and other directly connected parties. In line with ICANN's practice of keeping incomplete root zone change requests in confidence, ICANN has not performed open consultation on this matter.

    What concerns or issues were raised by the community?

    Any concerns or issues are raised within the public report that will be published in conjunction with this action. This report will be published on the IANA website at http://www.iana.org/ should the root zone change request has successfully completed final processing, usually 1-2 months after the Board's decision.

    What significant materials did the Board review?

    The Board is involved in assessing requests against a variety of public interest criteria. This criteria includes establishing the country-code is eligible (e.g. listed in the ISO 3166-1 standard); establishing the proposed manager is supported by the local Internet community; establishing the proposed operator is operationally and technically competent; establishing the proposed manager is based locally and bound under local law; establishing the proposed manager operates fairly and equitably; establishing that in cases there is a transfer of operations that an appropriate plan is in place to preserve ongoing stability of the domain; and establishing that the action is compatible with any applicable local laws and regulations. During the staff compilation process, the applicant is asked to provide a variety of materials in support of these various aspects. Pertinent information from these supplied materials and other staff research is provided to the Board, and published in a public report at the end of implementing an approved request.

    What factors the Board found to be significant?

    The Board considers factors described in the public report, in relation to the basic principles of country-code domain delegation described earlier.

    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, and the local communities to which country-code top-level domains are designated to serve.

    Are there fiscal 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 fiscal impact of the internal operations of country-code top-level domains within a country, other than ensuring the operator is based in country and has the appropriate mechanisms to allow the local Internet community to properly oversee the domain's ongoing operation.

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

    For country-code top-level domain delegations, ICANN seeks to approve only such requests where reasonable concerns have been satisfactorily addressed, and the proposed new manager has demonstrated a sufficient level of operational and technical competency where such concerns should be minimal.

  3. Public Comment Posting: Further Bylaws Changes for Revised PDP

    Whereas, on 27 September 2011, the GNSO Council adopted the Updated Final Report (http://gnso.icann.org/improvements/updated-final-report-pdpwt-28sep11.pdf [PDF, 1.51 MB]) of the Policy Development Process Working Team (PDP-WT), setting out a proposed new Annex A to the ICANN Bylaws and a Policy Development Process (PDP) Manual, in fulfilment of a directive to develop a new PDP that is more effective and responsive to the GNSO's needs.

    Whereas, the Board adopted the new Annex A on 8 December 2011 and directed transition to the new PDP.

    Whereas, additional Bylaws revisions are necessary to fully implement the new PDP, including definition of new voting thresholds set out in the PDP-WT Updated Final Report.

    Resolved (2012.02.07.04). the ICANN Board approves the posting for public comment of further revisions to the ICANN Bylaws as necessary for the implementation of the new PDP.

    Rationale for Resolution 2012.02.07.04

    The further revision of the ICANN Bylaws is necessary for complete documentation of the transition to the new PDP as approved by the GNSO Council and the ICANN Board. To assure accountability to the ICANN community, the posting for public comment of the proposed Bylaws changes will allow for community input and transparency into the implementation steps. This action does not have an impact on ICANN's resources and will not have an impact on the security or stability of the DNS.

  4. Reaffirmation of second round of applications in New gTLD Program

    Prior to the consideration of this item, Board members and liaisons that have been identified as having a potential conflict of interest related to the New gTLD Program were excused from the meeting.

    Whereas, the first application window for the New gTLD Program opened on 12 January 2012 and will close on 12 April 2012.

    Whereas, the GNSO policy recommendations accepted by the Board on 26 June 2008 stated that ICANN should introduce new gTLDs in rounds.

    Whereas, in the process of forming the New gTLD Program, ICANN has committed to undertake certain work prior to initiating a second round of an application window for the New gTLD Program.

    Resolved (2012.02.07.05), ICANN is committed to opening a second application window for the New gTLD Program as expeditiously as possible.

    Resolved (2012.02.07.06), the Board directs the CEO to publish a document describing the work plan required prior to initiating a second application window for the New gTLD Program, specifically addressing the GAC requirement for assessment of trademark protections and root zone operation, and identifying other prerequisites to the next round of new gTLDs.

    Resolved(2012.02.07.07), the Board directs the CEO to continue working with the ICANN community to refine the work plan and address the prerequisites needed to open the second round of new gTLDs.

    Rationale for Resolutions 2012.02.07.05 – 2012.02.07.07

    In response to continued calls from the community regarding whether ICANN will proceed with additional rounds of applications for new gTLD applications, the Board takes this action to reaffirm ICANN's commitment to following the GNSO policy recommendations on the introduction of new gTLDs. Those recommendations included that new gTLDs should be introduced in rounds. ICANN has agreed to undertake work and study prior to the opening of another application window, and is working to remain accountable both to the GNSO policy recommendations as well as to the commitments for further work and study. These prerequisites include specifically addressing the GAC requirement for assessment of trademark protections and root zone operation. Though it will not be possible to identify a date certain for the opening of a second round of applications for the New gTLD Program, it is important to provide detail to the community regarding the specific work required.

    The action directed in this resolution will not have any further impact on ICANN resources. In addition, the action required in this resolution will not impact the security or the stability of the DNS. Of course, part of ICANN's continued commitment in monitoring the impact of the introduction of new gTLDs includes the impact on the security and the stability of the DNS.

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