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
Recommendations on the Country-Code Names Supporting
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.
3. ccNSO Council
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.
4. Staff Support and Funding
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
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,
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.
6. Policy Development Process
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
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
"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.
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.
1. Initiating an Issue Report
An Issue Report, which initiates a ccPDP, may be requested by any of
(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
c. How that party is affected by the
d. Support for the issue to initiate
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
2) Is within the scope of the ccNSO pursuant
to the ccNSO's
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
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.
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 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.
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 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
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.
7. Task Forces
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
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.
d. Collection of Information.
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;
(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
1. A clear statement of any Supermajority
Vote (being 66% of the task force) position of the task force on the
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
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.
10. Council Deliberation
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
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;
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
13. Members Vote
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.
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
15. Board Vote
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
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").
5. In circumstances where
(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
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.
17. Maintenance of Records
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
f. All public comments submitted; and
g. The ultimate disposition of any PDP undertaken.
concerning the layout, construction and functionality of this site
should be sent to firstname.lastname@example.org.
©2003 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.