Skip to main content
Resources

Adopted Resolutions from ICANN Board Meeting

Approval of Minutes

Resolved (06.81), the minutes of the Board Meeting of 15 August 2006 are approved.

Resolved (06.82), the minutes of the Board Meeting of 7 September 2006 are approved.

Resolved (06.83), the minutes of the Board Meeting of 25 September 2006 are approved.

Approval of New Registry Service by PIR - Excess Deletion Fee

Whereas, PIR is concerned about the growth of domain tasting in the .ORG registry, and has proposed a “restocking fee” on certain .ORG domain names deleted during the 5-day add-grace period.

Whereas, PIR discussed the proposal at the ICANN Meeting in Marrakech, Morocco, consulted with the Non-commercial Users Constituency, the At-Large Advisory Constituency, and with a number of ICANN-accredited registrars.

Whereas, PIR submitted a request for a new registry service called excess deletion fee under the Registry Services Evaluation Policy.

Whereas, ICANN conducted its review of the request and determined that there are no significant competition, security or stability issues.

Resolved, (06.84), the President and the General Counsel are authorized to enter into an amendment of the .ORG Registry Agreement to implement the proposed excess deletion fee service.

Approval of New Registry Service by NeuLevel - Bulk Transfer of Partial Portfolio

Whereas, Register.com and CSC Corporate Domains, two ICANN-accredited registrars, approached NeuLevel to request approval of a registry service called bulk transfer of partial portfolio, in order to assist with the completion of CSC’s acquisition of Register.com’s corporate services division

Whereas, NeuLevel submitted a request for a new registry service called bulk transfer of partial portfolio under the Registry Services Evaluation Policy.

Whereas, ICANN conducted its review of the request and determined that there are no significant competition, security or stability issues.

Resolved (06.85) the President and the General Counsel are authorized to enter into an amendment of the .BIZ Registry Agreement to implement the proposed bulk transfer of partial portfolio service.

Review of .TRAVEL Wildcard Proposal

Whereas, Tralliance Corporation submitted a request for a new registry service called search.travel under the Registry Services Evaluation Policy. The proposed service would insert a wildcard into the .TRAVEL zone.

Whereas, ICANN conducted its review of the request and determined that although there were no significant competition issues, the proposal might raise significant security and stability issues and referred the proposal to the Registry Services Technical Evaluation Panel for further evaluation.

Whereas, on 2 November 2006, the Registry Services Technical Evaluation Panel review team completed its report on the search.travel proposal. The report was posted for public comment.

Whereas, based on the report of the Registry Services Technical Evaluation Panel, input from the Security and Stability Advisory Committee, At-Large Advisory Committee and other public comments, ICANN has concluded that the proposal creates a reasonable risk of a meaningful adverse effect on security and stability.

Resolved, (06.85) that the Board agrees that the Tralliance Corporation search.travel wildcard proposal creates a reasonable risk of a meaningful adverse effect on security and stability and directs staff to inform Tralliance that the proposal is not approved.

Approval of Supplement to IETF-ICANN MOU

Whereas, ICANN and the IETF signed a Memorandum of Understanding in 2000 detailing ICANN's responsibilities in supporting IETF-related activities through its performance of the IANA function.

Whereas, Section 4.1 of the ICANN-IETF MOU provides "The IANA will work with the IETF to develop any missing criteria and procedures over time, which the IANA will adopt when so instructed by the IESG.

Whereas, ICANN staff and the IETF have developed a Supplemental Agreement that finalizes the criteria and procedures mutually agreed upon. The processes and scope of work outlined in the Supplemental Agreement document work that ICANN staff already performs, and adds specific timelines for satisfactory performance of that work, as well as reporting metrics designed to allow the public to assess ICANN's performance of the IANA function.

Resolved (06.86), the Supplemental Agreement to the ICANN-IETF MOU is approved.

Sydney Business License Approval

Whereas, it is important for ICANN as it globalizes its operations to be able to both employ staff from different countries and to put into place the ability to operate on a 24/7 timeframe for operational and logistical support. In 2003, ICANN opened an office in Brussels, Belgium, which has helped ICANN to become more efficient and responsive.

Whereas, ICANN already has a significant presence in Australia, and obtaining a foreign business registration in Sydney will enable ICANN to further increase its operational efficiency and responsiveness, reducing administrative inefficiencies created by the lack of a formal business presence there.

Resolved (06.87), the Board authorizes the President to establish a foreign business license and an office for ICANN in Sydney, Australia.

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