Skip to main content

Resolutions Adopted at Special ICANN Board Meeting | Special Meeting of the Board via Telephone

Redelegation of .tf (French Southern Territories)

Whereas, on 10 March 2000, in resolution 00.13, the Board authorized the President and staff to work with the ccTLD managers, Governmental Advisory Committee, and other interested parties to prepare draft language for ccTLD contracts, policy statements, and/or communications, including appropriate funding arrangements, to be presented to the Board and posted for public comment as soon as practicable;

Whereas, on 13 March 2001, in resolution 01.37, the Board directed ICANN management to press forward with continued vigor toward the completion of draft legacy agreements, and to pursue, as needed, acceptable ccTLD agreements;

Whereas, negotiators for AFNIC and ICANN have reached agreement, subject to the ICANN Board's approval, on the terms of a framework of accountability for the .tf top-level domain;

Whereas, the President recommends that authorization be given to enter into this agreement subject to the foregoing;

Resolved [04.41] that the President is authorized to enter into on behalf of ICANN the framework of accountability for .tf in substantially the form as provided to the Board, with any minor corrections or adjustments, and verification of documentation, as appropriate; and

Resolved [04.42] that, upon signature of the agreement, the President is authorized to take such actions as appropriate to implement the agreement.


RSSAC Recommendation on IPv6 Nameserver Records

Whereas, ICANN's Root Server System Advisory Committee (RSSAC) has submitted a recommendation to the ICANN board to allow IANA to “proceed with adding AAAA glue [name server] records to the delegations of those TLDs that request it,” and suggests some operational guidelines for IANA to use in implementing this recommendation.

Whereas the RSSAC recommendation is based on a thorough study, including extensive testing on a real testbed network.

Whereas the Security and Stability Advisory Committee (SSAC) was asked to review the RSSAC recommendation and has raised no objections.

Whereas, ICANN staff has analyzed the RSSAC recommendation, and prepared a draft administrative procedure document for IANA to submit to the relevant communities for public comment and implementation.

Whereas, extensive consultations have taken place between and among ICANN staff, the SSAC, and interested members of the community, including root server operators and ccTLD managers.

Resolved [04.43] that the Board formally accepts the recommendation of the RSSAC, and directs the President, through the IANA Manager and staff, to submit the draft procedures to the relevant communities for public comment and implementation.


SITA Domain Name Activation

Whereas, SITA is the registry operator for the .aero top-level domain;

Whereas, SITA requested and received authorization from ICANN in October 2003, to register up to 1000 names to perform testing of a new product intended to add services to the aviation community when using the .aero domain names;

Whereas, currently more than 200 airports have registered their

Whereas, on 17 March 2004 SITA requested that ICANN amend SITA’s Registry Agreement to permit SITA to populate the second level according to a proposed plan. In the first step, it is necessary to activate .aero domain names corresponding to all aviation community agreed two and three character airline and airport location code identifiers. (e.g. <> and <lax. aero>). Endorsement to this request has been given by the DOT AERO Council

Resolved [04.44], that the ICANN President and General Counsel are authorized to negotiate and implement modifications to SITA's Registry Agreement with ICANN for operation of the .aero top-level domain as deemed necessary to provide for the offering of such proposed population of the second level with airline and/or airport location code identifiers by SITA, provided that the offering of such second level allocation by SITA would be in accordance with and consistent with all other applicable contractual limitations in the Registry Agreement.


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"""" is not an IDN."