Fifth Supplemental Implementation
Report of the Committee on ICANN Evolution and Reform
22 April 2003
Committee
on ICANN Evolution and Reform
Fifth Supplemental Implementation Report
22 April 2003
One of the outstanding areas of work for the ERC involves the recommendations to the Board on the formation of the Supporting Organization for country-code names. As was reflected in the President's Report: ICANN The Case for Reform, the original incorporation of ccTLD registries under the former Domain Name Supporting Organization (DNSO) needed to be rethought. In its Blueprint, the ERC acknowledged the intense discussion and work of the ccTLD community, in its diversity of positions and opinions concerned with what are the responsibilities of ccTLD administrators that fall strictly under the purview of national or otherwise local jurisdiction, and those that lead to the need for global harmonization and coordination. The country-code Names Supporting Organization (ccNSO) is proposed as the forum where this distinction will be further understood and developed, and from which the global aspects will continuously emerge.
The ccNSO is a supporting organization for the purpose of engaging in activities relevant to country-code top-level domains, specifically (1) developing policy recommendations to the ICANN Board; and (2) nurturing consensus across the constituencies, including the name-related activities of ccTLDs.
In September 2002, the ERC established the ccNSO Assistance Group for the purpose of providing recommendations on a structure and set of operating procedures for the Blueprint's ccNSO. The ccNSO Assistance Group over the course of several months, and through weekly conference calls, e-mail, and physical meetings at ICANN meetings, developed recommendations on five 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; and the ccNSO Council. Participants in 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.
Following several months of work, which included posting for comment the individual categories identified out of the Blueprint, the ccNSO-AG posted its compiled recommendations. A topic paper providing background accompanied the recommendations.
Based on the ccNSO AG recommendations, the ERC has prepared the attached recommendations for the ccNSO and for the ccNSO Policy Development Process. The ERC would like to note its strong appreciation for the hard work by the ccNSO-AG in preparing the recommendations.
The ERC has sought in these recommendations to reflect the well-thought-out work of the ccNSO-AG, the input received during the public consultations with the ICANN community, including those at the last ICANN meeting in Rio de Janeiro. The ERC welcomes public comments and feedback on the recommendations. Subsequent to receiving comments, the ERC will prepare the draft bylaws for the ccNSO section of the ICANN bylaws, and post those for public omment and subsequent finalization.
Committee on ICANN Evolution and Reform
22 April 2003
Committee on ICANN Evolution
and Reform
Recommendations on the Country-Code Names Supporting
Organization (ccNSO)
22 April 2003
There shall be a policy-development body known as the Country-Code Names Supporting Organization (ccNSO), which shall be responsible for developing and recommending to the ICANN Board substantive policies relating to country-code top-level domains.
This document describes the structure and operation of the ccNSO that shall be reviewed in the ccNSO's second year of operation, based on accumulated experience, consistent with ICANN's Bylaws.
The ccNSO shall consist of (i) ccTLD managers that have agreed in writing to be members of the ccNSO [as described in Section 5], and (ii) a ccNSO Council responsible for managing the policy development process of the ccNSO.
a. Composition of the Council: The Council shall 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.)
b. 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.
c. Observers: Observer status shall be held by a liaison officer appointed by the GAC, ALAC; and each of the ccTLD regional organizations may also appoint a liaison officer. The ccNSO Council may also address the logistics for the exchange observers with the councils of other ICANN Supporting Organizations.
d. Nominations and Qualifications: Any ccNSO member may nominate an individual to serve as a ccNSO Council member representing the ccNSO member's Region. Nominations must be seconded by another ccNSO member from the same Region. ccNSO Council members must support the policies committed to by ccNSO members.
e. 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 shall 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.)
f. Terms, Except for members of the Inaugural Council: Council members shall hold office for 3-year terms. 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.
Council members may be removed for not attending three consecutive meetings, or for inappropriate behavior, both as determined by the super majority of the Council.
g. Organization of Council: The Council shall elect a Chair and shall elect such Vice Chair(s) as it shall deem appropriate.
h. Vacancies. 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.
i. 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.
a. A member of the ICANN staff may be assigned upon request of the ccNSO Council to support the ccNSO, whose work on substantive matters shall be assigned by the Chair of the ccNSO Council, and shall be designated as the ccNSO Staff Manager (Staff Manager).
b. ICANN may provide administrative and operational support necessary for the ccNSO to carry out its responsibilities. Such support shall not include an obligation for ICANN to fund travel expenses incurred by ccNSO participants for travel to any meeting of the ccNSO or for any other purpose.
a. Entitlement to membership: Managers shall be entitled to be members of the ccNSO.
b. Representation of members: Managers shall be represented by the person, organization or entity listed as the Administrative Contact in the IANA database or such other person, organization or entity as the Manager shall appoint in writing to represent them.
c. ccNSO Membership Fee: the ccNSO shall establish a membership fee structure to assist in covering the costs of operating the ccNSO.
d. 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) managers who are members of the ccNSO provided that such policies shall not conflict with the law applicable to the (ccTLD) manager which shall, at all times, remain paramount.
e. A ccNSO member may apply to the ccNSO Council to be exempt from a policy that is binding under paragraph d of this section on the grounds that the implementation of the policy would mean that the policy would require the member to breach custom, religion or public policy of the member's country. In making such an application the member must also satisfy the ccNSO Council, that the granting of such an exemption shall not impair DNS operations.
The exemption shall be granted provided that a minimum of 12 members of the ccNSO Council shall vote in favor of the application.
Initially, the policy-development procedures to be followed by the ccNSO shall be as stated in Annex A.
With regard to transition, the ERC supports the ccNSO AG recommendation 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) manager 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 shall comprise the 9 ccTLD manager members from the ccNSO AG together with a further 6 ccTLD managers for a total of 15 ccTLD managers. The general logistics of the elections for the Council should be left to the Launching Group to formulate. However, the ERC 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.
Elections shall commence as soon as a minimum of four managers each from each of the five ICANN Regions has applied/subscribed for ccNSO membership.
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 shall 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; the logistics for the exchange of observers between the GNSO and the ccNSO Councils, and ccNSO representatives to the ICANN Nominating Committee.
"manager or managers" means the person, organization or entity responsible for managing an ISO 3166 country-code top-level domain and referred to in the IANA database as the "Sponsoring Organization" for that country-code top-level domain.
"ccTLD regional organization" means an organization in which ccTLD managers co-operate on a regional basis, such as CENTR, APTLD, LACTLD, AFTLD, etc.
Annex A
Recommendations on Policy-Development Process (ccPDP)
of the ccNSO
The following process shall govern the ccNSO policy-development process ("PDP"). Modifications shall be 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. The structure and operation of the ccNSO, including this PDP, shall be included in the periodic review of ICANN's structure and operations conducted in the ccNSO's second year of operation, consistent with ICANN's Bylaws.
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 Organization. One or more of the Regional Organizations 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 Section 1(a) above or the receipt of a request as outlined in Sections 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 shall 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 shall establish a guide or framework for future decision-making.
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.
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 shall 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 shall be required to initiate 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 shall 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.
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") and, following formal request for GAC participation in the Task Force, accept up to two representatives from the Governmental Advisory Committee 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 Organizations and Advisory Committees. A comment period (in accordance with the PDP Time Line) shall be commenced for the issue. Comments shall 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.
a. Role of Task Force. If a task force is created, it role shall be responsible for (i) gathering information documenting the positions of the Regions and other groups and parties; and (ii) otherwise obtaining relevant information that shall 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 shall 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 shall 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 shall, 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.
1. Regional Organization Statements. The Representatives shall each be responsible for soliciting the position of their Regional Organization, 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 Organization) 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 Organization;
(iii) A clear statement of how the Regional Organization 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 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 Council shall formally request the Chair of the GAC to offer opinion or advice.
d. The Issue Manager shall 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 shall 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.
a. Upon receipt of a Final Report, whether as the result of a task force or otherwise, the Council chair shall (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 shall work towards achieving a recommendation to present 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.
d. The Council shall formally request the Chair of the GAC to offer opinion or advice.
11. Recommendation of the Council
A recommendation supported by 14 or more of the Council members shall 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.
Following the submission of the Members Report and within the time designated by the PDP Time Line, the members shall 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.
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.
a. The Board shall 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 shall 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 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 shall state its reasons for doing so in its final decision ("Supplemental Board Statement").
(i) the Board determines not to accept a ccNSO Supplemental Recommendation, and
(ii) the opinion of the General Counsel pursuant to Section 2 e was that the issue was within the scope of the ccNSO pursuant to the ccNSO's Scope Matrix,
then the Board shall not be entitled to set policy on the issue upon which the recommendation was and the status quo shall be preserved until such time as the ccNSO shall, under this Policy Development Process, make a recommendation on the issue that is deemed acceptable.
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.
Throughout the PDP, from policy suggestion to a final decision by the Board, ICANN shall maintain on the Website, a status web page detailing the progress of each PDP issue, which shall 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.
Questions concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.
Page Updated
20-Aug-2003
©2003 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.