Skip to main content
Resources

Request For Proposals and Terms of Reference for the Independent Review of the DNS Root Server System Advisory Committee

A. Request For Proposals ("RFP"):

1. Introduction

1.1. This RFP should be read in conjunction with the Terms of Reference (ToR) for Independent Review of the DNS Root Server System Advisory Committee ("RSSAC") (see below). Read together, these two documents provide the materials necessary to respond to this RFP to perform the independent review of the RSSAC ("Review").

1.2. ICANN now seeks to appoint an independent consultant to undertake the Review. The information outlined below illustrates the scope of the work and the criteria for selection.

2. Objectives

2.1. The review is designed to determine: (i) whether the DNS Root Server System Advisory Committee 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. The Review, which is mandated by the Bylaws concerning periodic review of elements of the ICANN structure, will be undertaken pursuant to guidance provided by the Board, including the Board's approval of the Terms of Reference.

2.2. The Review is due to begin as soon as possible. A full project timeline will be developed, but it is anticipated that a key milestone will include presentation of a draft Review and then a final Review. The results of the Review will be posted for public review and comment, and considered by the Board.

2.3. The Review of the DNS Root Server System Advisory Committee is expected to include personal interviews, surveys and research. The successful candidate is welcome to suggest additional forms of soliciting the information.

2.4. The Review team is expected to have knowledge of the DNS Root Server System, as well as some familiarity with the ICANN process.

3. Tender Scope and Conditions

3.1. Given the Terms of Reference found below and responding specifically to the requests for further information, applicants should provide:

3.1.1. Statement of Suitability. The Statement of Suitability must include a detailed outline of the applicant's ability to perform the work showing past projects, consultancies, research, publications and other relevant information, including references.

3.1.2. Work Approach. The Work Approach needs to detail the way in which the applicant would respond to the Terms of Reference; provide details about specific skills with interview techniques, data gathering and report writing. The successful candidate will be required to communicate through email, conference calls, and video conference over IP.

3.1.3. Description of Final Product. Describe, prospectively, the form and organization of the final report. The report should be suitable for electronic transmission, i.e., limited file size and widely used format.

3.1.4. Team Curriculum Vitae. The response must include Curriculum Vitae for the whole team showing each individual's suitability for the proposed work.

3.1.5. ICANN Contract Compliance: Applicants should warrant that they are willing to operate under a non-disclosure agreement.

3.1.6. The proposal should include a work schedule including key milestone dates and a statement of proposed fees.

3.2 Deadline / requirements: Interested applicants should submit proposals by email to rfprssacreview@icann.org to the attention of Denise Michel, Vice President, Policy Development, by 15 August 2008 (a confirmation email will be sent for each proposal received).


B. Terms of Reference

ICANN's Bylaws require that Supporting Organisations, Councils and Advisory Committees be independently reviewed. These Terms of Reference will form the basis for a review of the DNS Root Server System Advisory Committee (RSSAC). The purpose of the Review is to help determine the best way forward, but such analysis depends in the first instance upon a solid assessment of how the RSSAC has performed to date.

The results of the Review shall be posted for public review and comment, and shall be considered by the Board not later than its second scheduled meeting after being posted for 30 days. As provided in the Bylaws, consideration by the Board includes the ability to revise the structure or operation of the RSSAC by a two-thirds vote of all Members.

A. Scope of Review

In accordance with Article IV, Section 4, Paragraph 1 of the ICANN Bylaws, the review of the RSSAC is designed to determine:

  • Whether the organization has a continuing purpose in the ICANN structure; and
  • If so, whether any change in structure or operations is desirable to improve its effectiveness.

Both of these questions should be answered as comprehensively as possible, taking into account the rationale for the RSSAC and its functioning so far. Key questions that the Review should consider are indicated below. This list is intended to be illustrative, rather than definitive or exhaustive, particularly as the initial results of the Review may suggest related questions that should also be answered. It will be important to consider the questions from different perspectives, including past and current members of the RSSAC, the ICANN Board, other Supporting Organizations (SOs) and Advisory Committees (ACs) and perhaps others within (and outside of) the ICANN community.

It is also important to note that this is a review of the ICANN Root Server System Advisory Committee, not a review of the operation of the Root Servers.

B. Rationale for the RSSAC

In accordance of Article XI, Section 2 of the Bylaws , the role of the Root Server System Advisory Committee ("RSSAC") is to advise the Board about the operation of the root name servers of the domain name system. The RSSAC considers and provides advice on the operational requirements of root name servers, including host hardware capacities, operating systems and name server software versions, network connectivity and physical environment. The RSSAC also examines and advises on the security aspects of the root name server system, as well as reviews the number, location, and distribution of root name servers considering the total system performance, robustness, and reliability. (See http://icann.org/committees/dns-root/ for RSSAC information)

Membership in the RSSAC consists of (i) each operator of an authoritative root name server (as listed at ftp://ftp.internic.net/domain/named.root), and (ii) such other persons as are appointed by the ICANN Board. The Chair is elected by the members of the DNS Root Server System Advisory Committee pursuant to procedures adopted by the members. The RSSAC appoints one non-voting liaison to the ICANN Board of Directors.

C. Questions to Address

PART I. Does the RSSAC have a continuing purpose in the ICANN structure?

  1. What purpose does the RSSAC serve?
  2. Has the RSSAC been effective in providing advice to the ICANN Board on matters as outlined in the Bylaws?
  3. How does RSSAC interact with other ICANN SOs and ACs? Are there regular communications between the RSSAC and other SOs and ACs?
  4. How effective has the RSSAC been in providing input and advice to other SOs and ACs?
  5. Overall, how effectively has RSSAC performed its role?
  6. Does the rationale for the RSSAC in the Bylaws need to be revised?
  7. What should be the purpose of the RSSAC going forward?

PART II. Is there any change in structure or operations that could improve the RSSAC's effectiveness?

Structure and composition

  1. What is the optimal size of RSSAC to maximize its effectiveness? Has the Board made effective use of its ability to appoint members of the ICANN community other than Root Server Operators to RSSAC?
  2. What should be the role of the Chair of the RSSAC, and how should that person be selected?
  3. Have members of the RSSAC had the skills needed to conduct their work effectively?
  4. Does a non-voting liaison seat on the Board provide sufficient input and representation for the Root Server System community? Is there any change needed?

Internal Operations and Procedures

  1. How does the RSSAC determine what advice to provide with respect to particular ICANN issues? What procedures govern how decisions regarding RSSAC input for the Board and other ICANN entities are made? Are any changes needed to these procedures to improve the timeliness and quality of advice that is provided?
  2. To what extent are the RSSAC's decisions and actions consistent with its procedures?
  3. Are sufficient safeguards in place to identify and address potential or actual conflicts of interest?
  4. Does the RSSAC operate in an accountable and transparent manner? Are any changes to RSSAC procedures necessary to enhance accountability and transparency?
  5. Are the RSSAC's procedures sufficient to guide all aspects of its work?

Resources and support

  1. Has the RSSAC had the resources necessary to accomplish its tasks?
  2. What kind of support has ICANN provided to the RSSAC? What is the appropriate level of financial, institutional and staff support that should be provided to RSSAC?

Overall

  1. What other general or specific measures could enhance the effectiveness of RSSAC?
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."