ccNSO Assistance Group: Compiled Recommendations

26 February 2003
Corrected: 11 March 2003

ccNSO Assistance Group
Compiled Recommendations
(for Discussion at Rio de Janeiro Meeting)
26 February 2003
Corrected: 11 March 2003

Contents

Introduction

I. Recommendations on Scope

II. Recommendations on Policy Development Process (ccPDP)

III. Recommendations on Membership

IV. Recommendations on Council

V. Recommendations on Structure

Introduction

The ccNSO Assistance Group (ccNSO-AG) was formed in September 2002 to assist the ICANN Evolution and Reform Committee by proposing recommendations on a structure and set of operating procedures for the Blueprint's Country Code Names Supporting Organization (ccNSO). Participants of the Assistance Group included ccTLD managers, participants of the GAC and other knowledgeable members of the community. All participants contributed to the Assistance Group in their individual capacities and contributed based on their personal views and experiences.

The Assistance Group conducted its work through conference calls, on-line discussions, and some members having face-to-face meetings. The ccNSO AG developed recommendations on 5 category areas identified out of the Blueprint. Those were: scope of the ccNSO as a global policy-development body; process of policy development in the ccNSO; ccNSO membership; structure of the ccNSO; ccNSO Council.

In approaching its work plan, the ccNSO AG sought to leverage the prior work of both the ccTLD registry community and other ERC Assistance Groups. The existence of prior work was of great assistance to the ccNSO AG efforts in working towards recommendations.

In its work, the Assistance Group sought to mould a high-level framework and recommendations to assist in the formation of a Supporting Organization that has the components and tools to focus authoritatively on the needs for effective global co-ordination at ICANN. The Assistance Group recognized the complex history of DNS management and is exploring frameworks to provide a sound methodology for the future to define openly responsibilities and other roles in functional areas of the DNS management to build confidence in the ccNSO as a major component of the Universal Domain Name System and the collective role of ccTLDs in the global management of the Internet at ICANN.

The ccNSO AG work plan was posted, and was as follows:

• Preliminary recommendations on Scope
  • Posted: 22 October 2002
  • Feedback: 28 October 2002 (Shanghai meeting)
  • ccNSO-AG Communiqué after consultation with the ccTLD Constituency
• Preliminary recommendations on Policy Development Process
  • Posted: 11 November 2002
    • Clarification: 29 November 2002
  • Feedback: 10 December 2002
• Preliminary recommendation on Membership
  • Posted: 10 December 2002
  • Feedback 24 December 2002
• Preliminary recommendations on Council
  • Posted: 24 December 2002
  • Feedback: 14 January 2003
• Preliminary recommendations on Structure
  • Posted: 28 January 2003
  • Feedback 7 February 2003

The ccNSO AG hereby sets forth its recommendations on the five categories of its work plan, those being the: Scope of the ccNSO, ccNSO's Policy Development Process (PDP), ccNSO Membership, ccNSO Council, and ccNSO Structure. Recommendations compiled in this document have been posted and commented on individually according to the timeline outlined above.

I. Recommendations on Scope

The purpose of the ccNSO is to engage and provide leadership in activities relevant to country-code top-level domains, specifically by:

1. Developing policy recommendations to the ICANN Board;
2. Nurturing consensus across the ccNSO’s community, including the name-related activities of ccTLDs; and
3. Coordinating with other ICANN SOs, Committees, or constituencies under ICANN.

The scope of the ccNSO’s authority and responsibilities must recognize the complex relation between ICANN and ccTLD managers/registries with regard to policy issues.

Policy areas

In order to identify the ccNSO’s policy role, the Assistance Group based its analyses on the following functional model of the DNS:

1. Data is registered/maintained to generate a zone-file,
2. A zone-file is in turn used in TLD name servers.

Therefore within a TLD two functions have to be performed (these are addressed in greater detail below):

1. Entering data into a database (DEF) and
2. Maintaining and ensuring upkeep of name-servers for the TLD (NSF).

These two core functions must be performed at the TLD registry level as well as at a higher level (IANA function and Root Servers) and at lower levels (such as, for example, .eu.com) of the DNS hierarchy. This mechanism, as RFC 1591 points out, is recursive.

"There are no requirements on sub domains of top-level domains beyond the requirements on higher-level domains themselves. That is, the requirements in this memo are applied recursively. In particular, all sub domains shall be allowed to operate their own domain name servers, providing in them whatever information the sub domain manager sees fit (as long as it is true and correct)."

The number of domain names registered has grown exponentially in the last five or six years. As a consequence, the impact of the DNS on society and society’s expectations about the DNS has also increased significantly. As a result, the first function (DEF) became more important in its own right (in hindsight: from auxiliary to name server function it evolved into the second core-function).

For the same reasons some latent, or secondary functions, have become important in their own right over time as well (such as, for example, WHOIS). However, these added functions derive from and are only secondary to the two core functions mentioned above and are not necessary (from a technical point of view) to run a TLD.

The Core Functions

1. Data entry function (DEF):

Looking at a more detailed level to the first function, entering and maintaining data in a database, it should be fully defined by a naming policy. This naming policy must specify the rules and conditions:

(a) Under which data will be collected and entered into a database or data changed (at the TLD level among others, data to reflect a transfer from registrant to registrant or changing registrar) in the database.

(b) For making certain data generally and publicly available (be it, for example, WHOIS or name-servers).

2. The Name-Server Function (NSF)

The name-server function involves essential interoperability and stability issues at the heart of the domain name system. The essential purpose of using domain names is reflected in this function of the domain name system. The importance of this function extends to name-servers at the TLD level, but also to the root-servers (system) and name-servers at lower levels. Data entry and maintenance FOR THE PURPOSE OF USING DOMAIN NAMES IN THE DNS is of no use unless this function is properly performed.

On its own merit and because of the interoperability and stability aspects, the proper functioning name-servers are of utmost importance to the individual, as well as the local and the global Internet community.

With regard to the name-server function therefore, policies need to be defined and established. By their nature these policies are more technical. Most parties involved, including the majority of ccTLD registries, have accepted the need for policies in this area by adhering to the relevant RFC’s, among others RFC 1591.

As the use of domain names has increased, necessary or beneficial approaches to ensuring the proper functioning of the DNS likewise have changed over time. It is clear that all relevant issues are not fully covered anymore by referring to RFC 1591, or even ICP-1. For example, as a result of the changes in technology RFC 1591 no longer captures all relevant aspects of ensuring the proper working of name-server function.

Roles of ccTLD Managers and ICANN with Regard to Policy, and Respective Responsibilities and Accountabilities.

It is in the interests of ICANN and ccTLD managers to ensure the stable and proper functioning of the domain name system. ICANN and the ccTLD registries each have a distinctive role to play in this regard, which are defined by the relevant policies.

The appropriate scope of the ccNSO cannot be established without reaching a common understanding of the allocation of authority between ICANN and ccTLD registries. Thus, the ccNSO AG discussed at length the ways in which to distinguish issues that are local in nature and should thus be resolved at the local level (i.e., by the ccTLD registry) or those that should be resolved at the global level (i.e., by the ICANN community).

The ccNSO AG distinguished three elements or roles as to which responsibility must be assigned on any given issue:

Policy role: meaning the ability and power to define a policy;

Executive role: meaning the ability and power to act upon and implement the policy; and

Accountability role: meaning the ability and power to hold the responsible entity accountable for exercising its power.

Firstly, responsibility presupposes a policy and this delineates a policy role. Depending on the issue that needs to be addressed those who are involved in defining and setting the policy need to be determined and defined. Secondly, this, defining the power to implement and act within the boundaries of a policy, presupposes an executive role. Finally, as a counter-balance to the executive role the accountability role needs to defined and determined.

Framework for Analyses:

Combining the two perspectives – that is, functions and responsibilities the following framework emerges:

The framework as presented above offers the possibility to:

1. Delineate and identify specific policy areas;
2. Define and determine roles with regard to these specific policy areas.

With regard to this delineation there is, of course, always a trade-off between precision/granularity and practicality.

The framework presents the recommendations of the ccNSO Assistance Group with respect an appropriate and workable allocation of authority among ccTLDs and other stakeholders. The Assistance Group recognizes that this framework may well require adjustment from time to time to reflect the changes in technology or in other areas that may affect the community’s ideas about the definition and allocation of roles in the DNS. Although it is explicitly not within the task and scope of the ccNSO AG to make recommendations with respect to the accountability role, it is clear a future accountability framework between ccTLD registries and ICANN will be needed and this probably will have an impact on the framework as presented.

II. Recommendations on Policy Development Process (ccPDP)

The ccNSO AG used the GNSO Policy Development Process (PDP) as a starting point for its recommendations on the PDP by the ccNSO. Adjustments were made to the GNSO PDP, as appropriate for the ccNSO.

The following process shall govern the ccNSO policy development process ("PDP") until such time as modifications are recommended to the ICANN Board of Directors ("Board") by the ccNSO and approved by the Board. Such recommendation shall be arrived at by the ccNSO by using the PDP.

1. Initiating an Issue Report

An Issue Report, which initiates a ccPDP, may be requested by any of the following:

(a) Council. The ccNSO Council ("Council") may call for the creation of an Issue Report by an affirmative vote of at least 7 of the members of the Council present at any meeting at which a motion to begin the policy development process.

(b) Board. The ICANN Board may call for the creation of an Issue Report by requesting the ccNSO Council to begin the policy development process. .

(c) Regional Organisation. One or more of the Regional Organisations representing ccTLDs in the ICANN recognized Regions may initiate an Issue Report by requesting the Council begin the policy development process.

(d) ICANN Supporting Organization or Advisory Committee. An ICANN Supporting Organization or an ICANN Advisory Committee may initiate an Issue Report by requesting the Council to begin the policy development process.

Any request for an Issues Report must be in writing and must set out the issue upon which an Issue Report is requested in sufficient detail to enable the Issue Report to be prepared. It shall be open to the Council to request further information or undertake further research or investigation for the purpose of determining whether or not the requested Issue Report should be created.

2. Creation of the Issue Report

Within 7 days of an affirmative vote as outlined in 1 a) above or the receipt of a request as outlined in 1 b), c) and d) above the Council shall appoint an Issue Manager. The Issue Manager may be a staff member of ICANN (in which case the costs of the Issue Manager shall be borne by ICANN) or such other person or persons selected by the Council (in which case the ccNSO shall be responsible for the costs of the Issue Manager).

Within fifteen (15) calendar days of appointment (or such other time as the Council shall, in consultation with the Issue Manager, deem to be appropriate), the Issue Manager will create an Issue Report. Each Issue Report shall contain at least the following:

a. The proposed issue raised for consideration;

b. The identity of the party submitting the issue;

c. How that party is affected by the issue

d. Support for the issue to initiate the PDP;

e. A recommendation from the Issue Manager as to whether the Council should move to initiate the PDP for this issue (the "Manager Recommendation"). Each Manager Recommendation shall include the opinion of the ICANN General Counsel regarding whether the issue is properly within the scope of the ICANN policy process as it pertains to ccTLDs. In coming to his opinion, the General Counsel shall examine whether the issue:

1) Is within the scope of ICANN's mission statement;

2) Is within the scope of the ccNSO pursuant to the ccNSO’s Scope Matrix;

In the event that the General Counsel reaches an opinion in the affirmative with respect to points 1 and 2 above then the General Counsel shall also consider whether the issue.

3) Implicates or affects an existing ICANN policy.

4) Is likely to have lasting value or applicability, albeit with the need for occasional updates; and will establish a guide or framework for future decision-making; or

f. In the event that the Manager Recommendation is in favor of initiating the PDP, a proposed time line for conducting each of the stages of PDP outlined herein;

Upon completion of the Issue Report, the Issue Manager shall distribute it to the full Council for a vote on whether to initiate the PDP.

3. Initiation of PDP

The Council shall decide whether to initiate the PDP as follows:

a. Within 21 days after receipt of an Issue Report from the Issue Manager, the Council shall meet to vote on whether to initiate the PDP. Such meeting may be convened in any manner deemed appropriate by the Council, including in person, via conference call or via electronic mail.

b. A vote of 10 or more Council members in favor of initiating the PDP will suffice to initiate the PDP PROVIDED THAT the Issue Manager recommendation states that the issue is properly within the scope of the ICANN mission statement and the ccNSO Scope Matrix. In the event that the Issue Manager states it is not properly within the scope of the ICANN mission statement or the ccNSO Scope matrix, then a vote of 12 or more Council members in favor of initiating the PDP will be required to initiate the PDP.

4. Commencement of the PDP

At the meeting of the Council where the PDP has been initiated pursuant to Section 3 above, the Council shall decide, by a majority vote of members present at the meeting, whether or not to appoint a task force to address the issue. If the Council votes:

a. In favor of convening a task force, it shall do so in accordance with Section 7 below.

b. Against convening a task force, then it will collect information on the policy issue in accordance with Section 8 below.

Council shall also, by a majority vote of members present at the meeting approve or amend and approve the time line for conducting the PDP set out in the Issue Report (the "PDP Time Line" Item 2-e-5 or 2-f).

5. Composition and Selection of Task Forces

a. Upon voting to appoint a task force, the Council shall invite each of the Regional Organizations to appoint two individuals to participate in the task force (the "Representatives"). Additionally, the Council may appoint up to three outside advisors (the "Advisors") to sit on the task force. The Council may increase the number of Representatives that may sit on a task force in its discretion in circumstances that it deems necessary or appropriate.

b. Any Regional Organization wishing to appoint Representatives to the task force must provide the names of the Representatives to the Issue Manager within ten (10) calendar days after such request so that they are included on the task force. Such Representatives need not be a member of the Council, but must be an individual who has an interest, and ideally knowledge and expertise, in the subject matter, coupled with the ability to devote a substantial amount of time to task force activities.

c. The Council may also pursue other actions that it deems appropriate to assist in the PDP, including appointing a particular individual or organization to gather information on the issue or scheduling meetings for deliberation or briefing. All such information shall be submitted to the Issue Manager in accordance with the PDP Time Line.

6. Public Notification of Initiation of the PDP and Comment Period

After initiation of the PDP, ICANN shall post a notification of such action to the ICANN Website and to the other ICANN Supporting Organisations and Advisory Committees. A comment period (in accordance with the PDP Time Line) shall be commenced for the issue. Comments will be accepted from ccTLD managers, other Supporting Organizations, Advisory Committees and from the public. The Issue Manager, or some other designated Council representative shall review the comments and incorporate them into a report (the "Comment Report") to be included in either the Preliminary Task Force Report or the Initial Report, as applicable.

7. Task Forces

a. Role of Task Force. If a task force is created, it role will be responsible for (i) gathering information documenting the positions of the Regions and other groups and parties; and (ii) otherwise obtaining relevant information that will enable the Task Force Report to be as complete and informative as possible to facilitate the Council’s meaningful and informed deliberation.

The task force shall not have any formal decision-making authority. Rather, the role of the task force shall be to gather information that will document the positions of various parties or groups as specifically and comprehensively as possible, thereby enabling the Council to have a meaningful and informed deliberation on the issue.

b. Task Force Charter or Terms of Reference. The Council, with the assistance of the Issue Manager, shall develop a charter or terms of reference for the task force (the "Charter") within the time designated in the PDP Time Line. Such Charter will include:

1. The issue to be addressed by the task force, as such issue was articulated for the vote before the Council that commenced the PDP;

2. The specific timeline that the task force must adhere to, as set forth below, unless the Council determines that there is a compelling reason to extend the timeline; and

3. Any specific instructions from the Council for the task force, including whether or not the task force should solicit the advice of outside advisors on the issue.

The task force shall prepare its report and otherwise conduct its activities in accordance with the Charter. Any request to deviate from the Charter must be formally presented to the Council and may only be undertaken by the task force upon a vote of a majority of the Council members present.

c. Appointment of Task Force Chair. The Issue Manager shall convene the first meeting of the task force within the time designated in the PDP Time Line. At the initial meeting, the task force members will, among other things, vote to appoint a task force chair. The chair shall be responsible for organizing the activities of the task force, including compiling the Task Force Report. The chair of a task force need not be a member of the Council.

d. Collection of Information.

1. Regional Organisation Statements. The Representatives will each be responsible for soliciting the position of their Regional Organisation, at a minimum, and may solicit other comments, as each Representative deems appropriate, regarding the issue under consideration. The position of the Regional Organization and any other comments gathered by the Representatives should be submitted in a formal statement to the task force chair (each, a "Regional Statement") within the time designated in the PDP Time Line. Every Region Statement shall include at least the following:

(i) If a Supermajority Vote (as defined by the Regional Organisation) was reached, a clear statement of the Regional Organization's position on the issue;

(ii) If a Supermajority Vote was not reached, a clear statement of all positions espoused by the members of the Regional Organisation;

(iii) A clear statement of how the Regional Organisation arrived at its position(s). Specifically, the statement should detail specific meetings, teleconferences, or other means of deliberating an issue, and a list of all members who participated or otherwise submitted their views;

(iv) An analysis of how the issue would affect the Region, including any financial impact on the Region; and

(v) An analysis of the period of time that would likely be necessary to implement the policy.

2. Outside Advisors. The task force may, in its discretion, solicit the opinions of outside advisors, experts, or other members of the public. Such opinions should be set forth in a report prepared by such outside advisors, and (i) clearly labeled as coming from outside advisors; (ii) accompanied by a detailed statement of the advisors' (a) qualifications and relevant experience; and (b) potential conflicts of interest. These reports should be submitted in a formal statement to the task force chair within the time designated in the PDP Time Line.

e. Task Force Report. The chair of the task force, working with the Issue Manager, shall compile the Regional Statements, and other information or reports, as applicable, into a single document ("Preliminary Task Force Report") and distribute the Preliminary Task Force Report to the full task force within the time designated in the PDP Time Line. The task force shall have a final task force meeting to consider deliberate the issues and try and reach a Supermajority Vote. After the final task force meeting, the chair of the task force and the Issue Manager shall create the final task force report (the "Task Force Report") and post it on the ICANN Website and to the other ICANN Supporting Organizations and Advisory Committees. Each Task Force Report must include:

1. A clear statement of any Supermajority Vote (being 66% of the task force) position of the task force on the issue;

2. If a Supermajority Vote was not reached, a clear statement of all positions espoused by task force members submitted within the timeline for submission of constituency reports. Each statement should clearly indicate (i) the reasons underlying the position and (ii) the Regional Organizations that held the position;

3. An analysis of how the issue would affect each Region, including any financial impact on the Region;

4. An analysis of the period of time that would likely be necessary to implement the policy; and

5. The advice of any outside advisors appointed to the task force by the Council, accompanied by a detailed statement of the advisors' (i) qualifications and relevant experience; and (ii) potential conflicts of interest.

8. Procedure if No Task Force is Formed

a. If the Council decides not to convene a task force, each Regional Organization shall, within the time designated in the PDP Time Line, appoint a representative to solicit the Region’s views on the issue. Each such representative shall be asked to submit a Regional Statement to the Issue Manager within the time designated in the PDP Time Line.

b. The Council may, in its discretion, take other steps to assist in the PDP, including, for example, appointing a particular individual or organization to gather information on the issue or scheduling meetings for deliberation or briefing. All such information shall be submitted to the Issue Manager within the time designated in the PDP Time Line.

c. The Issue Manager will take all Regional Statements, and other information and compile (and post on the Comment Site) an Initial Report within the time designated in the PDP Time Line. Thereafter, the PDP shall, in accordance with Section 9 below, create a Final Report.

9. Comments to the Task Force Report or Initial Report

a. A comment period (in accordance with the PDP Time Line) shall be opened for comments on the Task Force Report or Initial Report. Comments will be accepted from ccTLD managers, other Supporting Organizations, Advisory Committees and from the public. All comments shall include the author’s name, relevant experience, and interest in the issue.

b. At the end of the comment period, the Issue Manager shall review the comments received and may, in the Issue Manager's reasonable discretion, add appropriate comments to the Task Force Report or Initial Report (collectively, the "Final Report"). The Issue Manager shall not be obligated to include all comments made during the comment period, nor shall the Issue Manager be obligated to include all comments submitted by any one individual or organization.

c. The Issue Manager shall prepare the Final Report and submit it to the Council chair within the time designated in the PDP Time Line.

10. Council Deliberation

a. Upon receipt of a Final Report, whether as the result of a task force or otherwise, the Council chair will (i) distribute the Final Report to all Council members; and (ii) call for a Council meeting within the time designated in the PDP Time Line wherein the Council will work towards achieving a recommendation to present to members of the ccNSO ("Members") for approval and subsequent recommendation to the Board. Such meeting may be convened in any manner deemed appropriate by the Council, including in person, via conference call or via electronic mail. The Issue Manager shall be present at the meeting.

b. The Council may commence its deliberation on the issue prior to the formal meeting, including via in-person meetings, conference calls, e-mail discussions or any other means the Council may choose.

c. The Council may, if it so chooses, solicit the opinions of outside advisors at its final meeting. The opinions of these advisors, if relied upon by the Council, shall be (i) embodied in the Council's report to the Board, (ii) specifically identified as coming from an outside advisor; and (iii) accompanied by a detailed statement of the advisor's (a) qualifications and relevant experience; and (b) potential conflicts of interest.

11. Recommendation of the Council

A recommendation supported by 12 or more Council members will be deemed to reflect the view of the Council, and may be conveyed to the Members as the Council's Recommendation. Notwithstanding the foregoing, as outlined below, all viewpoints expressed by Council members during the PDP must be included in the Members’ Report.

12. Council Report to the Members

In the event that a Council Recommendation is adopted pursuant to Section 11 then the Issue Manager shall, within 7 days of the Council meeting, incorporate the Council’s Recommendation together with any other viewpoints of the Council members into a Members Report to be approved by the Council and then to be submitted to the Members (the "Members Report"). The Members Report must contain at least the following:

a. A clear statement of the Council’s recommendation;

b. The Final Report submitted to the Council; and

c. A copy of the minutes of the Council’s deliberation on the policy issue, including the all opinions expressed during such deliberation, accompanied by a description of who expressed such opinions.

13. Members Vote

Following the submission of the Members Report and within the time designated by the PDP Time Line, the members will be given an opportunity to vote on the Council Recommendation. The vote of members shall be electronic and members’ votes shall be lodged over such a period of time as designated in the PDP Time Line.

In the event that more than 66 per cent of the votes received at the end of the voting period shall be in favor of the Council Recommendation then the recommendation shall be conveyed to the Board in accordance with Section 14 below as the ccNSO Recommendation.

14. Board Report

The Issue Manager shall within 7 days of a ccNSO Recommendation being made in accordance with Section 13 incorporate the ccNSO Recommendation into a report to be approved by the Council and then to be submitted to the Board (the "Board Report"). The Board Report must contain at least the following:

i. A clear statement of the ccNSO recommendation;

ii. The Final Report and the Member Report submitted to the Council; and

iii. A copy of the minutes of the Council deliberation on the policy issue, including all opinions expressed during such deliberation, accompanied by a description of who expressed such opinions.

15. Board Vote

a. The Board will meet to discuss the ccNSO Recommendation as soon as feasible after receipt of the Board Report from the Issue Manager.

b. The Board shall adopt the ccNSO Recommendation unless by a vote of more than sixty-six (66%) percent the Board determines that such policy is not in the best interests of the ICANN community or ICANN.

1. In the event that the Board determines not to act in accordance with the ccNSO Recommendation, the Board shall (i) state its reasons for its determination not to act in accordance with the ccNSO Recommendation in a report to the Council (the "Board Statement"); and (ii) submit the Board Statement to the Council.

2. The Council shall review the Board Statement for discussion with the Board within the time designated in the PDP Time Line. The Board shall determine the method (e.g., by teleconference, e-mail, or otherwise) by which the Council and Board will discuss the Board Statement. The discussions shall be held in good faith and in a timely and efficient manner, to find a mutually acceptable solution.

3. At the conclusion of the Council and Board discussions, the Council shall meet to affirm or modify its Council Recommendation, and communicate that conclusion (the "Supplemental Recommendation") to the Members in a Supplemental Members Report, including an explanation for its current recommendation. Members shall be given an opportunity to vote on the Supplemental Recommendation under the same conditions outlined in Section 13. In the event that more than 66% of the votes cast during the voting period are in favor of the Supplemental Recommendation then that recommendation shall be conveyed to the Board as the ccNSO Supplemental Recommendation and the Board shall adopt the recommendation unless more than sixty-six (66%) percent of the Board determines that such policy is not in the interests of the ICANN community or ICANN.

4. In the event that the Board does not accept the ccNSO Supplemental Recommendation, it will state its reasons for doing so in its final decision (“Supplemental Board Statement”).

5. In circumstances where the Board determines not to accept a ccNSO Supplemental Recommendation, the Board shall not be entitled to set policy on the issue upon which the recommendation was made and the status quo shall be preserved until such time as the ccNSO shall make a recommendation on the issue that is deemed acceptable under this Policy Development Process.

16. Implementation of the Policy

Upon adoption by the Board a ccNSO Recommendation or ccNSO Supplemental Recommendation, the Board shall, as appropriate, direct or authorize ICANN staff to implement the policy.

17. Maintenance of Records

Throughout the PDP, from policy suggestion to a final decision by the Board, ICANN will maintain on the Website, a status web page detailing the progress of each PDP issue, which will describe:

a. The initial suggestion for a policy;

b. A list of all suggestions that do not result in the creation of an Issue Report;

c. The timeline to be followed for each policy;

d. All discussions among the Council regarding the policy;

e. All reports from task forces, the Issue Manager, the Council and the Board;

f. All public comments submitted; and

g. The ultimate disposition of any PDP undertaken.

III. Recommendations on Membership

1. Entitlement to membership: ccTLD registries shall be entitled to be members of the ccNSO.

2. Representation of members: ccTLD registries shall be represented by their ccTLD registry managers or such other persons as the ccTLD registry shall appoint in writing to represent them.

3. ccNSO Membership Fee: the ccNSO will establish a membership fee structure to assist in covering the costs of operating the ccNSO.

4. Policy: Policies that

a. have been developed through the ccNSO policy-development process; and

b. have been recommended as such by the ccNSO to the Board of ICANN; and

c. are adopted by the Board of ICANN as policies;

shall be binding upon ccTLD registries who are members of the ccNSO provided that such policies shall not conflict with the law applicable to the ccTLD Registry which shall, at all times, remain paramount.

Definitions

"ccTLD registry" means a Country Code Top Level Domain registry being a registry of domain names having two characters as defined by RFC 1591.

"ccTLD registry manager" means the entity or organization to which the management of an ISO 3166 country code Top Level Domain Internet Registry has been delegated by IANA, and is reflected in the IANA database.

IV. Recommendations on Council

1. Composition of the Council: The Council will comprise 18 voting members, including 3 put forward by the Nominating Committee. To ensure geographic diversity, ccNSO members in each of the 5 recognized ICANN regions (the Region or Regions) shall be entitled to elect 3 Council members.

If at some later date ICANN shall recognize other geographical regions, the number of members of the Council shall be adjusted so that each recognized region shall continue to have the right to elect an equal number of Council members.

2. Responsibilities of the Council: The role of the Council is to administer and co-ordinate the affairs of the ccNSO (including coordinating an annual meeting of members) and to manage the development of policy recommendations in accordance with the ccNSO PDP. The Council shall also undertake such other roles as the members of the ccNSO shall decide from time to time.

3. Observers: Observer status will be held by a liaison officer appointed by the GAC, ALAC, and each of the ccTLD regional organizations may also appoint a liaison officer.

4. Qualifications: To become a Council member an individual must be nominated by a member of the ccNSO to stand for election in that members Region; and while not necessarily being a member of the ccNSO, must support policies committed to by ccNSO members That nomination must be seconded by another ccNSO member from the same Region.

5. Election of Council Members: If at the close of nominations there are more candidates nominated in a particular Region than there are seats available for that Region, an election will be held. All ccNSO members from the relevant Region shall be entitled to vote in the election.

If unclear which region a ccNSO member belongs to, the member should self-select for the purposes of Council appointment.

6. Terms, Except for members of the Inaugural Council: Council members shall hold office for 3-year terms unless removed for not attending three consecutive meetings, or for inappropriate behavior as determined by the super majority of the Council.

In the case of the inaugural Council, 1 member elected from each Region shall be appointed for a 1 year term, 1 member elected from each Region shall be appointed for a 2 year term and the final member elected from each Region shall be appointed for a 3 year term.

7. Organization of Council: The Council shall elect a Chair and shall elect such Vice Chair as it shall deem appropriate.

8. Vacancies, Interim vacancies shall be filled by an election in the Region of the vacating Council member or appropriate measures approved by the Council after consultation with the relevant Region. Candidates elected by this process shall serve only the remaining term of the vacating Council member.

9. Meetings: The Council shall meet regularly on a schedule determined by its members, but not less than four times per year. Meetings may be held in person, or via appropriate technology, at the discretion of the Council. To the extent practicable, Council meetings should coincide with meetings of the Board of ICANN, and of the other Support Organizations.

V. Recommendations on Structure

Issues addressed under structure reflect how to transition into the new structure, and items that may not have been addressed but the ccNSO Assistance Group believes important to address with its recommendations.

With regard to transition, the ccNSO Assistance Group recommends that there be a Launching Group, which has the responsibility to formalize the arrangements for the ccNSO, liaise with the ccTLD community and ICANN regarding this, and to organize the election for the first ccNSO Council. The Launching Group would also accept applications from ccTLDs for membership of the ccNSO, with members of the ccNSO able to vote for the Council.

Membership during this period would comprise of a ccTLD registry providing a letter recognizing the role of the ccNSO within the ICANN structure, its policy development process and agreeing to adhere to the rules for membership and fees.

The Launching Group should be drawn from the ccNSO AG and the ccTLD Community, and comprise fifteen (15) ccTLD registry managers. The general logistics of the elections for the Council should be left to the Launching Group to formulate. However, the ccNSO Assistance Group recommends that the whole Council should be elected at once following a nomination period, with three members per region elected for a one, two and three year term respectively. The elections should be organized within 120 days of the adoption of the bylaws.

Members of the Launching Group shall be entitled to stand for election to the Council.

The Launching Group would have no power other than formalization of the start-up of the ccNSO pursuant to the ICANN bylaws and to organize and run the election of the Council. As soon as the first Council is elected, the Launching Group’s work will end.

The ccNSO Council, once elected, will need to address issues such as: working procedures for the Council; options for a secretariat; working procedures to address issues that do not go through the Policy Development Process; and the possibility of exchange of observers between the GNSO and the ccNSO Councils.

Page updated 23-Apr-2003
©2003 The Internet Corporation for Assigned Names and Numbers. All rights reserved.