ccNSO Assistance Group
(for Discussion at Rio de Janeiro Meeting)
26 February 2003
Corrected: 11 March 2003
I. Recommendations on Scope
II. Recommendations on Policy Development Process (ccPDP)
III. Recommendations on Membership
IV. Recommendations on Council
V. Recommendations on Structure
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
The ccNSO AG work plan was posted, and was as follows:
- Preliminary recommendations on Scope
- Preliminary recommendations on Policy Development Process
- Preliminary recommendation on Membership
- Preliminary recommendations on Council
- Preliminary recommendations on Structure
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
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.
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.
of ccTLD Managers and ICANN with Regard to Policy, and Respective Responsibilities
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:
(ns-specs, recovery, resilience)
TLD - Name server
Best Practice – Recommendations (recovery, resilience)
User Name server
|IANA (transfer, changes, name server, contact details)
Third level domains
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.
(ns-specs, recovery, resilience)
TLD - Name server
Best Practice – Recommendations (recovery, resilience)
|ICANN through ccNSO Policy development Process
|IANA/LIC, including Local government
|ccNSO process to be organized
User Name server
|IANA (transfer, changes, name server, contact details)
|ICANN Board through ccNSO Policy Development Process
ccTLD Managers, DoC, national authorities (in some cases)
|LIC (including the government)/
(according to local structure)
|LIC (including national authorities in some cases)
Third level domains
|Registrant, Users of lower level domain names
II. Recommendations on Policy Development Process
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
(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
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
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
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;
(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
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
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
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.
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;
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 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
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
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
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
d. All discussions among the Council regarding
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
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
4. Policy: Policies that
a. have been developed through the ccNSO policy-development
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.
"ccTLD registry" means a Country Code Top Level Domain registry
being a registry of domain names having two characters as defined by RFC
"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
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
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
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
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.
concerning the layout, construction and functionality of this site
should be sent to email@example.com.
©2003 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.