Proposed
Revisions to Bylaws to Implement ERC's ccNSO Recommendations
13 June 2003
Update:
The Committee on ICANN Evolution and Reform (ERC) has posted "ccNSO
Formation: Proposed Revisions to the Bylaws", which is an
analysis of these proposed revisions to the bylaws and of recent public
commentary on its ccNSO recommendations. Click
here to view the ERC analysis. |
To the ICANN Community:
The following proposed revisions to the ICANN bylaws have been
prepared to implement the recommendations of the Evolution and Reform
Committee (ERC) to the Board on establishment of a Country-Code
Names Supporting Organization (ccNSO) as set forth in its Fifth
Supplemental Implementation Report (22 April 2003) and its Response
to Comments Received on ERC's ccNSO Recommendations (29 May
2003).
The ERC is currently working on a report explaining various aspects
of these bylaws, as well as giving details abou the proposed Board
resolutions regarding the ccNSO Launching Group that it recommends.
That report is not yet complete, but will be posted in a few days.
So that the community has the greatest possible time to review these
proposed bylaws in advance of the ICANN Montreal meeting, the ERC
has asked me to post them without waiting for completion of the
ERC's report.
When the ERC's report is posted, an online comment mechanism will
be established. In addition, a portion of the 25 June 2003 Public
Forum in Montréal will be devoted to discussion of the ERC's
ccNSO recommendations, as well as these proposed revisions to the
bylaws.
In the draft that follows, all of the text of Article
IX, Annex B, and Annex
C is new. Otherwise, added text is
underlined and in magenta and deleted
text is stricken out and in red.
Respectfully submitted,
Louis Touton
ICANN General Counsel
|
ARTICLE IV: ACCOUNTABILITY AND REVIEW, Section
4. PERIODIC REVIEW OF ICANN STRUCTURE AND OPERATIONS
1. The Board shall cause a periodic
review, if feasible no less frequently than every three years, of the
performance and operation of each Supporting Organization, each
Supporting Organization Council, each
Advisory Committee (other than the Governmental Advisory Committee),
and the Nominating Committee by an entity or entities independent of
the organization under review. The goal of the review, to be undertaken
pursuant to such criteria and standards as the Board shall direct, shall
be to determine (i) whether that organization has a continuing purpose
in the ICANN structure, and (ii) if so, whether any change in structure
or operations is desirable to improve its effectiveness. The results
of such reviews shall be posted on the Website for public review and
comment, and shall be considered by the Board no later than the second
scheduled meeting of the Board after such results have been posted for
30 days. The consideration by the Board includes the ability to revise
the structure or operation of the parts of ICANN being reviewed by a
two-thirds vote of all members of the Board.
2. The first of
such reviews, to be initiated within one year
following the adoption of these Bylaws no
later than 15 December 2003 and to be completed in time for Board consideration
at ICANN's annual meeting in 2004, shall be of the GNSO Council
and the ICANN Root Server System Advisory Committee. The
second of such reviews, to be initiated no later than 15 November 2004
and to be completed in time for Board consideration at ICANN's annual
meeting in 2005, shall be of the ccNSO, the ccNSO Council, and such
other organizations as the Board may designate.
3. The Governmental Advisory Committee
shall provide its own review mechanisms.
ARTICLE VI: BOARD OF DIRECTORS, Section 4. ADDITIONAL
QUALIFICATIONS
[Paragraph 1 is unchanged.]
2. No person who serves in any capacity (including
as a liaison) on any Supporting Organization Council shall simultaneously
serve as a Director or liaison to the Board. If such a person accepts
a nomination to be considered for selection by the Supporting Organization
Council to be a Director, the person shall not, following such nomination,
participate in any discussion of, or vote by, the Supporting Organization
Council relating to the selection of Directors by the Council, until
the Council has selected the full complement of Directors it is responsible
for selecting. In the event that a person serving in any capacity on
a Supporting Organization Council accepts a nomination to be considered
for selection as a Director, the constituency group or other group
or entity that selected the person may select a replacement
for purposes of the Council's selection process.
[Paragraph 3 is unchanged.]
ARTICLE IX: COUNTRY-CODE NAMES SUPPORTING ORGANIZATION
[Note: This entire Article IX is new. The addition
of this text is not shown by redlining.]
Section 1. DESCRIPTION
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 Board substantive policies relating to country-code
top-level domains.
Section 2. ORGANIZATION
The ccNSO shall consist of (i) ccTLD managers that have agreed in writing
to be members of the ccNSO (see Section 4(2) of this Article) and (ii)
a ccNSO Council responsible for managing the policy-development process
of the ccNSO.
Section 3. ccNSO COUNCIL
1. The ccNSO Council shall consist of (a) three
ccNSO Council members selected by the ccNSO members within each of ICANN's
Geographic Regions in the manner described in Section
4(7) through (9) of this Article; (b) three ccNSO Council members
selected by the ICANN Nominating Committee; (c) liaisons as described
in paragraph 2 of this Section; and (iv) observers
as described in paragraph 3 of this Section.
2. There shall also be one liaison to the ccNSO
Council from each of the following organizations, to the extent they
choose to appoint such a liaison: (a) the Governmental Advisory Committee;
(b) the At-Large Advisory Committee; and (c) each of the Regional Organizations
described in Section 5 of this Article. These liaisons
shall not be members of or entitled to vote on the ccNSO Council, but
otherwise shall be entitled to participate on equal footing with members
of the ccNSO Council. Appointments of liaisons shall be made by providing
written notice to the ICANN Secretary, with a notification copy to the
ccNSO Chair, and shall be for the term designated by the appointing
organization as stated in the written notice. The appointing organization
may recall from office or replace its liaison at any time by providing
written notice of the recall or replacement to the ICANN Secretary,
with a notification copy to the ccNSO Chair.
3. The ccNSO Council may agree with the Council
of any other ICANN Supporting Organization to exchange observers. Such
observers shall not be members of or entitled to vote on the ccNSO Council,
but otherwise shall be entitled to participate on equal footing with
members of the ccNSO Council. The appointing Council may designate its
observer (or revoke or change the designation of its observer) on the
ccNSO Council at any time by providing written notice to the ICANN Secretary,
with a notification copy to the ccNSO Chair.
4. Subject to the provisions of the Transition
Article of these Bylaws: (a) the regular term of each ccNSO Council
member shall begin at the conclusion of an ICANN annual meeting and
shall end at the conclusion of the third ICANN annual meeting thereafter;
(b) the regular terms of the three ccNSO Council members selected by
the ccNSO members within each ICANN Geographic Region shall be staggered
so that one member's term begins in a year divisible by three, a second
member's term begins in the first year following a year divisible by
three, and the third member's term begins in the second year following
a year divisible by three; and (c) the regular terms of the three ccNSO
Council members selected by the Nominating Committee shall be staggered
in the same manner. Each ccNSO Council member shall hold office during
his or her regular term and until a successor has been selected and
qualified or until that member resigns or is removed in accordance with
these Bylaws.
5. A ccNSO Council member may resign at any time
by giving written notice to the ICANN Secretary, with a notification
copy to the ccNSO Chair.
6. ccNSO Council members may be removed for not
attending three consecutive meetings of the ccNSO Council or for inappropriate
behavior, both as determined by at least a 66% vote of all of the members
of the ccNSO Council.
7. A vacancy on the ccNSO Council shall be deemed
to exist in the case of the death, resignation, or removal of any ccNSO
Council member. Vacancies in the positions of the three members selected
by the Nominating Committee shall be filled for the unexpired term involved
by the Nominating Committee giving the ICANN Secretary written notice
of its selection, with a notification copy to the ccNSO Chair. Vacancies
in the positions of the ccNSO Council members selected by ccNSO members
shall be filled by the procedure described in Section
4(7) through (9) of this Article.
8. The role of the ccNSO Council is to administer
and coordinate the affairs of the ccNSO (including coordinating an annual
meeting of ccNSO members as described in Section 4(6)
of this Article) and to manage the development of policy recommendations
in accordance with Section 6 of this Article. The ccNSO Council shall
also undertake such other roles as the members of the ccNSO shall decide
from time to time.
9. The ccNSO Council shall make selections to
fill Seats 11 and 12 on the Board by written ballot or by action at
a meeting; any such selection must have affirmative votes of a majority
of all the members of the ccNSO Council then in office. Notification
of the ccNSO Council's selections shall be given by the ccNSO Chair
in writing to the ICANN Secretary, consistent with Article VI, Sections
8(4) and 12(1).
10. The ccNSO Council shall select the ccNSO
Chair and such Vice Chair(s) as it deems appropriate. Selections of
the ccNSO Chair and Vice Chair(s) shall be by written ballot or by action
at a meeting; any such selection must have affirmative votes of a majority
of all the members of the ccNSO Council then in office. The term of
office of the ccNSO Chair and any Vice Chair(s) shall be as specified
by the ccNSO Council at or before the time the selection is made. The
ccNSO Chair or any Vice Chair(s) may be recalled from office by the
same procedure as used for selection.
11. The ccNSO Council shall adopt such rules
for ccNSO membership and operating procedures as it deems necessary,
provided they are consistent with these Bylaws. Rules for ccNSO membership
and operating procedures adopted by the ccNSO Council shall be published
on the Website.
12. Except as provided by paragraphs 9
and 10 of this Section, the ccNSO Council shall
act at meetings. The ccNSO Council shall meet regularly on a schedule
it determines, but not fewer than four times each calendar year. At
the discretion of the ccNSO Council, meetings may be held in person
or by other means, provided that all ccNSO Council members are permitted
to participate by at least one means described in paragraph
14 of this Section. Except where determined by a majority vote of
the members of the ccNSO Council present that a closed session is appropriate,
physical meetings shall be open to attendance by all interested persons.
To the extent practicable, ccNSO Council meetings should coincide with
meetings of the Board, or of one or more of ICANN's other Supporting
Organizations.
13. Notice of time and place (and information
about means of participation other than personal attendance) of all
meetings of the ccNSO Council shall be provided to each ccNSO Council
member, liaison, and observer by e-mail, telephone, facsimile, or a
paper notice delivered personally or by postal mail. In case the notice
is sent by postal mail, it shall be sent at least 21 days before the
time of the holding of the meeting. In case the notice is delivered
personally or by telephone, facsimile, or e-mail it shall be provided
at least seven days before the time of the holding of the meeting. At
least seven days in advance of each ccNSO Council meeting (or if not
practicable, as far in advance as is practicable), a notice of such
meeting and, to the extent known, an agenda for the meeting shall be
posted.
14. Members of the ccNSO Council may participate
in a meeting of the ccNSO Council through personal attendance or use
of electronic communication (such as telephone or video conference),
provided that (a) ccNSO Council members participating in the meeting
can speak to and hear one another, (b) all ccNSO Council members participating
in the meeting are provided the means of fully participating in all
matters before the ccNSO Council, and (c) there is a reasonable means
of verifying the identity of ccNSO Council members participating in
the meeting and their votes. A majority of the ccNSO Council members
(i.e. those entitled to vote) then in office shall constitute a quorum
for the transaction of business, and actions by a majority vote of the
ccNSO Council members present at any meeting at which there is a quorum
shall be actions of the ccNSO Council, unless otherwise provided in
these Bylaws. The ccNSO Council shall transmit minutes of its meetings
to the ICANN Secretary, who shall cause those minutes to be posted to
the Website as soon as practicable following the meeting, and no later
than 21 days following the meeting.
Section 4. MEMBERSHIP
1. The ccNSO shall have a membership consisting
of ccTLD managers. Any ccTLD manager that meets the membership qualifications
stated in paragraph 2 of this Section shall be entitled to be members
of the ccNSO. For purposes of this Article, a ccTLD manager is the organization
or entity responsible for managing an ISO 3166 country-code top-level
domain and referred to in the IANA database under the current heading
of "Sponsoring Organization" for that country-code top-level
domain.
2. Any ccTLD manager may become a ccNSO member
by submitting an application to a person designated by the ccNSO Council
to receive applications. Subject to the provisions of the Transition
Article of these Bylaws, the application shall be in writing in
a form designated by the ccNSO Council. The application shall include
the ccTLD manager's recognition of the role of the ccNSO within the
ICANN structure as well as the ccTLD manager's agreement, for the duration
of its membership in the ccNSO, (a) to adhere to rules for ccNSO membership
adopted by the ccNSO Council, (b) to abide by policies developed and
recommended by the ccNSO and adopted by the Board in the manner described
by paragraphs 10 and 11 of this Section, and (c)
to pay ccNSO membership fees established by the ccNSO Council under
Section 7(3) of this Article. A ccNSO member may
resign from membership at any time by giving written notice to a person
designated by the ccNSO Council to receive notices of resignation. In
the absence of designation by the ccNSO Council of a person to receive
applications and notices of resignation, they shall be sent to the ICANN
Secretary, who shall notify the ccNSO Council of receipt of any such
applications and notices.
3. Neither membership in the ccNSO nor membership
in any Regional Organization described in Section 5 of
this Article shall be a condition for access to or registration
in the IANA database. Membership in the ccNSO is independent of any
individual relationship a ccTLD manager has with ICANN or the ccTLD
manager's receipt of IANA services.
4. The Geographic Regions of ccTLDs shall be as
described in Article VI, Section 5 of these Bylaws. For purposes of
this Article, managers of ccTLDs within a Geographic Region that are
members of the ccNSO are referred to as ccNSO members "within"
the Geographic Region, regardless of the physical location of the ccTLD
manager. In cases where the Geographic Region of a ccNSO member is unclear,
the ccTLD member should self-select according to procedures adopted
by the ccNSO Council.
5. Each ccTLD manager may designate in writing
a person, organization, or entity to represent the ccTLD manager. In
the absence of such a designation, the ccTLD manager shall be represented
by the person, organization, or entity listed as the administrative
contact in the IANA database.
6. There shall be an annual meeting of ccNSO members,
which shall be coordinated by the ccNSO Council. Annual meetings should
be open for all to attend, and a reasonable opportunity shall be provided
for non-members of the ccNSO to address the meeting. To the extent practicable,
annual meetings of the ccNSO members shall be held in person and should
coincide with meetings of the Board, or of one or more of ICANN's other
Supporting Organizations.
7. The ccNSO Council members selected by the ccNSO
members from each Geographic Region (see Section 3(1)(a)
of this Article) shall be selected through nomination, and if necessary
election, by the ccNSO members within that Geographic Region. At least
90 days before the end of the regular term of any ccNSO-member-selected
member of the ccNSO Council, or upon the occurrence of a vacancy in
the seat of such a ccNSO Council member, the ccNSO Council shall establish
a nomination and election schedule, which shall be sent to all ccNSO
members within the Geographic Region and posted on the Website.
8. Any ccNSO member may nominate an individual
to serve as a ccNSO Council member representing the ccNSO member's Geographic
Region. Nominations must be seconded by another ccNSO member from the
same Geographic Region. By accepting their nomination, individuals nominated
to the ccNSO Council agree to support the policies committed to by ccNSO
members.
9. If at the close of nominations there are no
more candidates nominated (with seconds and acceptances) in a particular
Geographic Region than there are seats on the ccNSO Council available
for that Geographic Region, then the nominated candidates shall be selected
to serve on the ccNSO Council. Otherwise, an election by written ballot
(which may be by e-mail) shall be held to select the ccNSO Council members
from among those nominated (with seconds and acceptances), with ccNSO
members from the Geographic Region being entitled to vote in the election
through their designated representatives. In such an election, a majority
of all ccNSO members in the Geographic Region shall constitute a quorum,
and the selected candidate must receive the votes of a majority of those
cast by ccNSO members within the Geographic Region. The ccNSO Chair
shall provide the ICANN Secretary prompt written notice of the selection
of ccNSO Council members under this paragraph.
10. Policies that (a) have been developed through
the ccPDP as described in Section 6 of this Article,
and (b) have been recommended as such by the ccNSO to the Board, and
(c) are adopted by the Board as policies, shall be binding upon ccNSO
members for the duration of their membership in the ccNSO, provided
that such policies do not conflict with the law applicable to the ccTLD
manager which shall, at all times, remain paramount.
11. A ccNSO member may apply to the ccNSO Council
to be exempt from a policy that is binding under paragraph 10 of this
Section on the grounds that implementation of the policy would require
the member to breach custom, religion, or public policy of the ccTLD's
country. In making such an application the member must also satisfy
the ccNSO Council that the granting of such an exemption will not impair
DNS operations. The exemption shall be granted unless by a 66% vote
the ccNSO Council rejects the application.
Section 5. REGIONAL ORGANIZATIONS
The ccNSO Council may designate a Regional Organization for each ICANN
Geographic Region, provided that the Regional Organization is open to
full membership by all ccNSO members within the Geographic Region. Decisions
to designate or de-designate a Regional Organization shall require a 66%
vote of all of the members of the ccNSO Council and shall be subject to
review according to procedures established by the Board.
Section 6. ccNSO POLICY-DEVELOPMENT PROCESS AND
SCOPE
1. In developing substantive policies within the
scope of the ccNSO and recommending them to the Board, the ccNSO shall
follow the ccNSO Policy-Development Process (ccPDP). The ccPDP shall
initially be as stated in Annex B to these Bylaws; modifications shall
be recommended to the Board by the ccNSO by use of the procedures of
the ccPDP, and shall be subject to approval by the Board.
2. The scope of the ccNSO's policy-development
role shall be defined by a policy developed according to the principles
and method of analysis described in the Framework for the Scope of the
ccNSO, and recommended to and considered by the Board following the
procedures of the ccPDP. The Framework for the Scope of the ccNSO shall
initially be as stated in Annex C to these Bylaws; modifications shall
be recommended to the Board by the ccNSO by use of the procedures of
the ccPDP, and shall be subject to approval by the Board.
Section 7. STAFF SUPPORT AND FUNDING
1. Upon request of the ccNSO Council, a member
of the ICANN staff may be assigned to support the ccNSO and shall be
designated as the ccNSO Staff Manager. Alternatively, the ccNSO Council
may designate, at ccNSO expense, another person to serve as ccNSO Staff
Manager. The work of the ccNSO Staff Manager on substantive matters
shall be assigned by the Chair of the ccNSO Council, and may include
the duties of ccPDP Issue Manager.
2. Upon request of the ccNSO Council, ICANN shall
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. The
ccNSO Council may make provision, at ccNSO expense, for administrative
and operational support in addition or as an alternative to support
provided by ICANN.
3. The ccNSO Council shall establish fees to be
paid by ccNSO members to defray ccNSO expenses as described in paragraphs
1 and 2 of this Section.
4. Written notices given to the ICANN Secretary
under this Article shall be permanently retained, and shall be made
available for review by the ccNSO Council on request. The ICANN Secretary
shall also maintain the roll of members of the ccNSO, which shall include
the name of each ccTLD manager's designated representative, and which
shall be posted on the Website.
ARTICLE X: GENERIC NAMES SUPPORTING ORGANIZATION,
Section 3. GNSO COUNCIL
1. Subject to the provisions of the Transition
Article of these Bylaws, the GNSO Council shall consist of two representatives
selected by each of the Constituencies described in Section 5 of this
Article, and three persons selected by the ICANN Nominating Committee.
No two representatives selected by a Constituency shall be citizens
of the same country or of countries located in the same Geographic Region.
There may also be two liaisons to the GNSO Council, one appointed by
each of the Governmental Advisory Committee and the At-Large Advisory
Committee from time to time, who shall not be members of or entitled
to vote on the GNSO Council, but otherwise shall be entitled to participate
on equal footing with members of the GNSO Council. The
appointing Advisory Committee shall designate its liaison (or revoke
or change the designation of its liaison) on the GNSO Council by providing
written notice to the Chair of the GNSO Council and to the ICANN Secretary.
The GNSO Council may also have observers as described in paragraph 9
of this Section.
[Paragraphs 2-8 are unchanged.]
9. The GNSO Council may
agree with the Council of any other ICANN Supporting Organization to
exchange observers. Such observers shall not be members of or entitled
to vote on the GNSO Council, but otherwise shall be entitled to participate
on equal footing with members of the GNSO Council. The appointing Council
shall designate its observer (or revoke or change the designation of
its observer) on the GNSO Council by providing written notice to the
Chair of the GNSO Council and to the ICANN Secretary.
ARTICLE XI: ADVISORY COMMITTEES, Section 2. SPECIFIC
ADVISORY COMMITTEES
4. At-Large Advisory Committee
[Paragraphs 4(a)-(e) are unchanged.]
f. Subject to the provisions of the Transition
Article of these Bylaws, the At-Large Advisory Committee may designate
non-voting liaisons to each of the ccNSO
Council and the GNSO Council.
[Paragraphs 4(g)-(j) are unchanged.]
ARTICLE XX: TRANSITION ARTICLE, Section 4. COUNTRY-CODE
NAMES SUPPORTING ORGANIZATION
Until such time as a Country-Code Names Supporting
Organization is established, Seats 11 and 12 on the New Board shall remain
vacant, and the delegate to the Nominating Committee established by the
New Bylaws designated to be selected by such an organization shall be
appointed by the Transition or New Board, depending on which is in existence
at the time any particular appointment is required, after due consultation
with members of the ccTLD community. Upon the organization and recognition
by the ICANN Board of a Country-Code Names Supporting Organization, that
Supporting Organization shall promptly select persons to fill Seats 11
and 12 on the New Board, and give written notice of those selections to
the ICANN Secretary. Any delegate to the Nominating Committee appointed
by the Transition or New Board according to this Section 4 then serving
shall remain in office, but subsequent appointments of the Nominating
Committee delegate described in Article VII, Section 2(8)(c) shall be
made by the Council of the Country Code Names Supporting Organization.
1. Upon the enrollment
of thirty ccTLD managers (with at least four within each Geographic
Region) as members of the ccNSO, written notice shall be posted on the
Website. As soon as feasible after that notice, the members of the initial
ccNSO Council to be selected by the ccNSO members shall be selected
according to the procedures stated in Article IX, Section 4(8) and (9).
Upon the completion of that selection process, a written notice that
the ccNSO Council has been constituted shall be posted on the Website.
Three ccNSO Council members shall be selected by the ccNSO members within
each Geographic Region, with one member to serve a term that ends upon
the conclusion of the first ICANN annual meeting after the ccNSO Council
is constituted, a second member to serve a term that ends upon the conclusion
of the second ICANN annual meeting after the ccNSO Council is constituted,
and the third member to serve a term that ends upon the conclusion of
the third ICANN annual meeting after the ccNSO Council is constituted.
(The definition of "ccTLD manager" stated in Article IX, Section
4(1) and the definitions stated in Article IX, Section 4(4) shall apply
within this Section 4 of Article XX.)
2.
After the adoption of Article IX of these Bylaws, the Nominating Committee
shall select the three members of the ccNSO Council described in Article
IX, Section 3(1)(b). In selecting three individuals to serve on the
ccNSO Council, the Nominating Committee shall designate one to serve
a term that ends upon the conclusion of the first ICANN annual meeting
after the ccNSO Council is constituted, a second member to serve a term
that ends upon the conclusion of the second ICANN annual meeting after
the ccNSO Council is constituted, and the third member to serve a term
that ends upon the conclusion of the second ICANN annual meeting after
the ccNSO Council is constituted. The three members of the ccNSO Council
selected by the Nominating Committee shall not take their seats before
the ccNSO Council is constituted.
3.
Upon the ccNSO Council being constituted, the At-Large Advisory Committee
and the Governmental Advisory Committee may designate one liaison each
to the ccNSO Council, as provided by Article IX, Section 3(2)(a) and
(b).
4.
Upon the ccNSO Council being constituted, the Council may designate
Regional Organizations as provided in Article IX, Section 5. Upon its
designation, a Regional Organization may designate a liaison to the
ccNSO Council.
5.
Until the ccNSO Council is constituted, Seats 11 and 12 on the New Board
shall remain vacant. Promptly after the ccNSO Council is constituted,
the ccNSO shall, through the ccNSO Council, make selections of Directors
to fill Seats 11 and 12 on the New Board, with terms to conclude upon
the commencement of the next regular term specified for each of those
Seats in Article VI, Section 8(1)(d) and (f) of the New Bylaws, and
shall give the ICANN Secretary written notice of its selections.
6.
Until the ccNSO Council is constituted, the delegate to the Nominating
Committee established by the New Bylaws designated to be selected by
the ccNSO shall be appointed by the Transition Board or New Board, depending
on which is in existence at the time any particular appointment is required,
after due consultation with members of the ccTLD community. Upon the
ccNSO Council being constituted, the delegate to the Nominating Committee
appointed by the Transition Board or New Board according to this Section
4(9) then serving shall remain in office, except that the ccNSO Council
may replace that delegate with one of its choosing within three months
after the conclusion of ICANN's annual meeting, or in the event of a
vacancy. Subsequent appointments of the Nominating Committee delegate
described in Article VII, Section 2(8)(c) shall be made by the ccNSO
Council.
Annex
B: ccNSO Policy-Development Process (ccPDP)
[Note: This entire Annex B is new.
The addition of this text is not shown by redlining.]
The following process shall govern the ccNSO policy-development process
("PDP").
1. Request for an Issue Report
An Issue Report may be requested by any of the following:
a. Council. The ccNSO Council (in this
Annex B, the "Council") may call for the creation of an Issue
Report by an affirmative vote of at least seven of the members of the
Council present at any meeting or voting by e-mail.
b. Board. The ICANN Board may call for
the creation of an Issue Report by requesting the 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 call for creation of an Issue Report by requesting the Council
to begin the policy-development process.
d. ICANN Supporting Organization or Advisory
Committee. An ICANN Supporting Organization or an ICANN Advisory
Committee may call for creation of an Issue Report by requesting the
Council to begin the policy-development process.
Any request for an Issue 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 seven days after an affirmative vote as outlined in Item 1(a)
above or the receipt of a request as outlined in Items 1 (b), (c), or
(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 after 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 and
within the scope of the ccNSO. In coming to his or her 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, determined
according to the process described in Article IX, Section 7 and Annex
C.;
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 to 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 vote on whether to
initiate the PDP. Such vote should be taken at a meeting held in any
manner deemed appropriate by the Council, including in person or by
conference call, but if a meeting is not feasible the vote may occur
by e-mail.
b. A vote of ten or more Council members in
favor of initiating the PDP shall suffice to initiate the PDP provided
that the Issue Report states that the issue is properly within the scope
of the ICANN mission statement and the ccNSO Scope Framework. In the
event that the Issue Report states it is not properly within the scope
of the ICANN mission statement or the ccNSO Scope framework, then a
vote of twelve or more Council members in favor of initiating the PDP
shall be required to initiate the PDP.
4. Decision Whether to Appoint Task Force;
Establishment of Time Line
At the meeting of the Council where the PDP has been initiated (or, where
the Council employs a vote by e-mail, in that vote) pursuant to Item 3
above, the Council shall decide, by a majority vote of members present
at the meeting (or voting by e-mail), 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 Item 7 below.
b. Against convening a task force, then it
shall collect information on the policy issue in accordance with Item
8 below.
The Council shall also, by a majority vote of members present at the
meeting or voting by e-mail, 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 (see Article
IX, Section 6) to appoint two individuals to participate in the task
force (the "Representatives"). Additionally, the Council may
appoint up to three advisors (the "Advisors") from outside
the ccNSO 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 members of the Council, but each 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 the
task force's 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 Website and to the other ICANN Supporting Organizations
and Advisory Committees. A comment period (in accordance with the PDP
Time Line, and ordinarily at least 21 days long) 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, its role shall be responsible for (i) gathering information
documenting the positions of the ccNSO members within the Geographic
Regions and other parties and groups; 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 initiated the PDP;
2. The specific time line 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
at a meeting or voting by e-mail. The quorum requirements of Article
IX, Section 3(14) shall apply to Council actions under this Item 7(b).
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 the Regional Organization for their Geographic Region, at a minimum,
and may solicit other comments, as each Representative deems appropriate,
including the comments of the ccNSO members in that region that are
not members of the Regional Organization, 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 Regional 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) A statement of the position on the
issue of any ccNSO members that are not members of the Regional
Organization;
(v) An analysis of how the issue would
affect the Region, including any financial impact on the Region;
and
(vi) 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, the Comment Report, 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
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 time line 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, the Comment Report, and other information and compile (and
post on the Website) an Initial Report within the time designated in
the PDP Time Line. Thereafter, the Issue Manager shall, in accordance
with Item 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, and ordinarily at least 21 days long) 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, to prepare 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; (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; and (iii) formally send to the GAC Chair an invitation
to the GAC to offer opinion or advice. Such meeting may be held in any
manner deemed appropriate by the Council, including in person or by
conference call. The Issue Manager shall be present at the meeting.
b. The Council may commence its deliberation
on the issue prior to the formal meeting, including via in-person meetings,
conference calls, e-mail discussions, or any other means the Council
may choose.
c. The Council may, if it so chooses, solicit
the opinions of outside advisors at its final meeting. The opinions
of these advisors, if relied upon by the Council, shall be (i) embodied
in the Council's report to the Board, (ii) specifically identified as
coming from an outside advisor; and (iii) accompanied by a detailed
statement of the advisor's (a) qualifications and relevant experience
and (b) potential conflicts of interest.
11. Recommendation of the Council
A recommendation supported by 14 or more of the Council members shall
be deemed to reflect the view of the Council, and shall 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 Item
11 then the Issue Manager shall, within seven days after 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 (see Item 10), including all the opinions
expressed during such deliberation, accompanied by a description of
who expressed such opinions.
13. Members Vote
Following the submission of the Members Report and within the time designated
by the PDP Time Line, the ccNSO 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 (ordinarily at least 21 days long).
In the event that more than 66% 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 Item
14 below as the ccNSO Recommendation.
14. Board Report
The Issue Manager shall within seven days after a ccNSO Recommendation
being made in accordance with Item 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:
a. A clear statement of the ccNSO recommendation;
b. The Final Report submitted to the Council;
and
c. the Members' Report.
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, taking into account procedures for Board consideration.
b. The Board shall adopt the ccNSO Recommendation
unless by a vote of more than 66% the Board determines that such policy
is not in the best interest of the ICANN community or of 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 discuss the Board
Statement with the Board within thirty days after the Board Statement
is submitted to the Council. 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. A recommendation supported by 14 or more of
the Council members shall be deemed to reflect the view of the Council
(the Council's "Supplemental Recommendation"). That Supplemental
Recommendation shall be conveyed to the Members in a Supplemental
Members Report, including an explanation for the Supplemental Recommendation.
Members shall be given an opportunity to vote on the Supplemental
Recommendation under the same conditions outlined in Item 13. In the
event that more than 66% of the votes cast by ccNSO Members 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
by a vote of more than 66% of the Board determines that such policy
is not in the best interest of the ICANN community or of 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 Item 2 e was that the issue was within the scope of
the ccNSO pursuant to the ccNSO's Scope Framework,
then the Board shall not be entitled to set policy on the issue addressed
by the recommendation and the status quo shall be preserved until
such time as the ccNSO shall, under the ccPDP, make a recommendation
on the issue that is deemed acceptable by the Board.
16. Implementation of the Policy
Upon adoption by the Board of 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
With respect to each ccPDP for which an Issue Report is requested (see
Item 1), ICANN shall maintain on the Website a status web page detailing
the progress of each ccPDP, which shall provide a list of relevant dates
for the ccPDP and shall also link to the following documents, to the extent
they have been prepared pursuant to the ccPDP:
a. Issue Report;
b. PDP Time Line;
c. Comment Report;
d. Regional Statement(s);
e. Preliminary Task Force Report;
f. Task Force Report;
g. Initial Report;
h. Final Report;
i. Members' Report;
j. Board Report;
k. Board Statement;
l. Supplemental Members Report; and
m. Supplemental Board Statement.
In addition, ICANN shall post on the Website comments received in electronic
written form specifically suggesting that a ccPDP be initiated.
Annex
C: Framework for the Scope of the ccNSO
[Note: This entire Annex C is new. The addition
of this text is not shown by redlining.]
This framework describes the principles and method of analysis to be
used in the development of the scope of the ccNSO's policy-development
role. As provided in Article IX, Section 6(2) of the Bylaws, that scope
shall be defined according to the procedures of the ccPDP.
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 Supporting Organizations, Committees,
and constituencies under ICANN.
The scope of the ccNSO's authority and responsibilities must recognize
the complex relation between ICANN and ccTLD managers/registries with
regard to policy issues. This framework shall assist the ccNSO, the ccNSO
Council, and the ICANN Board and staff in delineating relevant global
policy issues.
Policy areas
The ccNSO's policy role should be based on an analysis of 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.
Within a TLD two functions have to be performed (these are addressed
in greater detail below):
1. Entering data into a database (Data Entry Function) and
2. Maintaining and ensuring upkeep of name-servers for the TLD (Name
Server Function).
These two core functions must be performed at the ccTLD registry level
as well as at a higher level (IANA function and root servers) and at lower
levels 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 Core Functions
1. Data Entry Function (DEF):
Looking at a more detailed level, the first function (entering and maintaining
data in a database) 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, through Whois or nameservers).
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 importance of this
function extends to nameservers at the ccTLD level, but also to the root
servers (and root-server system) and nameservers at lower levels.
On its own merit and because of interoperability and stability considerations,
properly functioning nameservers are of utmost importance to the individual,
as well as to the local and the global Internet communities.
With regard to the nameserver function, therefore, policies need to be
defined and established. Most parties involved, including the majority
of ccTLD registries, have accepted the need for common policies in this
area by adhering to the relevant RFCs, among others RFC 1591.
Respective Roles with Regard to Policy, Responsibilities, and Accountabilities
It is in the interest 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 that can
be defined by the relevant policies. The scope of the ccNSO cannot be
established without reaching a common understanding of the allocation
of authority between ICANN and ccTLD registries.
Three roles can be distinguished as to which responsibility must be assigned
on any given issue:
- Policy role: i.e. the ability and power to define a policy;
- Executive role: i.e. the ability and power to act upon and
implement the policy; and
- Accountability role: i.e. the ability and power to hold the
responsible entity accountable for exercising its power.
Firstly, responsibility presupposes a policy and this delineates the
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 presupposes an executive role defining the
power to implement and act within the boundaries of a policy. Finally,
as a counter-balance to the executive role, the accountability role needs
to defined and determined.
The framework below offers an aid to:
1. delineate and identify specific policy areas;
2. define and determine roles with regard to these specific policy
areas.
The following framework illustrates the method described above for identifying
the allocation of authority among ccTLD managers and other stakeholders,
which should form the basis for determining the policy-development scope
of the ccNSO. This example is not intended to be authoritative, but rather
to serve as guidance in the ccPDP process by which the scope of the ccNSO's
policy-development role will be developed. It is anticipated that the
accuracy of the assignments of policy, executive, and accountability roles
shown below will be considered during the scope-definition ccPDP process.
Name Server Function
Level 1: Root Name Servers
Policy role: IETF, RSSAC (ICANN)
Executive role: Root Server System Operators
Accountability role: RSSAC (ICANN), (US DoC-ICANN MoU)
Level 2: ccTLD Registry Name Servers
Policy role: ccNSO Policy Development Process (ICANN), for best practices
a ccNSO process can be organized
Executive role: ccTLD Manager
Accountability role: part ICANN (IANA), part Local Internet Community,
including local government
Level 3: User's Name Servers
Policy role: ccTLD Manager, IETF (RFC)
Executive role: Registrant
Accountability role: ccTLD Manager
Data Entry Function
Level 1: Root Level Registry
Policy role: ccNSO Policy Development Process (ICANN)
Executive role: ICANN (IANA)
Accountability role: ICANN community, TLD Managers, US DoC, (national
authorities in some cases)
Level 2: ccTLD Registry
Policy role: Local Internet Community, including local government, and/or
ccTLD Manager according to local structure
Executive role: ccTLD Manager
Accountability role: Local Internet Community, including national authorities
in some cases
Level 3: Second and Lower Levels
Policy role: Registrant
Executive role: Registrant
Accountability role: Registrant, users of lower-level domain names
Questions
concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.
Page Updated
21-Jun-2003
©2003 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.
|