The mission of The Internet Corporation for Assigned Names and Numbers
(“ICANN”) is to coordinate, at the overall level, the global
Internet's systems of unique identifiers, and in particular to ensure
the stable and secure operation of the Internet's unique identifier systems.
In particular, ICANN:

1. Coordinates the allocation and assignment of
the three sets of unique identifiers for the Internet, which are

2. Coordinates the operation and evolution of the
DNS root name server system.

3. Coordinates policy development reasonably and
appropriately related to these technical functions.

Section 2. CORE VALUES

In performing its mission, the following core values should guide the
decisions and actions of ICANN:

1. Preserving and enhancing the operational stability,
reliability, security, and global interoperability of the Internet.

2. Respecting the creativity, innovation, and flow
of information made possible by the Internet by limiting ICANN's activities
to those matters within ICANN's mission requiring or significantly benefiting
from global coordination.

3. To the extent feasible and appropriate, delegating
coordination functions to or recognizing the policy role of other responsible
entities that reflect the interests of affected parties.

4. Seeking and supporting broad, informed participation
reflecting the functional, geographic, and cultural diversity of the
Internet at all levels of policy development and decision-making.

5. Where feasible and appropriate, depending on
market mechanisms to promote and sustain a competitive environment.

6. Introducing and promoting competition in the
registration of domain names where practicable and beneficial in the
public interest.

7. Employing open and transparent policy development
mechanisms that (i) promote well-informed decisions based on expert advice,
and (ii) ensure that those entities most affected can assist in the policy
development process.

8. Making decisions by applying documented policies
neutrally and objectively, with integrity and fairness.

9. Acting with a speed that is responsive to the
needs of the Internet while, as part of the decision-making process,
obtaining informed input from those entities most affected.

10. Remaining accountable to the Internet community
through mechanisms that enhance ICANN's effectiveness.

11. While remaining rooted in the private sector,
recognizing that governments and public authorities are responsible for
public policy and duly taking into account governments' or public authorities'
recommendations.

These core values are deliberately expressed in very general terms,
so that they may provide useful and relevant guidance in the broadest
possible range of circumstances. Because they are not narrowly prescriptive,
the specific way in which they apply, individually and collectively, to
each new situation will necessarily depend on many factors that cannot
be fully anticipated or enumerated; and because they are statements of
principle rather than practice, situations will inevitably arise in which
perfect fidelity to all eleven core values simultaneously is not possible.
Any ICANN body making a recommendation or decision shall exercise its
judgment to determine which core values are most relevant and how they
apply to the specific circumstances of the case at hand, and to determine,
if necessary, an appropriate and defensible balance among competing values.

ARTICLE II: POWERS

Section 1. GENERAL POWERS

Except as otherwise provided in the Articles of Incorporation or these
Bylaws, the powers of ICANN shall be exercised by, and its property controlled
and its business and affairs conducted by or under the direction of, the
Board. With respect to any matters that would fall within the provisions
of Article III, Section 6, the Board may act only
by a majority vote of all members of the Board. In all other matters,
except as otherwise provided in these Bylaws or by law, the Board may
act by majority vote of those present at any annual, regular, or special
meeting of the Board. Any references in these Bylaws to a vote of the
Board shall mean the vote of only those members present at the meeting
where a quorum is present unless otherwise specifically provided in these
Bylaws by reference to “all of the members of the Board.”

Section 2. RESTRICTIONS

ICANN shall not act as a Domain Name System Registry or Registrar or
Internet Protocol Address Registry in competition with entities affected
by the policies of ICANN. Nothing in this Section is intended to prevent
ICANN from taking whatever steps are necessary to protect the operational
stability of the Internet in the event of financial failure of a Registry
or Registrar or other emergency.

Section 3. NON-DISCRIMINATORY TREATMENT

ICANN shall not apply its standards, policies, procedures, or practices
inequitably or single out any particular party for disparate treatment
unless justified by substantial and reasonable cause, such as the promotion
of effective competition.

ARTICLE III: TRANSPARENCY

Section 1. PURPOSE

ICANN and its constituent bodies shall operate to the maximum extent
feasible in an open and transparent manner and consistent with procedures
designed to ensure fairness.

Section 2. WEBSITE

ICANN shall maintain a publicly-accessible Internet World Wide Web site
(the “Website”), which may include, among other things, (i)
a calendar of scheduled meetings of the Board, Supporting Organizations,
and Advisory Committees; (ii) a docket of all pending policy development
matters, including their schedule and current status; (iii) specific meeting
notices and agendas as described below; (iv) information on ICANN's budget,
annual audit, financial contributors and the amount of their contributions,
and related matters; (v) information about the availability of accountability
mechanisms, including reconsideration, independent review, and Ombudsman
activities, as well as information about the outcome of specific requests
and complaints invoking these mechanisms; (vi) announcements about ICANN
activities of interest to significant segments of the ICANN community;
(vii) comments received from the community on policies being developed
and other matters; (viii) information about ICANN's physical meetings
and public forums; and (ix) other information of interest to the ICANN
community.

Section 3. MANAGER OF PUBLIC PARTICIPATION

There shall be a staff position designated as Manager of Public Participation,
or such other title as shall be determined by the President, that shall
be responsible, under the direction of the President, for coordinating
the various aspects of public participation in ICANN, including the Website
and various other means of communicating with and receiving input from
the general community of Internet users.

Section 4. MEETING NOTICES AND AGENDAS

At least seven days in advance of each Board 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.

Section 5. MINUTES AND PRELIMINARY REPORTS

1. All minutes of meetings of the Board and Supporting
Organizations (and any councils thereof) shall be approved promptly by
the originating body and provided to the ICANN Secretary for posting
on the Website.

2.
No later than 11:59 p.m. on the second business days after the conclusion of each meeting (as calculated by local time at the location of ICANN's principal office), any resolutions passed by the Board of Directors at that meeting shall be made publicly available on the Website; provided, however, that any actions relating to personnel or employment matters, legal matters (to the extent the Board determines it is necessary or appropriate to protect the interests of ICANN), matters that ICANN is prohibited by law or contract from disclosing publicly, and other matters that the Board determines, by a three-quarters (3/4) vote of Directors present at the meeting and voting, are not appropriate for public distribution, shall not be included in the preliminary report made publicly available. The Secretary shall send notice to the Board of Directors and the Chairs of the Supporting Organizations (as set forth in Articles VIII - X of these Bylaws) and Advisory Committees (as set forth in Article XI of these Bylaws) informing them that the resolutions have been posted.

3.
No later than 11:59 p.m. on the seventh business days after the conclusion of each meeting (as calculated by local time at the location of ICANN's principal office), any actions taken by the Board shall be made publicly available in a preliminary report on the Website, subject to the limitations on disclosure set forth in Section 5.2 above. For any matters that the Board determines not to disclose, the Board shall describe in general terms in the relevant preliminary report the reason for such nondisclosure.

4. No later than the day after the date on which they are formally approved by the Board (or, if such day is not a business day, as calculated by local time at the location of ICANN's principal office, then the next immediately following business day), the minutes shall be made publicly available on the Website; provided, however, that any minutes relating to personnel or employment matters, legal matters (to the extent the Board determines it is necessary or appropriate to protect the interests of ICANN), matters that ICANN is prohibited by law or contract from disclosing publicly, and other matters that the Board determines, by a three-quarters (3/4) vote of Directors present at the meeting and voting, are not appropriate for public distribution, shall not be included in the minutes made publicly available. For any matters that the Board determines not to disclose, the Board shall describe in general terms in the relevant minutes the reason for such nondisclosure.

Section 6. NOTICE AND COMMENT ON POLICY ACTIONS

1. With respect to any policies that are being
considered by the Board for adoption that substantially affect the operation
of the Internet or third parties, including the imposition of any fees
or charges, ICANN shall:

a. provide public notice on the Website explaining
what policies are being considered for adoption and why, at least twenty-one
days (and if practical, earlier) prior to any action by the Board;

b. provide a reasonable opportunity for parties
to comment on the adoption of the proposed policies, to see the comments
of others, and to reply to those comments, prior to any action by the
Board; and

c. in those cases where the policy action affects
public policy concerns, to request the opinion of the Governmental Advisory
Committee and take duly into account any advice timely presented by
the Governmental Advisory Committee on its own initiative or at the
Board's request.

2. Where both practically feasible and consistent
with the relevant policy development process, an in-person public forum
shall also be held for discussion of any proposed policies as described
in Section 6(1)(b) of this Article, prior to
any final Board action.

3. After taking action on any policy subject
to this Section, the Board shall publish in the meeting minutes the reasons
for any action taken, the vote of each Director voting on the action,
and the separate statement of any Director desiring publication of such
a statement.

Section 7. TRANSLATION OF DOCUMENTS

As appropriate and to the extent provided in the ICANN budget, ICANN
shall facilitate the translation of final published documents into various
appropriate languages.

ARTICLE IV: ACCOUNTABILITY AND REVIEW

Section 1. PURPOSE

In carrying out its mission as set out in these Bylaws, ICANN should
be accountable to the community for operating in a manner that is consistent
with these Bylaws, and with due regard for the core values set forth in Article
I of these Bylaws. The provisions of this Article, creating processes
for reconsideration and independent review of ICANN actions and periodic
review of ICANN's structure and procedures, are intended to reinforce
the various accountability mechanisms otherwise set forth in these Bylaws,
including the transparency provisions of Article III and
the Board and other selection mechanisms set forth throughout these Bylaws.

Section 2. RECONSIDERATION

1. ICANN shall have in place a process by which
any person or entity materially affected by an action of ICANN may request
review or reconsideration of that action by the Board.

2. Any person or entity may submit a request for
reconsideration or review of an ICANN action or inaction (“Reconsideration
Request”) to the extent that he, she, or it have been adversely
affected by:

a. one or more staff actions or inactions that
contradict established ICANN policy(ies); or

b. one or more actions or inactions of the ICANN
Board that have been taken or refused to be taken without consideration
of material information, except where the party submitting the request
could have submitted, but did not submit, the information for the Board's
consideration at the time of action or refusal to act.

3. The Board has designated the Board Governance Committee to review
and consider any such Reconsideration Requests. The Board Governance
Committee shall have the authority to:

a. evaluate requests for review or reconsideration;

b. determine whether a stay of the contested
action pending resolution of the request is appropriate;

c. conduct whatever factual investigation is
deemed appropriate;

d. request additional written submissions from
the affected party, or from other parties; and

e. make a recommendation to the Board of Directors
on the merits of the request.

4. ICANN shall absorb the normal administrative
costs of the reconsideration process. It reserves the right to recover
from a party requesting review or reconsideration any costs which are
deemed to be extraordinary in nature. When such extraordinary costs can
be foreseen, that fact and the reasons why such costs are necessary and
appropriate to evaluating the Reconsideration Request shall be communicated
to the party seeking reconsideration, who shall then have the option
of withdrawing the request or agreeing to bear such costs.

5. All Reconsideration Requests must be submitted
to an e-mail address designated by the Board Governance Committee within
thirty days after:

a. for requests challenging Board actions, the
date on which information about the challenged Board action is first
published in a preliminary report or minutes of the Board's meetings;
or

b. for requests challenging staff actions, the
date on which the party submitting the request became aware of, or reasonably
should have become aware of, the challenged staff action; or

c. for requests challenging either Board or
staff inaction, the date on which the affected person reasonably concluded,
or reasonably should have concluded, that action would not be taken
in a timely manner.

6. All Reconsideration Requests must include the
information required by the Board Governance Committee, which shall include
at least the following information:

a. name, address, and contact information for
the requesting party, including postal and e-mail addresses;

b. the specific action or inaction of ICANN
for which review or reconsideration is sought;

c. the date of the action or inaction;

d. the manner by which the requesting party
will be affected by the action or inaction;

e. the extent to which, in the opinion of the
party submitting the Request for Reconsideration, the action or inaction
complained of adversely affects others;

f. whether a temporary stay of any action complained
of is requested, and if so, the harms that will result if the action
is not stayed;

g. in the case of staff action or inaction,
a detailed explanation of the facts as presented to the staff and the
reasons why the staff's action or inaction was inconsistent with established
ICANN policy(ies);

h. in the case of Board action or inaction,
a detailed explanation of the material information not considered by
the Board and, if the information was not presented to the Board, the
reasons the party submitting the request did not submit it to the Board
before it acted or failed to act;

i. what specific steps the requesting party
asks ICANN to take-i.e., whether and how the action should be reversed,
cancelled, or modified, or what specific action should be taken;

j. the grounds on which the requested action
should be taken; and

k. any documents the requesting party wishes
to submit in support of its request.

7. All Reconsideration Requests shall be posted
on the Website..

8. The Board Governance Committee shall have authority
to consider Reconsideration Requests from different parties in the same
proceeding so long as (i) the requests involve the same general action
or inaction and (ii) the parties submitting Reconsideration Requests
are similarly affected by such action or inaction.

9. The Board Governance Committee shall review
Reconsideration Requests promptly upon receipt and announce, within thirty
days, its intention to either decline to consider or proceed to consider
a Reconsideration Request after receipt of the Request. The announcement
shall be posted on the Website.

10. The Board Governance Committee announcement
of a decision not to hear a Reconsideration Request must contain an explanation
of the reasons for its decision.

11. The Board Governance Committee may request
additional information or clarifications from the party submitting the
Request for Reconsideration.

12. The Board Governance Committee may ask the
ICANN staff for its views on the matter, which comments shall be made
publicly available on the Website.

13. If the Board Governance Committee requires
additional information, it may elect to conduct a meeting with the party
seeking Reconsideration by telephone, e-mail or, if acceptable to the
party requesting reconsideration, in person. To the extent any information
gathered in such a meeting is relevant to any recommendation by the Board
Governance Committee, it shall so state in its recommendation.

14. The Board Governance Committee may also request
information relevant to the request from third parties. To the extent
any information gathered is relevant to any recommendation by the Board
Governance Committee, it shall so state in its recommendation.

15. The Board Governance Committee shall act
on a Reconsideration Request on the basis of the public written record,
including information submitted by the party seeking reconsideration
or review, by the ICANN staff, and by any third party.

16. To protect against abuse of the reconsideration
process, a request for reconsideration may be dismissed by the Board
Governance Committee where it is repetitive, frivolous, non-substantive,
or otherwise abusive, or where the affected party had notice and opportunity
to, but did not, participate in the public comment period relating to
the contested action, if applicable. Likewise, the Board Governance Committee
may dismiss a request when the requesting party does not show that it
will be affected by ICANN's action.

17. The Board Governance Committee shall make
a final recommendation to the Board with respect to a Reconsideration
Request within ninety days following its receipt of the request, unless
impractical, in which case it shall report to the Board the circumstances
that prevented it from making a final recommendation and its best estimate
of the time required to produce such a final recommendation. The final
recommendation shall be posted on the Website.

18. The Board shall not be bound to follow the
recommendations of the Board Governance Committee. The final decision
of the Board shall be made public as part of the preliminary report and
minutes of the Board meeting at which action is taken.

19. The Board Governance Committee shall submit
a report to the Board on an annual basis containing at least the following
information for the preceding calendar year:

a. the number and general nature of Reconsideration
Requests received;

b. the number of Reconsideration Requests on
which the Board Governance Committee has taken action;

c. the number of Reconsideration Requests that
remained pending at the end of the calendar year and the average length
of time for which such Reconsideration Requests have been pending;

d. a description of any Reconsideration Requests
that were pending at the end of the calendar year for more than ninety
(90) days and the reasons that the Board Governance Committee has not
taken action on them;

e. the number and nature of Reconsideration
Requests that the Board Governance Committee declined to consider on
the basis that they did not meet the criteria established in this policy;

f. for Reconsideration Requests that were denied,
an explanation of any other mechanisms available to ensure that ICANN
is accountable to persons materially affected by its decisions; and

g. whether or not, in the Board Governance
Committee's view, the criteria for which reconsideration may be requested
should be revised, or another process should be adopted or modified,
to ensure that all persons materially affected by ICANN decisions have
meaningful access to a review process that ensures fairness while limiting
frivolous claims.

1. In addition to the reconsideration process
described in Section 2 of this Article, ICANN shall
have in place a separate process for independent third-party review of
Board actions alleged by an affected party to be inconsistent with the
Articles of Incorporation or Bylaws.

2. Any person materially affected by a decision
or action by the Board that he or she asserts is inconsistent with the
Articles of Incorporation or Bylaws may submit a request for independent
review of that decision or action.

3. Requests for such independent review shall
be referred to an Independent Review Panel (“IRP”), which shall
be charged with comparing contested actions of the Board to the Articles
of Incorporation and Bylaws, and with declaring whether the Board has
acted consistently with the provisions of those Articles of Incorporation
and Bylaws.

4. The IRP shall be operated by an international
arbitration provider appointed from time to time by ICANN (“the
IRP Provider”) using arbitrators under contract with or nominated
by that provider.

5. Subject to the approval of the Board, the IRP
Provider shall establish operating rules and procedures, which shall
implement and be consistent with this Section 3.

6. Either party may elect that the request for
independent review be considered by a three-member panel; in the absence
of any such election, the issue shall be considered by a one-member panel.

7. The IRP Provider shall determine a procedure
for assigning members to individual panels; provided that if ICANN so
directs, the IRP Provider shall establish a standing panel to hear such
claims.

8. The IRP shall have the authority to:

a. request additional written submissions from
the party seeking review, the Board, the Supporting Organizations, or
from other parties;

b. declare whether an action or inaction of
the Board was inconsistent with the Articles of Incorporation or Bylaws;
and

c. recommend that the Board stay any action
or decision, or that the Board take any interim action, until such time
as the Board reviews and acts upon the opinion of the IRP.

9. Individuals holding an official position or
office within the ICANN structure are not eligible to serve on the IRP.

10. In order to keep the costs and burdens of
independent review as low as possible, the IRP should conduct its proceedings
by e-mail and otherwise via the Internet to the maximum extent feasible.
Where necessary, the IRP may hold meetings by telephone.

11. The IRP shall adhere to conflicts-of-interest
policy stated in the IRP Provider's operating rules and procedures, as
approved by the Board.

12. Declarations of the IRP shall be in writing.
The IRP shall make its declaration based solely on the documentation,
supporting materials, and arguments submitted by the parties, and in
its declaration shall specifically designate the prevailing party. The
party not prevailing shall ordinarily be responsible for bearing all
costs of the IRP Provider, but in an extraordinary case the IRP may in
its declaration allocate up to half of the costs of the IRP Provider
to the prevailing party based upon the circumstances, including a consideration
of the reasonableness of the parties' positions and their contribution
to the public interest. Each party to the IRP proceedings shall bear
its own expenses.

13. The IRP operating procedures, and all petitions,
claims, and declarations, shall be posted on the Website when they become
available.

14. The IRP may, in its discretion, grant a party's
request to keep certain information confidential, such as trade secrets.

15. Where feasible, the Board shall consider
the IRP declaration at the Board's next meeting.

Section 4. PERIODIC REVIEW OF ICANN STRUCTURE
AND OPERATIONS

1. The Board shall cause a periodic review 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.

These periodic reviews shall be conducted no less frequently than every five years, based on feasibility as determined by the Board. Each five-year cycle will be computed from the moment of the reception by the Board of the final report of the relevant review Working Group.

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.

1. There shall be an Office of Ombudsman, to be
managed by an Ombudsman and to include such staff support as the Board
determines is appropriate and feasible. The Ombudsman shall be a full-time
position, with salary and benefits appropriate to the function, as determined
by the Board.

2. The Ombudsman shall be appointed by the Board
for an initial term of two years, subject to renewal by the Board.

3. The Ombudsman shall be subject to dismissal
by the Board only upon a three-fourths (3/4) vote of the entire Board.

4. The annual budget for the Office of Ombudsman
shall be established by the Board as part of the annual ICANN budget
process. The Ombudsman shall submit a proposed budget to the President,
and the President shall include that budget submission in its entirety
and without change in the general ICANN budget recommended by the ICANN
President to the Board. Nothing in this Article shall prevent the President
from offering separate views on the substance, size, or other features
of the Ombudsman's proposed budget to the Board.

Section 2. CHARTER

The charter of the Ombudsman shall be to act as a neutral dispute resolution
practitioner for those matters for which the provisions of the Reconsideration
Policy set forth in Section 2 of Article IV or the
Independent Review Policy set forth in Section 3 of Article
IV have not been invoked. The principal function of the Ombudsman
shall be to provide an independent internal evaluation of complaints by
members of the ICANN community who believe that the ICANN staff, Board
or an ICANN constituent body has treated them unfairly. The Ombudsman
shall serve as an objective advocate for fairness, and shall seek to evaluate
and where possible resolve complaints about unfair or inappropriate treatment
by ICANN staff, the Board, or ICANN constituent bodies, clarifying the
issues and using conflict resolution tools such as negotiation, facilitation,
and “shuttle diplomacy” to achieve these results.

Section 3. OPERATIONS

The Office of Ombudsman shall:

1. facilitate the fair, impartial, and timely resolution
of problems and complaints that affected members of the ICANN community
(excluding employees and vendors/suppliers of ICANN) may have with specific
actions or failures to act by the Board or ICANN staff which have not
otherwise become the subject of either the Reconsideration or Independent
Review Policies;

2. exercise discretion to accept or decline to
act on a complaint or question, including by the development of procedures
to dispose of complaints that are insufficiently concrete, substantive,
or related to ICANN's interactions with the community so as to be inappropriate
subject matters for the Ombudsman to act on. In addition, and without
limiting the foregoing, the Ombudsman shall have no authority to act
in any way with respect to internal administrative matters, personnel
matters, issues relating to membership on the Board, or issues related
to vendor/supplier relations;

3. have the right to have access to (but not to
publish if otherwise confidential) all necessary information and records
from ICANN staff and constituent bodies to enable an informed evaluation
of the complaint and to assist in dispute resolution where feasible (subject
only to such confidentiality obligations as are imposed by the complainant
or any generally applicable confidentiality policies adopted by ICANN);

4. heighten awareness of the Ombudsman program
and functions through routine interaction with the ICANN community and
online availability;

5. maintain neutrality and independence, and have
no bias or personal stake in an outcome; and

6. comply with all ICANN conflicts-of-interest
and confidentiality policies.

Section 4. INTERACTION WITH ICANN AND OUTSIDE ENTITIES

1. No ICANN employee, Board member, or other participant
in Supporting Organizations or Advisory Committees shall prevent or impede
the Ombudsman's contact with the ICANN community (including employees
of ICANN). ICANN employees and Board members shall direct members of
the ICANN community who voice problems, concerns, or complaints about
ICANN to the Ombudsman, who shall advise complainants about the various
options available for review of such problems, concerns, or complaints.

2. ICANN staff and other ICANN participants shall
observe and respect determinations made by the Office of Ombudsman concerning
confidentiality of any complaints received by that Office.

3. Contact with the Ombudsman shall not constitute
notice to ICANN of any particular action or cause of action.

4. The Ombudsman shall be specifically authorized
to make such reports to the Board as he or she deems appropriate with
respect to any particular matter and its resolution or the inability
to resolve it. Absent a determination by the Ombudsman, in his or her
sole discretion, that it would be inappropriate, such reports shall be
posted on the Website.

5. The Ombudsman shall not take any actions not
authorized in these Bylaws, and in particular shall not institute, join,
or support in any way any legal actions challenging ICANN structure,
procedures, processes, or any conduct by the ICANN Board, staff, or constituent
bodies.

Section 5. ANNUAL REPORT

The Office of Ombudsman shall publish on an annual basis a consolidated
analysis of the year's complaints and resolutions, appropriately dealing
with confidentiality obligations and concerns. Such annual report should
include a description of any trends or common elements of complaints received
during the period in question, as well as recommendations for steps that
could be taken to minimize future complaints. The annual report shall
be posted on the Website.

ARTICLE VI: BOARD OF DIRECTORS

Section 1. COMPOSITION OF THE BOARD

The ICANN Board of Directors (“Board”) shall consist of fifteen
voting members (“Directors”). In addition, six non-voting liaisons
(“Liaisons”) shall be designated for the purposes set forth
in Section 9 of this Article. Only Directors shall
be included in determining the existence of quorums, and in establishing
the validity of votes taken by the ICANN Board.

Section 2. DIRECTORS AND THEIR SELECTION; ELECTION
OF CHAIRMAN AND VICE-CHAIRMAN

1. The Directors shall consist of:

a. Eight voting members selected by the Nominating
Committee established by Article VII of these Bylaws.
These seats on the Board of Directors are referred to in these Bylaws
as Seats 1 through 8.

b. Two voting members selected by the Address
Supporting Organization according to the provisions of Article
VIII of these Bylaws. These seats on the Board of Directors are
referred to in these Bylaws as Seat 9 and Seat 10.

c. Two voting members selected by the Country-Code
Names Supporting Organization according to the provisions of Article
IX of these Bylaws. These seats on the Board of Directors are referred
to in these Bylaws as Seat 11 and Seat 12.

d. Two voting members selected by the Generic
Names Supporting Organization according to the provisions of Article
X of these Bylaws. These seats on the Board of Directors are referred
to in these Bylaws as Seat 13 and Seat 14.

e. The President ex officio, who shall be a
voting member.

2. In carrying out its responsibilities to fill
Seats 1 through 8, the Nominating Committee shall seek to ensure that
the ICANN Board is composed of members who in the aggregate display diversity
in geography, culture, skills, experience, and perspective, by applying
the criteria set forth in Section 3 of this Article.
At no time when it makes its selection shall the Nominating Committee
select a Director to fill any vacancy or expired term whose selection
would cause the total number of Directors (not including the President)
from countries in any one Geographic Region (as defined in Section
5 of this Article) to exceed five; and the Nominating Committee shall
ensure when it makes its selections that the Board includes at least
one Director who is from a country in each ICANN Geographic Region (“Diversity
Calculation”).

For purposes of this sub-section 2 of Article VI, Section 2 of the
ICANN Bylaws, if any candidate for director maintains citizenship of
more than one country, or has been domiciled for more than five years
in a country of which the candidate does not maintain citizenship (“Domicile”),
that candidate may be deemed to be from either country and must select
in his/her Statement of Interest the country of citizenship or Domicile
that he/she wants the Nominating Committee to use for Diversity Calculation
purposes. For purposes of this sub- section 2 of Article VI, Section
2 of the ICANN Bylaws, a person can only have one “Domicile,” which shall
be determined by where the candidate has a permanent residence and place
of habitation.

3. In carrying out their responsibilities to fill
Seats 9 through 14, the Supporting Organizations shall seek to ensure
that the ICANN Board is composed of members that in the aggregate display
diversity in geography, culture, skills, experience, and perspective,
by applying the criteria set forth in Section 3 of this
Article. At any given time, no two Directors selected by a Supporting
Organization shall be citizens from the same country or of countries
located in the same Geographic Region.

For purposes of this sub-section 3 of Article VI, Section 2 of the
ICANN Bylaws, if any candidate for director maintains citizenship of
more than one country, or has been domiciled for more than five years
in a country of which the candidate does not maintain citizenship (“Domicile”),
that candidate may be deemed to be from either country and must select
in his/her Statement of Interest the country of citizenship or Domicile
that he/she wants the Supporting Organization to use for selection purposes.
For purposes of this sub-section 3 of Article VI, Section 2 of the ICANN
Bylaws, a person can only have one “Domicile,” which shall be determined
by where the candidate has a permanent residence and place of habitation.

4. The Board shall annually elect a Chairman and
a Vice-Chairman from among the Directors, not including the President.

Section 3. CRITERIA FOR SELECTION OF DIRECTORS

ICANN Directors shall be:

1. Accomplished persons of integrity, objectivity,
and intelligence, with reputations for sound judgment and open minds,
and a demonstrated capacity for thoughtful group decision-making;

2. Persons with an understanding of ICANN's mission
and the potential impact of ICANN decisions on the global Internet community,
and committed to the success of ICANN;

3. Persons who will produce the broadest cultural
and geographic diversity on the Board consistent with meeting the other
criteria set forth in this Section;

4. Persons who, in the aggregate, have personal
familiarity with the operation of gTLD registries and registrars; with
ccTLD registries; with IP address registries; with Internet technical
standards and protocols; with policy-development procedures, legal traditions,
and the public interest; and with the broad range of business, individual,
academic, and non-commercial users of the Internet;

5. Persons who are willing to serve as volunteers,
without compensation other than the reimbursement of certain expenses;
and

6. Persons who are able to work and communicate
in written and spoken English.

Section 4. ADDITIONAL QUALIFICATIONS

1. Notwithstanding anything herein to the contrary,
no official of a national government or a multinational entity established
by treaty or other agreement between national governments may serve as
a Director. As used herein, the term “official” means a person
(i) who holds an elective governmental office or (ii) who is employed
by such government or multinational entity and whose primary function
with such government or entity is to develop or influence governmental
or public policies.

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.

3. Persons serving in any capacity on the Nominating
Committee shall be ineligible for selection to positions on the Board
as provided by Article VII, Section 8.

Section 5. INTERNATIONAL REPRESENTATION

In order to ensure broad international representation on the Board,
the selection of Directors by the Nominating Committee and each Supporting
Organization shall comply with all applicable diversity provisions of
these Bylaws or of any Memorandum of Understanding referred to in these
Bylaws concerning the Supporting Organization. One intent of these diversity
provisions is to ensure that at all times each Geographic Region shall
have at least one Director, and at all times no region shall have more
than five Directors on the Board (not including the President). As used
in these Bylaws, each of the following is considered to be a “Geographic
Region”: Europe; Asia/Australia/Pacific; Latin America/Caribbean
islands; Africa; and North America. The specific countries included in
each Geographic Region shall be determined by the Board, and this Section
shall be reviewed by the Board from time to time (but at least every three
years) to determine whether any change is appropriate, taking account
of the evolution of the Internet.

Section 6. DIRECTORS' CONFLICTS OF INTEREST

The Board, through the Board Governance Committee, shall require a
statement from each Director not less frequently than once a year setting
forth all business and other affiliations that relate in any way to the
business and other affiliations of ICANN. Each Director shall be responsible
for disclosing to ICANN any matter that could reasonably be considered
to make such Director an “interested director” within the meaning
of Section 5233 of the California Nonprofit Public Benefit Corporation
Law (“CNPBCL”). In addition, each Director shall disclose to
ICANN any relationship or other factor that could reasonably be considered
to cause the Director to be considered to be an “interested person” within
the meaning of Section 5227 of the CNPBCL. The Board shall adopt policies
specifically addressing Director, Officer, and Supporting Organization
conflicts of interest. No Director shall vote on any matter in which he
or she has a material and direct financial interest that would be affected
by the outcome of the vote.

Section 7. DUTIES OF DIRECTORS

Directors shall serve as individuals who have the duty to act in what
they reasonably believe are the best interests of ICANN and not as representatives
of the entity that selected them, their employers, or any other organizations
or constituencies.

a. The regular terms of Seats 1 through 3 shall
begin at the conclusion of ICANN's annual meeting in 2003 and each ICANN
annual meeting every third year after 2003;

b. The regular terms of Seats 4 through 6 shall
begin at the conclusion of ICANN's annual meeting in 2004 and each ICANN
annual meeting every third year after 2004;

c. The regular terms of Seats 7 and 8 shall
begin at the conclusion of ICANN's annual meeting in 2005 and each ICANN
annual meeting every third year after 2005;

d. The regular terms of Seats 9 and 12 shall
begin on the day six months after the conclusion of ICANN's annual meeting
in 2002 and each ICANN annual meeting every third year after 2002;

e. The regular terms of Seats 10 and 13 shall
begin on the day six months after the conclusion of ICANN's annual meeting
in 2003 and each ICANN annual meeting every third year after 2003; and

f. The regular terms of Seats 11 and 14 shall
begin on the day six months after the conclusion of ICANN's annual meeting
in 2004 and each ICANN annual meeting every third year after 2004.

2. Each Director holding any of Seats 1 through
14, including a Director selected to fill a vacancy, shall hold office
for a term that lasts until the next term for that Seat commences and
until a successor has been selected and qualified or until that Director
resigns or is removed in accordance with these Bylaws.

3. At least one month before the commencement
of each annual meeting, the Nominating Committee shall give the Secretary
of ICANN written notice of its selection of Directors for seats with
terms beginning at the conclusion of the annual meeting.

4. No later than five months after the conclusion
of each annual meeting, any Supporting Organization entitled to select
a Director for a Seat with a term beginning on the day six months after
the conclusion of the annual meeting shall give the Secretary of ICANN
written notice of its selection.

5. Subject to the provisions of the Transition
Article of these Bylaws, no Director may serve more than three consecutive
terms. For these purposes, a person selected to fill a vacancy in a term
shall not be deemed to have served that term.

6. The term as Director of the person holding
the office of President shall be for as long as, and only for as long
as, such person holds the office of President.

2. Subject to the provisions of the Transition
Article of these Bylaws, the non-voting liaisons shall serve terms
that begin at the conclusion of each annual meeting. At least one month
before the commencement of each annual meeting, each body entitled to
appoint a non-voting liaison shall give the Secretary of ICANN written
notice of its appointment.

3. Non-voting liaisons shall serve as volunteers,
without compensation other than the reimbursement of certain expenses.

4. Each non-voting liaison may be reappointed,
and shall remain in that position until a successor has been appointed
or until the liaison resigns or is removed in accordance with these Bylaws.

5. The non-voting liaisons shall be entitled to
attend Board meetings, participate in Board discussions and deliberations,
and have access (under conditions established by the Board) to materials
provided to Directors for use in Board discussions, deliberations and
meetings, but shall otherwise not have any of the rights and privileges
of Directors. Non-voting liaisons shall be entitled (under conditions
established by the Board) to use any materials provided to them pursuant
to this Section for the purpose of consulting with their respective committee
or organization.

Section 10. RESIGNATION OF A DIRECTOR OR NON-VOTING
LIAISON

Subject to Section 5226 of the CNPBCL, any Director or non-voting liaison
may resign at any time, either by oral tender of resignation at any meeting
of the Board (followed by prompt written notice to the Secretary of ICANN)
or by giving written notice thereof to the President or the Secretary
of ICANN. Such resignation shall take effect at the time specified, and,
unless otherwise specified, the acceptance of such resignation shall not
be necessary to make it effective. The successor shall be selected pursuant
to Section 12 of this Article.

Section 11. REMOVAL OF A DIRECTOR OR NON-VOTING
LIAISON

1. Any Director may be removed, following notice
to that Director and, if selected by a Supporting Organization, to that
Supporting Organization, by a three-fourths (3/4) majority vote of all
Directors; provided, however, that the Director who is the subject of
the removal action shall not be entitled to vote on such an action or
be counted as a voting member of the Board when calculating the required
three-fourths (3/4) vote; and provided further, that each vote to remove
a Director shall be a separate vote on the sole question of the removal
of that particular Director.

2. With the exception of the non-voting liaison
appointed by the Governmental Advisory Committee, any non-voting liaison
may be removed, following notice to that liaison and to the organization
by which that liaison was selected, by a three-fourths (3/4) majority
vote of all Directors if the selecting organization fails to promptly
remove that liaison following such notice. The Board may request the
Governmental Advisory Committee to consider the replacement of the non-voting
liaison appointed by that Committee if the Board, by a three-fourths
(3/4) majority vote of all Directors, determines that such an action
is appropriate.

Section 12. VACANCIES

1. A vacancy or vacancies in the Board of Directors
shall be deemed to exist in the case of the death, resignation, or removal
of any Director; if the authorized number of Directors is increased;
or if a Director has been declared of unsound mind by a final order of
court or convicted of a felony or incarcerated for more than 90 days
as a result of a criminal conviction or has been found by final order
or judgment of any court to have breached a duty under Sections 5230
et seq. of the CNPBCL. Any vacancy occurring on the Board of Directors
shall be filled by the Nominating Committee, unless (a) that Director
was selected by a Supporting Organization, in which case that vacancy
shall be filled by that Supporting Organization, or (b) that Director
was the President, in which case the vacancy shall be filled in accordance
with the provisions of Article XIII of these Bylaws.
The selecting body shall give written notice to the Secretary of ICANN
of their appointments to fill vacancies. A Director selected to fill
a vacancy on the Board shall serve for the unexpired term of his or her
predecessor in office and until a successor has been selected and qualified.
No reduction of the authorized number of Directors shall have the effect
of removing a Director prior to the expiration of the Director's term
of office.

2. The organizations selecting the non-voting
liaisons identified in Section 9 of this Article are
responsible for determining the existence of, and filling, any vacancies
in those positions. They shall give the Secretary of ICANN written notice
of their appointments to fill vacancies.

Section 13. ANNUAL MEETINGS

Annual meetings of ICANN shall be held for the purpose of electing Officers
and for the transaction of such other business as may come before the
meeting. Each annual meeting for ICANN shall be held at the principal
office of ICANN, or any other appropriate place of the Board's time and
choosing, provided such annual meeting is held within 14 months of the
immediately preceding annual meeting. If the Board determines that it
is practical, the annual meeting should be distributed in real-time and
archived video and audio formats on the Internet.

Section 14. REGULAR MEETINGS

Regular meetings of the Board shall be held on dates to be determined
by the Board. In the absence of other designation, regular meetings shall
be held at the principal office of ICANN.

Section 15. SPECIAL MEETINGS

Special meetings of the Board may be called by or at the request of
one-quarter (1/4) of the members of the Board or by the Chairman of the
Board or the President. A call for a special meeting shall be made by
the Secretary of ICANN. In the absence of designation, special meetings
shall be held at the principal office of ICANN.

Section 16. NOTICE OF MEETINGS

Notice of time and place of all meetings shall be delivered personally
or by telephone or by electronic mail to each Director and non-voting
liaison, or sent by first-class mail (air mail for addresses outside the
United States) or facsimile, charges prepaid, addressed to each Director
and non-voting liaison at the Director's or non-voting liaison's address
as it is shown on the records of ICANN. In case the notice is mailed,
it shall be deposited in the United States mail at least fourteen (14)
days before the time of the holding of the meeting. In case the notice
is delivered personally or by telephone or facsimile or electronic mail
it shall be delivered personally or by telephone or facsimile or electronic
mail at least forty-eight (48) hours before the time of the holding of
the meeting. Notwithstanding anything in this Section to the contrary,
notice of a meeting need not be given to any Director who signed a waiver
of notice or a written consent to holding the meeting or an approval of
the minutes thereof, whether before or after the meeting, or who attends
the meeting without protesting, prior thereto or at its commencement,
the lack of notice to such Director. All such waivers, consents and approvals
shall be filed with the corporate records or made a part of the minutes
of the meetings.

Section 17. QUORUM

At all annual, regular, and special meetings of the Board, a majority
of the total number of Directors then in office shall constitute a quorum
for the transaction of business, and the act of a majority of the Directors
present at any meeting at which there is a quorum shall be the act of
the Board, unless otherwise provided herein or by law. If a quorum shall
not be present at any meeting of the Board, the Directors present thereat
may adjourn the meeting from time to time to another place, time, or date.
If the meeting is adjourned for more than twenty-four (24) hours, notice
shall be given to those Directors not at the meeting at the time of the
adjournment.

Section 18. ACTION BY TELEPHONE MEETING OR BY
OTHER COMMUNICATIONS EQUIPMENT

Members of the Board or any Committee of the Board may participate in
a meeting of the Board or Committee of the Board through use of (i) conference
telephone or similar communications equipment, provided that all Directors
participating in such a meeting can speak to and hear one another or (ii)
electronic video screen communication or other communication equipment;
provided that (a) all Directors participating in such a meeting can speak
to and hear one another, (b) all Directors are provided the means of fully
participating in all matters before the Board or Committee of the Board,
and (c) ICANN adopts and implements means of verifying that (x) a person
participating in such a meeting is a Director or other person entitled
to participate in the meeting and (y) all actions of, or votes by, the
Board or Committee of the Board are taken or cast only by the members
of the Board or Committee and not persons who are not members. Participation
in a meeting pursuant to this Section constitutes presence in person at
such meeting. ICANN shall make available at the place of any meeting of
the Board the telecommunications equipment necessary to permit members
of the Board to participate by telephone.

Section 19. ACTION WITHOUT MEETING

Any action required or permitted to be taken by the Board or a Committee
of the Board may be taken without a meeting if all of the Directors entitled
to vote thereat shall individually or collectively consent in writing
to such action. Such written consent shall have the same force and effect
as the unanimous vote of such Directors. Such written consent or consents
shall be filed with the minutes of the proceedings of the Board.

Section 20. ELECTRONIC MAIL

If permitted under applicable law, communication by electronic mail
shall be considered equivalent to any communication otherwise required
to be in writing. ICANN shall take such steps as it deems appropriate
under the circumstances to assure itself that communications by electronic
mail are authentic.

Section 21. RIGHTS OF INSPECTION

Every Director shall have the right at any reasonable time to inspect
and copy all books, records and documents of every kind, and to inspect
the physical properties of ICANN. ICANN shall establish reasonable procedures
to protect against the inappropriate disclosure of confidential information.

Section 22. COMPENSATION

The Chair of the ICANN Board shall be entitled to receive reasonable compensation for his/her services as a Director. The compensation committee shall be responsible for recommending a reasonable level of compensation for the Board Chair. Only those members of the Compensation Committee that are free from conflicts of interest with respect to the party for whom compensation is under consideration shall participate in the deliberations or voting on the recommendation to the Board. Only those members of the Board that are free from conflicts of interest with respect to the party for whom compensation is under consideration shall participate in the deliberations or voting on the approval of compensation for the Board Chair. At no time shall the Board Chair participate in deliberations or voting on compensation for the Board Chair. The Compensation Committee and the Board shall follow appropriate processes set forth in the United States Internal Revenue Code and applicable Treasury Regulations to ensure that there is a rebuttable presumption of reasonable compensation established for the Board Chair.

All Directors other than the Board Chair shall receive no compensation for their services as Directors. The Board may, however, authorize the reimbursement of actual and necessary reasonable expenses incurred by any Directors and non-voting liaisons performing their duties as Directors or non-voting liaisons.

Section 23. PRESUMPTION OF ASSENT

A Director present at a Board meeting at which action on any corporate
matter is taken shall be presumed to have assented to the action taken
unless his or her dissent or abstention is entered in the minutes of the
meeting, or unless such Director files a written dissent or abstention
to such action with the person acting as the secretary of the meeting
before the adjournment thereof, or forwards such dissent or abstention
by registered mail to the Secretary of ICANN immediately after the adjournment
of the meeting. Such right to dissent or abstain shall not apply to a
Director who voted in favor of such action.

ARTICLE VII: NOMINATING COMMITTEE

Section 1. DESCRIPTION

There shall be a Nominating Committee of ICANN, responsible for the
selection of all ICANN Directors except the President and those Directors
selected by ICANN's Supporting Organizations, and for such other selections
as are set forth in these Bylaws.

9. A non-voting Associate Chair, who may be appointed
by the Chair, at his or her sole discretion, to serve during all or part
of the term of the Chair. The Associate Chair may not be a person who
is otherwise a member of the same Nominating Committee. The Associate
Chair shall assist the Chair in carrying out the duties of the Chair,
but shall not serve, temporarily or otherwise, in the place of the Chair.

1. Each voting delegate shall serve a one-year
term. A delegate may serve at most two successive one-year terms, after
which at least two years must elapse before the individual is eligible
to serve another term.

2. The regular term of each voting delegate shall
begin at the conclusion of an ICANN annual meeting and shall end at the
conclusion of the immediately following ICANN annual meeting.

3. Non-voting liaisons shall serve
during the term designated by the entity that appoints them. The Chair,
the immediately previous Chair serving as an advisor, and any Associate
Chair shall serve as such until the conclusion of the next ICANN annual
meeting.

4. Vacancies in the positions of
delegate, non-voting liaison, or Chair shall be filled by the entity
entitled to select the delegate, non-voting liaison, or Chair involved.
A vacancy in the position of non-voting advisor (immediately previous
Chair) may be filled by the Board from among persons with prior service
on the Board or a Nominating Committee. A vacancy in the position of
Associate Chair may be filled by the Chair in accordance with the criteria
established by Section 2(9) of this Article.

5. The existence of any vacancies shall not affect
the obligation of the Nominating Committee to carry out the responsibilities
assigned to it in these Bylaws.

Section 4. CRITERIA FOR SELECTION OF NOMINATING
COMMITTEE DELEGATES

Delegates to the ICANN Nominating Committee shall be:

1. Accomplished persons of integrity, objectivity,
and intelligence, with reputations for sound judgment and open minds,
and with experience and competence with collegial large group decision-making;

2. Persons with wide contacts, broad experience
in the Internet community, and a commitment to the success of ICANN;

3. Persons whom the selecting body is confident
will consult widely and accept input in carrying out their responsibilities;

4. Persons who are neutral and objective, without
any fixed personal commitments to particular individuals, organizations,
or commercial objectives in carrying out their Nominating Committee responsibilities;

5. Persons with an understanding of ICANN's mission
and the potential impact of ICANN's activities on the broader Internet
community who are willing to serve as volunteers, without compensation
other than the reimbursement of certain expenses; and

6. Persons who are able to work and communicate
in written and spoken English.

Section 5. DIVERSITY

In carrying out its responsibilities to select members of the ICANN
Board (and selections to any other ICANN bodies as the Nominating Committee
is responsible for under these Bylaws), the Nominating Committee shall
take into account the continuing membership of the ICANN Board (and such
other bodies), and seek to ensure that the persons selected to fill vacancies
on the ICANN Board (and each such other body) shall, to the extent feasible
and consistent with the other criteria required to be applied by Section
4 of this Article, make selections guided by Core Value 4 in Article
I, Section 2 .

Section 6. ADMINISTRATIVE AND OPERATIONAL SUPPORT

ICANN shall provide administrative and operational support necessary
for the Nominating Committee to carry out its responsibilities.

Section 7. PROCEDURES

The Nominating Committee shall adopt such operating procedures as it
deems necessary, which shall be published on the Website.

Section 8. INELIGIBILITY FOR SELECTION BY NOMINATING
COMMITTEE

No person who serves on the Nominating Committee in any capacity shall
be eligible for selection by any means to any position on the Board or
any other ICANN body having one or more membership positions that the
Nominating Committee is responsible for filling, until the conclusion
of an ICANN annual meeting that coincides with, or is after, the conclusion
of that person's service on the Nominating Committee.

Section 9. INELIGIBILITY FOR SERVICE ON NOMINATING
COMMITTEE

No person who is an employee of or paid consultant to ICANN (including
the Ombudsman) shall simultaneously serve in any of the Nominating Committee
positions described in Section 2 of this Article.

ARTICLE VIII: ADDRESS SUPPORTING ORGANIZATION

Section 1. DESCRIPTION

1. The Address Supporting Organization (ASO)
shall advise the Board with respect to policy issues relating to the
operation, assignment, and management of Internet addresses.

2. The ASO shall be the entity established by
the Memorandum of Understanding entered on 21 October 2004 between ICANN
and the Number Resource Organization (NRO), an organization of the existing
regional Internet registries (RIRs).

Section 2. ADDRESS COUNCIL

1. The ASO shall have an Address Council, consisting
of the members of the NRO Number Council.

2. The Address Council shall select Directors
to those seats on the Board designated to be filled by the ASO.

ARTICLE IX: COUNTRY-CODE NAMES SUPPORTING ORGANIZATION

Section 1. DESCRIPTION

There shall be a policy-development body known as the Country-Code Names
Supporting Organization (ccNSO), which shall be responsible for:

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.

Policies that apply to ccNSO members by virtue of their membership
are only those policies developed according to section 4.10 and 4.11 of
this Article. However, the ccNSO may also engage in other activities authorized
by its members. Adherence to the results of these activities will be voluntary
and such activities may include: seeking to develop voluntary best practices
for ccTLD managers, assisting in skills building within the global community
of ccTLD managers, and enhancing operational and technical cooperation
among ccTLD managers.

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.

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 Council 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 Council 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 Council 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 Council Chair.

6. ccNSO Council members may be removed for not
attending three consecutive meetings of the ccNSO Council without sufficient
cause or for grossly 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 Council Chair.
Vacancies in the positions of the ccNSO Council members selected by ccNSO
members shall be filled for the unexpired term 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 meetings,
including 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 Council
Chair in writing to the ICANN Secretary, consistent with Article VI, Sections
8(4) and 12(1).

10. The ccNSO Council shall select from among
its members the ccNSO Council Chair and such Vice Chair(s) as it deems
appropriate. Selections of the ccNSO Council 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 Council 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 Council Chair or any
Vice Chair(s) may be recalled from office by the same procedure as used
for selection.

11. The ccNSO Council, subject to direction by
the ccNSO members, shall adopt such rules and procedures for the ccNSO
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 be held in
conjunction 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 day 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 day 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) all 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”,
or under any later variant, 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 of the ccNSO, including membership
rules, (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. Upon resignation the ccTLD manager ceases to agree to
(a) adhere to rules of the ccNSO, including membership rules, (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. 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. Any individual relationship a ccTLD manager has with
ICANN or the ccTLD manager's receipt of IANA services is not in any way
contingent upon membership in the ccNSO.

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 ccTLD managers that are not members of the ccNSO as well as other
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
be held in conjunction 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 entitled to vote 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 Council Chair shall provide the ICANN Secretary prompt written
notice of the selection of ccNSO Council members under this paragraph.

10. Subject to clause 4(11), ICANN policies shall
apply to ccNSO members by virtue of their membership to the extent, and
only to the extent, that the policies (a) only address issues that are
within scope of the ccNSO according to Article IX, Section 6 and Annex
C; (b) have been developed through the ccPDP as described in Section
6 of this Article, and (c) have been recommended as such by the ccNSO
to the Board, and (d) are adopted by the Board as policies, provided
that such policies do not conflict with the law applicable to the ccTLD
manager which shall, at all times, remain paramount. In addition, such
policies shall apply to ICANN in its activities concerning ccTLDs.

11. A ccNSO member shall not be bound if it provides
a declaration to the ccNSO Council stating that (a) implementation of
the policy would require the member to breach custom, religion, or public
policy (not embodied in the applicable law described in paragraph
10 of this Section), and (b) failure to implement the policy would
not impair DNS operations or interoperability, giving detailed reasons
supporting its statements. After investigation, the ccNSO Council will
provide a response to the ccNSO member's declaration. If there is a ccNSO
Council consensus disagreeing with the declaration, which may be demonstrated
by a vote of 14 or more members of the ccNSO Council, the response shall
state the ccNSO Council's disagreement with the declaration and the reasons
for disagreement. Otherwise, the response shall state the ccNSO Council's
agreement with the declaration. If the ccNSO Council disagrees, the ccNSO
Council shall review the situation after a six-month period. At the end
of that period, the ccNSO Council shall make findings as to (a) whether
the ccNSO members' implementation of the policy would require the member
to breach custom, religion, or public policy (not embodied in the applicable
law described in paragraph 10 of this Section)
and (b) whether failure to implement the policy would impair DNS operations
or interoperability. In making any findings disagreeing with the declaration,
the ccNSO Council shall proceed by consensus, which may be demonstrated
by a vote of 14 or more members of the ccNSO Council.

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. The scope of the ccNSO's policy-development
role shall be as stated in Annex C to these Bylaws;
any modifications to the scope 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. In developing global 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 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.

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, as approved by the ccNSO members.

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 1. DESCRIPTION

There shall be a policy-development body known as the Generic Names
Supporting Organization (GNSO), which shall be responsible for developing
and recommending to the ICANN Board substantive policies relating to
generic top-level domains.

Section 2. ORGANIZATION

The GNSO shall consist of:

(i) A number of Constituencies, where applicable, organized within
the Stakeholder Groups as described in Section 5 of this
Article;

(iv) a GNSO Council responsible for
managing the policy development process of the GNSO, as described
in
Section 3 of this Article.

Except as otherwise defined in these Bylaws, the four Stakeholder Groups
and the Constituencies will be responsible
for defining their own charters with the approval of their members
and of the ICANN Board of Directors.

a. three representatives
selected from the Registries Stakeholder Group;

b. three representatives selected from the Registrars Stakeholder
Group;

c. six representatives selected from the Commercial Stakeholder
Group;

d. six representatives selected from the Non-Commercial Stakeholder
Group; and

e.
three representatives selected by the ICANN Nominating Committee, one of
which shall be non-voting, but otherwise entitled to participate on equal
footing with other members of the GNSO Council including, e.g. the making
and seconding of motions and of serving as Chair if elected. One Nominating
Committee Appointee voting representative shall be assigned to each House
(as described in Section
3(8) of this Article) by the Nominating Committee.

No individual representative may hold more
than one seat on the GNSO Council at the same time.

Stakeholder
Groups should, in their charters, ensure their representation
on the GNSO Council is as diverse as
possible and practicable, including considerations of geography,
GNSO Constituency, sector, ability and gender.

There may also be
liaisons to the GNSO Council from other ICANN Supporting Organizations
and/or Advisory
Committees, from time to time. The appointing organization
shall designate, revoke, or change its liaison on the
GNSO Council by providing written notice to the Chair of the
GNSO Council and to the ICANN Secretary.
Liaisons shall not be members of or entitled to vote, to make
or second motions, or to serve as an officer on the
GNSO Council, but otherwise liaisons shall be entitled to participate
on equal footing with members of the GNSO
Council.

2.
Subject to the provisions of the Transition
Article XX, and Section 5 of these Bylaws, the regular term of each
GNSO Council member shall begin at the conclusion of an ICANN annual meeting
and shall end at the conclusion of the second ICANN annual meeting thereafter.
The regular term of two representatives selected from Stakeholder Groups
with three Council seats shall begin in even-numbered years and the regular
term of the other representative selected from that Stakeholder Group shall
begin in odd-numbered years. The regular term of three representatives
selected from Stakeholder Groups with six Council seats shall begin in
even-numbered years and the regular term of the other three representatives
selected from that Stakeholder Group shall begin in odd-numbered years.
The regular term of one of the three members selected by the Nominating
Committee shall begin in even-numbered years and the regular term of the
other two of the three members selected by the Nominating Committee shall
begin in odd-numbered years. Each GNSO 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.

Except in
a “special circumstance,” such as, but not limited to, meeting
geographic or other diversity requirements defined in the Stakeholder
Group charters, where no alternative representative is available to serve,
no Council member may be selected to serve more than two consecutive
terms, in such a special circumstance a Council member may serve one
additional term. For these purposes, a person selected to fill a vacancy
in a term shall not be deemed to have served that term. A former Council
member who has served two consecutive terms must remain out of office
for one full term prior to serving any subsequent term as Council member.
A “special circumstance” is defined in the GNSO Operating Procedures.

3. A vacancy on the GNSO Council shall be deemed
to exist in the case of the death, resignation, or removal of any member.
Vacancies shall be filled for the unexpired term by the appropriate Nominating
Committee or Stakeholder Group that selected the member holding the position
before the vacancy occurred by giving the GNSO Secretariat written notice
of its selection. Procedures for handling Stakeholder Group-appointed
GNSO Council member vacancies, resignations, and removals are prescribed
in the applicable Stakeholder Group Charter.

A GNSO Council member selected by the Nominating Committee may be removed
for cause: i) stated by a three-fourths (3/4) vote of all members of the
applicable House to which the Nominating Committee appointee is assigned;
or ii) stated by a three-fourths (3/4) vote of all members of each House
in the case of the non-voting Nominating Committee appointee (see Section
3(8) of this Article). Such removal shall be subject to reversal by
the ICANN Board on appeal by the affected GNSO Council member.

4.
The GNSO Council is responsible for managing the policy development process
of the GNSO. It shall adopt such procedures (the “GNSO Operating Procedures”)
as it sees fit to carry out that responsibility, provided that such procedures
are approved by a majority vote of each House. The GNSO Operating Procedures
shall be effective upon the expiration of a twenty-one (21) day public
comment period, and shall be subject to Board oversight and review. Until
any modifications are recommended by the GNSO Council, the applicable procedures
shall be as set forth in Section
6 of this Article.

5. No more than one officer, director or employee
of any particular corporation or other organization (including its subsidiaries
and affiliates) shall serve on the GNSO Council at any given time.

6. The GNSO shall make selections to fill Seats
13 and 14 on the ICANN Board by written ballot or by action at
a meeting. Each of the two voting Houses of the GNSO, as described in
Section 3(8) of this Article, shall make a selection to fill one of two
ICANN Board seats, as outlined below; any such selection must have affirmative
votes compromising sixty percent (60%) of all the respective voting House
members:

a. the Contracted Party House shall select a representative to
fill Seat 13; and

b. the Non-Contracted Party House shall select
a representative to fill Seat 14

Election procedures are defined
in the GNSO Operating Procedures.

Notification of the Board seat selections shall be given by the GNSO
Chair in writing to the ICANN Secretary, consistent with Article
VI, Sections 8(4) and 12(1).

7.
The GNSO Council shall select the GNSO Chair for a term the GNSO Council
specifies, but not longer than one year. Each House (as described in Section
3.8 of this Article) shall select a Vice-Chair, who will be a Vice-Chair
of the whole of the GNSO Council, for a term the GNSO Council specifies,
but not longer than one year. The procedures for selecting the Chair and
any other officers are contained in the GNSO Operating Procedures. In the
event that the GNSO Council has not elected a GNSO Chair by the end of
the previous Chair's term, the Vice-Chairs will serve as Interim GNSO Co-Chairs
until a successful election can be held.

8. Except as otherwise required in these Bylaws,
for voting purposes, the GNSO Council (see Section 3(1) of this
Article) shall be organized into a bicameral House structure as
described below:

a. the Contracted Parties House includes the Registries Stakeholder
Group (three members), the Registrars
Stakeholder Group (three members), and one voting member appointed
by the ICANN Nominating
Committee for a total of seven voting members; and

b. the Non Contracted Parties House includes the Commercial
Stakeholder Group (six members), the Non-Commercial Stakeholder
Group (six members), and one voting member appointed by the ICANN Nominating
Committee to that House for a total of thirteen voting members.

Except as otherwise specified in these Bylaws, each member
of a voting House is entitled to cast one vote in each
separate matter before the GNSO Council.

9. Except as otherwise specified in these Bylaws,
Annex A hereto, or the GNSO Operating Procedures, the default
threshold to pass a GNSO Council motion or other voting action
requires a simple majority vote of each House.
The voting thresholds described below shall apply to the following
GNSO actions:

a. Create an Issues Report: requires an affirmative vote of more
than 25% vote of each House or majority of one
House;

b. Initiate a Policy Development Process (“PDP”) Within Scope (as
described in Annex A): requires an
affirmative vote of more than 33% of each House or more than 66%
of one House;

c. Initiate a PDP Not Within Scope:
requires an affirmative vote of more than 75% of one House and
a majority of the other House (“GNSO Supermajority”);

d. Approve a PDP Recommendation Without a GNSO Supermajority: requires
an affirmative vote of a majority
of each House and further requires that one GNSO Council member
representative of at least 3 of the 4
Stakeholder Groups supports the Recommendation;

e. Approve a PDP Recommendation With a GNSO Supermajority:
requires an affirmative vote of a GNSO
Supermajority; and

f. Approve a PDP Recommendation Imposing New Obligations on
Certain Contracting Parties: where an
ICANN contract provision specifies that “a two-thirds vote
of the council” demonstrates the presence of a
consensus, the GNSO Supermajority vote threshold will have
to be met or exceeded with respect to any
contracting party affected by such contract provision.

Section 4. STAFF SUPPORT AND FUNDING

1. A member of the ICANN staff shall be assigned
to support the GNSO, whose work on substantive matters shall be assigned
by the Chair of the GNSO Council, and shall be designated as the GNSO
Staff Manager (Staff Manager).

2.
ICANN shall provide administrative and operational support necessary for
the GNSO to carry out its responsibilities. Such support shall not include
an obligation for ICANN to fund travel expenses incurred by GNSO participants
for travel to any meeting of the GNSO or for any other purpose. ICANN may,
at its discretion, fund travel expenses for GNSO participants under any
travel support procedures or guidelines that it may adopt from time to
time.

3. Each Stakeholder Group identified in paragraph
1 of this Section and each of its associated Constituencies, where applicable,
shall maintain recognition with the ICANN Board. Recognition is granted
by the Board based upon the extent to which, in fact, the entity represents
the global interests of the stakeholder communities it purports to represent
and operates to the maximum extent feasible in an open and transparent
manner consistent with procedures designed to ensure fairness. Stakeholder
Group and Constituency Charters may be reviewed periodically as prescribed
by the Board.

4. Any group of individuals or entities may petition
the Board for recognition as a new or separate Constituency in
the Non-Contracted Parties House. Any such petition shall contain:

a. A detailed explanation of why the addition of such a Constituency
will improve the ability of the GNSO to
carry out its policy-development responsibilities;

b. A detailed explanation of why the proposed new Constituency
adequately represents, on a global basis, the
stakeholders it seeks to represent;

c. A recommendation for organizational placement within a particular
Stakeholder Group; and

d. A proposed charter that adheres to the principles and procedures
contained in these Bylaws.

Any petition for the recognition of a new Constituency and
the associated charter shall be posted for public
comment.

5. The Board may create new Constituencies as described
in Section 5(3) in response to such a petition, or on its own motion,
if the Board determines that such action would serve the purposes of
ICANN. In the event the Board is considering acting on its own motion
it shall post a detailed explanation of why such action is necessary
or desirable, set a reasonable time for public comment, and not make
a final decision on whether to create such new Constituency until after
reviewing all comments received. Whenever the Board posts a petition
or recommendation for a new Constituency for public comment, the Board
shall notify the GNSO Council and the appropriate Stakeholder Group affected
and shall consider any response to that notification prior to taking
action.

Section 6. POLICY DEVELOPMENT PROCESS

The policy-development procedures to be followed by the GNSO shall be
as stated in Annex A to these Bylaws. These procedures may be supplemented
or revised in the manner stated in Section 3(4) of this Article.

ARTICLE XI: ADVISORY COMMITTEES

Section 1. GENERAL

The Board may create one or more Advisory Committees in addition to
those set forth in this Article. Advisory Committee membership may consist
of Directors only, Directors and non-directors, or non-directors only,
and may also include non-voting or alternate members. Advisory Committees
shall have no legal authority to act for ICANN, but shall report their
findings and recommendations to the Board.

Section 2. SPECIFIC ADVISORY COMMITTEES

There shall be at least the following Advisory Committees:

1. Governmental Advisory Committee

a. The Governmental Advisory Committee should
consider and provide advice on the activities of ICANN as they relate
to concerns of governments, particularly matters where there may be
an interaction between ICANN's policies and various laws and international
agreements or where they may affect public policy issues.

b. Membership in the Governmental Advisory Committee
shall be open to all national governments. Membership shall also be
open to Distinct Economies as recognized in international fora, and
multinational governmental organizations and treaty organizations, on
the invitation of the Governmental Advisory Committee through its Chair.

c. The Governmental Advisory Committee may adopt
its own charter and internal operating principles or procedures to guide
its operations, to be published on the Website.

d. The chair of the Governmental Advisory Committee
shall be elected by the members of the Governmental Advisory Committee
pursuant to procedures adopted by such members.

e. Each member of the Governmental Advisory
Committee shall appoint one accredited representative to the Committee.
The accredited representative of a member must hold a formal official
position with the member's public administration. The term “official” includes
a holder of an elected governmental office, or a person who is employed
by such government, public authority, or multinational governmental
or treaty organization and whose primary function with such government,
public authority, or organization is to develop or influence governmental
or public policies.

f. The Governmental Advisory Committee shall
annually appoint one non-voting liaison to the ICANN Board of Directors,
without limitation on reappointment, and shall annually appoint one
non-voting liaison to the ICANN Nominating Committee.

g. The Governmental Advisory Committee may designate
a non-voting liaison to each of the Supporting Organization Councils
and Advisory Committees, to the extent the Governmental Advisory Committee
deems it appropriate and useful to do so.

h. The Board shall notify the Chair of the Governmental
Advisory Committee in a timely manner of any proposal raising public
policy issues on which it or any of ICANN's supporting organizations
or advisory committees seeks public comment, and shall take duly into
account any timely response to that notification prior to taking action.

i. The Governmental Advisory Committee may put
issues to the Board directly, either by way of comment or prior advice,
or by way of specifically recommending action or new policy development
or revision to existing policies.

j. The advice of the Governmental Advisory Committee
on public policy matters shall be duly taken into account, both in the
formulation and adoption of policies. In the event that the ICANN Board
determines to take an action that is not consistent with the Governmental
Advisory Committee advice, it shall so inform the Committee and state
the reasons why it decided not to follow that advice. The Governmental
Advisory Committee and the ICANN Board will then try, in good faith
and in a timely and efficient manner, to find a mutually acceptable
solution.

k. If no such solution can be found, the ICANN
Board will state in its final decision the reasons why the Governmental
Advisory Committee advice was not followed, and such statement will
be without prejudice to the rights or obligations of Governmental Advisory
Committee members with regard to public policy issues falling within
their responsibilities.

2. Security and Stability Advisory Committee

a. The role of the Security and Stability Advisory
Committee (“SSAC”) is to advise the ICANN community and Board
on matters relating to the security and integrity of the Internet's
naming and address allocation systems. It shall have the following responsibilities:

1. To develop a security framework for Internet
naming and address allocation services that defines the key focus areas,
and identifies where the responsibilities for each area lie. The committee
shall focus on the operational considerations of critical naming infrastructure.

2. To communicate on security matters with
the Internet technical community and the operators and managers of
critical DNS infrastructure services, to include the root name server
operator community, the top-level domain registries and registrars,
the operators of the reverse delegation trees such as in-addr.arpa
and ip6.arpa, and others as events and developments dictate. The Committee
shall gather and articulate requirements to offer to those engaged
in technical revision of the protocols related to DNS and address allocation
and those engaged in operations planning.

3. To engage in ongoing threat assessment
and risk analysis of the Internet naming and address allocation services
to assess where the principal threats to stability and security lie,
and to advise the ICANN community accordingly. The Committee shall
recommend any necessary audit activity to assess the current status
of DNS and address allocation security in relation to identified risks
and threats.

4. To communicate with those who have direct
responsibility for Internet naming and address allocation security
matters (IETF, RSSAC, RIRs, name registries, etc.), to ensure that
its advice on security risks, issues, and priorities is properly synchronized
with existing standardization, deployment, operational, and coordination
activities. The Committee shall monitor these activities and inform
the ICANN community and Board on their progress, as appropriate.

5. To report periodically to the Board on
its activities.

6. To make policy recommendations to the ICANN
community and Board.

b. The SSAC's chair and members shall be appointed by the Board. SSAC membership appointment shall be for a three-year term, commencing on 1 January and ending the second year thereafter on 31 December. The chair and members may be re-appointed, and there are no limits to the number of terms the chair or members may serve. The SSAC chair may provide recommendations to the Board regarding appointments to the SSAC. The SSAC chair shall stagger appointment recommendations so that approximately one-third (1/3) of the membership of the SSAC is considered for appointment or re-appointment each year. (Note: The first full term under this paragraph shall commence on 1 January 2011 and end on 31 December 2013. Prior to 1 January 2011, the SSAC shall be comprised as stated in the Bylaws as amended 25 June 2010, and the SSAC chair shall recommend the re-appointment of all current SSAC members to full or partial terms as appropriate to implement the provisions of this paragraph.)

a. The role of the Root Server System Advisory
Committee (“RSSAC”) shall be to advise the Board about the
operation of the root name servers of the domain name system. The RSSAC
shall consider and provide advice on the operational requirements of
root name servers, including host hardware capacities, operating systems
and name server software versions, network connectivity and physical
environment. The RSSAC shall examine and advise on the security aspects
of the root name server system. Further, the RSSAC shall review the
number, location, and distribution of root name servers considering
the total system performance, robustness, and reliability.

b. Membership in the RSSAC shall consist of
(i) each operator of an authoritative root name server (as listed at <ftp://ftp.internic.net/domain/named.root>),
and (ii) such other persons as are appointed by the ICANN Board.

c. The initial chairman of the DNS Root Server
System Advisory Committee shall be appointed by the Board; subsequent
chairs shall be elected by the members of the DNS Root Server System
Advisory Committee pursuant to procedures adopted by the members.

d. The Root Server System Advisory Committee
shall annually appoint one non-voting liaison to the ICANN Board of
Directors, without limitation on re-appointment, and shall annually
appoint one non-voting liaison to the ICANN Nominating Committee.

4. At-Large Advisory Committee

a. The role of the At-Large Advisory Committee
(“ALAC”) shall be to consider and provide advice on the activities
of ICANN, insofar as they relate to the interests of individual Internet
users.

b. The ALAC shall consist of (i) two members
selected by each of the Regional At-Large Organizations (“RALOs”)
established according to paragraph 4(g) of this Section,
and (ii) five members selected by the Nominating Committee. The five
members selected by the Nominating Committee shall include one citizen
of a country within each of the five Geographic Regions established
according to Section 5 of Article VI.

1. The term of one member selected by each
RALO shall begin at the conclusion of an ICANN annual meeting in an
even-numbered year.

2. The term of the other member selected by
each RALO shall begin at the conclusion of an ICANN annual meeting
in an odd-numbered year.

3. The terms of three of the members selected
by the Nominating Committee shall begin at the conclusion of an annual
meeting in an odd-numbered year and the terms of the other two members
selected by the Nominating Committee shall begin at the conclusion
of an annual meeting in an even-numbered year.

4. The regular term of each member shall end
at the conclusion of the second ICANN annual meeting after the term
began.

d. The Chair of the ALAC shall be elected by
the members of the ALAC pursuant to procedures adopted by the Committee.

e. The ALAC shall annually appoint one non-voting
liaison to the ICANN Board of Directors, without limitation on re-appointment,
and shall, after consultation with each RALO, annually appoint five
voting delegates (no two of whom shall be citizens of countries in the
same Geographic Region, as defined according to Section
5 of Article VI) to the Nominating Committee.

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.

g. There shall be one RALO for each Geographic
Region established according to Section 5 of Article
VI. Each RALO shall serve as the main forum and coordination point
for public input to ICANN in its Geographic Region and shall be a non-profit
organization certified by ICANN according to criteria and standards
established by the Board based on recommendations of the At-Large Advisory
Committee. An organization shall become the recognized RALO for its
Geographic Region upon entering a Memorandum of Understanding with ICANN
addressing the respective roles and responsibilities of ICANN and the
RALO regarding the process for selecting ALAC members and requirements
of openness, participatory opportunities, transparency, accountability,
and diversity in the RALO's structure and procedures, as well as criteria
and standards for the RALO's constituent At-Large Structures.

h. Each RALO shall be comprised of self-supporting
At-Large Structures within its Geographic Region that have been certified
to meet the requirements of the RALO's Memorandum of Understanding with
ICANN according to paragraph 4(i) of this Section.
If so provided by its Memorandum of Understanding with ICANN, a RALO
may also include individual Internet users who are citizens or residents
of countries within the RALO's Geographic Region.

i. Membership in the At-Large Community

The criteria and standards for the certification of At-Large Structures
within each Geographic Region shall be established by the Board based
on recommendations from the ALAC and shall be stated in the Memorandum
of Understanding between ICANN and the RALO for each Geographic Region.

The criteria and standards for the certification of At-Large Structures
shall be established in such a way that participation by individual
Internet users who are citizens or residents of countries within the
Geographic Region (as defined in Section
5 of Article VI) of the RALO will predominate in the operation
of each At-Large Structure within the RALO, while not necessarily excluding
additional participation, compatible with the interests of the individual
Internet users within the region, by others.

Each RALO's Memorandum of Understanding shall also include provisions
designed to allow, to the greatest extent possible, every individual
Internet user who is a citizen of a country within the RALO's Geographic
Region to participate in at least one of the RALO's At-Large Structures.

To the extent compatible with these objectives, the criteria and
standards should also afford to each RALO the type of structure that
best fits the customs and character of its Geographic Region.

Once the criteria and standards have been established as provided
in this Clause i, the ALAC, with the advice and participation of the
RALO where the applicant is based, shall be responsible for certifying
organizations as meeting the criteria and standards for At-Large Structure
accreditation.

Decisions to certify or decertify an At-Large Structure shall be
made as decided by the ALAC in its Rules of Procedure, save always
that any changes made to the Rules of Procedure in respect of ALS applications
shall be subject to review by the RALOs and by the ICANN Board.

Decisions as to whether to accredit, not to accredit, or disaccredit
an At-Large Structure shall be subject to review according to procedures
established by the Board.

On an ongoing basis, the ALAC may also give advice as to whether
a prospective At-Large Structure meets the applicable criteria and
standards.

j. The ALAC is also responsible, working in
conjunction with the RALOs, for coordinating the following activities:

1. Keeping the community of individual Internet
users informed about the significant news from ICANN;

2. Distributing (through posting or otherwise)
an updated agenda, news about ICANN, and information about items in
the ICANN policy-development process;

3. Promoting outreach activities in the community
of individual Internet users;

5. Establishing an outreach strategy about
ICANN issues in each RALO's Region;

6. Making public, and analyzing, ICANN's proposed
policies and its decisions and their (potential) regional impact and
(potential) effect on individuals in the region;

7. Offering Internet-based mechanisms that
enable discussions among members of At-Large structures; and

8. Establishing mechanisms and processes that
enable two-way communication between members of At-Large Structures
and those involved in ICANN decision-making, so interested individuals
can share their views on pending ICANN issues.

Section 3. PROCEDURES

Each Advisory Committee shall determine its own rules of procedure and
quorum requirements.

Section 4. TERM OF OFFICE

The chair and each member of a committee shall serve until his or her
successor is appointed, or until such committee is sooner terminated,
or until he or she is removed, resigns, or otherwise ceases to qualify
as a member of the committee.

Section 5. VACANCIES

Vacancies on any committee shall be filled in the same manner as provided
in the case of original appointments.

Section 6. COMPENSATION

Committee members shall receive no compensation for their services as
a member of a committee. The Board may, however, authorize the reimbursement
of actual and necessary expenses incurred by committee members, including
Directors, performing their duties as committee members.

ARTICLE XI-A: OTHER ADVISORY MECHANISMS

Section 1. EXTERNAL EXPERT ADVICE

1. Purpose. The purpose of seeking external
expert advice is to allow the policy-development process within ICANN
to take advantage of existing expertise that resides in the public or
private sector but outside of ICANN. In those cases where there are relevant
public bodies with expertise, or where access to private expertise could
be helpful, the Board and constituent bodies should be encouraged to
seek advice from such expert bodies or individuals.

2. Types of Expert Advisory Panels.

a. On its own initiative or at the suggestion
of any ICANN body, the Board may appoint, or authorize the President
to appoint, Expert Advisory Panels consisting of public or private sector
individuals or entities. If the advice sought from such Panels concerns
issues of public policy, the provisions of Section
1(3)(b) of this Article shall apply.

b. In addition, in accordance with Section
1(3) of this Article, the Board may refer issues of public policy
pertinent to matters within ICANN's mission to a multinational governmental
or treaty organization.

3. Process for Seeking Advice-Public Policy
Matters.

a. The Governmental Advisory Committee may
at any time recommend that the Board seek advice concerning one or more
issues of public policy from an external source, as set out above.

b. In the event that the Board determines,
upon such a recommendation or otherwise, that external advice should
be sought concerning one or more issues of public policy, the Board
shall, as appropriate, consult with the Governmental Advisory Committee
regarding the appropriate source from which to seek the advice and the
arrangements, including definition of scope and process, for requesting
and obtaining that advice.

c. The Board shall, as appropriate, transmit
any request for advice from a multinational governmental or treaty organization,
including specific terms of reference, to the Governmental Advisory
Committee, with the suggestion that the request be transmitted by the
Governmental Advisory Committee to the multinational governmental or
treaty organization.

4. Process for Seeking and Advice-Other Matters.
Any reference of issues not concerning public policy to an Expert Advisory
Panel by the Board or President in accordance with Section
1(2)(a) of this Article shall be made pursuant to terms of reference
describing the issues on which input and advice is sought and the procedures
and schedule to be followed.

5. Receipt of Expert Advice and its Effect.
External advice pursuant to this Section shall be provided in written
form. Such advice is advisory and not binding, and is intended to augment
the information available to the Board or other ICANN body in carrying
out its responsibilities.

6. Opportunity to Comment. The Governmental
Advisory Committee, in addition to the Supporting Organizations and other
Advisory Committees, shall have an opportunity to comment upon any external
advice received prior to any decision by the Board.

Section 2. TECHNICAL LIAISON GROUP

1. Purpose. The quality of ICANN's work depends
on access to complete and authoritative information concerning the technical
standards that underlie ICANN's activities. ICANN's relationship to the
organizations that produce these standards is therefore particularly
important. The Technical Liaison Group (TLG) shall connect the Board
with appropriate sources of technical advice on specific matters pertinent
to ICANN's activities.

2. TLG Organizations. The TLG shall consist
of four organizations: the European Telecommunications Standards Institute
(ETSI), the International Telecommunications Union's Telecommunication
Standardization Sector (ITU-T), the World Wide Web Consortium (W3C),
and the Internet Architecture Board (IAB).

3. Role. The role of the TLG organizations shall
be to channel technical information and guidance to the Board and to
other ICANN entities. This role has both a responsive component and an
active “watchdog” component, which involve the following responsibilities:

a. In response to a request for information,
to connect the Board or other ICANN body with appropriate sources of
technical expertise. This component of the TLG role covers circumstances
in which ICANN seeks an authoritative answer to a specific technical
question. Where information is requested regarding a particular technical
standard for which a TLG organization is responsible, that request shall
be directed to that TLG organization.

b. As an ongoing “watchdog” activity,
to advise the Board of the relevance and progress of technical developments
in the areas covered by each organization's scope that could affect
Board decisions or other ICANN actions, and to draw attention to global
technical standards issues that affect policy development within the
scope of ICANN's mission. This component of the TLG role covers circumstances
in which ICANN is unaware of a new development, and would therefore
otherwise not realize that a question should be asked.

4. TLG Procedures. The TLG shall not have officers
or hold meetings, nor shall it provide policy advice to the Board as
a committee (although TLG organizations may individually be asked by
the Board to do so as the need arises in areas relevant to their individual
charters). Neither shall the TLG debate or otherwise coordinate technical
issues across the TLG organizations; establish or attempt to establish
unified positions; or create or attempt to create additional layers or
structures within the TLG for the development of technical standards
or for any other purpose.

5. Technical Work of the IANA. The TLG shall
have no involvement with the IANA's work for the Internet Engineering
Task Force, Internet Research Task Force, or the Internet Architecture
Board, as described in the Memorandum of Understanding Concerning the
Technical Work of the Internet Assigned Numbers Authority ratified by
the Board on 10 March 2000.

6. Individual Technical Experts. Each TLG organization
shall designate two individual technical experts who are familiar with
the technical standards issues that are relevant to ICANN's activities.
These 8 experts shall be available as necessary to determine, through
an exchange of e-mail messages, where to direct a technical question
from ICANN when ICANN does not ask a specific TLG organization directly.

7. Board Liaison and Nominating Committee Delegate.
Annually, in rotation, one TLG organization shall appoint one non-voting
liaison to the Board according to Article VI, Section
9(1)(d). Annually, in rotation, one TLG organization shall select
one voting delegate to the ICANN Nominating Committee according to Article
VII, Section 2(8)(j). The rotation order for the appointment of the
non-voting liaison to the Board shall be ETSI, ITU-T, and W3C. The rotation
order for the selection of the Nominating Committee delegate shall be
W3C, ETSI, and ITU-T. (IAB does not participate in these rotations because
the IETF otherwise appoints a non-voting liaison to the Board and selects
a delegate to the ICANN Nominating Committee.)

ARTICLE XII: BOARD AND TEMPORARY COMMITTEES

Section 1. BOARD COMMITTEES

The Board may establish one or more committees of the Board, which shall
continue to exist until otherwise determined by the Board. Only Directors
may be appointed to a Committee of the Board. If a person appointed to
a Committee of the Board ceases to be a Director, such person shall also
cease to be a member of any Committee of the Board. Each Committee of
the Board shall consist of two or more Directors. The Board may designate
one or more Directors as alternate members of any such committee, who
may replace any absent member at any meeting of the committee. Committee
members may be removed from a committee at any time by a two-thirds (2/3)
majority vote of all members of the Board; provided, however, that any
Director or Directors which are the subject of the removal action shall
not be entitled to vote on such an action or be counted as a member of
the Board when calculating the required two-thirds (2/3) vote; and, provided
further, however, that in no event shall a Director be removed from a
committee unless such removal is approved by not less than a majority
of all members of the Board.

Section 2. POWERS OF BOARD COMMITTEES

1. The Board may delegate to Committees of the
Board all legal authority of the Board except with respect to:

a. The filling of vacancies on the Board or
on any committee;

b. The amendment or repeal of Bylaws or the
Articles of Incorporation or the adoption of new Bylaws or Articles
of Incorporation;

c. The amendment or repeal of any resolution
of the Board which by its express terms is not so amendable or repealable;

d. The appointment of committees of the Board
or the members thereof;

e. The approval of any self-dealing transaction,
as such transactions are defined in Section 5233(a) of the CNPBCL;

2. The Board shall have the power to prescribe
the manner in which proceedings of any Committee of the Board shall be
conducted. In the absence of any such prescription, such committee shall
have the power to prescribe the manner in which its proceedings shall
be conducted. Unless these Bylaws, the Board or such committee shall
otherwise provide, the regular and special meetings shall be governed
by the provisions of Article VI applicable to meetings
and actions of the Board. Each committee shall keep regular minutes of
its proceedings and shall report the same to the Board from time to time,
as the Board may require.

Section 3. TEMPORARY COMMITTEES

The Board may establish such temporary committees as it sees fit, with
membership, duties, and responsibilities as set forth in the resolutions
or charters adopted by the Board in establishing such committees.

ARTICLE XIII: OFFICERS

Section 1. OFFICERS

The officers of ICANN shall be a President (who shall serve as Chief
Executive Officer), a Secretary, and a Chief Financial Officer. ICANN
may also have, at the discretion of the Board, any additional officers
that it deems appropriate. Any person, other than the President, may hold
more than one office, except that no member of the Board (other than the
President) shall simultaneously serve as an officer of ICANN.

Section 2. ELECTION OF OFFICERS

The officers of ICANN shall be elected annually by the Board, pursuant
to the recommendation of the President or, in the case of the President,
of the Chairman of the ICANN Board. Each such officer shall hold his or
her office until he or she resigns, is removed, is otherwise disqualified
to serve, or his or her successor is elected.

Section 3. REMOVAL OF OFFICERS

Any Officer may be removed, either with or without cause, by a two-thirds
(2/3) majority vote of all the members of the Board. Should any vacancy
occur in any office as a result of death, resignation, removal, disqualification,
or any other cause, the Board may delegate the powers and duties of such
office to any Officer or to any Director until such time as a successor
for the office has been elected.

Section 4. PRESIDENT

The President shall be the Chief Executive Officer (CEO) of ICANN in
charge of all of its activities and business. All other officers and staff
shall report to the President or his or her delegate, unless stated otherwise
in these Bylaws. The President shall serve as an ex officio member of
the Board, and shall have all the same rights and privileges of any Board
member. The President shall be empowered to call special meetings of the
Board as set forth herein, and shall discharge all other duties as may
be required by these Bylaws and from time to time may be assigned by the
Board.

Section 5. SECRETARY

The Secretary shall keep or cause to be kept the minutes of the Board
in one or more books provided for that purpose, shall see that all notices
are duly given in accordance with the provisions of these Bylaws or as
required by law, and in general shall perform all duties as from time
to time may be prescribed by the President or the Board.

Section 6. CHIEF FINANCIAL OFFICER

The Chief Financial Officer (“CFO”) shall be the chief financial
officer of ICANN. If required by the Board, the CFO shall give a bond
for the faithful discharge of his or her duties in such form and with
such surety or sureties as the Board shall determine. The CFO shall have
charge and custody of all the funds of ICANN and shall keep or cause to
be kept, in books belonging to ICANN, full and accurate amounts of all
receipts and disbursements, and shall deposit all money and other valuable
effects in the name of ICANN in such depositories as may be designated
for that purpose by the Board. The CFO shall disburse the funds of ICANN
as may be ordered by the Board or the President and, whenever requested
by them, shall deliver to the Board and the President an account of all
his or her transactions as CFO and of the financial condition of ICANN.
The CFO shall be responsible for ICANN's financial planning and forecasting
and shall assist the President in the preparation of ICANN's annual budget.
The CFO shall coordinate and oversee ICANN's funding, including any audits
or other reviews of ICANN or its Supporting Organizations. The CFO shall
be responsible for all other matters relating to the financial operation
of ICANN.

Section 7. ADDITIONAL OFFICERS

In addition to the officers described above, any additional or assistant
officers who are elected or appointed by the Board shall perform such
duties as may be assigned to them by the President or the Board.

Section 8. COMPENSATION AND EXPENSES

The compensation of any Officer of ICANN shall be approved by the Board.
Expenses incurred in connection with performance of their officer duties
may be reimbursed to Officers upon approval of the President (in the case
of Officers other than the President), by another Officer designated by
the Board (in the case of the President), or the Board.

Section 9. CONFLICTS OF INTEREST

The Board, through the Board Governance Committee, shall establish
a policy requiring a statement from each Officer not less frequently than
once a year setting forth all business and other affiliations that relate
in any way to the business and other affiliations of ICANN.

ARTICLE XIV: INDEMNIFICATION OF DIRECTORS, OFFICERS,
EMPLOYEES, AND OTHER AGENTS

ICANN shall, to maximum extent permitted by the CNPBCL, indemnify each
of its agents against expenses, judgments, fines, settlements, and other
amounts actually and reasonably incurred in connection with any proceeding
arising by reason of the fact that any such person is or was an agent
of ICANN, provided that the indemnified person's acts were done in good
faith and in a manner that the indemnified person reasonably believed
to be in ICANN's best interests and not criminal. For purposes of this
Article, an “agent” of ICANN includes any person who is or was
a Director, Officer, employee, or any other agent of ICANN (including
a member of any Supporting Organization, any Advisory Committee, the Nominating
Committee, any other ICANN committee, or the Technical Liaison Group)
acting within the scope of his or her responsibility; or is or was serving
at the request of ICANN as a Director, Officer, employee, or agent of
another corporation, partnership, joint venture, trust, or other enterprise.
The Board may adopt a resolution authorizing the purchase and maintenance
of insurance on behalf of any agent of ICANN against any liability asserted
against or incurred by the agent in such capacity or arising out of the
agent's status as such, whether or not ICANN would have the power to indemnify
the agent against that liability under the provisions of this Article.

ARTICLE XV: GENERAL PROVISIONS

Section 1. CONTRACTS

The Board may authorize any Officer or Officers, agent or agents, to
enter into any contract or execute or deliver any instrument in the name
of and on behalf of ICANN, and such authority may be general or confined
to specific instances. In the absence of a contrary Board authorization,
contracts and instruments may only be executed by the following Officers:
President, any Vice President, or the CFO. Unless authorized or ratified
by the Board, no other Officer, agent, or employee shall have any power
or authority to bind ICANN or to render it liable for any debts or obligations.

Section 2. DEPOSITS

All funds of ICANN not otherwise employed shall be deposited from time
to time to the credit of ICANN in such banks, trust companies, or other
depositories as the Board, or the President under its delegation, may
select.

Section 3. CHECKS

All checks, drafts, or other orders for the payment of money, notes,
or other evidences of indebtedness issued in the name of ICANN shall be
signed by such Officer or Officers, agent or agents, of ICANN and in such
a manner as shall from time to time be determined by resolution of the
Board.

Section 4. LOANS

No loans shall be made by or to ICANN and no evidences of indebtedness
shall be issued in its name unless authorized by a resolution of the Board.
Such authority may be general or confined to specific instances; provided,
however, that no loans shall be made by ICANN to its Directors or Officers.

ARTICLE XVI: FISCAL MATTERS

Section 1. ACCOUNTING

The fiscal year end of ICANN shall be determined by the Board.

Section 2. AUDIT

At the end of the fiscal year, the books of ICANN shall be closed and
audited by certified public accountants. The appointment of the fiscal
auditors shall be the responsibility of the Board.

Section 3. ANNUAL REPORT AND ANNUAL STATEMENT

The Board shall publish, at least annually, a report describing its
activities, including an audited financial statement and a description
of any payments made by ICANN to Directors (including reimbursements of
expenses). ICANN shall cause the annual report and the annual statement
of certain transactions as required by the CNPBCL to be prepared and sent
to each member of the Board and to such other persons as the Board may
designate, no later than one hundred twenty (120) days after the close
of ICANN's fiscal year.

Section 4. ANNUAL BUDGET

At least forty-five (45) days prior to the commencement of each fiscal
year, the President shall prepare and submit to the Board, a proposed
annual budget of ICANN for the next fiscal year, which shall be posted
on the Website. The proposed budget shall identify anticipated revenue
sources and levels and shall, to the extent practical, identify anticipated
material expense items by line item. The Board shall adopt an annual budget
and shall publish the adopted Budget on the Website.

Section 5. FEES AND CHARGES

The Board may set fees and charges for the services and benefits provided
by ICANN, with the goal of fully recovering the reasonable costs of the
operation of ICANN and establishing reasonable reserves for future expenses
and contingencies reasonably related to the legitimate activities of ICANN.
Such fees and charges shall be fair and equitable, shall be published
for public comment prior to adoption, and once adopted shall be published
on the Website in a sufficiently detailed manner so as to be readily accessible.

ARTICLE XVII: MEMBERS

ICANN shall not have members, as defined in the California Nonprofit
Public Benefit Corporation Law (“CNPBCL”), notwithstanding the
use of the term “Member” in these Bylaws, in any ICANN document,
or in any action of the ICANN Board or staff.

ARTICLE XVIII: OFFICES AND SEAL

Section 1. OFFICES

The principal office for the transaction of the business of ICANN shall
be in the County of Los Angeles, State of California, United States of
America. ICANN may also have an additional office or offices within or
outside the United States of America as it may from time to time establish.

Section 2. SEAL

The Board may adopt a corporate seal and use the same by causing it
or a facsimile thereof to be impressed or affixed or reproduced or otherwise.

ARTICLE XIX: AMENDMENTS

Except as otherwise provided in the Articles of Incorporation or these
Bylaws, the Articles of Incorporation or Bylaws of ICANN may be altered,
amended, or repealed and new Articles of Incorporation or Bylaws adopted
only upon action by a two-thirds (2/3) vote of all members of the Board.

ARTICLE XX: TRANSITION ARTICLE

Section 1. PURPOSE

This Transition Article sets forth the provisions for the transition
from the processes and structures defined by the ICANN Bylaws, as amended
and restated on 29 October 1999 and amended through 12 February 2002 (the “Old
Bylaws”), to the processes and structures defined by the Bylaws
of which this Article is a part (the “New Bylaws”). [Explanatory Note (dated 10 December 2009): For Section 5(3) of this Article, reference to the Old Bylaws refers to the Bylaws as amended and restated through to 20 March 2009.]

Section 2. BOARD OF DIRECTORS

1. For the period beginning on the adoption of
this Transition Article and ending on the Effective Date and Time of
the New Board, as defined in paragraph 5 of this Section
2, the Board of Directors of the Corporation (“Transition Board”)
shall consist of the members of the Board who would have been Directors
under the Old Bylaws immediately after the conclusion of the annual meeting
in 2002, except that those At-Large members of the Board under the Old
Bylaws who elect to do so by notifying the Secretary of the Board on
15 December 2002 or in writing or by e-mail no later than 23 December
2002 shall also serve as members of the Transition Board. Notwithstanding
the provisions of Article VI, Section 12 of the New
Bylaws, vacancies on the Transition Board shall not be filled. The
Transition Board shall not have liaisons as provided by Article
VI, Section 9 of the New Bylaws. The Board Committees existing on
the date of adoption of this Transition Article shall continue in existence,
subject to any change in Board Committees or their membership that the
Transition Board may adopt by resolution.

2. The Transition Board shall elect a Chair and
Vice-Chair to serve until the Effective Date and Time of the New Board.

4. Promptly after the adoption of this Transition
Article, a Nominating Committee shall be formed including, to the extent
feasible, the delegates and liaisons described in Article
VII, Section 2 of the New Bylaws, with terms to end at the conclusion
of the ICANN annual meeting in 2003. The Nominating Committee shall proceed
without delay to select Directors to fill Seats 1 through 8 on the New
Board, with terms to conclude upon the commencement of the first regular
terms specified for those Seats in Article VI, Section
8(1)(a)-(c) of the New Bylaws, and shall give the ICANN Secretary
written notice of that selection.

5. The Effective Date and Time of the New Board
shall be a time, as designated by the Transition Board, during the first
regular meeting of ICANN in 2003 that begins not less than seven calendar
days after the ICANN Secretary has received written notice of the selection
of Directors to fill at least ten of Seats 1 through 14 on the New Board.
As of the Effective Date and Time of the New Board, it shall assume from
the Transition Board all the rights, duties, and obligations of the ICANN
Board of Directors. Subject to Section 4 of this Article, the Directors
(Article VI, Section 2(1)(a)-(d)) and non-voting
liaisons (Article VI, Section 9) as to which the
ICANN Secretary has received notice of selection shall, along with the
President (Article VI, Section 2(1)(e)), be seated
upon the Effective Date and Time of the New Board, and thereafter any
additional Directors and non-voting liaisons shall be seated upon the
ICANN Secretary’s receipt of notice of their selection.

6. The New Board shall elect a Chairman and Vice-Chairman
as its first order of business. The terms of those Board offices shall
expire at the end of the annual meeting in 2003.

7. Committees of the Board in existence as of
the Effective Date and Time of the New Board shall continue in existence
according to their existing charters, but the terms of all members of
those committees shall conclude at the Effective Date and Time of the
New Board. Temporary committees in existence as of the Effective Date
and Time of the New Board shall continue in existence with their existing
charters and membership, subject to any change the New Board may adopt
by resolution.

8. In applying the term-limitation provision of Section
8(5) of Article VI, a Director's service on the Board before the
Effective Date and Time of the New Board shall count as one term.

Section 3. ADDRESS SUPPORTING ORGANIZATION

The Address Supporting Organization shall continue in operation according
to the provisions of the Memorandum
of Understanding originally entered on 18 October 1999 between ICANN
and a group of regional Internet registries (RIRs), and amended
in October 2000, until a replacement Memorandum of Understanding becomes
effective. Promptly after the adoption of this Transition Article, the
Address Supporting Organization shall make selections, and give the ICANN
Secretary written notice of those selections, of:

With respect to the ICANN Directors that it is entitled to select, and
taking into account the need for rapid selection to ensure that the New
Board becomes effective as soon as possible, the Address Supporting Organization
may select those Directors from among the persons it previously selected
as ICANN Directors pursuant to the Old Bylaws. To the extent the Address
Supporting Organization does not provide the ICANN Secretary written notice,
on or before 31 March 2003, of its selections for Seat 9 and Seat 10,
the Address Supporting Organization shall be deemed to have selected for
Seat 9 the person it selected as an ICANN Director pursuant to the Old
Bylaws for a term beginning in 2001 and for Seat 10 the person it selected
as an ICANN Director pursuant to the Old Bylaws for a term beginning in
2002.

Section 4. 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 third 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
appoint 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.

Section 5. GENERIC NAMES SUPPORTING ORGANIZATION

1. The Generic Names Supporting Organization (“GNSO”),
upon the adoption of this Transition Article, shall
continue its operations; however, it shall be restructured into
four new Stakeholder Groups which shall represent,
organizationally, the former Constituencies of the GNSO, subject
to ICANN Board approval of each individual
Stakeholder Group Charter:

a. The gTLD Registries Constituency shall be assigned to the Registries
Stakeholder Group;

b. The Registrars Constituency shall be assigned to the Registrars
Stakeholder Group;

c. The Business Constituency shall be assigned to the Commercial
Stakeholder Group;

d. The Intellectual Property Constituency shall be assigned
to the Commercial Stakeholder Group;

e. The Internet Services Providers Constituency shall be assigned
to the Commercial Stakeholder Group; and

f. The Non-Commercial Users Constituency shall be assigned
to the Non-Commercial Stakeholder Group.

2.
Each GNSO Constituency described in paragraph 1 of this subsection shall
continue operating substantially as before and no Constituency official,
working group, or other activity shall be changed until further action
of the Constituency, provided that each GNSO Constituency described in
paragraph 1 (c-f) shall submit to the ICANN Secretary a new or revised
Charter inclusive of its operating procedures, adopted according to the
Constituency's processes and consistent with these Bylaws Amendments, no
later than the ICANN meeting in October 2009, or another date as the Board
may designate by resolution.

3.
Prior to the commencement of the ICANN meeting in October 2009, or another
date the Board may designate by resolution, the GNSO Council shall consist
of its current Constituency structure and officers as described in Article
X, Section 3(1) of the Bylaws (as amended and restated on 29 October
1999 and amended through 20 March 2009 (the "Old Bylaws")). Thereafter,
the composition of the GNSO Council shall be as provided in these Bylaws,
as they may be amended from time to time. All committees, task forces,
working groups, drafting committees, and similar groups established by
the GNSO Council and in existence immediately before the adoption of this
Transition Article shall continue in existence with the same charters,
membership, and activities, subject to any change by action of the GNSO
Council or ICANN Board.

4. Beginning with the commencement of the ICANN
Meeting in October 2009, or another date the Board may
designate by resolution (the “Effective Date of the Transition”),
the GNSO Council seats shall be assigned as
follows:

a. The three seats currently assigned to the Registry Constituency
shall be reassigned as three seats of the
Registries Stakeholder Group;

b. The three seats currently assigned to the Registrar Constituency
shall be reassigned as three seats of the
Registrars Stakeholder Group;

c. The three seats currently assigned to each of the Business
Constituency, the Intellectual Property
Constituency, and the Internet Services Provider Constituency
(nine total) shall be decreased to be six seats of
the Commercial Stakeholder Group;

d. The three seats currently assigned to the Non-Commercial
Users Constituency shall be increased to be six
seats of the Non-Commercial Stakeholder Group;

e. The three seats currently selected by the Nominating Committee
shall be assigned by the Nominating
Committee as follows: one voting member to the Contracted Party
House, one voting member to the Non-Contracted Party House,
and one non-voting member assigned to the GNSO Council at large.

Representatives on the GNSO Council shall be appointed or elected consistent
with the provisions in each applicable Stakeholder Group Charter,
approved by the Board, and sufficiently in advance of the October
2009 ICANN Meeting that will permit those representatives to act in their
official capacities at the start of said meeting.

5.
The GNSO Council, as part of its Restructure Implementation Plan, will
document: (a) how vacancies, if any, will be handled during the transition
period; (b) for each Stakeholder Group, how each assigned Council seat
to take effect at the 2009 ICANN annual meeting will be filled, whether
through a continuation of an existing term or a new election or appointment;
(c) how it plans to address staggered terms such that the new GNSO Council
preserves as much continuity as reasonably possible; and (d) the effect
of Bylaws term limits on each Council member.

6. As soon as practical after the commencement
of the ICANN meeting in October 2009, or another date the Board may designate
by resolution, the GNSO Council shall, in accordance with Article
X, Section 3(7) and its GNSO Operating Procedures, elect officers and give
the ICANN Secretary written notice of its selections.

1. Upon the adoption of the New Bylaws, the Governmental
Advisory Committee shall continue in operation according to its existing
operating principles and practices, until further action of the committee.
The Governmental Advisory Committee may designate liaisons to serve with
other ICANN bodies as contemplated by the New Bylaws by providing written
notice to the ICANN Secretary. Promptly upon the adoption of this Transition
Article, the Governmental Advisory Committee shall notify the ICANN Secretary
of the person selected as its delegate to the Nominating Committee, as
set forth in Article VII, Section 2 of the New Bylaws.

3. Upon the adoption of the New Bylaws, the Security
and Stability Advisory Committee shall continue in operation according
to its existing operating principles and practices, until further action
of the committee. Promptly upon the adoption of this Transition Article,
the Security and Stability Advisory Committee shall notify the ICANN
Secretary of the person selected as its delegate to the Nominating Committee,
as set forth in Article VII, Section 2(4) of the
New Bylaws.

4. Upon the adoption of the New Bylaws, the Root
Server System Advisory Committee shall continue in operation according
to its existing operating principles and practices, until further action
of the committee. Promptly upon the adoption of this Transition Article,
the Root Server Advisory Committee shall notify the ICANN Secretary
of the person selected as its delegate to the Nominating Committee,
as set forth in Article VII, Section 2(3) of the
New Bylaws.

5. At-Large Advisory Committee

a. There shall exist an Interim At-Large Advisory
Committee until such time as ICANN recognizes, through the entry of
a Memorandum of Understanding, all of the Regional At-Large Organizations
(RALOs) identified in Article XI, Section 2(4) of
the New Bylaws. The Interim At-Large Advisory Committee shall be
composed of (i) ten individuals (two from each ICANN region) selected
by the ICANN Board following nominations by the At-Large Organizing
Committee and (ii) five additional individuals (one from each ICANN
region) selected by the initial Nominating Committee as soon as feasible
in accordance with the principles established in Article
VII, Section 5 of the New Bylaws. The initial Nominating Committee
shall designate two of these individuals to serve terms until the conclusion
of the ICANN annual meeting in 2004 and three of these individuals to
serve terms until the conclusion of the ICANN annual meeting in 2005.

b. Upon the entry of each RALO into such a Memorandum
of Understanding, that entity shall be entitled to select two persons
who are citizens and residents of that Region to be members of the At-Large
Advisory Committee established by Article XI, Section
2(4) of the New Bylaws. Upon the entity's written notification to
the ICANN Secretary of such selections, those persons shall immediately
assume the seats held until that notification by the Interim At-Large
Advisory Committee members previously selected by the Board from the
RALO's region.

c. Upon the seating of persons selected by all
five RALOs, the Interim At-Large Advisory Committee shall become the
At-Large Advisory Committee, as established by Article
XI, Section 2(4) of the New Bylaws. The five individuals selected
to the Interim At-Large Advisory Committee by the Nominating Committee
shall become members of the At-Large Advisory Committee for the remainder
of the terms for which they were selected.

d. Promptly upon its creation, the Interim At-Large
Advisory Committee shall notify the ICANN Secretary of the persons selected
as its delegates to the Nominating Committee, as set forth in Article
VII, Section 2(6) of the New Bylaws.

Section 8. OFFICERS

ICANN officers (as defined in Article XIII of the New
Bylaws) shall be elected by the then-existing Board of ICANN at the
annual meeting in 2002 to serve until the annual meeting in 2003.

Section 9. GROUPS APPOINTED BY THE PRESIDENT

Notwithstanding the adoption or effectiveness of the New Bylaws, task
forces and other groups appointed by the ICANN President shall continue
unchanged in membership, scope, and operation until changes are made by
the President.

Section 10. CONTRACTS WITH ICANN

Notwithstanding the adoption or effectiveness of the New Bylaws, all
agreements, including employment and consulting agreements, entered by
ICANN shall continue in effect according to their terms.

Annex A: GNSO
Policy-Development Process

The following process shall govern the GNSO policy development process
(“PDP”) until such time as modifications are recommended to and approved
by the ICANN Board of Directors (“Board”). [Note: this Annex includes
amendments that were needed on an interim basis to allow the GNSO to operate
while community and Board discussions continue on revised policy development
and operating procedures].

1. Raising an Issue

An issue may be raised for consideration as part of the PDP by any of
the following:

a. Board Initiation. The Board may initiate the PDP by instructing
the GNSO Council (“Council”) to begin the
process outlined in this Annex.

b. Council Initiation. The GNSO Council may initiate the PDP by
a vote of at least twenty-five percent (25%) of the
members of the Council of each House or a majority of one House.

c. Advisory Committee Initiation. An Advisory Committee may
raise an issue for policy development by action of
such committee to commence the PDP, and transmission of that
request to the GNSO Council.

2. Creation of the Issue Report

Within fifteen (15) calendar days after receiving either (i) an instruction
from the Board; (ii) a properly supported motion from a Council member;
or (iii) a properly supported motion from an Advisory Committee, the Staff
Manager will create a report (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 Staff Manager
as to whether the Council should initiate the PDP for this issue (the
“Staff Recommendation”). Each Staff Recommendation shall include the opinion
of the ICANN General Counsel regarding whether the issue proposed to initiate
the PDP is properly within the scope of the ICANN policy process and within
the scope of the GNSO. In determining whether the issue is properly within
the scope of the ICANN policy process, the General Counsel shall examine
whether such issue:

1. is within the scope of ICANN's mission
statement;

2. is broadly applicable to multiple situations
or organizations;

3. is likely to have lasting value or applicability,
albeit with the need for occasional updates;

4. will establish a guide or framework for
future decision-making; or

5. implicates or affects an existing ICANN
policy.

f. On or before the fifteen (15) day deadline,
the Staff Manager shall distribute the Issue Report to the full Council
for a vote on whether to initiate the PDP, as discussed below.

3. Initiation of PDP

The Council shall initiate the PDP as follows:

a. Issue Raised by the Board. If the Board
directs the Council to initiate the PDP, then the Council shall meet
and do so within fifteen (15) calendar days after receipt of the Issue
Report, with no intermediate vote of the Council.

b. Issue Raised by Other than by the Board.
If a policy issue is presented to the Council for consideration via an
Issue Report, then the Council shall meet within fifteen (15) calendar
days after receipt of such Report 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.

c. Vote of the Council.
A vote of more than 33% of the Council members of each House or more than
66% vote of one House in favor of initiating the PDP within scope will
suffice to initiate the PDP; unless the Staff Recommendation stated that
the issue is not properly within the scope of the ICANN policy process
or the GNSO, in which case a GNSO Supermajority Vote as set forth in Article
X, Section 3, paragraph 9(c) in favor of initiating the PDP will be
required to initiate the PDP.

4. Commencement of the PDP

At the meeting of the Council initiating the PDP, the Council shall
decide, by a majority vote of members of each House, whether 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 the provisions of Item 7
below.

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

5. Composition and Selection of Task Forces

a. Upon voting to appoint a task force, the
Council shall invite each of the Constituencies and/or Stakeholder Groups
of the GNSO to appoint one individual to participate in the task force.
Additionally, the Council may appoint up to three outside advisors to
sit on the task force. (Each task force member is referred to in this
Annex as a
"Representative" and collectively, the "Representatives"). The Council
may increase the number of Representatives per Constituency or Stakeholder
Group that may sit on a task force in its discretion in circumstances that
it deems necessary or appropriate.

b. Any Constituency or Stakeholder Group wishing
to appoint a Representative to the task force must submit the name of
the Constituency or Stakeholder Group designee to the Staff Manager within
ten (10) calendar days after such request in order to be included on
the task force. Such designee need not be a member of the Council, but
must be an individual who has an interest, and ideally knowledge and expertise,
in the area to be developed, coupled with the ability to devote a substantial
amount of time to task force activities.

c. The Council may also pursue other options
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 Staff Manager within thirty-five
(35) calendar days after initiation of the PDP.

6. Public Notification of Initiation of the
PDP

After initiation of the PDP, ICANN shall post a notification of such
action to the Website. A public comment period shall be commenced for
the issue for a period of twenty (20) calendar days after initiation of
the PDP. The Staff Manager, or some other designated representative of
ICANN shall review the public comments and incorporate them into a report
(the "Public 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 will generally be to (i) gather information detailing the positions
of the Stakeholder Groups and the formal constituencies and provisional
constituencies, if any, within the GNSO; and (ii) otherwise obtain relevant
information that will enable the Task Force Report to be as complete
and informative as possible.

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 Staff Manager, shall develop
a charter or terms of reference for the task force (the "Charter") within
ten (10) calendar days after initiation of the PDP. 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 Board 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 each house of the Council
members.

c. Appointment of Task Force Chair. The Staff
Manager shall convene the first meeting of the task force within
five (5) calendar days after receipt of the Charter. 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. Constituency and Stakeholder Group
Statements.
The Representatives of the Stakeholder Groups will each be responsible
for soliciting the position of their Stakeholder Groups or any of their
constituencies, at a minimum, and other comments as each Representative
deems appropriate, regarding the issue under consideration. This position
and other comments, as applicable, should be submitted in a formal statement
to the task force chair (each, a "Constituency/Stakeholder Group Statement")
within thirty-five (35) calendar days after initiation of the PDP. Every
Constituency/Stakeholder Group Statement shall include at least the
following:

(i) If a Supermajority Vote was reached,
a clear statement of the constituency's or Stakeholder Group’s position
on the issue;

(ii) If a Supermajority Vote was not reached,
a clear statement of all positions espoused by constituency or Stakeholder
Group members;

(iii) A clear statement of how the constituency
or Stakeholder Group arrived at its position(s). Specifically, the
statement should detail specific constituency or Stakeholder Group
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 constituency or Stakeholder Group, including any financial
impact on the constituency or Stakeholder Group; and

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

2. Outside Advisors. The task force, should
it deem it appropriate or helpful, may solicit the opinions of outside
advisors, experts, or other members of the public, in addition to those
of constituency or Stakeholder Group members. 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 thirty-five (35) calendar
days after initiation of the PDP.

e. Task Force Report. The chair of the task
force, working with the Staff Manager, shall compile the Constituency/Stakeholder
Group Statements, Public 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 forty (40) calendar days after initiation of the PDP. The task
force shall have a final task force meeting within five (5) days after
the date of distribution of the Preliminary Task Force Report to deliberate
the issues and try and reach a Supermajority Vote. Within five (5) calendar
days after the final task force meeting, the chair of the task force
and the Staff Manager shall create the final task force report (the "Task
Force Report") and post it on the Comment Site. Each Task Force Report
must include:

1. A clear statement of any Supermajority
Vote 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 twenty-day timeline for submission of constituency or Stakeholder
Group reports. Each statement should clearly indicate (i) the reasons
underlying the position and (ii) the constituency(ies) or Stakeholder
Group(s) that held the position;

3. An analysis of how the issue would affect
each constituency or Stakeholder Group of the task force, including
any financial impact on the constituency or Stakeholder Group;

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, the Council will request that, within ten (10) calendar days
thereafter, each constituency or Stakeholder Group appoint a representative
to solicit the constituency's or Stakeholder Group’s views on the issue.
Each such representative shall be asked to submit a Constituency/Stakeholder
Group Statement to the Staff Manager within thirty-five (35) calendar
days after initiation of the PDP.

b. The Council may also pursue other options
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 Staff Manager within thirty-five (35) calendar
days after initiation of the PDP.

c. The Staff Manager will take all Constituency/Stakeholder
Group Statements, Public Comment Statements, and other information and
compile (and post on the Comment Site) an Initial Report within fifty
(50) calendar days after initiation of the PDP. Thereafter, the PDP shall
follow the provisions of Item 9 below in creating a Final Report.

9. Public Comments to the Task Force Report
or Initial Report

a. The public comment period will last for
twenty (20) calendar days after posting of the Task Force Report or Initial
Report. Any individual or organization may submit comments during the public
comment period, including any Constituency or Stakeholder Group that
did not participate in the task force. All comments shall be accompanied
by the name of the author of the comments, the author's relevant experience,
and the author's interest in the issue.

b. At the end of the twenty (20) day period,
the Staff Manager will be responsible for reviewing the comments received
and adding those deemed appropriate for inclusion in the Staff Manager's
reasonable discretion to the Task Force Report or Initial Report (collectively,
the "Final Report"). The Staff Manager shall not be obligated to include
all comments made during the comment period, including each comment made
by any one individual or organization.

c. The Staff Manager shall prepare the Final
Report and submit it to the Council chair within ten (10) calendar days
after the end of the public comment period.

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 ten (10) calendar days thereafter. 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. The deliberation process shall
culminate in a formal Council meeting either in person or via teleconference,
wherein the Council will work towards achieving a Successful GNSO Vote
to present to the Board.

b. 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) be accompanied by a detailed statement
of the advisor's (x) qualifications and relevant experience; and (y)
potential conflicts of interest.

11. Council Report to the Board

The Staff Manager will be present at the final meeting of the Council,
and will have five (5) calendar days after the meeting to incorporate
the views of the Council into a report to be submitted to the Board (the "Board
Report"). The Board Report must contain at least the following:

a. A clear statement of any Successful GNSO
Vote recommendation of the Council;

b. If a Successful GNSO Vote was not reached, a clear statement
of all positions held by Council members. Each
statement should clearly indicate (i) the reasons underlying
each position and (ii) the constituency(ies) or
Stakeholder Group(s) that held the position;

c. An analysis of how the issue would affect each constituency
or Stakeholder Group, including any financial impact on the constituency
or Stakeholder Group;

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

e. The advice of any outside advisors relied upon, which should
be accompanied by a detailed statement of the
advisor's (i) qualifications and relevant experience; and (ii)
potential conflicts of interest;

f. The Final Report submitted to the Council; and

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

12. Agreement of the Council

A. Successful GNSO Vote of the Council members will be deemed to reflect
the view of the Council, and may be conveyed to the Board as the Council's
recommendation. In the event a GNSO Supermajority Vote is not achieved,
approval of the recommendations contained in the Final Report requires
a majority of both houses and further requires that one representative
of at least 3 of the 4 Stakeholder Groups supports the recommendations.
Abstentions shall not be permitted; thus all Council members must cast
a vote unless they identify a financial interest in the outcome of
the policy issue. Notwithstanding the foregoing, as set forth above,
all viewpoints expressed by Council members during the PDP must be included
in the Board Report.

13. Board Vote

a. The Board will meet to discuss the GNSO
Council recommendation as soon as feasible after receipt of the Board
Report from the Staff Manager.

b. In the event that the Council reached a
GNSO Supermajority Vote, the Board shall adopt the policy according to
the GNSO Supermajority Vote recommendation unless by a vote of more than
sixty-six (66%) percent of the Board determines that such policy is not
in the best interests of the ICANN community or ICANN.

c. In the event that the Board determines
not to act in accordance with the GNSO Supermajority Vote
recommendation, the Board shall (i) articulate the reasons for
its determination in a report to the Council (the "Board Statement");
and (ii) submit the Board Statement to the Council.

d. The Council shall review the Board Statement for discussion
with the Board within twenty (20) calendar days
after the Council's receipt of the Board Statement. 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.

e. At the conclusion of the Council and Board discussions, the
Council shall meet to affirm or modify its
recommendation, and communicate that conclusion (the "Supplemental
Recommendation") to the Board,
including an explanation for its current recommendation. In the
event that the Council is able to reach a GNSO
Supermajority Vote on the Supplemental Recommendation, 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.

f. In any case in which the Council is not able to reach GNSO Supermajority
vote, a majority vote of the Board will
be sufficient to act.

g. When a final decision on a GNSO Council Recommendation or
Supplemental Recommendation is timely, the
Board shall take a preliminary vote and, where practicable,
will publish a tentative decision that allows for a ten
(10) day period of public comment prior to a final decision
by the Board.

14. Implementation of the Policy

Upon a final decision of the Board, the Board shall, as appropriate,
give authorization or direction to the ICANN staff to take all necessary
steps to implement the policy.

15. Maintenance of Records

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

a. The initial suggestion for a policy;

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

c. The timeline to be followed for each policy;

d. All discussions among the Council regarding the policy;

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

f. All public comments submitted.

16. Additional Definitions

"Comment Site" and "Website" refer to one or more
web sites designated by ICANN on which notifications and
comments regarding the PDP will be posted.

"Supermajority Vote" means a vote of more than sixty-six
(66) percent of the members present at a meeting of the
applicable body, with the exception of the GNSO Council.

“Staff Manager" means an ICANN staff person(s) who manages the
PDP.

“GNSO Supermajority Vote” shall have the meaning set forth in the
Bylaws.

A “Successful GNSO Vote” is an affirmative vote of the GNSO Council
that meets the relevant voting thresholds set
forth in Article X, Section 3(9) including, without limitation,
a GNSO Supermajority Vote.

Annex B: ccNSO
Policy-Development Process (ccPDP)

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.

e. Members of the ccNSO. The members of the ccNSO may call for
the creation of an Issue Report by an affirmative vote of at least ten
members of the ccNSO present at any meeting or voting by e-mail.

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 and Initiation Threshold

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, and be supported by, an 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:

1) The issue is within the scope of ICANN's mission statement;

2) Analysis of the relevant factors according to Article
IX, Section 6(2) and Annex C affirmatively
demonstrates that the issue is within the scope of the ccNSO;

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.

In all events, consideration of revisions to the ccPDP (this Annex
B) or to the scope of the ccNSO (Annex C)
shall be within the scope of ICANN and the ccNSO.

In the event that General Counsel is of the opinion the issue is not
properly within the scope of the ccNSO Scope, the Issue Manager shall
inform the Council of this opinion. If after an analysis of the relevant
factors according to Article IX, Section 6 and Annex C a majority of
10 or more Council members is of the opinion the issue is within scope
the Chair of the ccNSO shall inform the Issue Manager accordingly. General
Counsel and the ccNSO Council shall engage in a dialogue according to
agreed rules and procedures to resolve the matter. In the event no agreement
is reached between General Counsel and the Council as to whether the
issue is within or outside Scope of the ccNSO then by a vote of 15 or
more members the Council may decide the issue is within scope. The Chair
of the ccNSO shall inform General Counsel and the Issue Manager accordingly.
The Issue Manager shall then proceed with a recommendation whether or
not the Council should move to initiate the PDP including both the opinion
and analysis of General Counsel and Council in the Issues Report.

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 (PDP Time Line).

g. If possible, the issue report shall indicate whether the resulting
output is likely to result in a policy to be approved by the ICANN Board.
In some circumstances, it will not be possible to do this until substantive
discussions on the issue have taken place. In these cases, the issue
report should indicate this uncertainty.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 be required 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.

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 PDP Time
Lineset 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

In considering whether to make a recommendation on the issue (a “Council
Recommendation”), the Council shall seek to act by consensus. If
a minority opposes a consensus position, that minority shall prepare and
circulate to the Council a statement explaining its reasons for opposition.
If the Council's discussion of the statement does not result in consensus,
then 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 (at least 21 days long).

In the event that at least 50% of the ccNSO members lodge votes within
the voting period, the resulting vote will be be employed without further
process. In the event that fewer than 50% of the ccNSO members lodge votes
in the first round of voting, the first round will not be employed and
the results of a final, second round of voting, conducted after at least
thirty days notice to the ccNSO members, will be employed if at least
50% of the ccNSO members lodge votes. 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 acceptance of such
policy would constitute a breach of the fiduciary duties of the Board
to the Company.

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 the event the Board determines not to accept a ccNSO Supplemental
Recommendation, 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: The
Scope of the ccNSO

This annex describes the scope and the principles and method of analysis
to be used in any further 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 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 annex 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 information below offers an aid to:

1. delineate and identify specific policy areas;

2. define and determine roles with regard to these specific policy
areas.

This annex defines the scope of the ccNSO with regard to developing
policies. The scope is limited to the policy role of the ccNSO policy-development
process for functions and levels explicitly stated below. It is anticipated
that the accuracy of the assignments of policy, executive, and accountability
roles shown below will be considered during a scope-definition ccPDP process.

Level 2: ccTLD Registry Name Servers in respect to interoperability
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 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

A note about tracking cookies:

This notice is intended to appear only the first time you visit the site on any computer.Dismiss

Domain Name System

Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."