BYLAWS FOR INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS | A California Nonprofit Public-Benefit Corporation (original) (raw)

(a) The mission of the Internet Corporation for Assigned Names and Numbers ("ICANN") is to ensure the stable and secure operation of the Internet's unique identifier systems as described in this Section 1.1(a) (the "Mission"). Specifically, ICANN:

(i) Coordinates the allocation and assignment of names in the root zone of the Domain Name System ("DNS") and coordinates the development and implementation of policies concerning the registration of second-level domain names in generic top-level domains ("gTLDs"). In this role, ICANN's scope is to coordinate the development and implementation of policies:

For which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS including, with respect to gTLD registrars and registries, policies in the areas described in Annex G-1 and Annex G-2; and

That are developed through a bottom-up consensus-based multistakeholder process and designed to ensure the stable and secure operation of the Internet's unique names systems.

The issues, policies, procedures, and principles addressed in Annex G-1 and Annex G-2 with respect to gTLD registrars and registries shall be deemed to be within ICANN's Mission.

(ii) Facilitates the coordination of the operation and evolution of the DNS root name server system.

(iii) Coordinates the allocation and assignment at the top-most level of Internet Protocol numbers and Autonomous System numbers. In service of its Mission, ICANN (A) provides registration services and open access for global number registries as requested by the Internet Engineering Task Force ("IETF") and the Regional Internet Registries ("RIRs") and (B) facilitates the development of global number registry policies by the affected community and other related tasks as agreed with the RIRs.

(iv) Collaborates with other bodies as appropriate to provide registries needed for the functioning of the Internet as specified by Internet protocol standards development organizations. In service of its Mission, ICANN's scope is to provide registration services and open access for registries in the public domain requested by Internet protocol development organizations.

(b) ICANN shall not act outside its Mission.

(c) ICANN shall not regulate (i.e., impose rules and restrictions on) services that use the Internet's unique identifiers or the content that such services carry or provide, outside the express scope of Section 1.1(a). For the avoidance of doubt, ICANN does not hold any governmentally authorized regulatory authority.

(d) For the avoidance of doubt and notwithstanding the foregoing:

(i) the foregoing prohibitions are not intended to limit ICANN's authority or ability to adopt or implement policies or procedures that take into account the use of domain names as natural-language identifiers;

(ii) Notwithstanding any provision of the Bylaws to the contrary, the terms and conditions of the documents listed in subsections (A) through (C) below, and ICANN's performance of its obligations or duties thereunder, may not be challenged by any party in any proceeding against, or process involving, ICANN (including a request for reconsideration or an independent review process pursuant to Article 4) on the basis that such terms and conditions conflict with, or are in violation of, ICANN's Mission or otherwise exceed the scope of ICANN's authority or powers pursuant to these Bylaws ("Bylaws") or ICANN's Articles of Incorporation ("Articles of Incorporation"):

(A)

(1) all registry agreements and registrar accreditation agreements between ICANN and registry operators or registrars in force on 1 October 2016 [1], including, in each case, any terms or conditions therein that are not contained in the underlying form of registry agreement and registrar accreditation agreement;

(2) any registry agreement or registrar accreditation agreement not encompassed by (1) above to the extent its terms do not vary materially from the form of registry agreement or registrar accreditation agreement that existed on 1 October 2016;

(B)any renewals of agreements described in subsection (A) pursuant to their terms and conditions for renewal; and

(C)ICANN's Five-Year Strategic Plan and Five-Year Operating Plan existing on 10 March 2016.

(iii) Section 1.1(d)(ii) does not limit the ability of a party to any agreement described therein to challenge any provision of such agreement on any other basis, including the other party's interpretation of the provision, in any proceeding or process involving ICANN.

(iv) ICANN shall have the ability to negotiate, enter into and enforce agreements, including public interest commitments, with any party in service of its Mission.

Section 1.2. COMMITMENTS AND CORE VALUES

In performing its Mission, ICANN will act in a manner that complies with and reflects ICANN's Commitments and respects ICANN's Core Values, each as described below.

(a) COMMITMENTS

In performing its Mission, ICANN must operate in a manner consistent with these Bylaws for the benefit of the Internet community as a whole, carrying out its activities in conformity with relevant principles of international law and international conventions and applicable local law, through open and transparent processes that enable competition and open entry in Internet-related markets. Specifically, ICANN commits to do the following (each, a "Commitment," and collectively, the "Commitments"):

(i) Preserve and enhance the administration of the DNS and the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS and the Internet;

(ii) Maintain the capacity and ability to coordinate the DNS at the overall level and work for the maintenance of a single, interoperable Internet;

(iii) Respect the creativity, innovation, and flow of information made possible by the Internet by limiting ICANN's activities to matters that are within ICANN's Mission and require or significantly benefit from global coordination;

(iv) Employ open, transparent and bottom-up, multistakeholder policy development processes that are led by the private sector (including business stakeholders, civil society, the technical community, academia, and end users), while duly taking into account the public policy advice of governments and public authorities. These processes shall (A) seek input from the public, for whose benefit ICANN in all events shall act, (B) promote well-informed decisions based on expert advice, and (C) ensure that those entities most affected can assist in the policy development process;

(v) Make decisions by applying documented policies consistently, neutrally, objectively, and fairly, without singling out any particular party for discriminatory treatment (i.e., making an unjustified prejudicial distinction between or among different parties); and

(vi) Remain accountable to the Internet community through mechanisms defined in these Bylaws that enhance ICANN's effectiveness.

(b) CORE VALUES

In performing its Mission, the following "Core Values" should also guide the decisions and actions of ICANN:

(i) 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 and the roles of bodies internal to ICANN and relevant external expert bodies;

(ii) 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 to ensure that the bottom-up, multistakeholder policy development process is used to ascertain the global public interest and that those processes are accountable and transparent;

(iii) Where feasible and appropriate, depending on market mechanisms to promote and sustain a competitive environment in the DNS market;

(iv) Introducing and promoting competition in the registration of domain names where practicable and beneficial to the public interest as identified through the bottom-up, multistakeholder policy development process;

(v) Operating with efficiency and excellence, in a fiscally responsible and accountable manner and, where practicable and not inconsistent with ICANN's other obligations under these Bylaws, at a speed that is responsive to the needs of the global Internet community;

(vi) While remaining rooted in the private sector (including business stakeholders, civil society, the technical community, academia, and end users), recognizing that governments and public authorities are responsible for public policy and duly taking into account the public policy advice of governments and public authorities;

(vii) Striving to achieve a reasonable balance between the interests of different stakeholders, while also avoiding capture; and

(viii) Subject to the limitations set forth in Section 27.2, within the scope of its Mission and other Core Values, respecting internationally recognized human rights as required by applicable law. This Core Value does not create, and shall not be interpreted to create, any obligation on ICANN outside its Mission, or beyond obligations found in applicable law. This Core Value does not obligate ICANN to enforce its human rights obligations, or the human rights obligations of other parties, against other parties.

(c) The Commitments and Core Values are intended to apply in the broadest possible range of circumstances. The Commitments reflect ICANN's fundamental compact with the global Internet community and are intended to apply consistently and comprehensively to ICANN's activities. The specific way in which Core Values are applied, individually and collectively, to any given situation may depend on many factors that cannot be fully anticipated or enumerated. Situations may arise in which perfect fidelity to all Core Values simultaneously is not possible. Accordingly, in any situation where one Core Value must be balanced with another, potentially competing Core Value, the result of the balancing must serve a policy developed through the bottom-up multistakeholder process or otherwise best serve ICANN's Mission.

ARTICLE 2 POWERS

Section 2.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 (as defined in Section 7.1). With respect to any matters that would fall within the provisions of Section 3.6(a)-(c), the Board may act only by a majority vote of all Directors. In all other matters, except as otherwise provided in these Bylaws or by law, the Board may act by majority vote of the Directors 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 Directors present at the meeting where a quorum is present unless otherwise specifically provided in these Bylaws by reference to "of all Directors."

Section 2.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 2.2 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 2.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 3 TRANSPARENCY

Section 3.1. OPEN AND TRANSPARENT

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, including implementing procedures to (a) provide advance notice to facilitate stakeholder engagement in policy development decision-making and cross-community deliberations, (b) maintain responsive consultation procedures that provide detailed explanations of the basis for decisions (including how comments have influenced the development of policy considerations), and (c) encourage fact-based policy development work. ICANN shall also implement procedures for the documentation and public disclosure of the rationale for decisions made by the Board and ICANN's constituent bodies (including the detailed explanations discussed above).

Section 3.2. WEBSITE

ICANN shall maintain a publicly-accessible Internet World Wide Web site (the "Website"), which may include, among other things, (a) a calendar of scheduled meetings of the Board, the EC (as defined in Section 6.1(a)), Supporting Organizations (as defined in Section 11.1), and Advisory Committees (as defined in Section 12.1); (b) a docket of all pending policy development matters, including their schedule and current status; (c) specific meeting notices and agendas as described below; (d) information on the ICANN Budget (as defined in Section 22.4(a)(i)), the IANA Budget (as defined in Section 22.4(b)(i)), annual audit, financial contributors and the amount of their contributions, and related matters; (e) 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; (f) announcements about ICANN activities of interest to significant segments of the ICANN community; (g) comments received from the community on policies being developed and other matters; (h) information about ICANN's physical meetings and public forums; and (i) other information of interest to the ICANN community.

Section 3.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 3.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 3.5. MINUTES AND PRELIMINARY REPORTS

All minutes of meetings of the Board, the Advisory Committees and Supporting Organizations (and any councils thereof) shall be approved promptly by the originating body and provided to the ICANN Secretary ("Secretary") for posting on the Website. All proceedings of the EC Administration (as defined in Section 6.3) and the EC shall be provided to the Secretary for posting on the Website.
No later than 11:59 p.m. on the second business day 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 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 resolutions made publicly available. The Secretary shall send notice to the Board and the Chairs of the Supporting Organizations (as set forth in Article 9 through Article 11) and Advisory Committees (as set forth in Article 12) informing them that the resolutions have been posted.
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 3.5(b) 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.
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 of the Board shall be made publicly available on the Website; provided, however, that any minutes of the Board 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 3.6. NOTICE AND COMMENT ON POLICY ACTIONS

(a) 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:

(i) 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;

(ii) 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 (such comment period to be aligned with ICANN's public comment practices), prior to any action by the Board; and

(iii) in those cases where the policy action affects public policy concerns, to request the opinion of the Governmental Advisory Committee ("GAC" or "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.

(b) 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 3.6(a)(ii), prior to any final Board action.

(c) After taking action on any policy subject to this Section 3.6, the Board shall publish in the meeting minutes the rationale for any resolution adopted by the Board (including the possible material effects, if any, of its decision on the global public interest, including a discussion of the material impacts to the security, stability and resiliency of the DNS, financial impacts or other issues that were considered by the Board in approving such resolutions), the vote of each Director voting on the resolution, and the separate statement of any Director desiring publication of such a statement.

(d) Where a Board resolution is consistent with GAC Consensus Advice (as defined in Section 12.2(a)(x)), the Board shall make a determination whether the GAC Consensus Advice was a material factor in the Board's adoption of such resolution, in which case the Board shall so indicate in such resolution approving the decision (a "GAC Consensus Board Resolution") and shall cite the applicable GAC Consensus Advice. To the extent practical, the Board shall ensure that GAC Consensus Board Resolutions only relate to the matters that were the subject of the applicable GAC Consensus Advice and not matters unrelated to the applicable GAC Consensus Advice. For the avoidance of doubt: (i) a GAC Consensus Board Resolution shall not have the effect of making any other Board resolutions in the same set or series so designated, unless other resolutions are specifically identified as such by the Board; and (ii) a Board resolution approving an action consistent with GAC Consensus Advice received during a standard engagement process in which input from all Supporting Organizations and Advisory Committees has been requested shall not be considered a GAC Consensus Board Resolution based solely on that input, unless the GAC Consensus Advice was a material factor in the Board's adoption of such resolution.

(e) GAC Carve-out

(i) Where a Board resolution is consistent with GAC Consensus Advice and the Board has determined that the GAC Consensus Advice was a material factor in the Board's adoption of such resolution as described in the relevant GAC Consensus Board Resolution, the Governmental Advisory Committee shall not participate as a decision-maker in the EC's exercise of its right to challenge the Board's implementation of such GAC Consensus Advice. In such cases, the Governmental Advisory Committee may participate in the EC in an advisory capacity only with respect to the applicable processes described in Annex D, but its views will not count as support or an objection for purposes of the thresholds needed to convene a community forum or exercise any right of the EC ("GAC Carve-out"). In the case of a Board Recall Process (as defined in Section 3.3 of Annex D), the GAC Carve-out shall only apply if an IRP Panel has found that, in implementing GAC Consensus Advice, the Board acted inconsistently with the Articles of Incorporation or these Bylaws.

(ii) When the GAC Carve-out applies (A) any petition notice provided in accordance with Annex D or Approval Action Board Notice (as defined in Section 1.2 of Annex D) shall include a statement that cites the specific GAC Consensus Board Resolution and the line item or provision that implements such specific GAC Consensus Board Resolution ("GAC Consensus Statement"), (B) the Governmental Advisory Committee shall not be eligible to support or object to any petition pursuant to Annex D or Approval Action (as defined in Section 1.1 of Annex D), and (C) any EC Decision (as defined in Section 4.1(a) of Annex D) that requires the support of four or more Decisional Participants (as defined in Section 6.1(a)) pursuant to Annex D shall instead require the support of three or more Decisional Participants with no more than one Decisional Participant objecting.

(iii) For the avoidance of doubt, the GAC Carve-out shall not apply to the exercise of the EC's rights where a material factor in the Board's decision was advice of the Governmental Advisory Committee that was not GAC Consensus Advice.

Section 3.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 4 ACCOUNTABILITY AND REVIEW

Section 4.1. PURPOSE

In carrying out its Mission, ICANN shall be accountable to the community for operating in accordance with the Articles of Incorporation and these Bylaws, including the Mission set forth in Article 1 of these Bylaws. This Article 4 creates reconsideration and independent review processes for certain actions as set forth in these Bylaws and procedures for periodic review of ICANN's structure and operations, which are intended to reinforce the various accountability mechanisms otherwise set forth in these Bylaws, including the transparency provisions of Article 3 and the Board and other selection mechanisms set forth throughout these Bylaws.

Section 4.2. RECONSIDERATION

(a) ICANN shall have in place a process by which any person or entity materially affected by an action or inaction of the ICANN Board or Staff may request ("Requestor") the review or reconsideration of that action or inaction by the Board. For purposes of these Bylaws, "Staff" includes employees and individual long-term paid contractors serving in locations where ICANN does not have the mechanisms to employ such contractors directly.

(b) The EC may file a Reconsideration Request (as defined in Section 4.2(c)) if approved pursuant to Section 4.3 of Annex D ("Community Reconsideration Request") and if the matter relates to the exercise of the powers and rights of the EC of these Bylaws. The EC Administration shall act as the Requestor for such a Community Reconsideration Request and shall act on behalf of the EC for such Community Reconsideration Request as directed by the Decisional Participants, as further described in Section 4.3 of Annex D.

(c) A Requestor may submit a request for reconsideration or review of an ICANN action or inaction ("Reconsideration Request") to the extent that the Requestor has been adversely affected by:

(i) One or more Board or Staff actions or inactions that contradict ICANN's Mission, Commitments, Core Values and/or established ICANN policy(ies);

(ii) One or more actions or inactions of the Board or Staff that have been taken or refused to be taken without consideration of material information, except where the Requestor could have submitted, but did not submit, the information for the Board's or Staff's consideration at the time of action or refusal to act; or

(iii) One or more actions or inactions of the Board or Staff that are taken as a result of the Board's or staff's reliance on false or inaccurate relevant information.

(d) Notwithstanding any other provision in this Section 4.2, the scope of reconsideration shall exclude the following:

(i) Disputes relating to country code top-level domain ("ccTLD") delegations and re-delegations;

(ii) Disputes relating to Internet numbering resources; and

(iii) Disputes relating to protocol parameters.

(e) The Board has designated the Board Accountability Mechanisms Committee to review and consider Reconsideration Requests. The Board Accountability Mechanisms Committee shall have the authority to:

(i) Evaluate Reconsideration Requests;

(ii) Summarily dismiss insufficient or frivolous Reconsideration Requests;

(iii) Evaluate Reconsideration Requests for urgent consideration;

(iv) Conduct whatever factual investigation is deemed appropriate;

(v) Request additional written submissions from the affected party, or from other parties; and

(vi) Make a recommendation to the Board on the merits of the Reconsideration Request, if it has not been summarily dismissed.

(f) ICANN shall absorb the normal administrative costs of the Reconsideration Request process. Except with respect to a Community Reconsideration Request, ICANN reserves the right to recover from a party requesting review or reconsideration any costs that 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 Requestor, who shall then have the option of withdrawing the request or agreeing to bear such costs.

(g) All Reconsideration Requests must be submitted by the Requestor to an email address designated by the Board Accountability Mechanisms Committee:

(i) For Reconsideration Requests that are not Community Reconsideration Requests, such Reconsideration Requests must be submitted:

(A)for requests challenging Board actions, within 30 days after the date on which information about the challenged Board action is first published in a resolution, unless the posting of the resolution is not accompanied by a rationale. In that instance, the request must be submitted within 30 days from the initial posting of the rationale;

(B)for requests challenging Staff actions, within 30 days after the date on which the Requestor became aware of, or reasonably should have become aware of, the challenged Staff action; or

(C)for requests challenging either Board or Staff inaction, within 30 days after the date on which the Requestor reasonably concluded, or reasonably should have concluded, that action would not be taken in a timely manner.

(ii) For Community Reconsideration Requests, such Community Reconsideration Requests must be submitted in accordance with the timeframe set forth in Section 4.3 of Annex D.

(h) To properly initiate a Reconsideration Request, all Requestors must review, complete and follow the Reconsideration Request form posted on the Website at https://www.icann.org/resources/pages/accountability/reconsideration-en. Requestors must also acknowledge and agree to the terms and conditions set forth in the form when filing.

(i) Requestors shall not provide more than 25 pages (double-spaced, 12-point font) of argument in support of a Reconsideration Request, not including exhibits. Requestors may submit all documentary evidence necessary to demonstrate why the action or inaction should be reconsidered, without limitation.

(j) Reconsideration Requests from different Requestors may be considered in the same proceeding so long as: (i) the requests involve the same general action or inaction; and (ii) the Requestors are similarly affected by such action or inaction. In addition, consolidated filings may be appropriate if the alleged causal connection and the resulting harm is substantially the same for all of the Requestors. Every Requestor must be able to demonstrate that it has been materially harmed and adversely impacted by the action or inaction giving rise to the request.

(k) The Board Accountability Mechanisms Committee shall review each Reconsideration Request upon its receipt to determine if it is sufficiently stated. The Board Accountability Mechanisms Committee may summarily dismiss a Reconsideration Request if: (i) the Requestor fails to meet the requirements for bringing a Reconsideration Request; or (ii) it is frivolous. The Board Accountability Mechanisms Committee's summary dismissal of a Reconsideration Request shall be documented and promptly posted on the Website.

(l) For all Reconsideration Requests that are not summarily dismissed, except Reconsideration Requests described in Section 4.2(l)(iii) and Community Reconsideration Requests, the Reconsideration Request shall be sent to the Ombudsman, who shall promptly proceed to review and consider the Reconsideration Request.

(i) The Ombudsman shall be entitled to seek any outside expert assistance as the Ombudsman deems reasonably necessary to perform this task to the extent it is within the budget allocated to this task.

(ii) The Ombudsman shall submit to the Board Accountability Mechanisms Committee his or her substantive evaluation of the Reconsideration Request within 15 days of the Ombudsman's receipt of the Reconsideration Request. The Board Accountability Mechanisms Committee shall thereafter promptly proceed to review and consideration.

(iii) For those Reconsideration Requests involving matters for which the Ombudsman has, in advance of the filing of the Reconsideration Request, taken a position while performing his or her role as the Ombudsman pursuant to Article 5 of these Bylaws, or involving the Ombudsman's conduct in some way, the Ombudsman shall recuse himself or herself and the Board Accountability Mechanisms Committee shall review the Reconsideration Request without involvement by the Ombudsman.

(m) The Board Accountability Mechanisms Committee may ask ICANN Staff for its views on a Reconsideration Request, which comments shall be made publicly available on the Website.

(n) The Board Accountability Mechanisms Committee may request additional information or clarifications from the Requestor, and may elect to conduct a meeting with the Requestor by telephone, email or, if acceptable to the Requestor, in person. A Requestor may also ask for an opportunity to be heard. The Board Accountability Mechanisms Committee's decision on any such request is final. To the extent any information gathered in such a meeting is relevant to any recommendation by the Board Accountability Mechanisms Committee, it shall so state in its recommendation.

(o) The Board Accountability Mechanisms Committee may also request information relevant to the Reconsideration Request from third parties. To the extent any information gathered is relevant to any recommendation by the Board Accountability Mechanisms Committee, it shall so state in its recommendation. Any information collected by ICANN from third parties shall be provided to the Requestor.

(p) The Board Accountability Mechanisms Committee shall act on a Reconsideration Request on the basis of the public written record, including information submitted by the Requestor, by the ICANN Staff, and by any third party.

(q) The Board Accountability Mechanisms Committee shall make a final recommendation to the Board with respect to a Reconsideration Request within 30 days following its receipt of the Ombudsman's evaluation (or 30 days following receipt of the Reconsideration Request involving those matters for which the Ombudsman recuses himself or herself or the receipt of the Community Reconsideration Request, if applicable), 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. In any event, the Board Accountability Mechanisms Committee shall endeavor to produce its final recommendation to the Board within 90 days of receipt of the Reconsideration Request. The final recommendation of the Board Accountability Mechanisms Committee shall be documented and promptly (i.e., as soon as practicable) posted on the Website and shall address each of the arguments raised in the Reconsideration Request. The Requestor may file a 10-page (double-spaced, 12-point font) document, not including exhibits, in rebuttal to the Board Accountability Mechanisms Committee's recommendation within 15 days of receipt of the recommendation, which shall also be promptly (i.e., as soon as practicable) posted to the Website and provided to the Board for its evaluation; provided, that such rebuttal shall: (i) be limited to rebutting or contradicting the issues raised in the Board Accountability Mechanisms Committee's final recommendation; and (ii) not offer new evidence to support an argument made in the Requestor's original Reconsideration Request that the Requestor could have provided when the Requestor initially submitted the Reconsideration Request.

(r) The Board shall not be bound to follow the recommendations of the Board Accountability Mechanisms Committee. The final decision of the Board and its rationale shall be made public as part of the preliminary report and minutes of the Board meeting at which action is taken. The Board shall issue its decision on the recommendation of the Board Accountability Mechanisms Committee within 45 days of receipt of the Board Accountability Mechanisms Committee's recommendation or as soon thereafter as feasible. Any circumstances that delay the Board from acting within this timeframe must be identified and posted on the Website. In any event, the Board's final decision shall be made within 135 days of initial receipt of the Reconsideration Request by the Board Accountability Mechanisms Committee. The Board's decision on the recommendation shall be posted on the Website in accordance with the Board's posting obligations as set forth in Article 3 of these Bylaws. If the Requestor so requests, the Board shall post both a recording and a transcript of the substantive Board discussion from the meeting at which the Board considered the Board Accountability Mechanisms Committee's recommendation. All briefing materials supplied to the Board shall be provided to the Requestor. The Board may redact such briefing materials and the recording and transcript on the basis that such information (i) relates to confidential personnel matters, (ii) is covered by attorney-client privilege, work product doctrine or other recognized legal privilege, (iii) is subject to a legal obligation that ICANN maintain its confidentiality, (iv) would disclose trade secrets, or (v) would present a material risk of negative impact to the security, stability or resiliency of the Internet. In the case of any redaction, ICANN will provide the Requestor a written rationale for such redaction. If a Requestor believes that a redaction was improper, the Requestor may use an appropriate accountability mechanism to challenge the scope of ICANN's redaction.

(s) If the Requestor believes that the Board action or inaction for which a Reconsideration Request is submitted is so urgent that the timing requirements of the process set forth in this Section 4.2 are too long, the Requestor may apply to the Board Accountability Mechanisms Committee for urgent consideration. Any request for urgent consideration must be made within two business days (as calculated by local time at the location of ICANN's principal office) of the posting of the resolution at issue. A request for urgent consideration must include a discussion of why the matter is urgent for reconsideration and must demonstrate a likelihood of success with the Reconsideration Request.

(t) The Board Accountability Mechanisms Committee shall respond to the request for urgent consideration within two business days after receipt of such request. If the Board Accountability Mechanisms Committee agrees to consider the matter with urgency, it will cause notice to be provided to the Requestor, who will have two business days after notification to complete the Reconsideration Request. The Board Accountability Mechanisms Committee shall issue a recommendation on the urgent Reconsideration Request within seven days of the completion of the filing of the Reconsideration Request, or as soon thereafter as feasible. If the Board Accountability Mechanisms Committee does not agree to consider the matter with urgency, the Requestor may still file a Reconsideration Request within the regular time frame set forth within these Bylaws.

(u) The Board Accountability Mechanisms Committee shall submit a report to the Board on an annual basis containing at least the following information for the preceding calendar year:

(i) the number and general nature of Reconsideration Requests received, including an identification if the Reconsideration Requests were acted upon, summarily dismissed, or remain pending;

(ii) for any Reconsideration Requests that remained pending at the end of the calendar year, the average length of time for which such Reconsideration Requests have been pending, and a description of the reasons for any Reconsideration Request pending for more than ninety (90) days;

(iii) an explanation of any other mechanisms available to ensure that ICANN is accountable to persons materially affected by its decisions; and

(iv) whether or not, in the Board Accountability Mechanisms 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.

Section 4.3. INDEPENDENT REVIEW PROCESS FOR COVERED ACTIONS

(a) In addition to the reconsideration process described in Section 4.2, ICANN shall have a separate process for independent third-party review of Disputes (defined in Section 4.3(b)(iii)) alleged by a Claimant (as defined in Section 4.3(b)(i)) to be within the scope of the Independent Review Process ("IRP"). The IRP is intended to hear and resolve Disputes for the following purposes ("Purposes of the IRP"):

(i) Ensure that ICANN does not exceed the scope of its Mission and otherwise complies with its Articles of Incorporation and Bylaws.

(ii) Empower the global Internet community and Claimants to enforce compliance with the Articles of Incorporation and Bylaws through meaningful, affordable and accessible expert review of Covered Actions (as defined in Section 4.3(b)(i)).

(iii) Ensure that ICANN is accountable to the global Internet community and Claimants.

(iv) Address claims that ICANN has failed to enforce its rights under the IANA Naming Function Contract (as defined in Section 16.3(a)).

(v) Provide a mechanism by which direct customers of the IANA naming functions may seek resolution of PTI (as defined in Section 16.1) service complaints that are not resolved through mediation.

(vi) Reduce Disputes by creating precedent to guide and inform the Board, Officers (as defined in Section 15.1), Staff members, Supporting Organizations, Advisory Committees, and the global Internet community in connection with policy development and implementation.

(vii) Secure the accessible, transparent, efficient, consistent, coherent, and just resolution of Disputes.

(viii) Lead to binding, final resolutions consistent with international arbitration norms that are enforceable in any court with proper jurisdiction.

(ix) Provide a mechanism for the resolution of Disputes, as an alternative to legal action in the civil courts of the United States or other jurisdictions.

This Section 4.3 shall be construed, implemented, and administered in a manner consistent with these Purposes of the IRP.

(b) The scope of the IRP is defined with reference to the following terms:

(i) A "Claimant" is any legal or natural person, group, or entity including, but not limited to the EC, a Supporting Organization, or an Advisory Committee that has been materially affected by a Dispute. To be materially affected by a Dispute, the Claimant must suffer an injury or harm that is directly and causally connected to the alleged violation.

(A)The EC is deemed to be materially affected by all Covered Actions. ICANN shall not assert any defenses of standing or capacity against the EC in any forum.

(B)ICANN shall not object to the standing of the EC, a Supporting Organization, or an Advisory Committee to participate in an IRP, to compel an IRP, or to enforce an IRP decision on the basis that it is not a legal person with capacity to sue. No special pleading of a Claimant's capacity or of the legal existence of a person that is a Claimant shall be required in the IRP proceedings. No Claimant shall be allowed to proceed if the IRP Panel (as defined in Section 4.3(g)) concludes based on evidence submitted to it that the Claimant does not fairly or adequately represent the interests of those on whose behalf the Claimant purports to act.

(ii) "Covered Actions" are defined as any actions or failures to act by or within ICANN committed by the Board, individual Directors, Officers, or Staff members that give rise to a Dispute.

(iii) "Disputes" are defined as:

(A)Claims that Covered Actions constituted an action or inaction that violated the Articles of Incorporation or Bylaws, including but not limited to any action or inaction that:

(1) exceeded the scope of the Mission;

(2) resulted from action taken in response to advice or input from any Advisory Committee or Supporting Organization that are claimed to be inconsistent with the Articles of Incorporation or Bylaws;

(3) resulted from decisions of process-specific expert panels that are claimed to be inconsistent with the Articles of Incorporation or Bylaws;

(4) resulted from a response to a DIDP (as defined in Section 22.7(d)) request that is claimed to be inconsistent with the Articles of Incorporation or Bylaws; or

(5) arose from claims involving rights of the EC as set forth in the Articles of Incorporation or Bylaws.

(B)Claims that ICANN, the Board, individual Directors, Officers or Staff members have not enforced ICANN's contractual rights with respect to the IANA Naming Function Contract, and

(C)Claims regarding PTI service complaints by direct customers of the IANA naming functions that are not resolved through mediation.

(i) EC challenges to the result(s) of a PDP, unless the Supporting Organization(s) that approved the PDP supports the EC bringing such a challenge;

(ii) Claims relating to ccTLD delegations and re-delegations;

(iii) Claims relating to Internet numbering resources, and

(iv) Claims relating to protocol parameters.

(d) An IRP shall commence with the Claimant's filing of a written statement of a Dispute (a "Claim") with the IRP Provider (described in Section 4.3(m) below). For the EC to commence an IRP ("Community IRP"), the EC shall first comply with the procedures set forth in Section 4.2 of Annex D.

(e) Cooperative Engagement Process

(i) Except for Claims brought by the EC in accordance with this Section 4.3 and Section 4.2 of Annex D, prior to the filing of a Claim, the parties are strongly encouraged to participate in a non-binding Cooperative Engagement Process ("CEP") for the purpose of attempting to resolve and/or narrow the Dispute. CEPs shall be conducted pursuant to the CEP Rules to be developed with community involvement, adopted by the Board, and as amended from time to time.

(ii) The CEP is voluntary. However, except for Claims brought by the EC in accordance with this Section 4.3 and Section 4.2 of Annex D, if the Claimant does not participate in good faith in the CEP and ICANN is the prevailing party in the IRP, the IRP Panel shall award to ICANN all reasonable fees and costs incurred by ICANN in the IRP, including legal fees.

(iii) Either party may terminate the CEP efforts if that party: (A) concludes in good faith that further efforts are unlikely to produce agreement; or (B) requests the inclusion of an independent dispute resolution facilitator ("IRP Mediator") after at least one CEP meeting.

(iv) Unless all parties agree on the selection of a particular IRP Mediator, any IRP Mediator appointed shall be selected from the members of the Standing Panel (described in Section 4.3(j) below) by its Chair, but such IRP Mediator shall not thereafter be eligible to serve as a panelist presiding over an IRP on the matter.

(f) ICANN hereby waives any defenses that may be afforded under Section 5141 of the California Corporations Code ("CCC") against any Claimant, and shall not object to the standing of any such Claimant to participate in or to compel an IRP, or to enforce an IRP decision on the basis that such Claimant may not otherwise be able to assert that a Covered Action is ultra vires.

(g) Upon the filing of a Claim, an Independent Review Process Panel ("IRP Panel", described in Section 4.3(k) below) shall be selected in accordance with the Rules of Procedure (as defined in Section 4.3(n)(i)). Following the selection of an IRP Panel, that IRP Panel shall be charged with hearing and resolving the Dispute, considering the Claim and ICANN's written response ("Response") in compliance with the Articles of Incorporation and Bylaws, as understood in light of prior IRP Panel decisions decided under the same (or an equivalent prior) version of the provision of the Articles of Incorporation and Bylaws at issue, and norms of applicable law. If no Response is timely filed by ICANN, the IRP Panel may accept the Claim as unopposed and proceed to evaluate and decide the Claim pursuant to the procedures set forth in these Bylaws.

(h) After a Claim is referred to an IRP Panel, the parties are urged to participate in conciliation discussions for the purpose of attempting to narrow the issues that are to be addressed by the IRP Panel.

(i) Each IRP Panel shall conduct an objective, de novo examination of the Dispute.

(i) With respect to Covered Actions, the IRP Panel shall make findings of fact to determine whether the Covered Action constituted an action or inaction that violated the Articles of Incorporation or Bylaws.

(ii) All Disputes shall be decided in compliance with the Articles of Incorporation and Bylaws, as understood in the context of the norms of applicable law and prior relevant IRP decisions.

(iii) For Claims arising out of the Board's exercise of its fiduciary duties, the IRP Panel shall not replace the Board's reasonable judgment with its own so long as the Board's action or inaction is within the realm of reasonable business judgment.

(iv) With respect to claims that ICANN has not enforced its contractual rights with respect to the IANA Naming Function Contract, the standard of review shall be whether there was a material breach of ICANN's obligations under the IANA Naming Function Contract, where the alleged breach has resulted in material harm to the Claimant.

(v) For avoidance of doubt, IRPs initiated through the mechanism contemplated at Section 4.3(a)(iv) above, shall be subject to a separate standard of review as defined in the IANA Naming Function Contract.

(j) Standing Panel

(i) There shall be an omnibus standing panel of at least seven members (the "Standing Panel") each of whom shall possess significant relevant legal expertise in one or more of the following areas: international law, corporate governance, judicial systems, alternative dispute resolution and/or arbitration. Each member of the Standing Panel shall also have knowledge, developed over time, regarding the DNS and ICANN's Mission, work, policies, practices, and procedures. Members of the Standing Panel shall receive at a minimum, training provided by ICANN on the workings and management of the Internet's unique identifiers and other appropriate training as recommended by the IRP Implementation Oversight Team (described in Section 4.3(n)(i)).

(ii) ICANN shall, in consultation with the Supporting Organizations and Advisory Committees, initiate a four-step process to establish the Standing Panel to ensure the availability of a number of IRP panelists that is sufficient to allow for the timely resolution of Disputes consistent with the Purposes of the IRP.

(A)ICANN, in consultation with the Supporting Organizations and Advisory Committees, shall initiate a tender process for an organization to provide administrative support for the IRP Provider (as defined in Section 4.3(m)), beginning by consulting the "IRP Implementation Oversight Team" (described in Section 4.3(n)(i)) on a draft tender document.

(B)ICANN shall issue a call for expressions of interest from potential panelists, and work with the Supporting Organizations and Advisory Committees and the Board to identify and solicit applications from well-qualified candidates, and to conduct an initial review and vetting of applications.

(C)The Supporting Organizations and Advisory Committees shall nominate a slate of proposed panel members from the well-qualified candidates identified per the process set forth in Section 4.3(j)(ii)(B).

(D)Final selection shall be subject to Board confirmation, which shall not be unreasonably withheld.

(iii) Appointments to the Standing Panel shall be made for a fixed term of five years with no removal except for specified cause in the nature of corruption, misuse of position, fraud or criminal activity. The recall process shall be developed by the IRP Implementation Oversight Team.

(iv) Reasonable efforts shall be taken to achieve cultural, linguistic, gender, and legal tradition diversity, and diversity by Geographic Region (as defined in Section 7.5).

(k) IRP Panel

(i) A three-member IRP Panel shall be selected from the Standing Panel to hear a specific Dispute.

(ii) The Claimant and ICANN shall each select one panelist from the Standing Panel, and the two panelists selected by the parties will select the third panelist from the Standing Panel. In the event that a Standing Panel is not in place when an IRP Panel must be convened for a given proceeding or is in place but does not have capacity due to other IRP commitments or the requisite diversity of skill and experience needed for a particular IRP proceeding, the Claimant and ICANN shall each select a qualified panelist from outside the Standing Panel and the two panelists selected by the parties shall select the third panelist. In the event that no Standing Panel is in place when an IRP Panel must be convened and the two party-selected panelists cannot agree on the third panelist, the IRP Provider's rules shall apply to selection of the third panelist.

(iii) Assignment from the Standing Panel to IRP Panels shall take into consideration the Standing Panel members' individual experience and expertise in issues related to highly technical, civil society, business, diplomatic, and regulatory skills as needed by each specific proceeding, and such requests from the parties for any particular expertise.

(iv) Upon request of an IRP Panel, the IRP Panel shall have access to independent skilled technical experts at the expense of ICANN, although all substantive interactions between the IRP Panel and such experts shall be conducted on the record, except when public disclosure could materially and unduly harm participants, such as by exposing trade secrets or violating rights of personal privacy.

(v) IRP Panel decisions shall be made by a simple majority of the IRP Panel.

(l) All IRP proceedings shall be administered in English as the primary working language, with provision of translation services for Claimants if needed.

(m) IRP Provider

(i) All IRP proceedings shall be administered by a well-respected international dispute resolution provider ("IRP Provider"). The IRP Provider shall receive and distribute IRP Claims, Responses, and all other submissions arising from an IRP at the direction of the IRP Panel, and shall function independently from ICANN.

(n) Rules of Procedure

(i) An IRP Implementation Oversight Team shall be established in consultation with the Supporting Organizations and Advisory Committees and comprised of members of the global Internet community. The IRP Implementation Oversight Team, and once the Standing Panel is established the IRP Implementation Oversight Team in consultation with the Standing Panel, shall develop clear published rules for the IRP ("Rules of Procedure") that conform with international arbitration norms and are streamlined, easy to understand and apply fairly to all parties. Upon request, the IRP Implementation Oversight Team shall have assistance of counsel and other appropriate experts.

(ii) The Rules of Procedure shall be informed by international arbitration norms and consistent with the Purposes of the IRP. Specialized Rules of Procedure may be designed for reviews of PTI service complaints that are asserted by direct customers of the IANA naming functions and are not resolved through mediation. The Rules of Procedure shall be published and subject to a period of public comment that complies with the designated practice for public comment periods within ICANN, and take effect upon approval by the Board, such approval not to be unreasonably withheld.

(iii) The Standing Panel may recommend amendments to such Rules of Procedure as it deems appropriate to fulfill the Purposes of the IRP, however no such amendment shall be effective without approval by the Board after publication and a period of public comment that complies with the designated practice for public comment periods within ICANN.

(iv) The Rules of Procedure are intended to ensure fundamental fairness and due process and shall at a minimum address the following elements:

(A) The time within which a Claim must be filed after a Claimant becomes aware or reasonably should have become aware of the action or inaction giving rise to the Dispute;

(B)Issues relating to joinder, intervention, and consolidation of Claims;

(C)Rules governing written submissions, including the required elements of a Claim, other requirements or limits on content, time for filing, length of statements, number of supplemental statements, if any, permitted evidentiary support (factual and expert), including its length, both in support of a Claimant's Claim and in support of ICANN's Response;

(D)Availability and limitations on discovery methods;

(E)Whether hearings shall be permitted, and if so what form and structure such hearings would take;

(F)Procedures if ICANN elects not to respond to an IRP; and

(G)The standards and rules governing appeals from IRP Panel decisions, including which IRP Panel decisions may be appealed.

(o) Subject to the requirements of this Section 4.3, each IRP Panel shall have the authority to:

(i) Summarily dismiss Disputes that are brought without standing, lack substance, or are frivolous or vexatious;

(ii) Request additional written submissions from the Claimant or from other parties;

(iii) Declare whether a Covered Action constituted an action or inaction that violated the Articles of Incorporation or Bylaws, declare whether ICANN failed to enforce ICANN's contractual rights with respect to the IANA Naming Function Contract or resolve PTI service complaints by direct customers of the IANA naming functions, as applicable;

(iv) Recommend that ICANN stay any action or decision, or take necessary interim action, until such time as the opinion of the IRP Panel is considered;

(v) Consolidate Disputes if the facts and circumstances are sufficiently similar, and take such other actions as are necessary for the efficient resolution of Disputes;

(vi) Determine the timing for each IRP proceeding; and

(vii) Determine the shifting of IRP costs and expenses consistent with Section 4.3(r).

(p) A Claimant may request interim relief. Interim relief may include prospective relief, interlocutory relief, or declaratory or injunctive relief, and specifically may include a stay of the challenged ICANN action or decision until such time as the opinion of the IRP Panel is considered as described in Section 4.3(o)(iv), in order to maintain the status quo. A single member of the Standing Panel ("Emergency Panelist") shall be selected to adjudicate requests for interim relief. In the event that no Standing Panel is in place when an Emergency Panelist must be selected, the IRP Provider's rules shall apply to the selection of the Emergency Panelist. Interim relief may only be provided if the Emergency Panelist determines that the Claimant has established all of the following factors:

(i) A harm for which there will be no adequate remedy in the absence of such relief;

(ii) Either: (A) likelihood of success on the merits; or (B) sufficiently serious questions related to the merits; and

(iii) A balance of hardships tipping decidedly toward the party seeking relief.

(q) Conflicts of Interest

(i) Standing Panel members must be independent of ICANN and its Supporting Organizations and Advisory Committees, and so must adhere to the following criteria:

(A)Upon consideration for the Standing Panel and on an ongoing basis, Panelists shall have an affirmative obligation to disclose any material relationship with ICANN, a Supporting Organization, an Advisory Committee, or any other participant in an IRP proceeding.

(B)Additional independence requirements to be developed by the IRP Implementation Oversight Team, including term limits and restrictions on post-term appointment to other ICANN positions.

(ii) The IRP Provider shall disclose any material relationship with ICANN, a Supporting Organization, an Advisory Committee, or any other participant in an IRP proceeding.

(r) ICANN shall bear all the administrative costs of maintaining the IRP mechanism, including compensation of Standing Panel members. Except as otherwise provided in Section 4.3(e)(ii), each party to an IRP proceeding shall bear its own legal expenses, except that ICANN shall bear all costs associated with a Community IRP, including the costs of all legal counsel and technical experts. Nevertheless, except with respect to a Community IRP, the IRP Panel may shift and provide for the losing party to pay administrative costs and/or fees of the prevailing party in the event it identifies the losing party's Claim or defense as frivolous or abusive.

(s) An IRP Panel should complete an IRP proceeding expeditiously, issuing an early scheduling order and its written decision no later than six months after the filing of the Claim, except as otherwise permitted under the Rules of Procedure. The preceding sentence does not provide the basis for a Covered Action.

(t) Each IRP Panel shall make its decision based solely on the documentation, supporting materials, and arguments submitted by the parties, and in its decision shall specifically designate the prevailing party as to each part of a Claim.

(u) All IRP Panel proceedings shall be conducted on the record, and documents filed in connection with IRP Panel proceedings shall be posted on the Website, except for settlement negotiation or other proceedings that could materially and unduly harm participants if conducted publicly. The Rules of Procedure, and all Claims, petitions, and decisions shall promptly be posted on the Website when they become available. Each IRP Panel may, in its discretion, grant a party's request to keep certain information confidential, such as trade secrets, but only if such confidentiality does not materially interfere with the transparency of the IRP proceeding.

(v) Subject to this Section 4.3, all IRP decisions shall be written and made public, and shall reflect a well-reasoned application of how the Dispute was resolved in compliance with the Articles of Incorporation and Bylaws, as understood in light of prior IRP decisions decided under the same (or an equivalent prior) version of the provision of the Articles of Incorporation and Bylaws at issue, and norms of applicable law.

(w) Subject to any limitations established through the Rules of Procedure, an IRP Panel decision may be appealed to the full Standing Panel sitting en banc within sixty (60) days of issuance of such decision.

(x) The IRP is intended as a final, binding arbitration process.

(i) IRP Panel decisions are binding final decisions to the extent allowed by law unless timely and properly appealed to the en banc Standing Panel. En banc Standing Panel decisions are binding final decisions to the extent allowed by law.

(ii) IRP Panel decisions and decisions of an en banc Standing Panel upon an appeal are intended to be enforceable in any court with jurisdiction over ICANN without a de novo review of the decision of the IRP Panel or en banc Standing Panel, as applicable, with respect to factual findings or conclusions of law.

(iii) ICANN intends, agrees, and consents to be bound by all IRP Panel decisions of Disputes of Covered Actions as a final, binding arbitration.

(A)Where feasible, the Board shall consider its response to IRP Panel decisions at the Board's next meeting, and shall affirm or reject compliance with the decision on the public record based on an expressed rationale. The decision of the IRP Panel, or en banc Standing Panel, shall be final regardless of such Board action, to the fullest extent allowed by law.

(B)If an IRP Panel decision in a Community IRP is in favor of the EC, the Board shall comply within 30 days of such IRP Panel decision.

(C)If the Board rejects an IRP Panel decision without undertaking an appeal to the en banc Standing Panel or rejects an en banc Standing Panel decision upon appeal, the Claimant or the EC may seek enforcement in a court of competent jurisdiction. In the case of the EC, the EC Administration may convene as soon as possible following such rejection and consider whether to authorize commencement of such an action.

(iv) By submitting a Claim to the IRP Panel, a Claimant thereby agrees that the IRP decision is intended to be a final, binding arbitration decision with respect to such Claimant. Any Claimant that does not consent to the IRP being a final, binding arbitration may initiate a non-binding IRP if ICANN agrees; provided that such a non-binding IRP decision is not intended to be and shall not be enforceable.

(y) ICANN shall seek to establish means by which community, non-profit Claimants and other Claimants that would otherwise be excluded from utilizing the IRP process may meaningfully participate in and have access to the IRP process.

Section 4.4. PERIODIC REVIEW OF ICANN STRUCTURE AND OPERATIONS

(a) 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 (as defined in Section 8.1) 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, council or committee has a continuing purpose in the ICANN structure, (ii) if so, whether any change in structure or operations is desirable to improve its effectiveness and (iii) whether that organization, council or committee is accountable to its constituencies, stakeholder groups, organizations and other stakeholders.

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 Directors, subject to any rights of the EC under the Articles of Incorporation and these Bylaws.

(b) The Governmental Advisory Committee shall provide its own review mechanisms.

Section 4.5. ANNUAL REVIEW

ICANN will produce an annual report on the state of the accountability and transparency reviews, which will discuss the status of the implementation of all review processes required bySection 4.6 and the status of ICANN's implementation of the recommendations set forth in the final reports issued by the review teams to the Board following the conclusion of such review ("Annual Review Implementation Report"). The Annual Review Implementation Report will be posted on the Website for public review and comment. Each Annual Review Implementation Report will be considered by the Board and serve as an input to the continuing process of implementing the recommendations from the review teams set forth in the final reports of such review teams required in Section 4.6.

Section 4.6. SPECIFIC REVIEWS

(a) Review Teams and Reports

(i) Review teams will be established for each applicable review, which will include both a limited number of members and an open number of observers. The chairs of the Supporting Organizations and Advisory Committees participating in the applicable review shall select a group of up to 21 review team members from among the prospective members nominated by the Supporting Organizations and Advisory Committees, balanced for diversity and skill. In addition, the Board may designate one Director or Liaison to serve as a member of the review team. Specific guidance on the selection process is provided within the operating standards developed for the conduct of reviews under this Section 4.6 (the "Operating Standards"). The Operating Standards shall be developed through community consultation, including public comment opportunities as necessary that comply with the designated practice for public comment periods within ICANN. The Operating Standards must be aligned with the following guidelines:

(A)Each Supporting Organization and Advisory Committee participating in the applicable review may nominate up to seven prospective members for the review team;

(B)Any Supporting Organization or Advisory Committee nominating at least one, two or three prospective review team members shall be entitled to have those one, two or three nominees selected as members to the review team, so long as the nominees meet any applicable criteria for service on the team; and

(C)If any Supporting Organization or Advisory Committee has not nominated at least three prospective review team members, the Chairs of the Supporting Organizations and Advisory Committees shall be responsible for the determination of whether all 21 SO/AC member seats shall be filled and, if so, how the seats should be allocated from among those nominated.

(ii) Members and liaisons of review teams shall disclose to ICANN and their applicable review team any conflicts of interest with a specific matter or issue under review in accordance with the most recent Board-approved practices and Operating Standards. The applicable review team may exclude from the discussion of a specific complaint or issue any member deemed by the majority of review team members to have a conflict of interest. Further details on the conflict of interest practices are included in the Operating Standards.

(iii) Review team decision-making practices shall be specified in the Operating Standards, with the expectation that review teams shall try to operate on a consensus basis. In the event a consensus cannot be found among the members of a review team, a majority vote of the members may be taken.

(iv) Review teams may also solicit and select independent experts to render advice as requested by the review team. ICANN shall pay the reasonable fees and expenses of such experts for each review contemplated by this Section 4.6 to the extent such fees and costs are consistent with the budget assigned for such review. Guidelines on how review teams are to work with and consider independent expert advice are specified in the Operating Standards.

(v) Each review team may recommend that the applicable type of review should no longer be conducted or should be amended.

(vi) Confidential Disclosure to Review Teams

(A) To facilitate transparency and openness regarding ICANN's deliberations and operations, the review teams, or a subset thereof, shall have access to ICANN internal information and documents pursuant to the Confidential Disclosure Framework set forth in the Operating Standards (the "Confidential Disclosure Framework"). The Confidential Disclosure Framework must be aligned with the following guidelines:

(1) ICANN must provide a justification for any refusal to reveal requested information. ICANN's refusal can be appealed to the Ombudsman and/or the ICANN Board for a ruling on the disclosure request.

(2) ICANN may designate certain documents and information as "for review team members only" or for a subset of the review team members based on conflict of interest. ICANN's designation of documents may also be appealed to the Ombudsman and/or the ICANN Board.

(3) ICANN may require review team members to sign a non-disclosure agreement before accessing documents.

(vii) Reports

(A) Each report of the review team shall describe the degree of consensus or agreement reached by the review team on each recommendation contained in such report. Any member of a review team not in favor of a recommendation of its review team (whether as a result of voting against a matter or objecting to the consensus position) may record a minority dissent to such recommendation, which shall be included in the report of the review team. The review team shall attempt to prioritize each of its recommendations and provide a rationale for such prioritization.

(B) At least one draft report of the review team shall be posted on the Website for public review and comment. The review team must consider the public comments received in response to any posted draft report and shall amend the report as the review team deems appropriate and in the public interest before submitting its final report to the Board. The final report should include an explanation of how public comments were considered as well as a summary of changes made in response to public comments.

(C) Each final report of a review team shall be published for public comment in advance of the Board's consideration. Within six months of receipt of a final report, the Board shall consider such final report and the public comments on the final report, and determine whether to approve the recommendations in the final report. If the Board does not approve any or all of the recommendations, the written rationale supporting the Board's decision shall include an explanation for the decision on each recommendation that was not approved. The Board shall promptly direct implementation of the recommendations that were approved.

(b) Accountability and Transparency Review

(i) The Board shall cause a periodic review of ICANN's execution of its commitment to maintain and improve robust mechanisms for public input, accountability, and transparency so as to ensure that the outcomes of its decision-making reflect the public interest and are accountable to the Internet community ("Accountability and Transparency Review").

(ii) The issues that the review team for the Accountability and Transparency Review (the "Accountability and Transparency Review Team") may assess include, but are not limited to, the following:

(A) assessing and improving Board governance which shall include an ongoing evaluation of Board performance, the Board selection process, the extent to which the Board's composition and allocation structure meets ICANN's present and future needs, and the appeal mechanisms for Board decisions contained in these Bylaws;

(B) assessing the role and effectiveness of the GAC's interaction with the Board and with the broader ICANN community, and making recommendations for improvement to ensure effective consideration by ICANN of GAC input on the public policy aspects of the technical coordination of the DNS;

(C) assessing and improving the processes by which ICANN receives public input (including adequate explanation of decisions taken and the rationale thereof);

(D) assessing the extent to which ICANN's decisions are supported and accepted by the Internet community;

(E) assessing the policy development process to facilitate enhanced cross community deliberations, and effective and timely policy development; and

(F) assessing and improving the Independent Review Process.

(iii) The Accountability and Transparency Review Team shall also assess the extent to which prior Accountability and Transparency Review recommendations have been implemented and the extent to which implementation of such recommendations has resulted in the intended effect.

(iv) The Accountability and Transparency Review Team may recommend to the Board the termination or amendment of other periodic reviews required by thisSection 4.6, and may recommend to the Board the creation of additional periodic reviews.

(v) The Accountability and Transparency Review Team should issue its final report within one year of convening its first meeting.

(vi) The Accountability and Transparency Review shall be conducted no less frequently than every five years measured from the date the previous Accountability and Transparency Review Team was convened.

(i) The Board shall cause a periodic review of ICANN's execution of its commitment to enhance the operational stability, reliability, resiliency, security, and global interoperability of the systems and processes, both internal and external, that directly affect and/or are affected by the Internet's system of unique identifiers that ICANN coordinates ("SSR Review").

(ii) The issues that the review team for the SSR Review ("SSR Review Team") may assess are the following:

(A) security, operational stability and resiliency matters, both physical and network, relating to the coordination of the Internet's system of unique identifiers;

(B) conformance with appropriate security contingency planning framework for the Internet's system of unique identifiers; and

(C) maintaining clear and globally interoperable security processes for those portions of the Internet's system of unique identifiers that ICANN coordinates.

(iii) The SSR Review Team shall also assess the extent to which ICANN has successfully implemented its security efforts, the effectiveness of the security efforts to deal with actual and potential challenges and threats to the security and stability of the DNS, and the extent to which the security efforts are sufficiently robust to meet future challenges and threats to the security, stability and resiliency of the DNS, consistent with ICANN's Mission.

(iv) The SSR Review Team shall also assess the extent to which prior SSR Review recommendations have been implemented and the extent to which implementation of such recommendations has resulted in the intended effect.

(v) The SSR Review shall be conducted no less frequently than every five years, measured from the date the previous SSR Review Team was convened.

(d) Competition, Consumer Trust and Consumer Choice Review

(i) ICANN will ensure that it will adequately address issues of competition, consumer protection, security, stability and resiliency, malicious abuse issues, sovereignty concerns, and rights protection prior to, or concurrent with, authorizing an increase in the number of new top-level domains in the root zone of the DNS pursuant to an application process initiated on or after the date of these Bylaws ("New gTLD Round").

(ii) After a New gTLD Round has been in operation for one year, the Board shall cause a competition, consumer trust and consumer choice review as specified in this Section 4.6(d) ("CCT Review").

(iii) The review team for the CCT Review ("CCT Review Team") will examine (A) the extent to which the expansion of gTLDs has promoted competition, consumer trust and consumer choice and (B) the effectiveness of the New gTLD Round's application and evaluation process and safeguards put in place to mitigate issues arising from the New gTLD Round.

(iv) For each of its recommendations, the CCT Review Team should indicate whether the recommendation, if accepted by the Board, must be implemented before opening subsequent rounds of new generic top-level domain applications periods.

(v) The CCT Review Team shall also assess the extent to which prior CCT Review recommendations have been implemented and the extent to which implementation of such recommendations has resulted in the intended effect.

(e) Registration Directory Service Review

(i) Subject to applicable laws, ICANN shall use commercially reasonable efforts to enforce its policies relating to registration directory services and shall work with Supporting Organizations and Advisory Committees to explore structural changes to improve accuracy and access to generic top-level domain registration data, as well as consider safeguards for protecting such data.

(ii) The Board shall cause a periodic review to assess the effectiveness of the then current gTLD registry directory service and whether its implementation meets the legitimate needs of law enforcement, promoting consumer trust and safeguarding registrant data ("Directory Service Review").

(iii) The review team for the Directory Service Review ("Directory Service Review Team") will consider the Organisation for Economic Co-operation and Development ("OECD") Guidelines on the Protection of Privacy and Transborder Flows of Personal Data as defined by the OECD in 1980 and amended in 2013 and as may be amended from time to time.

(iv) The Directory Service Review Team shall assess the extent to which prior Directory Service Review recommendations have been implemented and the extent to which implementation of such recommendations has resulted in the intended effect.

(v) The Directory Service Review shall be conducted no less frequently than every five years, measured from the date the previous Directory Service Review Team was convened, except that the first Directory Service Review to be conducted after 1 October 2016 shall be deemed to be timely if the applicable Directory Service Review Team is convened on or before 31 October 2016.

Section 4.7. COMMUNITY MEDIATION

(a) If the Board refuses or fails to comply with a duly authorized and valid EC Decision under these Bylaws, the EC Administration representative of any Decisional Participant who supported the exercise by the EC of its rights in the applicable EC Decision during the applicable decision period may request that the EC initiate a mediation process pursuant to this Section 4.7. The Board shall be deemed to have refused or failed to comply with a duly authorized and valid EC Decision if the Board has not complied with the EC Decision within 30 days of being notified of the relevant EC Decision.

(b) If a Mediation Initiation Notice (as defined in Section 4.1(a) of Annex D) is delivered to the Secretary pursuant to and in compliance with Section 4.1(a) of Annex D, as soon as reasonably practicable thereafter, the EC Administration shall designate individuals to represent the EC in the mediation ("Mediation Administration") and the Board shall designate representatives for the mediation ("Board Mediation Representatives"). Members of the EC Administration and the Board can designate themselves as representatives. ICANN shall promptly post the Mediation Initiation Notice on the Website.

(c) There shall be a single mediator who shall be selected by the agreement of the Mediation Administration and Board Mediation Representatives. The Mediation Administration shall propose a slate of at least five potential mediators, and the Board Mediation Representatives shall select a mediator from the slate or request a new slate until a mutually-agreed mediator is selected. The Board Mediation Representatives may recommend potential mediators for inclusion on the slates selected by the Mediation Administration. The Mediation Administration shall not unreasonably decline to include mediators recommended by the Board Mediation Representatives on proposed slates and the Board Mediation Representatives shall not unreasonably withhold consent to the selection of a mediator on slates proposed by the Mediation Administration.

(d) The mediator shall be a licensed attorney with general knowledge of contract law and general knowledge of the DNS and ICANN. The mediator may not have any ongoing business relationship with ICANN, any Supporting Organization (or constituent thereof), any Advisory Committee (or constituent thereof), the EC Administration or the EC. The mediator must confirm in writing that he or she is not, directly or indirectly, and will not become during the term of the mediation, an employee, partner, executive officer, director, consultant or advisor of ICANN, any Supporting Organization (or constituent thereof), any Advisory Committee (or constituent thereof), the EC Administration or the EC.

(e) The mediator shall conduct the mediation in accordance with these Bylaws, the laws of California and the rules and procedures of a well-respected international dispute resolution provider, which may be the IRP Provider. The arbitration will be conducted in the English language consistent with the provisions relevant for mediation under the IRP Rules of Procedure and will occur in Los Angeles County, California, unless another location is mutually-agreed between the Mediation Administration and Board Mediation Representatives.

(f) The Mediation Administration and the Board Mediation Representatives shall discuss the dispute in good faith and attempt, with the mediator's assistance, to reach an amicable resolution of the dispute.

(g) ICANN shall bear all costs of the mediator.

(h) If the Mediation Administration and the Board Mediation Representatives have engaged in good faith participation in the mediation but have not resolved the dispute for any reason, the Mediation Administration or the Board Mediation Representatives may terminate the mediation at any time by declaring an impasse.

(i) If a resolution to the dispute is reached by the Mediation Administration and the Board Mediation Representatives, the Mediation Administration and the Board Mediation Representatives shall document such resolution including recommendations ("Mediation Resolution" and the date of such resolution, the "Mediation Resolution Date"). ICANN shall promptly post the Mediation Resolution on the Website (in no event later than 14 days after mediation efforts are completed) and the EC Administration shall promptly notify the Decisional Participants of the Mediation Resolution.

(j) The EC shall be deemed to have accepted the Mediation Resolution if it has not delivered an EC Community IRP Initiation Notice (as defined in Section 4.2(e) of Annex D) pursuant to and in compliance with Section 4.2 of Annex D within eighty (80) days following the Mediation Resolution Date.

ARTICLE 5 OMBUDSMAN

Section 5.1. OFFICE OF OMBUDSMAN

(a) ICANN shall maintain an Office of Ombudsman ("Office of Ombudsman"), to be managed by an ombudsman ("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.

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

(d) 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 Section 5.1 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 5.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 Independent Review Process set forth in Section 4.3 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. With respect to the Reconsideration Request Process set forth in Section 4.2 , the Ombudsman shall serve the function expressly provided for in Section 4.2 .

Section 5.3. OPERATIONS

The Office of Ombudsman shall:

(a) 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 a Reconsideration Request or Independent Review Process;

(b) perform the functions set forth in Section 4.2 relating to review and consideration of Reconsideration Requests;

(c) 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;

(d) 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);

(e) heighten awareness of the Ombudsman program and functions through routine interaction with the ICANN community and online availability;

(f) maintain neutrality and independence, and have no bias or personal stake in an outcome; and

(g) comply with all ICANN conflicts of interest and confidentiality policies.

Section 5.4. INTERACTION WITH ICANN AND OUTSIDE ENTITIES

(a) 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.

(b) 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.

(d) 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.

(e) 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.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 6 EMPOWERED COMMUNITY

Section 6.1. COMPOSITION AND ORGANIZATION OF THE EMPOWERED COMMUNITY

(a) The Empowered Community ("EC") shall be a nonprofit association formed under the laws of the State of California consisting of the ASO, the ccNSO (as defined in Section 10.1), the GNSO (as defined in Section 11.1), the ALAC (as defined in Section 12.2(d)(i)) and the GAC (each a "Decisional Participant" or "associate," and collectively, the "Decisional Participants").

(b) This Article 6 shall constitute the articles of association of the EC and shall be considered the formational "governing document" (as defined in Section 18008 of the CCC) of the EC, and the terms contained herein and in these Bylaws relating to the EC shall be the EC's "governing principles" (as defined in Section 18010 of the CCC), which may only be amended as set forth in Section 25.2 . Where necessary for purposes of interpretation of these Bylaws, an "associate" shall be deemed to be a "member" of the EC as defined in Section 18015 of the CCC. Any change in the number and/or identity of Decisional Participants for any reason (including the resignation of any Decisional Participant or the addition of new Decisional Participants as a result of the creation of additional Supporting Organizations or Advisory Committees), and any corresponding changes in the voting thresholds for exercise of the EC's rights described in Annex D of these Bylaws, will only be effective following the completion of the process for amending Fundamental Bylaws described in Section 25.2 and Annex D. The EC may not be dissolved except upon the completion of the process for amending Fundamental Bylaws described in Section 25.2 and Annex D.

(c) The sole purpose of the EC is to exercise its rights and perform its obligations under ICANN's Articles of Incorporation and these Bylaws, and the EC shall have no other powers or rights except as expressly provided therein. The EC may only act as provided in these Bylaws. Any act of the EC that is not in accordance with these Bylaws shall not be effective.

(d) The EC shall not acquire, hold, manage, encumber or transfer any interest in real or personal property, nor have any directors, officers or employees. The EC shall not merge with or into another entity nor shall it dissolve, except with the approval of the Board and as part of a Fundamental Bylaw Amendment (as defined in Section 25.2(b)).

(e) Decisional Participants shall not transfer their right to be an associate of the EC. Any attempted transfer by any Decisional Participant of its right to be an associate of the EC shall be void ab initio.

(f) The location and street address of the EC shall be the principal office of ICANN.

(g) Each Decisional Participant shall, except as otherwise provided in Annex D, adopt procedures for exercising the rights of such Decisional Participant pursuant to the procedures set forth in Annex D, including (i) who can submit a petition to such Decisional Participant, (ii) the process for an individual to submit a petition to such Decisional Participant, including whether a petition must be accompanied by a rationale, (iii) how the Decisional Participant determines whether to accept or reject a petition, (iv) how the Decisional Participant determines whether an issue subject to a petition has been resolved, (v) how the Decisional Participant determines whether to support or object to actions supported by another Decisional Participant, and (vi) the process for the Decisional Participant to notify its constituents of relevant matters.

Section 6.2. POWERS AND ACKNOWLEDGMENTS

(a) Pursuant to and in compliance with the terms and conditions of these Bylaws, the EC shall have the powers and rights, as set forth more fully elsewhere in these Bylaws, to:

(i) Appoint and remove individual Directors (other than the President);

(ii) Recall the entire Board;

(iii) Reject ICANN Budgets, IANA Budgets, Operating Plans (as defined in Section 22.5(a)(i)) and Strategic Plans (as defined in Section 22.5(b)(i));

(iv) Reject Standard Bylaw Amendments (as defined in Section 25.1(a));

(v) Approve Fundamental Bylaw Amendments, Articles Amendments (as defined in Section 25.2(b)), and Asset Sales (as defined in Article 26(a));

(vi) Reject PTI Governance Actions (as defined in Section 16.2(d));,

(vii) Require the ICANN Board to re-review its rejection of IFR Recommendation Decisions (as defined in Section 18.6(d)), Special IFR Recommendation Decisions (as defined in Section 18.12(e)), SCWG Creation Decisions (as defined in Section 19.1(d)) and SCWG Recommendation Decisions (as defined in Section 19.4(d));

(viii) Initiate a Community Reconsideration Request, mediation or a Community IRP; and

(ix) Take necessary and appropriate action to enforce its powers and rights, including through the community mechanism contained in Annex D or an action filed in a court of competent jurisdiction.

(b) The EC may pursue an action in any court with jurisdiction over ICANN to enforce the EC's rights under these Bylaws. ICANN acknowledges the EC's legal personhood and shall not raise the EC's legal personhood as a defense in any proceeding between ICANN and the EC. ICANN shall not assert as a defense that prior filing or completion of a Reconsideration Request or an IRP Claim was a prerequisite to an action in court regarding the EC's power to appoint or remove an individual Director or recall the Board (except to the extent an IRP Panel award is applicable pursuant to Section 3.6(e)).

(c) By nominating a Director for designation by the EC or exercising the community mechanism contained in Annex D with respect to any rights granted to the EC pursuant to these Bylaws, the EC and each of its Decisional Participants agrees and consents to the terms of these Bylaws and intends to be legally bound hereby.

Section 6.3. EC ADMINISTRATION

(a) The Decisional Participants shall act through their respective chairs or such other persons as may be designated by the Decisional Participants (collectively, such persons are the "EC Administration"). Each Decisional Participant shall deliver annually a written certification from its chair or co-chairs to the Secretary designating the individual who shall represent the Decisional Participant on the EC Administration.

(b) In representing a Decisional Participant on the EC Administration, the representative individual shall act solely as directed by the represented Decisional Participant and in accordance with processes developed by such Decisional Participant in accordance with Section 6.1(g).

(c) In representing the EC Administration, the individuals serving thereon shall act as required for the EC to follow the applicable procedures in Annex D, and to implement EC decisions made in accordance with such procedures.

(d) All communications and notices required or permitted to be given under these Bylaws by a Decisional Participant shall be provided by the Decisional Participant's representative on the EC Administration. All communications and notices required or permitted to be given under these Bylaws by the EC shall be provided by any member of the EC Administration. Where a particular Bylaws notice provision does not require notice to the Secretary, the EC and the Decisional Participants shall provide a copy of the notice to the Secretary in accordance with Section 21.5, and ICANN shall post it on the Website.

(e) ICANN shall be entitled to rely on notices from a Decisional Participant's representative or an individual serving on the EC Administration delivered in accordance with Section 21.5 as evidence that the actions set forth therein have been approved by or are the actions of the Decisional Participant, the EC or the EC Administration, as applicable, pursuant to and in compliance with the requirements of these Bylaws (including Annex D) .

(f) No person participating in the EC, the EC Administration or a Decisional Participant shall be liable for any debt, obligation or liability of ICANN or the EC, other than in the case of a fraudulent act committed by such person.

In the event the EC Administration receives from the Secretary a valid notice as described in Section 7.11(a)(i)(B), indicating that the Board has voted to remove a Director without cause pursuant to Section 7.11(a)(i)(B), the EC shall without deliberation consent to such removal, and the EC Administration shall provide notice to the Secretary of such consent.

ARTICLE 7 BOARD OF DIRECTORS

Section 7.1. COMPOSITION OF THE BOARD

The ICANN Board of Directors ("Board") shall consist of sixteen voting directors ("Directors"). In addition, four non-voting liaisons ("Liaisons") shall be appointed for the purposes set forth in Section 7.9. Only Directors shall be included in determining the existence of quorums, and in establishing the validity of votes taken by the Board.

Section 7.2. DIRECTORS AND THEIR SELECTION; ELECTION OF CHAIR AND VICE-CHAIR

(a) As of the effective date of the amendment and restatement of these Bylaws on 1 October 2016, the EC shall be the sole designator of ICANN and shall designate, within the meaning of Section 5220 of the CCC, all Directors except for the President ex officio. The EC shall notify promptly the Secretary in writing of the following designations:

(i) Eight Directors nominated by the Nominating Committee to be designated as Directors by the EC. These seats on the Board are referred to in these Bylaws as Seats 1 through 8.

(ii) Two Directors nominated by the ASO to be designated as Directors by the EC. These seats on the Board are referred to in these Bylaws as Seat 9 and Seat 10.

(iii) Two Directors nominated by the ccNSO to be designated as Directors by the EC. These seats on the Board are referred to in these Bylaws as Seat 11 and Seat 12.

(iv) Two Directors nominated by the GNSO to be designated as Directors by the EC. These seats on the Board are referred to in these Bylaws as Seat 13 and Seat 14.

(v) One Director nominated by the At-Large Community to be designated as Directors by the EC. This seat on the Board is referred to in these Bylaws as Seat 15.

In addition to the Directors designated by the EC, the President shall serve ex officio as a Director. The seat held by the President on the Board is referred to in these Bylaws as Seat 16.

(b) In carrying out its responsibilities to nominate the Directors for Seats 1 through 8 for designation by the EC, the Nominating Committee shall ensure that the Board is composed of Directors who, in the aggregate, display diversity in geography, culture, skills, experience, and perspective, by applying the criteria set forth in Section 7.3, Section 7.4 and Section 7.5. At no time when it makes its nomination shall the Nominating Committee nominate a Director to fill any vacancy or expired term whose designation would cause the total number of Directors (not including the President) from countries in any one Geographic Region to exceed five; and the Nominating Committee shall ensure when it makes its nominations that the Board includes at least one Director who is from a country in each ICANN Geographic Region ("Diversity Calculation"). For purposes of this Section 7.2(b), 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 or her Statement of Interest the country of citizenship or Domicile that he or she wants the Nominating Committee to use for Diversity Calculation purposes. For purposes of this Section 7.2(b), a person can only have one Domicile, which shall be determined by where the candidate has a permanent residence and place of habitation.

(c) In carrying out their responsibilities to nominate Directors for Seats 9 through 15 for designation by the EC, the Supporting Organizations and the At-Large Community shall seek to ensure that the Board is composed of Directors who, in the aggregate, display diversity in geography, culture, skills, experience, and perspective, by applying the criteria set forth in Section 7.3, Section 7.4 and Section 7.5. The Supporting Organizations shall ensure that, at any given time, no two Directors nominated by a Supporting Organization are citizens from the same country or of countries located in the same Geographic Region. For purposes of this Section 7.2(c), if any candidate for Director maintains citizenship or Domicile of more than one country, that candidate may be deemed to be from either country and must select in his or her Statement of Interest the country of citizenship or Domicile that he or she wants the Supporting Organization or the At-Large Community, as applicable, to use for nomination purposes. For purposes of this Section 7.2(c), a person can only have one Domicile, which shall be determined by where the candidate has a permanent residence and place of habitation.

(d) The Board shall annually elect a Chair and a Vice-Chair from among the Directors, not to include the President.

(e) The EC shall designate each person nominated as a Director by the Nominating Committee, the ASO, the ccNSO, the GNSO and the At-Large Community in accordance with this Section 7.2.

(f) As a condition to sitting on the Board, each Director other than the President ex officio shall sign a pre-service letter pursuant to which such Director:

(i) acknowledges and agrees to the EC's right to remove the Director at any time and for any reason following the processes set forth in these Bylaws;

(ii) acknowledges and agrees that serving as a Director shall not establish any employment or other relationship (whether to ICANN, the EC, any body entitled to nominate a Director, or any of their agents) that provides any due process rights related to termination of service as a Director; and

(iii) conditionally and irrevocably resigns as a Director automatically effective upon communication to the Director or, in the case of Board recall, communication to the Board of a final determination of removal following the processes set forth in these Bylaws.

Section 7.3.CRITERIA FOR NOMINATION OF DIRECTORS

Directors shall be:

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

(b) 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;

(c) Persons who will produce the broadest cultural and geographic diversity on the Board consistent with meeting the other criteria set forth in this Section 7.3;

(d) 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; and

(e) Persons who are able to work and communicate in written and spoken English.

Section 7.4. ADDITIONAL QUALIFICATIONS

(a) 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.

(b) 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 is identified by, or presents themselves to, the Supporting Organization Council or the At-Large Community for consideration for nomination to serve as a Director, the person shall not thereafter participate in any discussion of, or vote by, the Supporting Organization Council or the committee designated by the At-Large Community relating to the nomination of Directors by the Council or At-Large Community, until the Council or committee(s) specified by the At-Large Community has nominated the full complement of Directors it is responsible for nominating. In the event that a person serving in any capacity on a Supporting Organization Council is considered for nomination to serve 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 nomination process. In the event that a person serving in any capacity on the At-Large Advisory Committee is identified as or accepts a nomination to be considered for nomination by the At-Large Community as a Director, the Regional At-Large Organization or other group or entity that selected the person may select a replacement for purposes of the At-Large Community's nomination process.

(c) Persons serving in any capacity on the Nominating Committee shall be ineligible for nomination or designation to positions on the Board as provided by Section 8.8.

(d) No person who serves on the EC Administration while serving in that capacity shall be considered for nomination or designated to the Board, nor serve simultaneously on the EC Administration and as a Director or Liaison to the Board.

Section 7.5. INTERNATIONAL REPRESENTATION

In order to ensure broad international representation on the Board, the nomination of Directors by the Nominating Committee, each Supporting Organization and the At-Large Community 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 Geographic 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": (a) Europe; (b) Asia/Australia/Pacific; (c) Latin America/Caribbean islands; (d) Africa; and (e) North America. The specific countries included in each Geographic Region shall be determined by the Board, and this Section 7.5 shall be reviewed by the Board from time to time (and in any event at least once every three years) to determine whether any change is appropriate, taking account of the evolution of the Internet.

Section 7.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 CCC. 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 CCC. The Board shall adopt policies specifically addressing Director, Officer, EC 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.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 EC, the Nominating Committee, Supporting Organization or Advisory Committee that nominated them, as applicable, their employers, or any other organizations or constituencies.

Section 7.8. TERMS OF DIRECTORS

(a) The regular term of office of Director Seats 1 through 15 shall begin as follows:

(i) The regular terms of Seats 1 through 3 shall begin at the conclusion of each ICANN annual meeting every third year after 2003;

(ii) The regular terms of Seats 4 through 6 shall begin at the conclusion of each ICANN annual meeting every third year after 2004;

(iii) The regular terms of Seats 7 and 8 shall begin at the conclusion of each ICANN annual meeting every third year after 2005;

(iv) The terms of Seats 9 and 12 shall begin at the conclusion of each ICANN annual meeting every third year after 2015;

(v) The terms of Seats 10 and 13 shall begin at the conclusion of each ICANN annual meeting every third year after 2013; and

(vi) The terms of Seats 11, 14 and 15 shall begin at the conclusion of each ICANN annual meeting every third year after 2014.

(b) Each Director holding any of Seats 1 through 15, including a Director nominated and designated 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 designated and qualified or until that Director resigns or is removed in accordance with these Bylaws. For the avoidance of doubt, the new governance provisions effective as of the amendment and restatement of these Bylaws on 1 October 2016 shall not have the effect of shortening or terminating the terms of any Directors serving at the time of the amendment and restatement.

(c) At least two months before the commencement of each annual meeting, the Nominating Committee shall give the EC Administration (with a copy to the Decisional Participants and Secretary) written notice of its nomination of Directors for seats with terms beginning at the conclusion of the annual meeting, and the EC Administration shall promptly provide the Secretary (with a copy to the Decisional Participants) with written notice of the designation of those Directors. All such notices shall be posted promptly to the Website.

(d) At least six months before the date specified for the commencement of the term as specified in Section 7.8(a)(iv) through Section 7.8(a)(vi) above, any Supporting Organization or the At-Large Community entitled to nominate a Director for a Seat with a term beginning that year shall give the EC Administration (with a copy to the Secretary and the Decisional Participants) written notice of its nomination of Directors for seats with terms beginning at the conclusion of the annual meeting, and the EC Administration shall promptly provide the Secretary (with a copy to the Decisional Participants) with written notice of the designation of those Directors. All such notices shall be posted promptly to the Website.

(e) No Director may serve more than three consecutive terms. For these purposes, a person designated to fill a vacancy in a term shall not be deemed to have served that term.

(f) 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.

Section 7.9. NON-VOTING LIAISONS

(a) The non-voting Liaisons shall include:

(i) One appointed by the Governmental Advisory Committee;

(ii) One appointed by the Root Server System Advisory Committee established by Section 12.2(c);

(iii) One appointed by the Security and Stability Advisory Committee established by Section 12.2(b); and

(iv) One appointed by the Internet Engineering Task Force.

(b) The 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 Liaison shall give the Secretary written notice of its appointment.

(c) Each 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.

(d) The 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. Liaisons shall be entitled (under conditions established by the Board) to use any materials provided to them pursuant to this Section 7.9(d) for the purpose of consulting with their respective committee or organization.

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

Subject to Section 5226 of the CCC, any Director or Liaison may resign at any time by giving written notice thereof to the Chair of the Board, the President, the Secretary, or the Board. 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.

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

(a) Directors

(i) Any Director designated by the EC may be removed without cause:

(A) by the EC pursuant to and in compliance with procedures in Section 3.1 or Section 3.2 of Annex D, as applicable, or

(B) following notice to that Director, by a three-fourths (3/4) majority vote of all Directors; provided, however, that (x) each vote to remove a Director shall be a separate vote on the sole question of the removal of that particular Director; and (y) such removal shall not be effective until the Secretary has provided notice to the EC Administration of the Board's removal vote and the requirements of Section 6.4 have been met.

(ii) The Board may remove any Director who has been declared of unsound mind by a final order of court, or convicted of a felony, or been found by a final order or judgment of any court to have breached any duty under Sections 5230 through 5239 of the CCC, and in the case of such removal, the Secretary shall promptly notify the EC Administration in writing, with a copy to the body that nominated such Director, and shall promptly post such notification to the Website. The vacancies created by such removal shall be filled in accordance with Section 7.12(a).

(iii) All Directors (other than the President) may be removed at the same time by the EC by the EC Administration delivering an EC Board Recall Notice to the Secretary pursuant to and in compliance with Section 3.3 of Annex D. The vacancies created by such removal shall be filled by the EC in accordance with Section 7.12(b).

(b) With the exception of the Liaison appointed by the Governmental Advisory Committee, any Liaison may be removed following notice to that Liaison and to the organization which selected that Liaison, 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 vacancies created by such removal shall be filled in accordance with Section 7.12. The Board may request the Governmental Advisory Committee to consider the replacement of the Governmental Advisory Committee Liaison if the Board, by a three-fourths (3/4) majority vote of all Directors, determines that such an action is appropriate.

Section 7.12. VACANCIES

(a) This Section 7.12(a) shall apply to Board vacancies other than those occurring by recall of all Directors (other than the President). A vacancy or vacancies in the Board shall be deemed to exist in the case of the death, resignation, or removal of any Director or Interim Director (as defined in Section 7.12(b)), or if the authorized number of Directors is increased. Vacancies occurring in Seats 1 through 15 shall be filled by the EC after nomination as provided in Section 7.2 and Articles 8 through 12. A vacancy in Seat 16 shall be filled as provided in Article 15. A Director designated by the EC 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 designated 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.

(b) This Section 7.12(b) shall apply to Board vacancies occurring when all Directors (other than the President) are recalled as provided by Section 7.11(a)(iii). Concurrently with delivery of any EC Board Recall Notice (as defined in Section 3.3(f) of Annex D), the EC Administration shall provide written notice of the EC's designation of individuals to fill such vacancies (each such individual, an "Interim Director") to the Decisional Participants and to the Secretary, who shall cause such notice to be promptly posted to the Website. An Interim Director must meet the criteria specified in Section 7.3, Section 7.4 and Section 7.5, as applicable. An Interim Director shall hold office until the EC designates the Interim Director's successor in accordance with Section 7.12(a), and the successor's designation shall occur within 120 days of the Interim Director's designation. For avoidance of doubt, persons designated as Interim Directors may be eligible for designation as Directors as well.

(c) The organizations selecting the Liaisons identified in Section 7.9 are responsible for determining the existence of, and filling, any vacancies in those positions. Such organizations shall give the Secretary written notice of their appointments to fill any such vacancies, subject to the requirements set forth in Section 7.4, as applicable.

Section 7.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 of 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 7.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 7.15. SPECIAL MEETINGS

Special meetings of the Board may be called by or at the request of one-quarter (1/4) of the Directors, by the Chair of the Board or the President. A call for a special meeting shall be made by the Secretary. Special meetings shall be held at the principal office of ICANN unless otherwise specified in the notice of the meeting.

Section 7.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 Liaison, or sent by first-class mail (air mail for addresses outside the United States) or facsimile, charges prepaid, addressed to each Director and Liaison at the Director's or 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 7.16 to the contrary, notice of a meeting need not be given to any Director or Liaison who signed a waiver of notice or a Director who signed 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 7.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 7.18. ACTIONS BY TELEPHONE MEETING OR BY OTHER COMMUNICATIONS EQUIPMENT

Directors and Liaisons may participate in a meeting of the Board or Board Committee (as defined in Section 14.1) through use of (a) conference telephone or similar communications equipment, provided that all Directors participating in such a meeting can speak to and hear one another or (b) electronic video screen communication or other communication equipment; provided that (i) all Directors participating in such a meeting can speak to and hear one another, (ii) all Directors are provided the means of fully participating in all matters before the Board or Board Committee, and (iii) ICANN adopts and implements means of verifying that (A) a person participating in such a meeting is a Director or other person entitled to participate in the meeting and (B) all actions of, or votes by, the Board or Board Committee are taken or cast only by Directors and not persons who are not Directors. Participation in a meeting pursuant to this Section 7.18 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 Directors and Liaisons to participate by telephone.

Section 7.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 7.20. ELECTRONIC MAIL

If permitted by 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 7.21. BOARD RIGHTS OF INSPECTION

(a) 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.

(b) ICANN shall establish reasonable procedures to protect against the inappropriate disclosure of confidential information.

Section 7.22. COMPENSATION

(a) Except for the President of ICANN, who serves ex officio as a Director, each of the Directors shall be entitled to receive compensation for his or her services as a Director. The President shall receive only his or her compensation for service as President and shall not receive additional compensation for service as a Director.

(b) If the Board determines to offer a compensation arrangement to one or more Directors (other than the President) for services to ICANN as Directors, the Board shall follow the process that is calculated to pay an amount for service as a Director that is not an excess benefit under the standards set forth in Section 4958 of the Internal Revenue Code of 1986, as amended (the "Code").

(c) As part of the process, the Board shall retain an Independent Valuation Expert (as defined in Section 7.22(g)(i)) to consult with and to advise the Board regarding Director compensation arrangements and to issue to the Board a Reasoned Written Opinion (as defined in Section 7.22(g)(ii)) from such expert regarding the ranges of Reasonable Compensation (as defined in Section 7.22(g)(iii)) for any such services by a Director. The expert's opinion shall address all relevant factors affecting the level of compensation to be paid a Director, including offices held on the Board, attendance at Board and Board Committee meetings, the nature of service on the Board and on Board Committees, and appropriate data as to comparability regarding director compensation arrangements for U.S.-based, nonprofit, tax-exempt organizations possessing a global employee base.

(d) After having reviewed the Independent Valuation Expert's Reasoned Written Opinion, the Board shall meet with the expert to discuss the expert's opinion and to ask questions of the expert regarding the expert's opinion, the comparability data obtained and relied upon, and the conclusions reached by the expert.

(e) The Board shall adequately document the basis for any determination the Board makes regarding a Director compensation arrangement concurrently with making that determination.

(f) In addition to authorizing payment of compensation for services as Directors as set forth in this Section 7.22, the Board may also authorize the reimbursement of actual and necessary reasonable expenses incurred by any Director and by Liaisons performing their duties as Directors or Liaisons.

(g) As used in this Section 7.22, the following terms shall have the following meanings:

(i) An "Independent Valuation Expert" means a person retained by ICANN to value compensation arrangements that: (A) holds itself out to the public as a compensation consultant; (B) performs valuations regarding compensation arrangements on a regular basis, with a majority of its compensation consulting services performed for persons other than ICANN; (C) is qualified to make valuations of the type of services involved in any engagement by and for ICANN; (D) issues to ICANN a Reasoned Written Opinion regarding a particular compensation arrangement; and (E) includes in its Reasoned Written Opinion a certification that it meets the requirements set forth in (A) through (D) of this definition.

(ii) A "Reasoned Written Opinion" means a written opinion of a valuation expert who meets the requirements of Section 7.22(g)(i)(A) through (D). To be reasoned, the opinion must be based upon a full disclosure by ICANN to the valuation expert of the factual situation regarding the compensation arrangement that is the subject of the opinion, the opinion must articulate the applicable valuation standards relevant in valuing such compensation arrangement, the opinion must apply those standards to such compensation arrangement, and the opinion must arrive at a conclusion regarding whether the compensation arrangement is within the range of Reasonable Compensation for the services covered by the arrangement. A written opinion is reasoned even though it reaches a conclusion that is subsequently determined to be incorrect so long as the opinion addresses itself to the facts and the applicable standards. However, a written opinion is not reasoned if it does nothing more than recite the facts and express a conclusion.

(iii) "Reasonable Compensation" shall have the meaning set forth in §53.4958-4(b)(1)(ii) of the Regulations issued under §4958 of the Code.

(h) Each of the Liaisons, with the exception of the Governmental Advisory Committee Liaison, shall be entitled to receive compensation for his or her services as a Liaison. If the Board determines to offer a compensation arrangement to one or more Liaisons, the Board shall approve that arrangement by a required three-fourths (3/4) vote.

Section 7.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 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.

Section 7.24 INTERIM BOARD

Except in circumstances in which urgent decisions are needed to protect the security, stability or resilience of the DNS or to the extent necessary to comply with its fiduciary obligations under applicable law, a Board that consists of a majority or more of Interim Directors (an "Interim Board") shall (a) consult with the chairs of the Supporting Organizations and Advisory Committees before making major decisions and (b) consult through a community forum (in a manner consistent with the process for a Rejection Action Community Forum pursuant to Section 2.3 of Annex D) prior to taking any action that would, if implemented, materially change ICANN's strategy, policies or management, including replacement of the then-serving President. Interim Directors shall be entitled to compensation as provided in this Article 7.

Section 7.25 COMMUNICATION OF DESIGNATION

Upon its receipt of nominations as provided in Articles 7 through 12, the EC Administration, on behalf of the EC, shall promptly notify the Secretary of the EC's designation of individuals to fill seats on the Board. ICANN shall post all such designations promptly to the Website.

ARTICLE 8 NOMINATING COMMITTEE

Section 8.1. DESCRIPTION

There shall be a Nominating Committee of ICANN ("Nominating Committee"), responsible for nominating all Directors except the President and those Directors nominated by Decisional Participants; for nominating two directors of PTI (in accordance with the articles of incorporation and bylaws of PTI); and for such other selections as are set forth in these Bylaws. Notification of the Nominating Committee's Director nominations shall be given by the Nominating Committee Chair in writing to the EC Administration, with a copy to the Secretary, and the EC shall promptly act on it as provided in Section 7.25. Notification of the Nominating Committee's PTI director nomination shall be given to the Secretary.

Section 8.2. COMPOSITION

The Nominating Committee shall be composed of the following persons:

(a) A non-voting Chair, appointed by the Board;

(b) A non-voting Chair-Elect, appointed by the Board as a non-voting advisor;

The Address Council of the Address Supporting Organization established by Section 9.2**;**
The Council of the Country Code Names Supporting Organization established by Section 10.3**;**
The Governmental Advisory Committee established by Section 12.2(a)
The Security and Stability Advisory Committee established by Section 12.2(b);
The Root Server System Advisory Committee established by Section 12.2(c); and
The Internet Engineering Task Force.

(d) Five voting delegates selected by the At-Large Advisory Committee established by Section 12.2(d);

(e) Seven voting delegates to the Nominating Committee shall be selected from the Generic Names Supporting Organization established by Article 11, as follows:

(i) One delegate from the Registries Stakeholder Group;

(ii) One delegate from the Registrars Stakeholder Group;

(iii) Two delegates from the Business Constituency, one representing small business users and one representing large business users;

(iv) One delegate from the Internet Service Providers and Connectivity Providers Constituency (as defined in Section 11.5(a)(iii));

(v) One delegate from the Intellectual Property Constituency; and

(vi) One delegate from consumer and civil society groups, selected by the Non-Commercial Users Constituency.

(f) 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.

Section 8.3. TERMS

(a) The term for each voting delegate shall be a two-year term. No individual may serve as a delegate for more than two terms. In addition, no individual may serve in consecutive terms, regardless of the entity selecting them to the Nominating Committee. An individual will only be eligible to serve a second term as a delegate on the Nominating committee if a minimum of two years has elapsed between the end of their first term and the beginning of the term for which they are being selected.

(b) 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 ICANN annual meeting in two years, subject to the Transition Article Section 27.5..

(c) The Chair, the Chair-Elect, and any Associate Chair shall serve as such until the conclusion of the next ICANN annual meeting.

(d) It is anticipated that upon the conclusion of the term of the Chair-Elect, the Chair-Elect will be appointed by the Board to the position of Chair. However, the Board retains the discretion to appoint any other person to the position of Chair. At the time of appointing a Chair-Elect, if the Board determines that the person identified to serve as Chair shall be appointed as Chair for a successive term, the Chair-Elect position shall remain vacant for the term designated by the Board.

(e) Vacancies in the positions of delegate, shall be filled by the entity entitled to select the delegate, subject to the details in the approved Nominating Committee Standard Operating Procedures. If a delegate is selected to fill a vacancy and less than eight months have elapsed in that term, the delegate will be considered to have served a full term for the purposes of Section 8.3(a). If more than eight months have elapsed in the term at the time the delegate is selected to fill a vacancy, such service will not be considered a full term pursuant to Section 8.3(a).

(f) For any vacancy in the position of Chair, the Board shall appoint a replacement. For any term that the Chair-Elect position is vacant pursuant to Section 8.3(d), or until any other vacancy in the position of Chair-Elect can be filled, a non-voting advisor to the Chair may be appointed by the Board from among persons with prior service on the Board or a Nominating Committee, including the immediately previous Chair of the Nominating Committee. A vacancy in the position of Associate Chair may be filled by the Chair in accordance with the criteria established by Section 8.2(i).

(g) 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 8.4. CRITERIA FOR SELECTION OF NOMINATING COMMITTEE DELEGATES

Delegates to the ICANN Nominating Committee shall be:

(a) 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;

(b) Persons with wide contacts, broad experience in the Internet community, and a commitment to the success of ICANN;

(c) Persons whom the selecting body is confident will consult widely and accept input in carrying out their responsibilities;

(d) 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;

(e) 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

(f) Persons who are able to work and communicate in written and spoken English.

Section 8.5. DIVERSITY

In carrying out its responsibilities to nominate Directors to fill Seats 1 through 8 (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 Board (and such other bodies), and seek to ensure that the persons it nominates to serve as Director and selects shall, to the extent feasible and consistent with the other criteria required to be applied by Section 8.4, be guided by Section 1.2(b)(ii).

Section 8.6. ADMINISTRATIVE AND OPERATIONAL SUPPORT

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

Section 8.7. PROCEDURES

The Nominating Committee shall adopt such operating procedures as it deems necessary, which shall be published on the Website. The Nominating Committee and the NomCom Standing Committee, while ensuring confidentiality, will ensure that they maintain transparency and accountability to the ICANN Community for all their processes.

Section 8.8. INELIGIBILITY FOR SELECTION BY NOMINATING COMMITTEE

No person who serves on the Nominating Committee in any capacity shall be eligible for nomination 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 8.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 8.2.

ARTICLE 9 ADDRESS SUPPORTING ORGANIZATION

Section 9.1. DESCRIPTION

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

(b) 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 RIRs.

Section 9.2. ADDRESS COUNCIL

(a) The ASO shall have an Address Council, consisting of the members of the NRO Number Council.

(b) The Address Council shall nominate individuals to fill Seats 9 and 10 on the Board. Notification of the Address Council's nominations shall be given by the Address Council in writing to the EC Administration, with a copy to the Secretary, and the EC shall promptly act on it as provided in Section 7.25.

ARTICLE 10 COUNTRY-CODE NAMES SUPPORTING ORGANIZATION

Section 10.1. DESCRIPTION

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

(a) developing and recommending to the Board global policies relating to country-code top-level domains;

(b) Nurturing consensus across the ccNSO's community, including the name-related activities of ccTLDs;

(d) Nominating individuals to fill Seats 11 and 12 on the Board; and

(e) Other responsibilities of the ccNSO as set forth in these Bylaws.

Policies that apply to ccNSO members by virtue of their membership are only those policies developed according to Section 10.4(j) and Section 10.4(k). 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 10.2. ORGANIZATION

The ccNSO shall consist of (a) ccTLD managers that have agreed in writing to be members of the ccNSO (see Section 10.4(b)) and (b) a ccNSO Council responsible for managing the policy-development process of the ccNSO.

Section 10.3. ccNSO COUNCIL

(a) The ccNSO Council shall consist of three ccNSO Council members selected by the ccNSO members within each of ICANN's Geographic Regions in the manner described in Section 10.4(g) through Section 10.4(i); (ii) three ccNSO Council members selected by the ICANN Nominating Committee; (iii) liaisons as described in Section 10.3(b); and (iv) observers as described in Section 10.3(c).

(b) 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: (i) the Governmental Advisory Committee; (ii) the At-Large Advisory Committee; and (iii) each of the Regional Organizations described in Section 10.5. 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.

(c) 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.

(d) (i) 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; (ii) 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 (iii) 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.

(e) 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.

(f) 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.

(g) 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 10.4(g) through (i).

(h) 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 10.4(f)) and to manage the development of policy recommendations in accordance with Section 10.6(a). The ccNSO Council shall also undertake such other roles as the members of the ccNSO shall decide from time to time.

(i) The ccNSO Council shall nominate individuals to fill Seats 11 and 12 on the Board by written ballot or by action at a meeting; any such nomination must have affirmative votes of a majority of all the members of the ccNSO Council then in office. Notification of the ccNSO Council's nominations shall be given by the ccNSO Council Chair in writing to the EC Administration, with a copy to the Secretary, and the EC shall promptly act on it as provided in Section 7.25.

(j) 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.

(k) 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.

(l) Except as provided by Section 10.3(i) and Section 10.3(j), 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 Section 10.3(n). 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.

(m) 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.

(n) 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 (i) all ccNSO Council members participating in the meeting can speak to and hear one another, (ii) all ccNSO Council members participating in the meeting are provided the means of fully participating in all matters before the ccNSO Council, and (iii)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 10.4. MEMBERSHIP

(a) The ccNSO shall have a membership consisting of ccTLD managers. Any ccTLD manager that meets the membership qualifications stated in Section 10.4(b) shall be entitled to be members of the ccNSO. For purposes of this Article 10, a ccTLD manager is the organization or entity responsible for managing a ccTLD according to and under the current heading "Delegation Record" in the Root Zone Database, or under any later modification, for that country-code top-level domain.

For purposes of this Article, and Annexes B and C of these Bylaws, "Territory" is defined to be the country, dependency or other area of particular geopolitical interest listed on the 'International Standard ISO 3166-1, Codes for the representation of names of countries and their subdivisions – Part 1: Country Codes', or, in some exceptional cases listed on the reserved ISO 3166-1 code elements.

(b) Any ccTLD manager may become a ccNSO member by submitting an application to a person designated by the ccNSO Council to receive applications. 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, (i) to adhere to rules of the ccNSO, including membership rules, (ii) to abide by policies developed and recommended by the ccNSO and adopted by the Board in the manner described by Section 10.4(j) and Section 10.4(k), and (ii) to pay ccNSO membership fees established by the ccNSO Council under Section 10.7(c). 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 Section 10.4(j) and Section 10.4(k), and (C) to pay ccNSO membership fees established by the ccNSO Council under Section 10.7(c). 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.

(c) Neither membership in the ccNSO nor membership in any Regional Organization described in Section 10.5 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.

(d) The Geographic Regions of ccTLDs shall be as described in Section 7.5. For purposes of this Article 10, 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.

(e) Designation of Representative

(i) Each ccTLD manager may designate in writing a person, organization, or entity to represent the ccTLD manager in matters relating to the ccNSO ("Representative"). In the absence of such a designation, the person, organization, or entity listed as the administrative contact in the IANA database shall be deemed to be the designate of the ccTLD manager by whom the ccNSO member shall be represented.

(ii) For any Territory for which there is a single ccTLD manager that is a ccNSO member, the Representative selected by that manager in accordance with Section 10.4(e) shall be the Territory's emissary ("Emissary") for the purpose of voting in the specific cases enumerated in this Article, Annex B, or Annex C of these Bylaws. In the event two or more ccTLD managers from the same Territory are ccNSO members, those ccTLD managers are to appoint one of the Representatives from among those ccNSO members to serve as the Emissary to vote on behalf of the ccNSO members from that Territory.

(iii) During any period in which an Emissary is not appointed, the ccTLD manager that has been the member of the ccNSO for the longest period is deemed to be the Emissary for that Territory.

(iv) Each Emissary, regardless of the number of ccTLD managers within the relevant Territory, is entitled to cast a single vote in any round of any voting process defined within this Article, Annex B or Annex C that is reserved for Emissary voting. The ccTLD managers within each Territory may define the process to determine how their respective Emissary's vote is determined.

(f) 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.

(g) The ccNSO Council members selected by the ccNSO members from each Geographic Region (see Section 10.3(a)(i)) 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.

(h) 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 a different Territory, 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.

(i) 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 electronic means) 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 Emissaries. In such an election, a majority of the Emissaries entitled to vote in the Geographic Region shall constitute a quorum, and the selected candidate must receive a plurality of the votes cast by the Emissaries 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.

(j) Subject to Section 10.4(k), ICANN policies shall apply to ccNSO members by virtue of their membership to the extent, and only to the extent, that the policies (i) only address issues that are within scope of the ccNSO according to Section 10.6(a) and Annex C; (ii) have been developed through the ccPDP as described in Section 10.6, and (iii) have been recommended as such by the ccNSO to the Board, and (iv) 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.

(k) A ccNSO member shall not be bound if it provides a declaration to the ccNSO Council stating that (i) implementation of the policy would require the member to breach custom, religion, or public policy (not embodied in the applicable law described in Section 10.4(j)), and (ii) 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 Section 10.4(j)) 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 10.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 10.6. ccNSO POLICY-DEVELOPMENT PROCESS AND SCOPE

(a) 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.

(b) 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 10.7. STAFF SUPPORT AND FUNDING

(a) 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.

(b) 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.

(c) The ccNSO Council shall establish fees to be paid by ccNSO members to defray ccNSO expenses as described in Section 10.7(a) and Section 10.7(b), as approved by the ccNSO members.

(d) Written notices given to the Secretary under this Article 10 shall be permanently retained, and shall be made available for review by the ccNSO Council on request. The 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 11 GENERIC NAMES SUPPORTING ORGANIZATION

Section 11.1. DESCRIPTION

There shall be a policy-development body known as the Generic Names Supporting Organization (the "Generic Names Supporting Organization" or "GNSO", and collectively with the ASO and ccNSO, the "Supporting Organizations")), which shall be responsible for developing and recommending to the Board substantive policies relating to generic top-level domains and other responsibilities of the GNSO as set forth in these Bylaws.

Section 11.2. ORGANIZATION

The GNSO shall consist of:

(a) A number of Constituencies, where applicable, organized within the Stakeholder Groups as described in Section 11.5;

(b) Four Stakeholder Groups organized within Houses as described in Section 11.5;

(d) A GNSO Council responsible for managing the policy development process of the GNSO, as described in Section 11.3; and

(e) 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 Board.

Section 11.3. GNSO COUNCIL

(a) Subject to Section 11.5, the GNSO Council shall consist of:

(i) three representatives selected from the Registries Stakeholder Group;

(ii) three representatives selected from the Registrars Stakeholder Group;

(iii) six representatives selected from the Commercial Stakeholder Group;

(iv) six representatives selected from the Non-Commercial Stakeholder Group; and

(v) 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 11.3(h)) 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.

(b) 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.

(c) 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 11.3(h)). Such removal shall be subject to reversal by the ICANN Board on appeal by the affected GNSO Council member.

(d) 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 11.6.

(e) 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.

(f) The GNSO shall nominate by written ballot or by action at a meeting individuals to fill Seats 13 and 14 on the Board. Each of the two voting Houses of the GNSO, as described in Section 11.3(h), shall make a nomination to fill one of two Board seats, as outlined below; any such nomination must have affirmative votes compromising sixty percent (60%) of all the respective voting House members:

(i) the Contracted Parties House (as described in Section 11.3(h)(i)) shall select a representative to fill Seat 13; and

(ii) the Non-Contracted Parties House (as described in Section 11.3(h)(ii)) shall select a representative to fill Seat 14.

Election procedures are defined in the GNSO Operating Procedures.

Notification of the Board seat nominations shall be given by the GNSO Chair in writing to the EC Administration, with a copy to the Secretary, and the EC shall promptly act on it as provided in Section 7.25.

(g) 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 11.3(h)) 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.

(h) Except as otherwise required in these Bylaws, for voting purposes, the GNSO Council (see Section 11.3(a)) shall be organized into a bicameral House structure as described below:

(i) 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

(ii) 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.

(i) Except as otherwise specified in these Bylaws, Annex A, Annex A-1 or Annex A-2 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:

(i) Create an Issues Report: requires an affirmative vote of more than one-fourth (1/4) vote of each House or majority of one House.

(ii) Initiate a Policy Development Process ("PDP") Within Scope (as described in Annex A): requires an affirmative vote of more than one-third (1/3) of each House or more than two-thirds (2/3) of one House.

(iii) Initiate a PDP Not Within Scope: requires an affirmative vote of GNSO Supermajority (as defined in Section 11.3(i)(xix)).

(iv) Approve a PDP Team Charter for a PDP Within Scope: requires an affirmative vote of more than one-third (1/3) of each House or more than two-thirds (2/3) of one House.

(v) Approve a PDP Team Charter for a PDP Not Within Scope: requires an affirmative vote of a GNSO Supermajority.

(vi) Changes to an Approved PDP Team Charter: For any PDP Team Charter approved under (iv) or (v) above, the GNSO Council may approve an amendment to the Charter through a simple majority vote of each House.

(vii) Terminate a PDP: Once initiated, and prior to the publication of a Final Report, the GNSO Council may terminate a PDP only for significant cause, upon a motion that passes with a GNSO Supermajority Vote in favor of termination.

(viii) 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.

(ix) Approve a PDP Recommendation With a GNSO Supermajority: requires an affirmative vote of a GNSO Supermajority,

(x) 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.

(xi) Modification of Approved PDP Recommendation: Prior to Final Approval by the Board, an Approved PDP Recommendation may be modified or amended by the GNSO Council with a GNSO Supermajority vote.

(xii) Initiation of an Expedited Policy Development Process ("EPDP"): requires an affirmative vote of a GNSO Supermajority.

(xiii) Approve an EPDP Team Charter: requires an affirmative vote of a GNSO Supermajority.

(xiv) Approval of EPDP Recommendations: requires an affirmative vote of a GNSO Supermajority.

(xv) Approve an EPDP 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.

(xvi) Initiation of a GNSO Guidance Process ("GGP"): requires an affirmative vote of more than one-third (1/3) of each House or more than two-thirds (2/3) of one House.

(xvii) Rejection of Initiation of a GGP Requested by the Board: requires an affirmative vote of a GNSO Supermajority.

(xviii) Approval of GGP Recommendations: requires an affirmative vote of a GNSO Supermajority.

(xix) A "GNSO Supermajority" shall mean: (A) two-thirds (2/3) of the Council members of each House, or (B) three-fourths (3/4) of the Council members of one House and a majority of the Council members of the other House.

(j) The voting thresholds described below shall apply to the following GNSO actions as a Decisional Participant in the Empowered Community. For any action not listed, the default threshold for the GNSO to act as a Decisional Participant in the Empowered community requires a simple majority vote of each House:

(i) Amendment of PTI Articles of Incorporation as contemplated in Section 16.2: requires an affirmative vote of a GNSO Supermajority.

(ii) GNSO Council Inspection Request as contemplated in Section 22.7: requires an affirmative vote of more than one-fourth (1/4) vote of each House or majority of one House.

(iii) GNSO Council Inspection Remedy, as contemplated in Section 22.7 - e, and Stakeholder Group / Constituency Inspection Remedy, as contemplated in Section 22.7 – e(ii) and e(iii), for an inspection requested by the GNSO as a Decisional Participant in the Empowered Community: requires an affirmative vote of more than one-fourth (1/4) vote of each House or majority of one House.

(iv) Amendments to Fundamental Bylaws and Article Amendments as contemplated by Section 25.2 of the Bylaws, Asset Sales, as contemplated by Article 26 of the Bylaws, amendments to ICANN Articles of Incorporation: requires an affirmative vote of a GNSO Supermajority.

(v) Approval of a Nominating Committee Director Removal Petition as contemplated in Annex D, Article 3, Section 3.1(b) and support for a petition submitted by a Petitioning Decisional Participant as contemplated in Section 3.2(d): requires an affirmative vote of a GNSO Supermajority.

(vi) Approval of a Nominating Committee Director Removal Supported Petition as contemplated in Annex D, Article 3, Section 3.1(f): requires an affirmative vote of a GNSO Supermajority.

(vii) Approval of a petition to remove a director holding seat 13 or 14 as contemplated in Annex D, Article 3, Section 3.2(a): requires an affirmative vote of at least three-fourths (3/4) of the House that appointed that Director.

(viii) Approval of a petition notice to remove a director holding seat 13 or 14 as contemplated in Annex D, Article 3, Section 3.2(f): requires an affirmative vote of at least three-fourths (3/4) of the GNSO Council and at least three-fourths (3/4) of the House that appointed that Director.

(ix) Approval of a Board Recall Petition as contemplated in Annex D, Article 3, Section 3.3(b) and support for another Petitioning Decisional Participant: requires an affirmative vote of a GNSO Supermajority.

(x) Approval of a Board Recall Supported Petition as contemplated in Annex D, Article 3, Section 3.3(e): requires an affirmative vote of a GNSO Supermajority.

Section 11.4. STAFF SUPPORT AND FUNDING

(a) 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").

(b) 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.

Section 11.5. STAKEHOLDER GROUPS

(a) The following "Stakeholder Groups" are hereby recognized as representative of a specific group of one or more "Constituencies" or interest groups:

(i) Registries Stakeholder Group representing all gTLD registries under contract to ICANN;

(ii) Registrars Stakeholder Group representing all registrars accredited by and under contract to ICANN;

(iii) Commercial Stakeholder Group representing the full range of large and small commercial entities of the Internet ("Commercial Stakeholder Group"), which includes the Business Constituency ("Business Constituency"), Intellectual Property Constituency ("Intellectual Property Constituency") and the Internet Service Providers and Connectivity Providers Constituency ("Internet Service Providers and Connectivity Providers Constituency"); and

(iv) Non-Commercial Stakeholder Group representing the full range of non-commercial entities of the Internet.

(b) Each Stakeholder Group is assigned a specific number of GNSO Council seats in accordance with Section 11.3(a).

(c) Each Stakeholder Group identified in Section 11.3(a) 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.

(d) 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:

(i) 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;

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

(iii) A recommendation for organizational placement within a particular Stakeholder Group; and

(iv) 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.

(e) The Board may create new Constituencies as described in Section 11.5(c) 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 11.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 11.3(d).

ARTICLE 12 ADVISORY COMMITTEES

Section 12.1. GENERAL

The Board may create one or more "Advisory Committees" in addition to those set forth in this Article 12. 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 12.2. SPECIFIC ADVISORY COMMITTEES

There shall be at least the following Advisory Committees:

(a) Governmental Advisory Committee

(i) 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.

(ii) 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.

(iii) 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.

(iv) 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.

(v) Each member of the Governmental Advisory Committee shall appoint one accredited representative to the Governmental Advisory 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.

(vi) The Governmental Advisory Committee shall annually appoint one Liaison to the Board, without limitation on reappointment, and shall annually appoint one non-voting liaison to the ICANN Nominating Committee.

(vii) 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.

(viii) 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 the Supporting Organizations or Advisory Committees seeks public comment, and shall take duly into account any timely response to that notification prior to taking action.

(ix) 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.

(x) 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 Board determines to take an action that is not consistent with Governmental Advisory Committee advice, it shall so inform the Governmental Advisory Committee and state the reasons why it decided not to follow that advice. Any Governmental Advisory Committee advice approved by a full Governmental Advisory Committee consensus, understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection ("GAC Consensus Advice"), may only be rejected by a vote of no less than 60% of the Board, and the Governmental Advisory Committee and the Board will then try, in good faith and in a timely and efficient manner, to find a mutually acceptable solution. The Governmental Advisory Committee will state whether any advice it gives to the Board is GAC Consensus Advice.

(xi) If GAC Consensus Advice is rejected by the Board pursuant to Section 12.2(a)(x) and if no such mutually acceptable solution can be found, the 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.

(b) Security and Stability Advisory Committee

(i) The role of the Security and Stability Advisory Committee ("Security and Stability Advisory Committee" or "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:

(A) 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 SSAC 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.

(B) 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 SSAC shall recommend any necessary audit activity to assess the current status of DNS and address allocation security in relation to identified risks and threats.

(C) To communicate with those who have direct responsibility for Internet naming and address allocation security matters (IETF, RSSAC (as defined in Section 12.2(c)(i)), 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 SSAC shall monitor these activities and inform the ICANN community and Board on their progress, as appropriate.

(D) To report periodically to the Board on its activities.

(E) To make policy recommendations to the ICANN community and Board.

(ii) 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. Members may be re-appointed, and there are no limits to the number of terms 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. The Board shall also have the power to remove SSAC appointees as recommended by or in consultation with the SSAC.

(iii) The SSAC shall annually appoint a Liaison to the Board according to Section 7.9.

(i) The role of the Root Server System Advisory Committee ("Root Server System Advisory Committee" or "RSSAC") is to advise the ICANN community and Board on matters relating to the operation, administration, security, and integrity of the Internet's Root Server System. It shall have the following responsibilities:

(A) Communicate on matters relating to the operation of the Root Servers and their multiple instances with the Internet technical community and the ICANN community. The RSSAC shall gather and articulate requirements to offer to those engaged in technical revision of the protocols and best common practices related to the operation of DNS servers.

(B) Communicate on matters relating to the administration of the Root Zone with those who have direct responsibility for that administration. These matters include the processes and procedures for the production of the Root Zone File.

(C) Engage in ongoing threat assessment and risk analysis of the Root Server System and recommend any necessary audit activity to assess the current status of root servers and the root zone.

(D) Respond to requests for information or opinions from the Board.

(E) Report periodically to the Board on its activities.

(F) Make policy recommendations to the ICANN community and Board.

(ii) The RSSAC shall be led by a chair.

(A) RSSAC membership appointment shall be for a three-year term, commencing on 1 January and ending the second year thereafter on 31 December. Members may be re-appointed, and there are no limits to the number of terms the members may serve.

(iii) The RSSAC shall annually appoint a Liaison to the Board according to Section 7.9(a)(ii).

(B) The RSSAC shall recommend the appointment of the chair to the Board following a nomination process that it devises and documents.

(iii) The RSSAC shall annually appoint a Liaison to the Board according to Section 7.9jm.

(d) At-Large Advisory Committee

(i) The At-Large Advisory Committee ("At-Large Advisory Committee" or "ALAC") is the primary organizational home within ICANN for individual Internet users. The role of the ALAC shall be to consider and provide advice on the activities of ICANN, insofar as they relate to the interests of individual Internet users. This includes policies created through ICANN's Supporting Organizations, as well as the many other issues for which community input and advice is appropriate. The ALAC, which plays an important role in ICANN's accountability mechanisms, also coordinates some of ICANN's outreach to individual Internet users.

(ii) The ALAC shall consist of (A) two members selected by each of the Regional At-Large Organizations ("RALOs") established according to Section 12.2(d)(vii), and (B) 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 7.5.

(iii) The regular terms of members of the ALAC shall be as follows:

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

(B) 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.

(C) 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.

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

(iv) The Chair of the ALAC shall be elected by the members of the ALAC pursuant to procedures adopted by the ALAC.

(v) The ALAC 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) to the Nominating Committee.

(vi) The At-Large Advisory Committee may designate non-voting liaisons to each of the ccNSO Council and the GNSO Council.

(vii) There shall be one RALO for each Geographic Region established according to Section 7.5. 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 ("At-Large Structures").

(viii) 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 Section 12.2(d)(ix). 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.

(ix) Membership in the At-Large Community

(A) 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.

(B) 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 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.

(C) 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.

(D) 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.

(E) Once the criteria and standards have been established as provided in this Section 12.2(d)(ix), 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.

(F) 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 an At-Large Structure applications shall be subject to review by the RALOs and by the Board.

(G) 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.

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

(x) The ALAC is also responsible, working in conjunction with the RALOs, for coordinating the following activities:

(A) Nominating individuals to fill Seat 15 on the Board. Notification of the At-Large Community's nomination shall be given by the ALAC Chair in writing to the EC Administration, with a copy to the Secretary, and the EC shall promptly act on it as provided in Section 7.25.

(B) Keeping the community of individual Internet users informed about the significant news from ICANN;

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

(D) Promoting outreach activities in the community of individual Internet users;

(E) Developing and maintaining on-going information and education programs, regarding ICANN and its work;

(F) Establishing an outreach strategy about ICANN issues in each RALO's Geographic Region;

(G) Participating in the ICANN policy development processes and providing input and advice that accurately reflects the views of individual Internet users;

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

(I) Offering Internet-based mechanisms that enable discussions among members of At-Large Structures; and

(xi) 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 12.3. PROCEDURES

Each Advisory Committee shall determine its own rules of procedure and quorum requirements; provided that each Advisory Committee shall ensure that the advice provided to the Board by such Advisory Committee is communicated in a clear and unambiguous written statement, including the rationale for such advice. The Board will respond in a timely manner to formal advice from all Advisory Committees explaining what action it took and the rationale for doing so.

Section 12.4. TERM OF OFFICE

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

Section 12.5. VACANCIES

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

Section 12.6. COMPENSATION

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

ARTICLE 13 OTHER ADVISORY MECHANISMS

Section 13.1. EXTERNAL EXPERT ADVICE

(a) 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.

(b) Types of Expert Advisory Panels

(i) 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 13.1(c) shall apply.

(ii) In addition, in accordance with Section 13.1(c), the Board may refer issues of public policy pertinent to matters within ICANN's Mission to a multinational governmental or treaty organization.

(i) 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.

(ii) 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.

(iii) 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.

(d) 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 13.1(b)(i) 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.

(e) Receipt of Expert Advice and its Effect. External advice pursuant to this Section 13.1 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.

(f) 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 13.2. TECHNICAL LIAISON GROUP

(a) 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.

(b) 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").

(c) 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:

(i) 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.

(ii) 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.

(d) 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.

(e) Technical Work with the IETF. The TLG shall have no involvement with ICANN's work for the Internet Engineering Task Force (IETF), Internet Research Task Force, or the Internet Architecture Board (IAB), as described in the IETF-ICANN Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority ratified by the Board on 10 March 2000 and any supplemental agreements thereto.

(f) 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.

ARTICLE 14 BOARD AND TEMPORARY COMMITTEES

Section 14.1. BOARD COMMITTEES

The Board may establish one or more committees of the Board (each, a "Board Committee"), which shall continue to exist until otherwise determined by the Board. Only Directors may be appointed to a Committee of the Board; provided, that a Liaison may be appointed as a liaison to a Committee of the Board consistent with their non-voting capacity. 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 Directors; provided, 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 Directors.

Section 14.2. POWERS OF BOARD COMMITTEES

(a) The Board may delegate to Committees of the Board all legal authority of the Board except with respect to:

(i) The filling of vacancies on the Board or on any committee;

(ii) The amendment or repeal of Bylaws or the Articles of Incorporation or the adoption of new Bylaws or Articles of Incorporation;

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

(iv) The appointment of committees of the Board or the members thereof;

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

(vi) The approval of the ICANN Budget or IANA Budget required by Section 22.4 or the Operating Plan or Strategic Plan required by Section 22.5; or

(vii) The compensation of any Officer described in Article 15.

(b) 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 of committees shall be governed by the provisions of Article 7 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 14.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 15 OFFICERS

Section 15.1. OFFICERS

The officers of ICANN (each, an "Officer") 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 15.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 Chair of the 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 15.3. REMOVAL OF OFFICERS

Any Officer may be removed, either with or without cause, by a two-thirds (2/3) majority vote of all Directors. 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 15.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 Director, and shall have all the same rights and privileges of any Director. 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 15.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 15.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 the ICANN Budget, the IANA Budget and Operating Plan. 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 15.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 15.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 15.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 16 POST-TRANSITION IANA ENTITY

Section 16.1. DESCRIPTION

ICANN shall maintain as a separate legal entity a California nonprofit public benefit corporation (["PTI"]) for the purpose of providing IANA services, including providing IANA naming function services pursuant to the IANA Naming Function Contract, as well as other services as determined by ICANN in coordination with the direct and indirect customers of the IANA functions. ICANN shall at all times be the sole member of PTI as that term is defined in Section 5056 of the CCC ("Member"). For the purposes of these Bylaws, the "IANA naming function" does not include the Internet Protocol numbers and Autonomous System numbers services (as contemplated by Section 1.1(a)(iii)), the protocol ports and parameters services and the root zone maintainer function.

Section 16.2. PTI Governance

(a) ICANN, in its capacity as the sole Member of PTI, shall elect the directors of PTI in accordance with the articles of incorporation and bylaws of PTI and have all other powers of a sole Member under the CCC except as otherwise provided in these Bylaws.

(b) No amendment or modification of the articles of incorporation of PTI shall be effective unless approved by the EC (pursuant to the procedures applicable to Articles Amendments described in Section 25.2, as if such Article Amendment referenced therein refers to an amendment of PTI's articles of incorporation).

(c) ICANN shall not amend or modify the bylaws of PTI in a manner that would effect any of the matters set forth in clauses (i) through (xiv) below (a "PTI Bylaw Amendment") if such PTI Bylaw Amendment has been rejected by the EC pursuant to the procedures described in Section 16.2(e):

(i) any change to the corporate form of PTI to an entity that is not a California nonprofit public benefit corporation organized under the CCC or any successor statute;

(ii) any change in the corporate mission of PTI that is materially inconsistent with ICANN's Mission as set forth in these Bylaws;

(iii) any change to the status of PTI as a corporation with members;

(iv) any change in the rights of ICANN as the sole Member of PTI, including voting, classes of membership, rights, privileges, preferences, restrictions and conditions;

(v) any change that would grant rights to any person or entity (other than ICANN) with respect to PTI as designators or otherwise to: (A) elect or designate directors of PTI; or (B) approve any amendments to the articles of incorporation or bylaws of PTI;

(vi) any change in the number of directors of the board of directors of PTI (the "PTI Board");

(vii) any changes in the allocation of directors on the PTI Board between independent directors and employees of ICANN or employees of PTI or to the definition of "independent" (as used in PTI's bylaws) for purposes of determining whether a director of PTI is independent;

(viii) the creation of any committee of the PTI Board with the power to exercise the authority of the PTI Board;

(ix) any change in the procedures for nominating independent PTI directors;

(x) the creation of classes of PTI directors or PTI directors with different terms or voting rights;

(xi) any change in PTI Board quorum requirements or voting requirements;

(xii) any change to the powers and responsibilities of the PTI Board or the PTI officers;

(xiii) any change to the rights to exculpation and indemnification that is adverse to the exculpated or indemnified party, including with respect to advancement of expenses and insurance, provided to directors, officers, employees or other agents of PTI; or

(xiv) any change to the requirements to amend the articles of incorporation or bylaws of PTI.

(d) ICANN shall not take any of the following actions (together with the PTI Bylaw Amendments, "PTI Governance Actions") if such PTI Governance Action has been rejected by the EC pursuant to the procedures described in Section 16.2(e).

(i) Any resignation by ICANN as sole Member of PTI or any transfer, disposition, cession, expulsion, suspension or termination by ICANN of its membership in PTI or any transfer, disposition, cession, expulsion, suspension or termination by ICANN of any right arising from its membership in PTI.

(ii) Any sale, transfer or other disposition of PTI's assets, other than (A) in the ordinary course of PTI's business, (B) in connection with an IANA Naming Function Separation Process (as defined in Section 19.1(a)) that has been approved in accordance with Article 19 or (C) the disposition of obsolete, damaged, redundant or unused assets.

(iii) Any merger, consolidation, sale or reorganization of PTI.

(iv) Any dissolution, liquidation or winding-up of the business and affairs of PTI or the commencement of any other voluntary bankruptcy proceeding of PTI.

(e) Promptly after the Board approves a PTI Governance Action (a "PTI Governance Action Approval"), the Secretary shall provide a notice of the Board's decision to the EC Administration and the Decisional Participants ("Board Notice"), which Board Notice shall enclose a copy of the PTI Governance Action that is the subject of the PTI Governance Action Approval. ICANN shall post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website promptly following the delivery of the Board Notice to the EC Administration and the Decisional Participants. The EC Administration shall promptly commence and comply with the procedures and requirements specified in Article 2 of Annex D.

(i) A PTI Governance Action shall become effective upon the earliest to occur of the following:

(A)(1) A Rejection Action Petition Notice (as defined in Section 2.2(c)(i) of Annex D) is not timely delivered by the Rejection Action Petitioning Decisional Participant (as defined in Section 2.2(c)(i) of Annex D) to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D or (2) a Rejection Process Termination Notice (as defined in Section 2.2(c)(ii) of Annex D) is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D, in which case the PTI Governance Action that is the subject of the PTI Governance Action Approval shall be in full force and effect as of the date immediately following the expiration of the Rejection Action Petition Period (as defined in Section 2.2(b) of Annex D) relating to such PTI Governance Action Approval and the effectiveness of such PTI Governance Action shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D;

(B)(1) A Rejection Action Supported Petition (as defined in Section 2.2(d)(i) of Annex D) is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D, in which case the PTI Governance Action that is the subject of the PTI Governance Action Approval shall be in full force and effect as of the date immediately following the expiration of the Rejection Action Petition Support Period (as defined in Section 2.2(d)(i) of Annex D) relating to such PTI Governance Action Approval and the effectiveness of such PTI Governance Action shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D; and

(C)(1) An EC Rejection Notice (as defined in Section 2.4(b) of Annex D) is not timely delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4 of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4(c) of Annex D, in which case the PTI Governance Action that is the subject of the PTI Governance Action Approval shall be in full force and effect as of the date immediately following the expiration of the Rejection Action Decision Period (as defined in Section 2.4(a) of Annex D) relating to such PTI Governance Action Approval and the effectiveness of such PTI Governance Action shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D.

(ii) A PTI Governance Action that has been rejected by the EC pursuant to and in compliance with Article 2 of Annex D shall have no force and effect, and shall be void ab initio.

(iii) Following receipt of an EC Rejection Notice relating to a PTI Governance Action, ICANN staff and the Board shall consider the explanation provided by the EC Administration as to why the EC has chosen to reject the PTI Governance Action in determining whether or not to develop a new PTI Governance Action and the substance of such new PTI Governance Action, which shall be subject to the procedures of this Section 16.2.

Section 16.3. IANA NAMING FUNCTION CONTRACT

(a) On or prior to 1 October 2016, ICANN shall enter into a contract with PTI for the performance of the IANA naming function (as it may be amended or modified, the "IANA Naming Function Contract") and a related statement of work (the "IANA Naming Function SOW"). Except as to implement any modification, waiver or amendment to the IANA Naming Function Contract or IANA Naming Function SOW related to an IFR Recommendation or Special IFR Recommendation approved pursuant to Section 18.6 or an SCWG Recommendation approved pursuant to Section 19.4 (which, for the avoidance of doubt, shall not be subject to this Section 16.3(a)), ICANN shall not agree to modify, amend or waive any Material Terms (as defined below) of the IANA Naming Function Contract or the IANA Naming Function SOW if a majority of each of the ccNSO and GNSO Councils reject the proposed modification, amendment or waiver. The following are the "Material Terms" of the IANA Naming Function Contract and IANA Naming Function SOW:

(i) The parties to the IANA Naming Function Contract and IANA Naming Function SOW;

(ii) The initial term and renewal provisions of the IANA Naming Function Contract and IANA Naming Function SOW;

(iii) The manner in which the IANA Naming Function Contract or IANA Naming Function SOW may be terminated;

(iv) The mechanisms that are available to enforce the IANA Naming Function Contract or IANA Naming Function SOW;

(v) The role and responsibilities of the CSC (as defined in Section 17.1), escalation mechanisms and/or the IFR (as defined in Section 18.1);

(vi) The IANA Naming Function Contract's provisions requiring that fees charged by PTI be based on direct costs and resources incurred by PTI;

(vii) The IANA Naming Function Contract's prohibition against subcontracting;

(viii)The availability of the IRP as a point of escalation for claims of PTI's failure to meet defined service level expectations;

(ix) The IANA Naming Function Contract's audit requirements; and

(x) The requirements related to ICANN funding of PTI.

(b) ICANN shall enforce its rights under the IANA Naming Function Contract and the IANA Naming Function SOW.

ARTICLE 17 CUSTOMER STANDING COMMITTEE

Section 17.1. DESCRIPTION

ICANN shall establish a Customer Standing Committee ("CSC") to monitor PTI's performance under the IANA Naming Function Contract and IANA Naming Function SOW.

The mission of the CSC is to ensure continued satisfactory performance of the IANA naming function for the direct customers of the naming services. The direct customers of the naming services are top-level domain registry operators as well as root server operators and other non-root zone functions.

The CSC will achieve this mission through regular monitoring of the performance of the IANA naming function against the IANA Naming Function Contract and IANA Naming Function SOW and through mechanisms to engage with PTI to remedy identified areas of concern.

The CSC is not authorized to initiate a change in PTI through a Special IFR (as defined in Section 18.1), but may escalate a failure to correct an identified deficiency to the ccNSO and GNSO, which might then decide to take further action using consultation and escalation processes, which may include a Special IFR. The ccNSO and GNSO may address matters escalated by the CSC, pursuant to their operating rules and procedures.

Section 17.2. COMPOSITION, APPOINTMENT, TERM AND REMOVAL

(a) The CSC shall consist of:

(i) Two individuals representing gTLD registry operators appointed by the Registries Stakeholder Group;

(ii) Two individuals representing ccTLD registry operators appointed by the ccNSO; and

(iii) One individual liaison appointed by PTI,

each appointed in accordance with the rules and procedures of the appointing organization; provided that such individuals should have direct experience and knowledge of the IANA naming function.

(b) If so determined by the ccNSO and GNSO, the CSC may, but is not required to, include one additional member: an individual representing top-level domain registry operators that are not considered a ccTLD or gTLD, who shall be appointed by the ccNSO and the GNSO. Such representative shall be required to submit a letter of support from the registry operator it represents.

(c) Each of the following organizations may also appoint one liaison to the CSC in accordance with the rules and procedures of the appointing organization: (i) GNSO (from the Registrars Stakeholder Group or the Non-Contracted Parties House), (ii) ALAC, (iii) either the NRO or ASO (as determined by the ASO), (iv) GAC, (v) RSSAC, (vi) SSAC and (vii) any other Supporting Organization or Advisory Committee established under these Bylaws.

(d) The GNSO and ccNSO shall approve the initial proposed members and liaisons of the CSC, and thereafter, the ccNSO and GNSO shall approve each annual slate of members and liaisons being recommended for a new term.

(e) The CSC members and liaisons shall select from among the CSC members who will serve as the CSC's liaison to the IFRT (as defined in Section 18.1) and any Separation Cross-Community Working Group ("SCWG").

(f) Any CSC member or liaison may be removed and replaced at any time and for any reason or no reason by the organization that appointed such member or liaison.

(g) In addition, the Chair of the CSC may recommend that a CSC member or liaison be removed by the organization that appointed such member or liaison, upon any of the following: (i) (A) for not attending without sufficient cause a minimum of nine CSC meetings in a one-year period (or at least 75% of all CSC meetings in a one-year period if less than nine meetings were held in such one-year period) or (B) if such member or liaison has been absent for more than two consecutive meetings without sufficient cause; or (ii) for grossly inappropriate behavior.

(h) A vacancy on the CSC shall be deemed to exist in the event of the death, resignation or removal of any CSC member or liaison. Vacancies shall be filled by the organization(s) that appointed such CSC member or liaison. The appointing organization(s) shall provide written notice to the Secretary of its appointment to fill a vacancy, with a notification copy to the Chair of the CSC. The organization(s) responsible for filling such vacancy shall use its reasonable efforts to fill such vacancy within one month after the occurrence of such vacancy.

Section 17.3.CSC CHARTER; PERIODIC REVIEW

(a) The CSC shall act in accordance with its charter (the "CSC Charter").

(b) The effectiveness of the CSC shall be reviewed two years after the first meeting of the CSC; and then every three years thereafter. The method of review will be determined by the ccNSO and GNSO and the findings of the review will be published on the Website.

(c) The CSC Charter shall be reviewed by a committee of representatives from the ccNSO and the Registries Stakeholder Group selected by such organizations. This review shall commence one year after the first meeting of the CSC. Thereafter, the CSC Charter shall be reviewed by such committee of representatives from the ccNSO and the Registries Stakeholder Group selected by such organizations at the request of the CSC, ccNSO, GNSO, the Board and/or the PTI Board and/or by an IFRT in connection with an IFR.

(d) Amendments to the CSC Charter shall not be effective unless ratified by the vote of a simple majority of each of the ccNSO and GNSO Councils pursuant to each such organizations' procedures. Prior to any action by the ccNSO and GNSO, any recommended changes to the CSC Charter shall be subject to a public comment period that complies with the designated practice for public comment periods within ICANN. Notwithstanding the foregoing, to the extent any provision of an amendment to the CSC Charter conflicts with the terms of the Bylaws, the terms of the Bylaws shall control.

Section 17.4. ADMINISTRATIVE AND OPERATIONAL SUPPORT

ICANN shall provide administrative and operational support necessary for the CSC to carry out its responsibilities, including providing and facilitating remote participation in all meetings of the CSC.

ARTICLE 18 IANA NAMING FUNCTION REVIEWS

Section 18.1. IANA NAMING FUNCTION REVIEW

The Board, or an appropriate committee thereof, shall cause periodic and/or special reviews (each such review, an "IFR") of PTI's performance of the IANA naming function against the contractual requirements set forth in the IANA Naming Function Contract and the IANA Naming Function SOW to be carried out by an IANA Function Review Team ("IFRT") established in accordance with Article 18, as follows:

(a) Regularly scheduled periodic IFRs, to be conducted pursuant to Section 18.2 below ("Periodic IFRs"); and

(b) IFRs that are not Periodic IFRs, to be conducted pursuant to Section 18.12 below ("Special IFRs").

Section 18.2. FREQUENCY OF PERIODIC IFRS

(a) The first Periodic IFR shall be convened no later than 1 October 2018.

(b) Periodic IFRs after the first Periodic IFR shall be convened no less frequently than every five years, measured from the date the previous IFRT for a Periodic IFR was convened.

(c) In the event a Special IFR is ongoing at the time a Periodic IFR is required to be convened under this Section 18.2, the Board shall cause the convening of the Periodic IFR to be delayed if such delay is approved by the vote of (i) a supermajority of the ccNSO Council (pursuant to the ccNSO's procedures or, if such procedures do not define a supermajority, two-thirds (2/3) of the ccNSO Council's members) and (ii) a GNSO Supermajority. Any decision by the ccNSO and GNSO to delay a Periodic IFR must identify the period of delay, which should generally not exceed 12 months after the completion of the Special IFR.

Section 18.3. IFR RESPONSIBILITIES

For each Periodic IFR, the IFRT shall:

(a) Review and evaluate the performance of PTI against the requirements set forth in the IANA Naming Function Contract in relation to the needs of its direct customers and the expectations of the broader ICANN community, and determine whether to make any recommendations with respect to PTI's performance;

(b) Review and evaluate the performance of PTI against the requirements set forth in the IANA Naming Function Contract and IANA Naming Function SOW;

(c) Review the IANA Naming Function SOW and determine whether to recommend any amendments to the IANA Naming Function Contract and IANA Naming Function SOW to account for the needs of the direct customers of the naming services and/or the community at large;

(d) Review and evaluate the openness and transparency procedures of PTI and any oversight structures for PTI's performance, including reporting requirements and budget transparency;

(e) Review and evaluate the performance and effectiveness of the EC with respect to actions taken by the EC, if any, pursuant to Section 16.2, Section 18.6, Section 18.12, Section 19.1, Section 19.4, Section 22.4(b) and Annex D;

(f) Review and evaluate the performance of the IANA naming function according to established service level expectations during the IFR period being reviewed and compared to the immediately preceding Periodic IFR period;

(g) Review and evaluate whether there are any systemic issues that are impacting PTI's performance under the IANA Naming Function Contract and IANA Naming Function SOW;

(h) Initiate public comment periods and other processes for community input on PTI's performance under the IANA Naming Function Contract and IANA Naming Function SOW (such public comment periods shall comply with the designated practice for public comment periods within ICANN);

(i) Consider input from the CSC and the community on PTI's performance under the IANA Naming Function Contract and IANA Naming Function SOW;

(j) Identify process or other areas for improvement in the performance of the IANA naming function under the IANA Naming Function Contract and IANA Naming Function SOW and the performance of the CSC and the EC as it relates to oversight of PTI; and

(k) Consider and assess any changes implemented since the immediately preceding IFR and their implications for the performance of PTI under the IANA Naming Function Contract and IANA Naming Function SOW.

Section 18.4. IFR REQUIRED INPUTS

In conducting an IFR, the IFRT shall review and analyze the following information:

(a) Reports provided by PTI pursuant to the IANA Naming Function Contract and/or IANA Naming Function SOW during the IFR period being reviewed, any portion of which may be redacted pursuant to the Confidential Disclosure Framework set forth in the Operating Standards in accordance with Section 4.6(a)(vi);

(b) Reports provided by the CSC in accordance with the CSC Charter during the IFR period being reviewed;

(c) Community inputs through public consultation procedures as reasonably determined by the IFRT, including, among other things, public comment periods, input provided at in-person sessions during ICANN meetings, responses to public surveys related to PTI's performance under the IANA Naming Function Contract and IANA Naming Function SOW, and public inputs during meetings of the IFRT;

(d) Recommendations for technical, process and/or other improvements relating to the mandate of the IFR provided by the CSC or the community; and

(e) Results of any site visit conducted by the IFRT, which shall be conducted in consultation with ICANN (i) upon reasonable notice, (ii) in a manner so as to not affect PTI's performance under the IANA Naming Function Contract or the IANA Naming Function SOW and (iii) pursuant to procedures and requirements reasonably developed by ICANN and reasonably acceptable to the IFRT. Any such site visit shall be limited to matters reasonably related to the IFRT's responsibilities pursuant to Section 18.3.

Section 18.5. IFR RESULTS AND RECOMMENDATIONS

(a) The results of the IFR are not limited and could include a variety of recommendations or no recommendation; provided, however, that any recommendations must directly relate to the matters discussed in Section 18.3 and comply with this Section 18.5.

(b) Any IFRT recommendations should identify improvements that are supported by data and associated analysis about existing deficiencies and how they could be addressed. Each recommendation of the IFRT shall include proposed remedial procedures and describe how those procedures are expected to address such issues. The IFRT's report shall also propose timelines for implementing the IFRT's recommendations. The IFRT shall attempt to prioritize each of its recommendations and provide a rationale for such prioritization.

(c) In any case where a recommendation of an IFRT focuses on a service specific to gTLD registry operators, no such recommendation shall be made by the IFRT in any report to the community (including any report to the Board) if opposition to such recommendation is expressed by any IFRT member appointed by the Registries Stakeholder Group. In any case where a recommendation of an IFRT focuses on a service specific to ccTLD registry operators, no such recommendation shall be made by the IFRT in any report to the community (including any report to the Board) if opposition to such recommendation is expressed by any IFRT member appointed by the ccNSO.

(d) Notwithstanding anything herein to the contrary, the IFRT shall not have the authority to review or make recommendations relating to policy or contracting issues that are not included in the IANA Naming Function Contract or the IANA Naming Function SOW, including, without limitation, policy development, adoption processes or contract enforcement measures between contracted registries and ICANN.

Section 18.6. RECOMMENDATIONS TO AMEND THE IANA NAMING FUNCTION CONTRACT, IANA NAMING FUNCTION SOW OR CSC

(a) The IFRT may recommend, among other things to the extent reasonably related to the IFR responsibilities set forth in Section 18.3, amendments to the IANA Naming Function Contract, IANA Naming Function SOW and/or the CSC Charter. The IFRT shall, at a minimum, take the following steps before an amendment to either the IANA Naming Function Contract, IANA Naming Function SOW or CSC Charter is proposed:

(i) Consult with the Board (such consultation to be conducted in parallel with other processes set forth in this Section 18.6(a)) and PTI;

(ii) Consult with the CSC;

(iii) Conduct a public input session for ccTLD and gTLD registry operators; and

(iv) Seek public comment on the amendments that are under consideration by the IFRT through a public comment period that complies with the designated practice for public comment periods within ICANN.

(b) A recommendation of an IFRT for a Periodic IFR that would amend the IANA Naming Function Contract or IANA Naming Function SOW shall only become effective if, with respect to each such recommendation (each, an "IFR Recommendation"), each of the following occurs in addition to the steps set out in Section 18.6(a)(i)-(iv) above:

(i) The IFR Recommendation has been approved by the vote of (A) a supermajority of the ccNSO Council (pursuant to the ccNSO's procedures or, if such procedures do not define a supermajority, two-thirds (2/3) of the ccNSO Council's members) and (B) a GNSO Supermajority;

(ii) The Board has approved the IFR Recommendation; and

(iii) The EC has not rejected the Board's approval of the IFR Recommendation pursuant to and in compliance with Section 18.6(e), if applicable.

(c) The Board shall accept or reject an IFR Recommendation within 45 days of the later of (1) the date that the condition in Section 18.6(b)(i) is satisfied or (2) the expiration of the public comment period contemplated by Section 18.6(a)(iv). If the Board does not act within that 45-day time period, the IFR Recommendation shall be deemed rejected.

(d) If the Board (x) rejects an IFR Recommendation that was approved by the ccNSO Council and GNSO Council pursuant to Section 18.6(b)(i) or (y) rejects an IFR Recommendation through expiration of time as specified in Section 18.6(c), , the Secretary shall provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall enclose a copy of the applicable IFR Recommendation. ICANN shall post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website promptly following the delivery of the Board Notice to the EC Administration and the Decisional Participants.

(i) ICANN shall, at the direction of the EC Administration, convene a Rejection Action Community Forum (as defined in Section 2.3(a) of Annex D), which Rejection Action Community Forum shall be conducted in accordance with Section 2.3 of Annex D, to discuss the Board Notice; provided, that, for purposes of Section 2.3 of Annex D, (A) the Board Notice shall be treated as the Rejection Action Supported Petition, (B) the EC Administration shall be treated as the Rejection Action Petitioning Decisional Participant (and there shall be no Rejection Action Supporting Decisional Participants (as defined in Section 2.2(d)(i) of Annex D) and (C) the Rejection Action Community Forum Period shall expire on the 21st day after the date the Secretary provides the Board Notice to the EC Administration and the Decisional Participants.

(ii) No later than 45 days after the conclusion of such Rejection Action Community Forum Period, the Board shall resolve to either uphold its rejection of the IFR Recommendation or approve the IFR Recommendation (either, a "Post-Forum IFR Recommendation Decision").

(A)If the Board in its Post-Forum IFR Recommendation Decision resolves to approve the IFR Recommendation, such IFR Recommendation will be subject to Section 18.6(e).

(B)For the avoidance of doubt, the Board shall not be obligated to change its decision on the IFR Recommendation as a result of the Rejection Action Community Forum.

(C)The Board's Post-Forum IFR Recommendation Decision shall be posted on the Website in accordance with the Board's posting obligations as set forth in Article 3.

(e) If the Board approves an IFR Recommendation that relates to an IANA Naming Function Separation Process as described in Article 19 (an "IFR Recommendation Decision"), the Secretary shall promptly provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall enclose a copy of the IFR Recommendation that is the subject of the IFR Recommendation Decision. ICANN shall post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website promptly following the delivery of the Board Notice to the EC Administration and the Decisional Participants. The EC Administration shall promptly commence and comply with the procedures and requirements specified in Article 2 of Annex D.

(i) An IFR Recommendation Decision shall become final upon the earliest to occur of the following:

(A)(1) A Rejection Action Petition Notice is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D, in which case the IFR Recommendation Decision shall be final as of the date immediately following the expiration of the Rejection Action Petition Period relating to such IFR Recommendation Decision;

(B)(1) A Rejection Action Supported Petition is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D, in which case the IFR Recommendation Decision shall be final as of the date immediately following the expiration of the Rejection Action Petition Support Period relating to such IFR Recommendation Decision; and

(C)(1) An EC Rejection Notice is not timely delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4 of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4(c) of Annex D, in which case the IFR Recommendation Decision shall be final as of the date immediately following the expiration of the Rejection Action Decision Period relating to such IFR Recommendation Decision.

(ii) An IFR Recommendation Decision that has been rejected by the EC pursuant to and in compliance with Article 2 of Annex D shall have no force and effect, and shall be void ab initio.

(f) Timelines for implementing any amendments to the IANA Naming Function Contract or IANA Naming Function SOW shall be reasonably agreed between the IFRT, ICANN and PTI.

(g) A recommendation of an IFRT that would amend the CSC Charter shall only become effective if approved pursuant to Section 17.3(d).

Section 18.7. COMPOSITION OF IFR TEAMS

Each IFRT shall consist of the following members and liaisons to be appointed in accordance with the rules and procedures of the appointing organization:

(a) Three representatives who are associated with ccTLD managers, appointed by the ccNSO Council. Representatives need not be associated with a ccNSO member. The ccNSO Council should use an inclusive process, which is open to all ccTLD managers, independent of their membership to the ccNSO. It is strongly recommended that the ccNSO Council reaches out to all ccTLD managers directly and/or through regional ccTLD organizations (i.e., AfTLD, APTLD, LACTLD, and CENTR) in seeking volunteers;

(b) Two representatives appointed by the Registries Stakeholder Group;

(d) One representative appointed by the Commercial Stakeholder Group;

(e) One representative appointed by the Non-Commercial Stakeholder Group;

(f) One representative appointed by the GAC;

(g) One representative appointed by the SSAC;

(h) One representative appointed by the RSSAC;

(i) One representative appointed by the ALAC;

(j) One liaison appointed by the CSC;

(k) One liaison who may be appointed by the ASO; and

(l) One liaison who may be appointed by the IAB.

(m) The IFRT shall also include an unlimited number of non-member, non-liaison participants.

(n) The IFRT shall not be a standing body. A new IFRT shall be constituted for each IFR and the IFRT shall automatically dissolve following the end of the process for approving such IFRT's IFR Recommendations pursuant to Section 18.6.

Section 18.8. MEMBERSHIP; ELECTION OF CO-CHAIRS, AND LIAISONS

(a) All candidates for appointment to the IFRT as a member or liaison shall submit an expression of interest to the organization that would appoint such candidate as a member or liaison to the IFRT, which shall state: (i) why the candidate is interested in becoming involved in the IFRT, (ii) what particular skills the candidate would bring to the IFRT, (iii) the candidate's knowledge of the IANA functions, (iv) the candidate's understanding of the purpose of the IFRT, and (v) that the candidate understands the time necessary to participate in the IFR process and can commit to the role.

(b) Members, liaisons and participants of the IFRT shall disclose to ICANN and the IFRT any conflicts of interest with a specific complaint or issue under review. The IFRT may exclude from the discussion of a specific complaint or issue any member deemed by the majority of IFRT members to have a conflict of interest. The co-chairs of the IFRT shall record any such conflict of interest in the minutes of the IFRT.

(c) To the extent reasonably possible, the appointing organizations for the IFRT members and liaisons shall work together to achieve an IFRT that is balanced for diversity (including functional, geographic and cultural) and skill, and should seek to broaden the number of individuals participating across the various reviews; provided, that the IFRT should include members from each ICANN Geographic Region. The ccNSO and Registries Stakeholder Group shall each endeavor to not appoint multiple members who are citizens of countries from the same ICANN Geographic Region, though an IFRT may proceed even if such geographic diversity targets for the ccNSO and/or the Registries Stakeholder Group appointees cannot be achieved.

(d) The IFRT shall be led by two co-chairs: one appointed by the GNSO from one of the members appointed pursuant to clauses (b)-(e) of Section 18.7 and one appointed by the ccNSO from one of the members appointed pursuant to clause (a) of Section 18.7.

(e) The PTI Board shall select a PTI staff member to serve as a point of contact to facilitate formal lines of communication between the IFRT and PTI. The Board shall select an ICANN staff member to serve as a point of contact to facilitate formal lines of communication between the IFRT and ICANN.

(f) Liaisons to the IFRT are not members of or entitled to vote on any matters before the IFRT, but otherwise are entitled to participate on equal footing with members of the IFRT.

(g) Other participants are entitled to participate in the IFRT, but are not entitled to vote.

(h) Removal and Replacement of IFRT Members and Liaisons

(i) The IFRT members and liaisons may be removed from the IFRT by their respective appointing organization at any time upon such organization providing written notice to the Secretary and the co-chairs of the IFRT.

(ii) A vacancy on the IFRT shall be deemed to exist in the event of the death, resignation or removal of any IFRT member or liaison. Vacancies shall be filled by the organization that appointed such IFRT member or liaison. The appointing organization shall provide written notice to the Secretary of its appointment to fill a vacancy, with a notification copy to the IFRT co-chairs. The organization responsible for filling such vacancy shall use its reasonable efforts to fill such vacancy within one month after the occurrence of such vacancy.

Section 18.9. MEETINGS

(a) All actions of the IFRT shall be taken by consensus of the IFRT, which is where a small minority may disagree, but most agree. If consensus cannot be reached with respect to a particular issue, actions by the majority of all of the members of the IFRT shall be the action of the IFRT.

(b) Any members of the IFRT not in favor of an action (whether as a result of voting against a matter or objecting to the consensus position) may record a minority dissent to such action, which shall be included in the IFRT minutes and/or report, as applicable.

(c) IFRT meetings, deliberations and other working procedures shall be open to the public and conducted in a transparent manner to the fullest extent possible.

(d) The IFRT shall transmit minutes of its meetings to the Secretary, who shall cause those minutes to be posted to the Website as soon as practicable following each IFRT meeting. Recordings and transcripts of meetings, as well as mailing lists, shall also be posted to the Website.

Section 18.10. COMMUNITY REVIEWS AND REPORTS

(a) The IFRT shall seek community input as to the issues relevant to the IFR through one or more public comment periods that shall comply with the designated practice for public comment periods within ICANN and through discussions during ICANN's public meetings in developing and finalizing its recommendations and any report.

(b) The IFRT shall provide a draft report of its findings and recommendations to the community for public comment. The public comment period is required to comply with the designated practice for public comment periods within ICANN.

(c) After completion of the IFR, the IFRT shall submit its final report containing its findings and recommendations to the Board. ICANN shall thereafter promptly post the IFRT's final report on the Website.

Section 18.11. ADMINISTRATIVE AND OPERATIONAL SUPPORT

ICANN shall provide administrative and operational support necessary for each IFRT to carry out its responsibilities, including providing and facilitating remote participation in all meetings of the IFRT.

Section 18.12. SPECIAL IFRS

(a) A Special IFR may be initiated outside of the cycle for the Periodic IFRs to address any deficiency, problem or other issue that has adversely affected PTI's performance under the IANA Naming Function Contract and IANA Naming Function SOW (a "PTI Performance Issue"), following the satisfaction of each of the following conditions:

(i) The Remedial Action Procedures of the CSC set forth in the IANA Naming Function Contract shall have been followed and failed to correct the PTI Performance Issue and the outcome of such procedures shall have been reviewed by the ccNSO and GNSO according to each organization's respective operating procedures;

(ii) The ccNSO and GNSO shall have considered the outcomes of the processes set forth in the Section 18.12(a)(i)) and shall have conducted meaningful consultation with the other Supporting Organizations and Advisory Committees with respect to the PTI Performance Issue and whether or not to initiate a Special IFR; and

(iii) After a public comment period that complies with the designated practice for public comment periods within ICANN, if a public comment period is requested by the ccNSO and the GNSO, a Special IFR shall have been approved by the vote of (A) a supermajority of the ccNSO Council (pursuant to the ccNSO's procedures or if such procedures do not define a supermajority, two-thirds (2/3) of the Council members) and (B) a GNSO Supermajority.

(b) Each Special IFR shall be conducted by an IFRT and shall follow the same procedures and requirements applicable to Periodic IFRs as set forth in this Section 18, except that:

(i) The scope of the Special IFR and the related inputs that are required to be reviewed by the IFRT shall be focused primarily on the PTI Performance Issue, its implications for overall IANA naming function performance by PTI and how to resolve the PTI Performance Issue;

(ii) The IFRT shall review and analyze the information that is relevant to the scope of the Special IFR; and

(iii) Each recommendation of the IFRT made in a Special IFR must be related to remediating the PTI Performance Issue or other issue with PTI's performance that is related to the IFRT responsibilities set forth in Section 18.3, and shall include proposed remedial procedures and describe how those procedures are expected to address the PTI Performance Issue or other relevant issue with PTI's performance. For avoidance of doubt, the IFRT may issue recommendations to initiate an IANA Naming Function Separation Process through a Special IFR,

(c) A recommendation of an IFRT arising from a Special IFR shall only become effective if, with respect to each such recommendation (each, a "Special IFR Recommendation"), each of the following occurs:

(i) The Special IFR Recommendation has been approved by the vote of (A) a supermajority of the ccNSO Council (pursuant to the ccNSO's procedures or, if such procedures do not define a supermajority, two-thirds (2/3) of the ccNSO Council's members) and (B) a GNSO Supermajority;

(ii) After a public comment period that complies with the designated practice for public comment periods within ICANN, the Board has approved the Special IFR Recommendation; and

(iii) The EC has not rejected the Board's approval of the Special IFR Recommendation pursuant to and in compliance with Section 18.12(e).

(d) The Board shall accept or reject a Special IFR Recommendation within 45 days of the later of (1) the date that the condition in Section 18.12(c)(i) is satisfied or (2) the expiration of the public comment period contemplated by Section 18.12(c)(ii). If the Board does not act within that 45-day time period, the Special IFR Recommendation shall be deemed rejected.

(e) If the Board (x) rejects a Special IFR Recommendation that was approved by the ccNSO Council and GNSO Council pursuant to Section 18.12(c)(i) or (y) ) rejects an IFR Recommendation through expiration of time as specified in Section 18.12(d the Secretary shall promptly provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall enclose a copy of the applicable Special IFR Recommendation. ICANN shall post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website promptly following the delivery of the Board Notice to the EC Administration and the Decisional Participants.

(i) ICANN shall, at the direction of the EC Administration, convene a Rejection Action Community Forum, which Rejection Action Community Forum shall be conducted in accordance with Section 2.3 of Annex D, to discuss the Board Notice; provided, that, for purposes of Section 2.3 of Annex D, (A) the Board Notice shall be treated as the Rejection Action Supported Petition, (B) the EC Administration shall be treated as the Rejection Action Petitioning Decisional Participant (and there shall be no Rejection Action Supporting Decisional Participants) and (C) the Rejection Action Community Forum Period shall expire on the 21st day after the date the Secretary provides the Board Notice to the EC Administration and the Decisional Participants.

(ii) No later than 45 days after the conclusion of such Rejection Action Community Forum Period, the Board shall resolve to either uphold its rejection of the Special IFR Recommendation or approve the Special IFR Recommendation (either, a "Post-Forum Special IFR Recommendation Decision").

(A)If the Board resolves to approve the Special IFR Recommendation, such Special IFR Recommendation will be subject to Section 18.12(f).

(B)For the avoidance of doubt, the Board shall not be obligated to change its decision on the Special IFR Recommendation as a result of the Rejection Action Community Forum.

(C)The Board's Post-Forum Special IFR Recommendation Decision shall be posted on the Website in accordance with the Board's posting obligations as set forth in Article 3.

(f) If the Board approves a Special IFR Recommendation that relates to an IANA Naming Function Separation Process as described in Article 19, (a "Special IFR Recommendation Decision"), the Secretary shall promptly provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall enclose a copy of the Special IFR Recommendation that is the subject of the Special IFR Recommendation Decision. ICANN shall post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website promptly following the delivery of the Board Notice to the EC Administration and the Decisional Participants. The EC Administration shall promptly commence and comply with the procedures and requirements specified in Article 2 of Annex D.

(i) A Special IFR Recommendation Decision shall become final upon the earliest to occur of the following:

(A)(1) A Rejection Action Petition Notice is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D, in which case the Special IFR Recommendation Decision shall be final as of the date immediately following the expiration of the Rejection Action Petition Period relating to such Special IFR Recommendation Decision;

(B)(1) A Rejection Action Supported Petition is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D, in which case the Special IFR Recommendation Decision shall be final as of the date immediately following the expiration of the Rejection Action Petition Support Period relating to such Special IFR Recommendation Decision; and

(C)(1) An EC Rejection Notice is not timely delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4 of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4(c) of Annex D, in which case the Special IFR Recommendation Decision shall be final as of the date immediately following the expiration of the Rejection Action Decision Period relating to such Special IFR Recommendation Decision.

(ii) A Special IFR Recommendation Decision that has been rejected by the EC pursuant to and in compliance with Article 2 of Annex D shall have no force and effect, and shall be void ab initio.

Section 18.13. PROPOSED SEPARATION PROCESS

The IFRT conducting either a Special IFR or Periodic IFR may, upon conclusion of a Special IFR or Periodic IFR, as applicable, determine that an IANA Naming Function Separation Process is necessary and, if so, it shall recommend the creation of an SCWG pursuant to Article 19.

ARTICLE 19IANA NAMING FUNCTION SEPARATION PROCESS

Section 19.1. ESTABLISHING AN SCWG

(a) An "IANA Naming Function Separation Process" is the process initiated in accordance with this Article 19 pursuant to which PTI may cease to perform the IANA naming function including, without limitation, the initiation of a request for proposal to select an operator to perform the IANA naming function instead of PTI ("IANA Naming Function RFP"), the selection of an IANA naming function operator other than PTI, termination or non-renewal of the IANA Naming Function Contract, and/or divestiture, or other reorganization of PTI by ICANN.

(b) The Board shall establish an SCWG if each of the following occurs:

(i) The IFRT conducting either a Special IFR or Periodic IFR, upon conclusion of a Special IFR or Periodic IFR, as applicable, has recommended that an IANA Naming Function Separation Process is necessary and has recommended the creation of an SCWG (an "SCWG Creation Recommendation");

(ii) The SCWG Creation Recommendation has been approved by the vote of (A) a supermajority of the ccNSO Council (pursuant to the ccNSO's procedures or, if such procedures do not define a supermajority, two-thirds (2/3) of the ccNSO Council's members) and (B) a GNSO Supermajority;

(iii) After a public comment period that complies with the designated practice for public comment periods within ICANN, the Board has approved the SCWG Creation Recommendation. A determination by the Board to not approve an SCWG Creation Recommendation, where such creation has been approved by the ccNSO and GNSO Councils pursuant to Section 19.1(b)(ii), shall require a vote of at least two-thirds (2/3) of the Board and the Board shall follow the same consultation procedures set forth in Section 9 of Annex A of these Bylaws that relate to Board rejection of a PDP recommendation that is supported by a GNSO Supermajority; and

(iv) The EC has not rejected the Board's approval of the SCWG Creation Recommendation pursuant to and in compliance with Section 19.1(d).

(c) If the Board (x) rejects an SCWG Creation Recommendation that was approved by the ccNSO Council and GNSO Council pursuant to Section 19.1(b)(ii) or (y) does not resolve to either accept or reject an SCWG Creation Recommendation within 45 days of the later of (1) the date that the condition in Section 19.1(b)(ii) is satisfied or (2) the expiration of the public comment period contemplated by Section 19.1(b)(iii), the Secretary shall provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall enclose a copy of the applicable SCWG Creation Recommendation. ICANN shall post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website promptly following the delivery of the Board Notice to the EC Administration and the Decisional Participants.

(i) ICANN shall, at the direction of the EC Administration, convene a Rejection Action Community Forum, which Rejection Action Community Forum shall be conducted in accordance with Section 2.3 of Annex D, to discuss the Board Notice; provided, that, for purposes of Section 2.3 of Annex D, (A) the Board Notice shall be treated as the Rejection Action Supported Petition, (B) the EC Administration shall be treated as the Rejection Action Petitioning Decisional Participant (and there shall be no Rejection Action Supporting Decisional Participants) and (C) the Rejection Action Community Forum Period shall expire on the 21st day after the date the Secretary provides the Board Notice to the EC Administration and the Decisional Participants.

(ii) No later than 45 days after the conclusion of such Rejection Action Community Forum Period, the Board shall resolve to either uphold its rejection of the SCWG Creation Recommendation or approve the SCWG Creation Recommendation (either, a "Post-Forum SCWG Creation Recommendation Decision").

(A)If the Board resolves to approve the SCWG Creation Recommendation, such SCWG Creation Recommendation will be subject to Section 19.1(d).

(B)For the avoidance of doubt, the Board shall not be obligated to change its decision on the SCWG Creation Recommendation as a result of the Rejection Action Community Forum.

(C)The Board's Post-Forum SCWG Creation Recommendation Decision shall be posted on the Website in accordance with the Board's posting obligations as set forth in Article 3.

(d) Promptly after the Board approves an SCWG Creation Recommendation (an "SCWG Creation Decision"), the Secretary shall provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall enclose a copy of the SCWG Creation Decision. ICANN shall post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website promptly following the delivery of the Board Notice to the EC Administration and the Decisional Participants. The EC Administration shall promptly commence and comply with the procedures and requirements specified in Article 2 of Annex D.

(i) An SCWG Creation Decision shall become final upon the earliest to occur of the following:

(A)(1) A Rejection Action Petition Notice is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D, in which case the SCWG Creation Decision shall be final as of the date immediately following the expiration of the Rejection Action Petition Period relating to such SCWG Creation Decision;

(B)(1) A Rejection Action Supported Petition is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D, in which case the SCWG Creation Decision shall be final as of the date immediately following the expiration of the Rejection Action Petition Support Period relating to such SCWG Creation Decision; and

(C)(1) An EC Rejection Notice is not timely delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4 of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4(c) of Annex D, in which case the SCWG Creation Decision shall be final as of the date immediately following the expiration of the Rejection Action Decision Period relating to such SCWG Creation Decision.

(ii) An SCWG Creation Decision that has been rejected by the EC pursuant to and in compliance with Article 2 of Annex D shall have no force and effect, and shall be void ab initio.

Section 19.2. SCWG RESPONSIBILITIES

The responsibilities of the SCWG shall be as follows:

(a) The SCWG shall determine how to resolve the PTI Performance Issue(s) which the IFRT that conducted the Special IFR or Periodic IFR, as applicable, identified as triggering formation of this SCWG.

(b) If the SCWG recommends the issuance of an IANA Naming Function RFP, the SCWG shall:

(i) Develop IANA Naming Function RFP guidelines and requirements for the performance of the IANA naming function, in a manner consistent with ICANN's publicly available procurement guidelines (as in effect immediately prior to the formation of the SCWG); and

(ii) Solicit input from ICANN as well as the global Internet community (through community consultation, including public comment opportunities as necessary that comply with the designated practice for public comment periods within ICANN) on requirements to plan and participate in the IANA Naming Function RFP process.

(c) If an SCWG Recommendation (as defined in Section 19.4(b)) to issue the IANA Naming Function RFP is approved pursuant to Section 19.4(b) and the EC does not reject the relevant SCWG Recommendation Decision pursuant to Section 19.4(d), the SCWG, in consultation with ICANN, shall:

(i) Issue the IANA Naming Function RFP;

(ii) Review responses from interested candidates to the IANA Naming Function RFP, which may be received from PTI and/or any other entity or person; and

(iii) Recommend the entity that ICANN should contract with to perform the IANA naming function.

(d) If the SCWG recommends an IANA Naming Function Separation Process other than the issuance of an IANA Naming Function RFP, the SCWG shall develop recommendations to be followed with respect to that process and its implementation consistent with the terms of this Article 19. The SCWG shall monitor and manage the implementation of such IANA Naming Function Separation Process.

Section 19.3. COMMUNITY REVIEWS AND REPORTS

(a) The SCWG shall seek community input through one or more public comment periods (such public comment period shall comply with the designated practice for public comment periods within ICANN) and may recommend discussions during ICANN's public meetings in developing and finalizing its recommendations and any report.

(b) The SCWG shall provide a draft report of its findings and recommendations to the community after convening of the SCWG, which such draft report will be posted for public comment on the Website. The SCWG may post additional drafts of its report for public comment until it has reached its final report.

(c) After completion of its review, the SCWG shall submit its final report containing its findings and recommendations to the Board. ICANN shall promptly post the SCWG's final report on the Website.

Section 19.4. SCWG RECOMMENDATIONS

(a) The recommendations of the SCWG are not limited and could include a variety of recommendations or a recommendation that no action is required; provided, however, that any recommendations must directly relate to the matters discussed in Section 19.2 and comply with this Section 19.4.

(b) ICANN shall not implement an SCWG recommendation (including an SCWG recommendation to issue an IANA Naming Function RFP) unless, with respect to each such recommendation (each, an "SCWG Recommendation"), each of the following occurs:

(i) The SCWG Recommendation has been approved by the vote of (A) a supermajority of the ccNSO Council (pursuant to the ccNSO's procedures or, if such procedures do not define a supermajority, two-thirds (2/3) of the ccNSO Council's members) and (B) a GNSO Supermajority;

(ii) After a public comment period that complies with the designated practice for public comment periods within ICANN, the Board has approved the SCWG Recommendation. A determination by the Board to not approve an SCWG Recommendation, where such SCWG Recommendation has been approved by the ccNSO and GNSO Councils pursuant to Section 19.4(b)(i), shall require a vote of at least two-thirds (2/3) of the Board and the Board shall follow the same consultation procedures set forth in Section 9 of Annex A of these Bylaws that relate to Board rejection of a PDP recommendation that is supported by a GNSO Supermajority; and

(iii) The EC has not rejected the Board's approval of the SCWG Recommendation pursuant to and in compliance with Section 19.4(d).

(c) If the Board (x) rejects an SCWG Recommendation that was approved by the ccNSO Council and GNSO Council pursuant to Section 19.4(b)(i) or (y) does not resolve to either accept or reject an SCWG Recommendation within 45 days of the later of (1) the date that the condition in Section 19.4(b)(i) is satisfied or (2) the expiration of the public comment period contemplated by Section 19.4(b)(ii), the Secretary shall provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall enclose a copy of the applicable SCWG Recommendation. ICANN shall post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website promptly following the delivery of the Board Notice to the EC Administration and the Decisional Participants.

(i) ICANN shall, at the direction of the EC Administration, convene a Rejection Action Community Forum, which Rejection Action Community Forum shall be conducted in accordance with Section 2.3 of Annex D, to discuss the Board Notice; provided, that, for purposes of Section 2.3 of Annex D, (A) the Board Notice shall be treated as the Rejection Action Supported Petition, (B) the EC Administration shall be treated as the Rejection Action Petitioning Decisional Participant (and there shall be no Rejection Action Supporting Decisional Participants) and (C) the Rejection Action Community Forum Period shall expire on the 21st day after the date the Secretary provides the Board Notice to the EC Administration and the Decisional Participants.

(ii) No later than 45 days after the conclusion of such Rejection Action Community Forum Period, the Board shall resolve to either uphold its rejection of the SCWG Recommendation or approve the SCWG Recommendation (either, a "Post-Forum SCWG Recommendation Decision").

(A)If the Board resolves to approve the SCWG Recommendation, such SCWG Recommendation will be subject to Section 19.4(d).

(B)For the avoidance of doubt, the Board shall not be obligated to change its decision on the SCWG Recommendation as a result of the Rejection Action Community Forum.

(C)The Board's Post-Forum SCWG Recommendation Decision shall be posted on the Website in accordance with the Board's posting obligations as set forth in Article 3.

(d) Promptly after the Board approves an SCWG Recommendation (an "SCWG Recommendation Decision"), the Secretary shall provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall enclose a copy of the SCWG Recommendation that is the subject of the SCWG Recommendation Decision. ICANN shall post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website promptly following the delivery of the Board Notice to the EC Administration and the Decisional Participants. The EC Administration shall promptly commence and comply with the procedures and requirements specified in Article 2 of Annex D.

(i) An SCWG Recommendation Decision shall become final upon the earliest to occur of the following:

(A)(1) A Rejection Action Petition Notice is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D, in which case the SCWG Recommendation Decision shall be final as of the date immediately following the expiration of the Rejection Action Petition Period relating to such SCWG Recommendation Decision;

(B)(1) A Rejection Action Supported Petition is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D, in which case the SCWG Recommendation Decision shall be final as of the date immediately following the expiration of the Rejection Action Petition Support Period relating to such SCWG Recommendation Decision; and

(C)(1) An EC Rejection Notice is not timely delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4 of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4(c) of Annex D, in which case the SCWG Recommendation Decision shall be final as of the date immediately following the expiration of the Rejection Action Decision Period relating to such SCWG Recommendation Decision.

(ii) An SCWG Recommendation Decision that has been rejected by the EC pursuant to and in compliance with Article 2 of Annex D shall have no force and effect, and shall be void ab initio.

(e) ICANN shall absorb the costs relating to recommendations made by the SCWG, including, without limitation, costs related to the process of selecting or potentially selecting a new operator for the IANA naming function and the operating costs of the successor operator that are necessary for the successor operator's performance of the IANA naming function as ICANN's independent contractor. ICANN shall not be authorized to raise fees from any TLD registry operators to cover the costs associated with implementation of any SCWG Recommendations that specifically relate to the transition to a successor operator. For avoidance of doubt, this restriction shall not apply to collecting appropriate fees necessary to maintain the ongoing performance of the IANA naming function, including those relating to the operating costs of the successor operator.

(f) In the event that (i) an SCWG Recommendation that selects an entity (other than PTI) as a new operator of the IANA naming function is approved pursuant to Section 19.4(b) and (ii) the EC does not reject the relevant SCWG Recommendation Decision pursuant to Section 19.4(d), ICANN shall enter into a contract with the new operator on substantially the same terms recommended by the SCWG and approved as part of such SCWG Recommendation.

(g) As promptly as practical following an SCWG Recommendation Decision becoming final in accordance with this Section 19.4, ICANN shall take all steps reasonably necessary to effect such SCWG Recommendation Decision as soon as practicable.

Section 19.5. SCWG COMPOSITION

(a) Each SCWG shall consist of the following members and liaisons to be appointed in accordance with the rules and procedures of the appointing organization:

(i) Three representatives who are associated with ccTLD managers, appointed by the ccNSO Council. Representatives need not be associated with a ccNSO member. The ccNSO shall use an inclusive process, which is open to all ccTLD managers, independent of their membership in the ccNSO. It is strongly recommended that the ccNSO Council reaches out to all ccTLD managers directly and/or through regional ccTLD organizations (i.e., AfTLD, APTLD, LACTLD and CENTR) in seeking volunteers;

(ii) Three representatives appointed by the Registries Stakeholder Group;

(iii) One representative appointed by the Registrars Stakeholder Group;

(iv) One representative appointed by the Commercial Stakeholder Group;

(v) One representative appointed by the Non-Commercial Stakeholder Group;

(vi) One representative appointed by the GAC;

(vii) One representative appointed by the SSAC;

(viii) One representative appointed by the RSSAC;

(ix) One representative appointed by the ALAC;

(x) One liaison appointed by the CSC;

(xi) One liaison appointed by the IFRT that conducted the Special IFR or Periodic IFR, as applicable, that recommended the creation of the SCWG, who shall be named in the IFRT's recommendation to convene the Special IFR;

(xii) One liaison who may be appointed by the ASO;

(xiii) One liaison who may be appointed by the IAB; and

(xiv) One liaison who may be appointed by the Board.

(xv) The SCWG may also include an unlimited number of non-member, non-liaison participants.

(b) All candidates for appointment to the SCWG as a member or liaison shall submit an expression of interest to the organization that would appoint such candidate as a member or liaison, which shall state (i) why the candidate is interested in becoming involved in the SCWG, (ii) what particular skills the candidate would bring to the SCWG, (iii) the candidate's knowledge of the IANA naming function, (iv) the candidate's understanding of the purpose of the SCWG, and (v)that the candidate understands the time necessary to participate in the SCWG process and can commit to the role.

(c) Members and liaisons of the SCWG shall disclose to ICANN and the SCWG any conflicts of interest with a specific complaint or issue under review. The SCWG may exclude from the discussion of a specific complaint or issue any member, liaison or participant deemed by the majority of SCWG members to have a conflict of interest. The co-chairs of the SCWG shall record any such conflict of interest in the minutes of the SCWG.

(d) To the extent reasonably possible, the appointing organizations for SCWG members and liaisons shall work together to:

(i) achieve an SCWG that is balanced for diversity (including functional, geographic and cultural) and skill, and should seek to broaden the number of individuals participating across the various reviews; provided, that the SCWG should include members from each ICANN Geographic Region. The ccNSO and Registries Stakeholder Group shall each endeavor to not appoint multiple members who are citizens of countries from the same ICANN Geographic Region, though an SCWG may proceed even if such geographic diversity targets for the ccNSO and/or the Registries Stakeholder Group appointees cannot be achieved;

(ii) ensure that the SCWG is comprised of individuals who are different from those individuals who comprised the IFRT that conducted the Special IFR or Periodic IFR, as applicable, that recommended the creation of the SCWG, other than the liaison to the IFRT appointed by the CSC; and

(iii) seek to appoint as representatives of the SCWG as many individuals as practicable with experience managing or participating in RFP processes.

(e) ICANN shall select an ICANN staff member and a PTI staff member to serve as points of contact to facilitate formal lines of communication between the SCWG and ICANN and the SCWG and PTI. Communications between the SCWG and the ICANN and PTI points of contact shall be communicated by the SCWG co-chairs.

(f) The SCWG shall not be a standing body. Each SCWG shall be constituted when and as required under these Bylaws and shall dissolve following the end of the process for approving such SCWG's SCWG Recommendations pursuant to Section 19.4(d).

Section 19.6. ELECTION OF CO-CHAIRS AND LIAISONS

(a) The SCWG shall be led by two co-chairs: one appointed by the GNSO from one of the members appointed pursuant to clauses (ii)-(v) of Section 19.5(a) and one appointed by the ccNSO from one of the members appointed pursuant to clause (i) of Section 19.5(a).

(b) Liaisons to the SCWG shall not be members of or entitled to vote on any matters before the SCWG, but otherwise shall be entitled to participate on equal footing with SCWG members.

(i) The SCWG members and liaisons may be removed from the SCWG by their respective appointing organization at any time upon such organization providing written notice to the Secretary and the co-chairs of the SCWG.

(ii) A vacancy on the SCWG shall be deemed to exist in the event of the death, resignation or removal of any SCWG member or liaison. Vacancies shall be filled by the organization that appointed such SCWG member or liaison. The appointing organization shall provide written notice to the Secretary of its appointment to fill a vacancy, with a notification copy to the SCWG co-chairs. The organization responsible for filling such vacancy shall use its reasonable efforts to fill such vacancy within one month after the occurrence of such vacancy.

Section 19.7. MEETINGS

(a) The SCWG shall act by consensus, which is where a small minority may disagree, but most agree.

(b) Any members of the SCWG not in favor of an action may record a minority dissent to such action, which shall be included in the SCWG minutes and/or report, as applicable.

(c) SCWG meetings and other working procedures shall be open to the public and conducted in a transparent manner to the fullest extent possible.

(d) The SCWG shall transmit minutes of its meetings to the Secretary, who shall cause those minutes to be posted to the Website as soon as practicable following each SCWG meeting, and no later than five business days following the meeting.

(e) Except as otherwise provided in these Bylaws, the SCWG shall follow the guidelines and procedures applicable to ICANN Cross Community Working Groups that will be publicly available and may be amended from time to time.

Section 19.8. ADMINISTRATIVE SUPPORT

ICANN shall provide administrative and operational support necessary for the SCWG to carry out its responsibilities, including providing and facilitating remote participation in all meetings of the SCWG.

Section 19.9. CONFLICTING PROVISIONS

In the event any SCWG Recommendation that is approved in accordance with this Article 19 requires ICANN to take any action that is inconsistent with a provision of the Bylaws (including any action taken in implementing such SCWG Recommendation), the requirements of such provision of these Bylaws shall not apply to the extent of that inconsistency.

ARTICLE 20 INDEMNIFICATION OF DIRECTORS, OFFICERS, EMPLOYEES, AND OTHER AGENTS

Section 20.1. INDEMNIFICATION GENERALLY

ICANN shall, to the maximum extent permitted by the CCC, 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 20, 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 the EC, the EC Administration, 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 20.

Section 20.2. INDEMNIFICATION WITH RESPECT TO DIRECTOR REMOVAL

If a Director initiates any proceeding in connection with his or her removal or recall pursuant to the Bylaws, to which a person who is a member of the leadership council (or equivalent body) of a Decisional Participant or representative of a Decisional Participant in the EC Administration is a party or is threatened to be made a party (as a party or witness) (a "Director Removal Proceeding"), ICANN shall, to the maximum extent permitted by the CCC, indemnify any such person, against expenses, judgments, fines, settlements, and other amounts actually and reasonably incurred by such person in connection with such Director Removal Proceeding, for actions taken by such person in his or her representative capacity within his or her Decisional Participant pursuant to the processes and procedures set forth in these Bylaws, provided that all such actions were taken by such person in good faith and in a manner that such person reasonably believed to be in ICANN's best interests and not criminal. The actual and reasonable legal fees of a single firm of counsel and other expenses actually and reasonably incurred by such person in defending against a Director Removal Proceeding shall be paid by ICANN in advance of the final disposition of such Director Removal Proceeding, provided, however, that such expenses shall be advanced only upon delivery to the Secretary of an undertaking (which shall be in writing and in a form provided by the Secretary) by such person to repay the amount of such expenses if it shall ultimately be determined that such person is not entitled to be indemnified by ICANN. ICANN shall not be obligated to indemnify such person against any settlement of a Director Removal Proceeding, unless such settlement is approved in advance by the Board in its reasonable discretion. Notwithstanding Section 20.1, the indemnification provided in this Section 20.2 shall be ICANN's sole indemnification obligation with respect to the subject matter set forth in this Section 20.2.

ARTICLE 21 GENERAL PROVISIONS

Section 21.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 21.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 21.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 21.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.

Section 21.5. NOTICES

All notices to be given to the EC Administration, the Decisional Participants, or the Secretary pursuant to any provision of these Bylaws shall be given either (a) in writing at the address of the appropriate party as set forth below or (b) via electronic mail as provided below, unless that party has given a notice of change of postal or email address, as provided in this Section 21.5. Any change in the contact information for notice below will be given by the party within 30 days of such change. Any notice required by these Bylaws will be deemed to have been properly given (i) if in paper form, when delivered in person or via courier service with confirmation of receipt or (ii) if via electronic mail, upon confirmation of receipt by the recipient's email server, provided that such notice via electronic mail shall be followed by a copy sent by regular postal mail service within three days. In the event other means of notice become practically achievable, such as notice via a secure website, the EC Administration, the Decisional Participants, and ICANN will work together to implement such notice means.

If to ICANN, addressed to:

Internet Corporation for Assigned Names and Numbers

12025 Waterfront Drive, Suite 300

Los Angeles, CA 90094-2536

USA

Email: [___]

Attention: Secretary

If to a Decisional Participant or the EC Administration, addressed to the contact information available at [insert Website reference].

ARTICLE 22 FISCAL AND STRATEGIC MATTERS, INSPECTION AND INDEPENDENT INVESTIGATION

Section 22.1. ACCOUNTING

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

Section 22.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 22.3. ANNUAL REPORT AND ANNUAL STATEMENT

The Board shall publish, at least annually, a report describing its activities, including an audited financial statement, a description of any payments made by ICANN to Directors (including reimbursements of expenses) and a description of ICANN's progress towards the obligations imposed under the Bylaws as revised on 1 October 2016 and the Operating Plan and Strategic Plan. ICANN shall cause the annual report and the annual statement of certain transactions as required by the CCC 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 22.4. BUDGETS

(a) ICANN Budget

(i) In furtherance of its Commitment to transparent and accountable budgeting processes, at least forty-five (45) days prior to the commencement of each fiscal year, ICANN staff shall prepare and submit to the Board a proposed annual operating plan and budget of ICANN for the next fiscal year (the "ICANN Budget"), which shall be posted on the Website. The ICANN Budget shall identify anticipated revenue sources and levels and shall, to the extent practical, identify anticipated material expense items by line item.

(ii) Prior to approval of the ICANN Budget by the Board, ICANN staff shall consult with the Supporting Organizations and Advisory Committees during the ICANN Budget development process, and comply with the requirements of this Section 22.4(a).

(iii) Prior to approval of the ICANN Budget by the Board, a draft of the ICANN Budget shall be posted on the Website and shall be subject to public comment.

(iv) After reviewing the comments submitted during the public comment period, the Board may direct ICANN staff to post a revised draft of the ICANN Budget and may direct ICANN Staff to conduct one or more additional public comment periods of lengths determined by the Board, in accordance with ICANN's public comment processes.

(v) Promptly after the Board approves an ICANN Budget (an "ICANN Budget Approval"), the Secretary shall provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall enclose a copy of the ICANN Budget that is the subject of the ICANN Budget Approval. ICANN shall post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website promptly following the delivery of the Board Notice to the EC Administration and the Decisional Participants. The EC Administration shall promptly commence and comply with the procedures and requirements specified in Article 2 of Annex D.

(vi) An ICANN Budget shall become effective upon the earliest to occur of the following:

(A)(1) A Rejection Action Petition Notice is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D, in which case the ICANN Budget that is the subject of the ICANN Budget Approval shall be in full force and effect as of the 28th day following the Rejection Action Board Notification Date (as defined in Section 2.2(a) of Annex D) relating to such ICANN Budget Approval and the effectiveness of such ICANN Budget shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D;

(B)(1) A Rejection Action Supported Petition is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D, in which case the ICANN Budget that is the subject of the ICANN Budget Approval shall be in full force and effect as of the date immediately following the expiration of the Rejection Action Petition Support Period relating to such ICANN Budget Approval and the effectiveness of such ICANN Budget shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D; and

(C)(1) An EC Rejection Notice is not timely delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4 of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4(c) of Annex D, in which case the ICANN Budget that is the subject of the ICANN Budget Approval shall be in full force and effect as of the date immediately following the expiration of the Rejection Action Decision Period relating to such ICANN Budget Approval and the effectiveness of such ICANN Budget shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D.

(vii) An ICANN Budget that has been rejected by the EC pursuant to and in compliance with Article 2 of Annex D shall have no force and effect, and shall be void ab initio.

(viii) Following receipt of an EC Rejection Notice relating to an ICANN Budget, ICANN staff and the Board shall consider the explanation provided by the EC Administration as to why the EC has chosen to reject the ICANN Budget in determining the substance of such new ICANN Budget, which shall be subject to the procedures of this Section 22.4(a).

(ix) If an ICANN Budget has not come into full force and effect pursuant to this Section 22.4(a) on or prior to the first date of any fiscal year of ICANN, the Board shall adopt a temporary budget in accordance with Annex E hereto ("Caretaker ICANN Budget"), which Caretaker ICANN Budget shall be effective until such time as an ICANN Budget has been effectively approved by the Board and not rejected by the EC pursuant to this Section 22.4(a).

(b) IANA Budget

(i) At least 45 days prior to the commencement of each fiscal year, ICANN shall prepare and submit to the Board a proposed annual operating plan and budget of PTI and the IANA department, which budget shall include itemization of the direct costs for ICANN's IANA department, all costs for PTI, direct costs for shared resources between ICANN and PTI and support functions provided by ICANN to PTI and ICANN's IANA department for the next fiscal year (the "IANA Budget"), which shall be posted on the Website. Separately and in addition to the general ICANN planning process, ICANN shall require PTI to prepare and submit to the PTI Board a proposed annual operating plan and budget for PTI's performance of the IANA functions for the next fiscal year ("PTI Budget"). ICANN shall require PTI to consult with the Supporting Organizations and Advisory Committees, as well as the Registries Stakeholder Group, the IAB and RIRs, during the PTI Budget development process, and shall seek public comment on the draft PTI Budget prior to approval of the PTI Budget by PTI. ICANN shall require PTI to submit the PTI Budget to ICANN as an input prior to and for the purpose of being included in the proposed Operating Plan (as defined in Section 22.5(a)) and ICANN Budget.

(ii) Prior to approval of the IANA Budget by the Board, ICANN staff shall consult with the Supporting Organizations and Advisory Committees, as well as the Registries Stakeholder Group, IAB and RIRs, during the IANA Budget development process, and comply with the requirements of this Section 22.4(b).

(iii) Prior to approval of the IANA Budget by the Board, a draft of the IANA Budget shall be posted on the Website and shall be subject to public comment.

(iv) After reviewing the comments submitted during the public comment period, the Board may direct ICANN staff to post a revised draft of the IANA Budget and may direct ICANN staff to conduct one or more additional public comment periods of lengths determined by the Board, in accordance with ICANN's public comment processes.

(v) Promptly after the Board approves an IANA Budget (an "IANA Budget Approval"), the Secretary shall provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall enclose a copy of the IANA Budget that is the subject of the IANA Budget Approval. ICANN shall post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website promptly following the delivery of the Board Notice to the EC Administration and the Decisional Participants. The EC Administration shall promptly commence and comply with the procedures and requirements specified in Article 2 of Annex D.

(vi) An IANA Budget shall become effective upon the earliest to occur of the following:

(A)(1) A Rejection Action Petition Notice is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D, in which case the IANA Budget that is the subject of the IANA Budget Approval shall be in full force and effect as of the 28th day following the Rejection Action Board Notification Date relating to such IANA Budget Approval and the effectiveness of such IANA Budget shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D;

(B)(1) A Rejection Action Supported Petition is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D, in which case the IANA Budget that is the subject of the IANA Budget Approval shall be in full force and effect as of the date immediately following the expiration of the Rejection Action Petition Support Period relating to such IANA Budget Approval and the effectiveness of such IANA Budget shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D; and

(C)(1) An EC Rejection Notice is not timely delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4 of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4(c) of Annex D, in which case the IANA Budget that is the subject of the IANA Budget Approval shall be in full force and effect as of the date immediately following the expiration of the Rejection Action Decision Period relating to such IANA Budget Approval and the effectiveness of such IANA Budget shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D.

(vii) An IANA Budget that has been rejected by the EC pursuant to and in compliance with Article 2 of Annex D shall have no force and effect, and shall be void ab initio.

(viii) Following receipt of an EC Rejection Notice relating to an IANA Budget, ICANN staff and the Board shall consider the explanation provided by the EC Administration as to why the EC has chosen to reject the IANA Budget in determining the substance of such new IANA Budget, which shall be subject to the procedures of this Section 22.4(b).

(ix) If an IANA Budget has not come into full force and effect pursuant to this Section 22.4(b) on or prior to the first date of any fiscal year of ICANN, the Board shall adopt a temporary budget in accordance with Annex F hereto ("Caretaker IANA Budget"), which Caretaker IANA Budget shall be effective until such time as an IANA Budget has been effectively approved by the Board and not rejected by the EC pursuant to this Section 22.4(b).

(c) If an IANA Budget does not receive an EC Rejection Notice but an ICANN Budget receives an EC Rejection Notice, any subsequent revised ICANN Budget shall not alter the expenditures allocated for the IANA Budget.

(d) If an ICANN Budget does not receive an EC Rejection Notice but an IANA Budget receives an EC Rejection Notice, any subsequent revised IANA Budget shall, once approved, be deemed to automatically modify the ICANN Budget in a manner determined by the Board without any further right of the EC to reject the ICANN Budget.

(e) Under all circumstances, the Board will have the ability to make out-of-budget funding decisions for unforeseen expenses necessary to maintaining ICANN's Mission or to fulfilling ICANN's pre-existing legal obligations and protecting ICANN from harm or waste.

(f) To maintain ongoing operational excellence and financial stability of the IANA functions (so long as they are performed by ICANN or pursuant to contract with ICANN) and PTI, ICANN shall be required to plan for and allocate funds to ICANN's performance of the IANA functions and to PTI, as applicable, that are sufficient to cover future expenses and contingencies to ensure that the performance of those IANA functions and PTI in the future are not interrupted due to lack of funding.

(g) The ICANN Budget and the IANA Budget shall be published on the Website.

Section 22.5. PLANS

(a) Operating Plan

(i) At least 45 days prior to the commencement of each fiscal year, ICANN staff shall prepare and submit to the Board a proposed operating plan of ICANN for the next five fiscal years (the "Operating Plan"), which shall be posted on the Website.

(ii) Prior to approval of the Operating Plan by the Board, ICANN staff shall consult with the Supporting Organizations and Advisory Committees during the Operating Plan development process, and comply with the requirements of this Section 22.5(a).

(iii) Prior to approval of the Operating Plan by the Board, a draft of the Operating Plan shall be posted on the Website and shall be subject to public comment.

(iv) After reviewing the comments submitted during the public comment period, the Board may direct ICANN staff to post a revised draft of the Operating Plan and may direct ICANN staff to conduct one or more additional public comment periods of lengths determined by the Board, in accordance with ICANN's public comment processes.

(v) Promptly after the Board approves an Operating Plan (an "Operating Plan Approval"), the Secretary shall provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall enclose a copy of the Operating Plan that is the subject of the Operating Plan Approval. ICANN shall post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website promptly following the delivery of the Board Notice to the EC Administration and the Decisional Participants. The EC Administration shall promptly commence and comply with the procedures and requirements specified in Article 2 of Annex D.

(vi) An Operating Plan shall become effective upon the earliest to occur of the following:

(A)(1) A Rejection Action Petition Notice is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D, in which case the Operating Plan that is the subject of the Operating Plan Approval shall be in full force and effect as of the 28th day following the Rejection Action Board Notification Date relating to such Operating Plan Approval and the effectiveness of such Operating Plan shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D;

(B)(1) A Rejection Action Supported Petition is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D, in which case the Operating Plan that is the subject of the Operating Plan Approval shall be in full force and effect as of the date immediately following the expiration of the Rejection Action Petition Support Period relating to such Operating Plan Approval and the effectiveness of such Operating Plan shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D; and

(C)(1) An EC Rejection Notice is not timely delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4 of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4(c) of Annex D, in which case the Operating Plan that is the subject of the Operating Plan Approval shall be in full force and effect as of the date immediately following the expiration of the Rejection Action Decision Period relating to such Operating Plan Approval and the effectiveness of such Operating Plan shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D.

(vii) An Operating Plan that has been rejected by the EC pursuant to and in compliance with Article 2 of Annex D shall have no force and effect, and shall be void ab initio.

(viii) Following receipt of an EC Rejection Notice relating to an Operating Plan, ICANN staff and the Board shall consider the explanation provided by the EC Administration as to why the EC has chosen to reject the Operating Plan in determining the substance of such new Operating Plan, which shall be subject to the procedures of this Section 22.5(a).

(b) Strategic Plan

(i) At least 45 days prior to the commencement of each five fiscal year period, with the first such period covering fiscal years 2021 through 2025, ICANN staff shall prepare and submit to the Board a proposed strategic plan of ICANN for the next five fiscal years (the "Strategic Plan"), which shall be posted on the Website.

(ii) Prior to approval of the Strategic Plan by the Board, ICANN staff shall consult with the Supporting Organizations and Advisory Committees during the Strategic Plan development process, and comply with the requirements of this Section 22.5(b).

(iii) Prior to approval of the Strategic Plan by the Board, a draft of the Strategic Plan shall be posted on the Website and shall be subject to public comment.

(iv) After reviewing the comments submitted during the public comment period, the Board may direct ICANN staff to submit a revised draft of the Strategic Plan and may direct ICANN staff to conduct one or more additional public comment periods of lengths determined by the Board, in accordance with ICANN's public comment processes.

(v) Promptly after the Board approves a Strategic Plan (a "Strategic Plan Approval"), the Secretary shall provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall enclose a copy of the Strategic Plan that is the subject of the Strategic Plan Approval. ICANN shall post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website promptly following the delivery of the Board Notice to the EC Administration and the Decisional Participants. The EC Administration shall promptly commence and comply with the procedures and requirements specified in Article 2 of Annex D.

(vi) A Strategic Plan shall become effective upon the earliest to occur of the following:

(A)(1) A Rejection Action Petition Notice is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D, in which case the Strategic Plan that is the subject of the Strategic Plan Approval shall be in full force and effect as of the 28th day following the Rejection Action Board Notification Date relating to such Strategic Plan Approval and the effectiveness of such Strategic Plan shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D;

(B)(1) A Rejection Action Supported Petition is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D, in which case the Strategic Plan that is the subject of the Strategic Plan Approval shall be in full force and effect as of the date immediately following the expiration of the Rejection Action Petition Support Period relating to such Strategic Plan Approval and the effectiveness of such Strategic Plan shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D; and

(C)(1) An EC Rejection Notice is not timely delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4 of Annex D or (2) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4(c) of Annex D, in which case the Strategic Plan that is the subject of the Strategic Plan Approval shall be in full force and effect as of the date immediately following the expiration of the Rejection Action Decision Period relating to such Strategic Plan Approval and the effectiveness of such Strategic Plan shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D.

(vii) A Strategic Plan that has been rejected by the EC pursuant to and in compliance with Article 2 of Annex D shall have no force and effect, and shall be void ab initio.

(viii) Following receipt of an EC Rejection Notice relating to a Strategic Plan, ICANN staff and the Board shall consider the explanation provided by the EC Administration as to why the EC has chosen to reject the Strategic Plan in determining the substance of such new Strategic Plan, which shall be subject to the procedures of this Section 22.5(b).

Section 22.6. 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.

Section 22.7. INSPECTION

(a) A Decisional Participant (the "Inspecting Decisional Participant") may request to inspect the accounting books and records of ICANN, as interpreted pursuant to the provisions of Section 6333 of the CCC, and the minutes of the Board or any Board Committee for a purpose reasonably related to such Inspecting Decisional Participant's interest as a Decisional Participant in the EC. The Inspecting Decisional Participant shall make such a request by providing written notice from the chair of the Inspecting Decisional Participant to the Secretary stating the nature of the documents the Inspecting Decisional Participant seeks to inspect ("Inspection Request"). Any Inspection Request must be limited to the accounting books and records of ICANN relevant to the operation of ICANN as a whole, and shall not extend to the underlying sources of such accounting books or records or to documents only relevant to a small or isolated aspect of ICANN's operations or that relate to the minutiae of ICANN's financial records or details of its management and administration (the "Permitted Scope"). Unless ICANN declines such request (as provided below), ICANN shall make the records requested under an Inspection Request available for inspection by such Inspecting Decisional Participant within 30 days of the date the Inspection Request is received by the Secretary or as soon as reasonably practicable thereafter. All materials and information made available by ICANN for inspection pursuant to an Inspection Request may only be used by the Inspecting Decisional Participant for purposes reasonably related to such Inspecting Decisional Participant's interest as a Decisional Participant in the EC. ICANN shall post all Inspection Requests to the Website.

(b) ICANN may decline an Inspection Request on the basis that such Inspection Request (i) is motivated by a Decisional Participant's financial, commercial or political interests, or those of one or more of its constituents, (ii) relates to documents that are not reasonably related to the purpose specified in the Inspection Request or the Inspecting Decisional Participant's interest as a Decisional Participant in the EC, (iii) requests identical records provided in a prior request of such Decisional Participant, (iv) is not within the Permitted Scope, (v) relates to personnel records, (vi) relates to documents or communications covered by attorney-client privilege, work product doctrine or other legal privilege or (vii) relates to documents or communications that ICANN may not make available under applicable law because such documents or communications contain confidential information that ICANN is required to protect. If an Inspection Request is overly broad, ICANN may request a revised Inspection Request from the Inspecting Decisional Participant.

(c) Any such inspections shall be conducted at the times and locations reasonably determined by ICANN and shall not be conducted in a manner that unreasonably interferes with ICANN's operations. All such inspections shall be subject to reasonable procedures established by ICANN, including, without limitation, the number of individuals authorized to conduct any such inspection on behalf of the Inspecting Decisional Participant. ICANN may require the inspectors to sign a non-disclosure agreement. The Inspecting Decisional Participant may, at its own cost, copy or otherwise reproduce or make a record of materials inspected. ICANN may redact or determine not to provide requested materials on the same basis that such information is of a category or type described in Section 22.7(b), in which case ICANN will provide the Inspecting Decisional Participant a written rationale for such redactions or determination.

(d) The inspection rights provided to the Decisional Participants pursuant to this Section 22.7 are granted to the Decisional Participants and are not granted or available to any other person or entity. Notwithstanding the foregoing, nothing in this Section 22.7 shall be construed as limiting the accessibility of ICANN's document information disclosure policy ("DIDP").

(e) If the Inspecting Decisional Participant believes that ICANN has violated the provisions of this Section 22.7, the Inspecting Decisional Participant may seek one or more of the following remedies: (i) appeal such matter to the Ombudsman and/or the Board for a ruling on the matter, (ii) initiate the Reconsideration Request process in accordance with Section 4.2, (iii) initiate the Independent Review Process in accordance with Section 4.3, or (iv) petition the EC to initiate (A) a Community IRP pursuant to Section 4.2 of Annex D or (B) a Board Recall Process pursuant to Section 3.3 of Annex D. Any determination by the Ombudsman is not binding on ICANN staff, but may be submitted by the Inspecting Decisional Participant when appealing to the Board for a determination, if necessary.

Section 22.8. INDEPENDENT INVESTIGATION

If three or more Decisional Participants deliver to the Secretary a joint written certification from the respective chairs of each such Decisional Participant that the constituents of such Decisional Participants have, pursuant to the internal procedures of such Decisional Participants, determined that there is a credible allegation that ICANN has committed fraud or that there has been a gross mismanagement of ICANN's resources, ICANN shall retain a third-party, independent firm to investigate such alleged fraudulent activity or gross mismanagement. ICANN shall post all such certifications to the Website. The independent firm shall issue a report to the Board. The Board shall consider the recommendations and findings set forth in such report. Such report shall be posted on the Website, which may be in a redacted form as determined by the Board, in order to preserve attorney-client privilege, work product doctrine or other legal privilege or where such information is confidential, in which case ICANN will provide the Decisional Participants that submitted the certification a written rationale for such redactions.

ARTICLE 23 MEMBERS

ICANN shall not have members, as contemplated by Section 5310 of the CCC, notwithstanding the use of the term "member" in these Bylaws, in any ICANN document, or in any action of the Board or staff. For the avoidance of doubt, the EC is not a member of ICANN.

ARTICLE 24 OFFICES AND SEAL

Section 24.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 24.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 25 AMENDMENTS

Section 25.1. AMENDMENTS TO THE STANDARD BYLAWS

(a) Except as otherwise provided in the Articles of Incorporation or these Bylaws, these Bylaws may be altered, amended, or repealed and new Bylaws adopted only upon approval by a two-thirds vote of all Directors and in compliance with the terms of this Section 25.1 (a "Standard Bylaw Amendment").

(b) Prior to approval of a Standard Bylaw Amendment by the Board, a draft of the Standard Bylaw Amendment shall be posted on the Website and shall be subject to public comment in accordance with ICANN's public comment processes.

(c) After reviewing the comments submitted during the public comment period, the Board may direct ICANN staff to post a revised draft of the Standard Bylaw Amendment and may conduct one or more additional public comment periods in accordance with ICANN's public comment processes.

(d) Within seven days after the Board's approval of a Standard Bylaw Amendment ("Standard Bylaw Amendment Approval"), the Secretary shall (i) provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall contain the form of the approved amendment and the Board's rationale for adopting such amendment, and (ii) post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website. The steps contemplated in Article 2 of Annex D shall then be followed.

(e) A Standard Bylaw Amendment shall become effective upon the earliest to occur of the following:

(i) (A) A Rejection Action Petition Notice is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D or (B) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(c) of Annex D, in which case the Standard Bylaw Amendment that is the subject of the Standard Bylaw Amendment Approval shall be in full force and effect as of the 30th day following the Rejection Action Board Notification Date relating to such Standard Bylaw Amendment Approval and the effectiveness of such Standard Bylaw Amendment shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D;

(ii) (A) A Rejection Action Supported Petition is not timely delivered by the Rejection Action Petitioning Decisional Participant to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D or (B) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.2(d) of Annex D, in which case the Standard Bylaw Amendment that is the subject of the Standard Bylaw Amendment Approval shall be in full force and effect as of the date immediately following the expiration of the Rejection Action Petition Support Period relating to such Standard Bylaw Amendment and the effectiveness of such Standard Bylaw Amendment shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D; or

(iii) (A) An EC Rejection Notice is not timely delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4 of Annex D or (B) a Rejection Process Termination Notice is delivered by the EC Administration to the Secretary pursuant to and in compliance with Section 2.4(c) of Annex D, in which case the Standard Bylaw Amendment that is the subject of the Standard Bylaw Amendment Approval shall be in full force and effect as of the date immediately following the expiration of the Rejection Action Decision Period relating to such Standard Bylaw Amendment and the effectiveness of such Standard Bylaw Amendment shall not be subject to further challenge by the EC pursuant to the EC's rejection right as described in Article 2 of Annex D.

(f) If an EC Rejection Notice is timely delivered by the EC Administration to the Secretary pursuant to and compliance with Section 2.4 of Annex D, the Standard Bylaw Amendment contained in the Board Notice shall be deemed to have been rejected by the EC. A Standard Bylaw Amendment that has been rejected by the EC shall be null and void and shall not become part of these Bylaws, notwithstanding its approval by the Board.

(g) The Secretary shall promptly inform the Board of the receipt and substance of any Rejection Action Petition, Rejection Action Supported Petition or EC Rejection Notice delivered by the Rejection Action Petitioning Decisional Participant or the EC Administration, as applicable, to the Secretary hereunder.

(h) Following receipt of an EC Rejection Notice pertaining to a Standard Bylaw Amendment, ICANN staff and the Board shall consider the explanation provided by the EC Administration as to why the EC has chosen to reject the Standard Bylaw Amendment in determining whether or not to develop a new Standard Bylaw Amendment and the substance of such new Standard Bylaw Amendment, which shall be subject to the procedures of this Section 25.1.

Section 25.2. AMENDMENTS TO THE FUNDAMENTAL BYLAWS AND ARTICLES OF INCORPORATION

(a) Article 1; Sections 4.2, 4.3 and 4.7; Article 6; Sections 7.1 through 7.5, inclusive, and Sections 7.8, 7.11, 7.12, 7.17, 7.24 and 7.25; those portions of Sections 8.1, 9.2(b), 10.3(i), 11.3(f) and 12.2(d)(x)(A) relating to the provision to the EC of nominations of Directors by the nominating body, Articles 16, 17, 18 and 19, Sections 22.4, 22.5, 22.7 and 22.8, Article 26, Section 27.1; Annexes D, E and F; and this Article 25 are each a "Fundamental Bylaw" and, collectively, are the "Fundamental Bylaws".

(b) Notwithstanding any other provision of these Bylaws, a Fundamental Bylaw or the Articles of Incorporation may be altered, amended, or repealed (a "Fundamental Bylaw Amendment" or an "Articles Amendment"), only upon approval by a three-fourths vote of all Directors and the approval of the EC as set forth in this Section 25.2.

(c) Prior to approval of a Fundamental Bylaw Amendment, or an Articles Amendment by the Board, a draft of the Fundamental Bylaw Amendment or Articles Amendment, as applicable, shall be posted on the Website and shall be subject to public comment in accordance with ICANN's public comment processes.

(d) After reviewing the comments submitted during the public comment period, the Board may direct ICANN staff to submit a revised draft of the Fundamental Bylaw Amendment or Articles Amendment, as applicable, and may direct ICANN staff to conduct one or more additional public comment periods in accordance with ICANN's public comment processes.

(e) Within seven days after the Board's approval of a Fundamental Bylaw Amendment or Articles Amendment, as applicable, the Secretary shall (i) provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall contain the form of the approved amendment and (ii) post the Board Notice, along with a copy of the notification(s) sent to the EC Administration and the Decisional Participants, on the Website. The steps contemplated in Article 1 of Annex D shall then be followed.

(f) If the EC Administration timely delivers an EC Approval Notice (as defined in Section 1.4(b) of Annex D), the Fundamental Bylaw Amendment or Articles Amendment, as applicable, set forth in the Board Notice shall be deemed approved by the EC, and, as applicable, (i) such Fundamental Bylaw Amendment shall be in full force and effect as part of these Bylaws as of the date immediately following the Secretary's receipt of the EC Approval Notice; or (ii) the Secretary shall cause such Articles Amendment promptly to be certified by the appropriate officers of ICANN and filed with the California Secretary of State. In the event of such approval, neither the Fundamental Bylaw Amendment nor the Articles Amendment shall be subject to any further review or approval of the EC. The Secretary shall promptly inform the Board of the receipt of an EC Approval Notice.

(g) If an EC Approval Notice is not timely delivered by the EC Administration to the Secretary, the Fundamental Bylaw Amendment or Articles Amendment, as applicable, set forth in the Board Notice shall be deemed not approved by the EC, shall be null and void, and, notwithstanding its approval by the Board, the Fundamental Bylaw Amendment shall not be part of these Bylaws and the Articles Amendment shall not be filed with the Secretary of State.

(h) If a Fundamental Bylaw Amendment or Articles Amendment, as applicable, is not approved by the EC, ICANN staff and the Board shall consider the concerns raised by the EC in determining whether or not to develop a new Fundamental Bylaws Amendment or Articles Amendment, as applicable, and the substance thereof, which shall be subject to the procedures of this Section 25.2.

Section 25.3. AMENDMENTS RESULTING FROM A POLICY DEVELOPMENT PROCESS

The Board shall not combine an amendment of these Bylaws that was the result of a policy development process of a Supporting Organization (a "PDP Amendment") with any other amendment. The Board shall indicate in the applicable Board Notice whether such amendment is a PDP Amendment.

Section 25.4. OTHER AMENDMENTS

For the avoidance of doubt, these Bylaws can only be amended as set forth in this Article 25. Neither the EC, the Decisional Participants, the Supporting Organizations, the Advisory Committees nor any other entity or person shall have the power to directly propose amendments to these Bylaws.

ARTICLE 26 SALE OR OTHER DISPOSITION OF ALL OR SUBSTANTIALLY ALL OF ICANN'S ASSETS

(a) ICANN may consummate a transaction or series of transactions that would result in the sale or disposition of all or substantially all of ICANN's assets (an "Asset Sale") only upon approval by a three-fourths vote of all Directors and the approval of the EC as set forth in this Article 26.

(b) Prior to approval of an Asset Sale by the Board, a draft of the definitive Asset Sale agreement (an "Asset Sale Agreement"), shall be posted on the Website and shall be subject to public comment in accordance with ICANN's public comment processes.

(c) After reviewing the comments submitted during the public comment period, the Board may direct ICANN staff to submit a revised draft of the Asset Sale Agreement, as applicable, and may direct ICANN staff to conduct one or more additional public comment periods in accordance with ICANN's public comment processes.

(d) Within seven days after the Board's approval of an Asset Sale the Secretary shall (i) provide a Board Notice to the EC Administration and the Decisional Participants, which Board Notice shall contain the form of the Asset Sale Agreement and (ii) post the Board Notice on the Website. The steps contemplated in Article 1 of Annex D shall then be followed.

(e) If the EC Administration timely delivers an EC Approval Notice for the Asset Sale pursuant to and in compliance with the procedures and requirements of Section 1.4(b) of Annex D, the Asset Sale set forth in the Board Notice shall be deemed approved by the EC, and the Asset Sale may be consummated by ICANN, but only under the terms set forth in the Asset Sale Agreement. In the event of such approval, the Asset Sale shall not be subject to any further review or approval of the EC. The Secretary shall promptly inform the Board of the receipt of an EC Approval Notice.

(f) If an EC Approval Notice is not timely delivered by the EC Administration to the Secretary, the Asset Sale set forth in the Board Notice shall be deemed not approved by the EC, shall be null and void, and, notwithstanding its approval by the Board, ICANN shall not consummate the Asset Sale.

(g) If an Asset Sale is not approved by the EC, ICANN staff and the Board shall consider the concerns raised by the EC in determining whether or not to consider a new Asset Sale, and the substance thereof, which shall be subject to the procedures of this Article 26.

ARTICLE 27 TRANSITION ARTICLE

Section 27.1. WORK STREAM 2

(a) The Cross-Community Working Group on Enhancing ICANN Accountability ("CCWG-Accountability") was established pursuant to a charter dated 3 November 2014 ("CCWG-Accountability Charter"). The CCWG-Accountability Charter was subsequently adopted by the GNSO, ALAC, ccNSO, GAC, ASO and SSAC ("CCWG Chartering Organizations"). The CCWG-Accountability Charter as in effect on 3 November 2014 shall remain in effect throughout Work Stream 2 (as defined therein).

(b) The CCWG-Accountability recommended in its Supplemental Final Proposal on Work Stream 1 Recommendations to the Board, dated 23 February 2016 ("CCWG-Accountability Final Report") that the below matters be reviewed and developed following the adoption date of these Bylaws ("Work Stream 2 Matters"), in each case, to the extent set forth in the CCWG-Accountability Final Report:

(i) Improvements to ICANN's standards for diversity at all levels;

(ii) ICANN staff accountability;

(iii) Supporting Organization and Advisory Committee accountability, including but not limited to improved processes for accountability, transparency, and participation that are helpful to prevent capture;

(iv) Improvements to ICANN's transparency, focusing on enhancements to ICANN's existing DIDP, transparency of ICANN's interactions with governments, improvements to ICANN's whistleblower policy and transparency of Board deliberations;

(v) Developing and clarifying the FOI-HR (as defined in Section 27.2);

(vi) Addressing jurisdiction-related questions, including how choice of jurisdiction and applicable laws for dispute settlement impact ICANN's accountability;

(vii) Considering enhancements to the Ombudsman's role and function;

(viii) Guidelines for standards of conduct presumed to be in good faith associated with exercising removal of individual Directors; and

(ix) Reviewing the CEP (as set forth in Section 4.3).

(c) As provided in the CCWG-Accountability Charter and the Board's 2014.10.16.16 resolution, the Board shall consider consensus-based recommendations from the CCWG-Accountability on Work Stream 2 Matters ("Work Stream 2 Recommendations") with the same process and criteria it committed to using to consider the CCWG-Accountability recommendations in the CCWG-Accountability Final Report ("Work Stream 1 Recommendations"). For the avoidance of doubt, that process and criteria includes:

(i) All Work Stream 2 Recommendations must further the following principles:

(A)Support and enhance the multistakeholder model;

(B)Maintain the security, stability and resiliency of the DNS;

(C)Meet the needs and expectations of the global customers and partners of the IANA services;

(D)Maintain the openness of the Internet; and

(E)Not result in ICANN becoming a government-led or an inter-governmental organization.

(ii) If the Board determines, by a vote of a two-thirds majority of the Board, that it is not in the global public interest to implement a Work Stream 2 Recommendation, it must initiate a dialogue with the CCWG-Accountability.

(iii) The Board shall provide detailed rationale to accompany the initiation of dialogue. The Board and the CCWG-Accountability shall mutually agree upon the method (e.g., by teleconference, email or otherwise) by which the dialogue will occur. Discussions shall be held in good faith and in a timely and efficient manner in an effort to find a mutually acceptable solution.

(iv) The CCWG-Accountability shall have an opportunity to address the Board's concerns and report back to the Board on further deliberations regarding the Board's concerns. The CCWG-Accountability shall discuss the Board's concerns within 30 days of the Board's initiation of the dialogue.

If a Work Stream 2 Recommendation is modified by the CCWG-Accountability, the CCWG-Accountability shall submit the modified Work Stream 2 Recommendation to the Board for further consideration along with detailed rationale on how the modification addresses the concerns raised by the Board.

(v) If, after the CCWG-Accountability modifies a Work Stream 2 Recommendation, the Board still believes it is not in the global public interest to implement the Work Stream 2 Recommendation, the Board may, by a vote of a two-thirds majority of the Board, send the matter back to the CCWG-Accountability for further consideration. The Board shall provide detailed rationale to accompany its action. If the Board determines not to accept a modified version of a Work Stream 2 Recommendation, unless required by its fiduciary obligations, the Board shall not establish an alternative solution on the issue addressed by the Work Stream 2 Recommendation until such time as the CCWG-Accountability and the Board reach agreement.

(d) ICANN shall provide adequate support for work on Work Stream 2 Matters, within budgeting processes and limitations reasonably acceptable to the CCWG-Accountability.

(e) The Work Stream 2 Matters specifically referenced in Section 27.1(b) shall be the only matters subject to this Section 27.1 and any other accountability enhancements should be developed through ICANN's other procedures.

(f) The outcomes of each Work Stream 2 Matter are not limited and could include a variety of recommendations or no recommendation; provided, however, that any resulting recommendations must directly relate to the matters discussed in Section 27.1(b).

Section 27.2. HUMAN RIGHTS

(a) The Core Value set forth in Section 1.2(b)(viii) shall have no force or effect unless and until a framework of interpretation for human rights ("FOI-HR") is (i) approved for submission to the Board by the CCWG-Accountability as a consensus recommendation in Work Stream 2, with the CCWG Chartering Organizations having the role described in the CCWG-Accountability Charter, and (ii) approved by the Board, in each case, using the same process and criteria as for Work Stream 1 Recommendations.

(b) No person or entity shall be entitled to invoke the reconsideration process provided in Section 4.2, or the independent review process provided in Section 4.3, based solely on the inclusion of the Core Value set forth in Section 1.2(b)(viii) (i) until after the FOI-HR contemplated by Section 27.2(a) is in place or (ii) for actions of ICANN or the Board that occurred prior to the effectiveness of the FOI-HR.

Section 27.3. EXISTING GROUPS AND TASK FORCES

Notwithstanding the adoption or effectiveness of these Bylaws, task forces and other groups in existence prior to the date of these Bylaws shall continue unchanged in membership, scope, and operation unless and until changes are made by ICANN in compliance with the Bylaws.

Section 27.4. CONTRACTS WITH ICANN

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

Section 27.5 NOMINATING COMMITTEE DELEGATE TERMS

(a) For the Nominating Committee with a term commencing at the conclusion of the ICANN General Meeting in 2024, the delegates shall be selected in accordance with Section 8.3 of these Bylaws as adopted on 11 October 2023. To effectuate the introduction of the two-year terms and support the goal of staggering delegate terms, the following delegates will serve a one-year term:

(i) The delegates appointed pursuant to:

(A) Section 8.2.(c)(i) (ASO);

(B) Section 8.2 (c)(iii) (GAC); and

(C) Section 8.2 (c)(v) (RSSAC).

(ii) Three of the delegates appointed by the At-Large Advisory Committee pursuant to Section 8.2(d).

(iii) Three of the delegated appointed by the Generic Names Supporting Organization pursuant to Section 8.2(e).

(b) The At-Large Advisory Committee and the Generic Names Supporting Organization are responsible for identifying which delegates are assigned to the one-year terms identified above.

(d) No person who served on either or both of the two prior Nominating Committees (with terms ending at the ICANN Annual General Meeting in 2023 or 2024) is eligible for appointment to the Nominating Committee term commencing at the conclusion of the ICANN General Meeting in 2024.

(e) For the Nominating Committee with a term commencing at the conclusion of ICANN General Meeting in 2025, only those seats as identified in this Section 27.5(a)(i)-(iii) shall be filled, each for a two-year term. No person who served on either or both of the Nominating Committees with terms ending at the ICANN Annual General Meeting in 2024 or 2025 shall be eligible for appointment to this term.

(f) For the purposes of calculating and filling vacancies under Section 8.3(e), the following rules shall apply for the one-year terms specified in this Transition Article:

Service in all or part of a one-year term shall not be counted towards the total time served on the Nominating Committee, and the persons remain eligible to serve two two-year terms pursuant to Section 8.3.
One-year terms vacated with less than four months remaining in the term shall not be replaced, regardless of the reason for vacancy. The seat shall remain vacant until the commencement of the Nominating Committee with a term commencing with the conclusion of ICANN's Annual General Meeting in 2025.

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 Board. The role of the GNSO is outlined in Article 11 of these Bylaws. If the GNSO is conducting activities that are not intended to result in a Consensus Policy, the Council may act through other processes.

Section 1. Required Elements of a Policy Development Process

The following elements are required at a minimum to form Consensus Policies as defined within ICANN contracts, and any other policies for which the GNSO Council requests application of this Annex A:

Final Issue Report requested by the Board, the GNSO Council ("Council") or Advisory Committee, which should include at a minimum a) the proposed issue raised for consideration, b) the identity of the party submitting the issue, and c) how that party Is affected by the issue;
Formal initiation of the Policy Development Process by the Council;
Formation of a Working Group or other designated work method;
Initial Report produced by a Working Group or other designated work method;
Final Report produced by a Working Group, or other designated work method, and forwarded to the Council for deliberation;
Council approval of PDP Recommendations contained in the Final Report, by the required thresholds;
PDP Recommendations and Final Report shall be forwarded to the Board through a Recommendations Report approved by the Council; and
Board approval of PDP Recommendations.

Section 2. Policy Development Process Manual

The GNSO shall maintain a Policy Development Process Manual ("PDP Manual") within the operating procedures of the GNSO maintained by the GNSO Council. The PDP Manual shall contain specific additional guidance on completion of all elements of a PDP, including those elements that are not otherwise defined in these Bylaws. The PDP Manual and any amendments thereto are subject to a twenty-one (21) day public comment period at minimum, as well as Board oversight and review, as specified at Section 11.3(d).

Section 3. Requesting an Issue Report

Board Request. The Board may request an Issue Report by instructing the GNSO Council ("Council") to begin the process outlined the PDP Manual. In the event the Board makes a request for an Issue Report, the Board should provide a mechanism by which the GNSO Council can consult with the Board to provide information on the scope, timing, and priority of the request for an Issue Report.

Council Request. The GNSO Council may request an Issue Report by a vote of at least one-fourth (1/4) of the members of the Council of each House or a majority of one House.

Advisory Committee Request. An Advisory Committee may raise an issue for policy development by action of such committee to request an Issue Report, and transmission of that request to the Staff Manager and GNSO Council.

Section 4. Creation of an Issue Report

Within forty-five (45) calendar days after receipt of either (i) an instruction from the Board; (ii) a properly supported motion from the GNSO Council; or (iii) a properly supported motion from an Advisory Committee, the Staff Manager will create a report (a "Preliminary Issue Report"). In the event the Staff Manager determines that more time is necessary to create the Preliminary Issue Report, the Staff Manager may request an extension of time for completion of the Preliminary Issue Report.

The following elements should be considered in the Issue Report:

The proposed issue raised for consideration;
The identity of the party submitting the request for the Issue Report;
How that party is affected by the issue, if known;
Support for the issue to initiate the PDP, if known;
The opinion of the ICANN General Counsel regarding whether the issue proposed for consideration within the Policy Development Process is properly within the scope of the Mission, policy process and more specifically the role of the GNSO as set forth in the Bylaws.
The opinion of ICANN Staff as to whether the Council should initiate the PDP on the issue.

Upon completion of the Preliminary Issue Report, the Preliminary Issue Report shall be posted on the Website for a public comment period that complies with the designated practice for public comment periods within ICANN.

The Staff Manager is responsible for drafting a summary and analysis of the public comments received on the Preliminary Issue Report and producing a Final Issue Report based upon the comments received. The Staff Manager should forward the Final Issue Report, along with any summary and analysis of the public comments received, to the Chair of the GNSO Council for consideration for initiation of a PDP.

Section 5. Initiation of the PDP

The Council may initiate the PDP as follows:

Board Request: If the Board requested an Issue Report, the Council, within the timeframe set forth in the PDP Manual, shall initiate a PDP. No vote is required for such action.

GNSO Council or Advisory Committee Requests: The Council may only initiate the PDP by a vote of the Council. Initiation of a PDP requires a vote as set forth in Section 11.3(i)(ii) and Section 11.3(i)(iii) in favor of initiating the PDP.

Section 6. Reports

An Initial Report should be delivered to the GNSO Council and posted for a public comment period that complies with the designated practice for public comment periods within ICANN, which time may be extended in accordance with the PDP Manual. Following the review of the comments received and, if required, additional deliberations, a Final Report shall be produced for transmission to the Council.

Section 7. Council Deliberation

Upon receipt of a Final Report, whether as the result of a working group or otherwise, the Council chair will (i) distribute the Final Report to all Council members; and (ii) call for Council deliberation on the matter in accordance with the PDP Manual.

The Council approval process is set forth in Section 11.3(i)(iv) through Section 11.3(vii), as supplemented by the PDP Manual.

Section 8. Preparation of the Board Report

If the PDP recommendations contained in the Final Report are approved by the GNSO Council, a Recommendations Report shall be approved by the GNSO Council for delivery to the Board.

Section 9. Board Approval Processes

The Board will meet to discuss the GNSO Council recommendation as soon as feasible, but preferably not later than the second meeting after receipt of the Board Report from the Staff Manager. Board deliberation on the PDP Recommendations contained within the Recommendations Report shall proceed as follows:

Any PDP Recommendations approved by a GNSO Supermajority Vote shall be adopted by the Board unless, by a vote of more than two-thirds (2/3) of the Board, the Board determines that such policy is not in the best interests of the ICANN community or ICANN. If the GNSO Council recommendation was approved by less than a GNSO Supermajority Vote, a majority vote of the Board will be sufficient to determine that such policy is not in the best interests of the ICANN community or ICANN.
In the event that the Board determines, in accordance with paragraph a above, that the policy recommended by a GNSO Supermajority Vote or less than a GNSO Supermajority vote is not in the best interests of the ICANN community or ICANN (the Corporation), 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.
The Council shall review the Board Statement for discussion with the Board as soon as feasible 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.
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 the then-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 two-thirds (2/3) of the Board determines that such policy is not in the interests of the ICANN community or ICANN. For any Supplemental Recommendation approved by less than a GNSO Supermajority Vote, a majority vote of the Board shall be sufficient to determine that the policy in the Supplemental Recommendation is not in the best interest of the ICANN community or ICANN.

Section 10. Implementation of Approved Policies

Upon a final decision of the Board adopting the policy, the Board shall, as appropriate, give authorization or direction to ICANN staff to work with the GNSO Council to create an implementation plan based upon the implementation recommendations identified in the Final Report, and to implement the policy. The GNSO Council may, but is not required to, direct the creation of an implementation review team to assist in implementation of the policy.

Section 11. 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. Such status page will outline the completed and upcoming steps in the PDP process, and contain links to key resources (e.g. Reports, Comments Fora, WG Discussions, etc.).

Section 12. Additional Definitions

"Comment Site", "Comment Forum", "Comments For a" and "Website" refer to one or more websites 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.

Section 13. Applicability

The procedures of this Annex A shall be applicable to all requests for Issue Reports and PDPs initiated after 8 December 2011. For all ongoing PDPs initiated prior to 8 December 2011, the Council shall determine the feasibility of transitioning to the procedures set forth in this Annex A for all remaining steps within the PDP. If the Council determines that any ongoing PDP cannot be feasibly transitioned to these updated procedures, the PDP shall be concluded according to the procedures set forth in Annex A in force on 7 December 2011.

Annex A-1: GNSO Expedited Policy Development Process

The following process shall govern the specific instances where the GNSO Council invokes the GNSO Expedited Policy Development Process ("EPDP"). The GNSO Council may invoke the EPDP in the following limited circumstances: (1) to address a narrowly defined policy issue that was identified and scoped after either the adoption of a GNSO policy recommendation by the Board or the implementation of such an adopted recommendation; or (2) to create new or additional recommendations for a specific policy issue that had been substantially scoped previously such that extensive, pertinent background information already exists, e.g. (a) in an Issue Report for a possible PDP that was not initiated; (b) as part of a previous PDP that was not completed; or (c) through other projects such as a GGP. The following process shall be in place until such time as modifications are recommended to and approved by the Board. Where a conflict arises in relation to an EPDP between the PDP Manual (see Annex 2 of the GNSO Operating Procedures) and the procedures described in this Annex A-1, the provisions of this Annex A-1 shall prevail.

The role of the GNSO is outlined in Article 11 of these Bylaws. Provided the Council believes and documents via Council vote that the above-listed criteria are met, an EPDP may be initiated to recommend an amendment to an existing Consensus Policy; however, in all cases where the GNSO is conducting policy-making activities that do not meet the above criteria as documented in a Council vote, the Council should act through a Policy Development Process (see Annex A).

Section 1. Required Elements of a GNSO Expedited Policy Development Process

The following elements are required at a minimum to develop expedited GNSO policy recommendations, including recommendations that could result in amendments to an existing Consensus Policy, as part of a GNSO Expedited Policy Development Process:

Formal initiation of the GNSO Expedited Policy Development Process by the GNSO Council, including an EPDP scoping document;
Formation of an EPDP Team or other designated work method;
Initial Report produced by an EPDP Team or other designated work method;
Final EPDP Policy Recommendation(s) Report produced by an EPDP Team, or other designated work method, and forwarded to the Council for deliberation;
GNSO Council approval of EPDP Policy Recommendations contained in the Final EPDP Policy Recommendation(s) Report, by the required thresholds;
EPDP Recommendations and Final EPDP Recommendation(s) Report forwarded to the Board through a Recommendations Report approved by the Council; and
Board approval of EPDP Recommendation(s).

Section 2. Expedited Policy Development Process Manual

The GNSO shall include a specific section(s) on the EPDP process as part of its maintenance of the GNSO Policy Development Process Manual (PDP Manual), described in Annex 5 of the GNSO Operating Procedures. The EPDP Manual shall contain specific additional guidance on completion of all elements of an EPDP, including those elements that are not otherwise defined in these Bylaws. The E PDP Manual and any amendments thereto are subject to a twenty-one (21) day public comment period at minimum, as well as Board oversight and review, as specified at Section 11.3(d) .

Section 3. Initiation of the EPDP

The Council may initiate an EPDP as follows:

The Council may only initiate the EPDP by a vote of the Council. Initiation of an EPDP requires an affirmative Supermajority vote of the Council (as defined in Section 11.3(i)(xii) of these Bylaws) in favor of initiating the EPDP.

The request to initiate an EPDP must be accompanied by an EPDP scoping document, which is expected to include at a minimum the following information:

Name of Council Member / SG / C;
Origin of issue (e.g. previously completed PDP);
Scope of the effort (detailed description of the issue or question that the EPDP is expected to address);
Description of how this issue meets the criteria for an EPDP, i.e. how the EPDP will address either: (1) a narrowly defined policy issue that was identified and scoped after either the adoption of a GNSO policy recommendation by the Board or the implementation of such an adopted recommendation, or (2) new or additional policy recommendations on a specific GNSO policy issue that had been scoped previously as part of a PDP that was not completed or other similar effort, including relevant supporting information in either case;
If not provided as part of item 4, the opinion of the ICANN General Counsel as to whether the issue proposed for consideration is properly within the scope of the Mission, policy process and more specifically the role of the GNSO;
Proposed EPDP mechanism (e.g. WG, DT, individual volunteers);
Method of operation, if different from GNSO Working Group Guidelines;
Decision-making methodology for EPDP mechanism, if different from GNSO Working Group Guidelines;
Target completion date.

Section 4. Council Deliberation

Upon receipt of an EPDP Final Recommendation(s) Report, whether as the result of an EPDP Team or otherwise, the Council chair will (i) distribute the Final EPDP Recommendation(s) Report to all Council members; and (ii) call for Council deliberation on the matter in accordance with the PDP Manual.

Approval of EPDP Recommendation(s) requires an affirmative vote of the Council meeting the thresholds set forth in Section 11.3(i)(xiv) and (xv), as supplemented by the PDP Manual.

Section 5. Preparation of the Board Report

If the EPDP Recommendation(s) contained in the Final EPDP Recommendation(s) Report are approved by the GNSO Council, a Recommendation(s) Report shall be approved by the GNSO Council for delivery to the Board.

Section 6. Board Approval Processes

The Board will meet to discuss the EPDP recommendation(s) as soon as feasible, but preferably not later than the second meeting after receipt of the Recommendations Report from the Staff Manager. Board deliberation on the EPDP Recommendations contained within the Recommendations Report shall proceed as follows:

Any EPDP Recommendations approved by a GNSO Supermajority Vote shall be adopted by the Board unless, by a vote of more than two-thirds (2/3) of the Board, the Board determines that such policy is not in the best interests of the ICANN community or ICANN. If the GNSO Council recommendation was approved by less than a GNSO Supermajority Vote, a majority vote of the Board will be sufficient to determine that such policy is not in the best interests of the ICANN community or ICANN.
In the event that the Board determines, in accordance with paragraph a above, that the proposed EPDP Recommendations are not in the best interests of the ICANN community or ICANN (the Corporation), 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.
The Council shall review the Board Statement for discussion with the Board as soon as feasible 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.

At the conclusion of the Council and Board discussions, the Council shall meet to affirm or modify its recommendation, and co mmunicate that conclusion (the "Supplemental Recommendation") to the Board, including an explanation for the then-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 two-thirds (2/3) of the Board determines that such guidance is not in the interests of the ICANN community or ICANN. For any Supplemental Recommendation approved by less than a GNSO Supermajority Vote, a majority vote of the Board shall be sufficient to determine that the guidance in the Supplemental Recommendation is not in the best interest of the ICANN community or ICANN.

Section 7. Implementation of Approved Policies

Upon a final decision of the Board adopting the EPDP recommendations, the Board shall, as appropriate, give authorization or direction to ICANN staff to implement the EPDP Recommendations. If deemed necessary, the Board shall direct ICANN staff to work with the GNSO Council to create a guidance implementation plan, based upon the guidance recommendations identified in the Final EPDP Recommendation(s) Report.

Section 8. Maintenance of Records

Throughout the EPDP, from initiation to a final decision by the Board, ICANN will maintain on the Website, a status web page detailing the progress of each EPDP issue. Such status page will outline the completed and upcoming steps in the EPDP process, and contain links to key resources (e.g. Reports, Comments Fora, EPDP Discussions, etc.).

Section 9. Applicability

The procedures of this Annex A-1 shall be applicable from 28 September 2015 onwards.

Annex A-2: GNSO Guidance Process

The following process shall govern the GNSO guidance process ("GGP") until such time as modifications are recommended to and approved by the Board . The role of the GNSO is outlined in Article 11 of these Bylaws. If the GNSO is conducting activities that are intended to result in a Consensus Policy, the Council should act through a Policy Development Process (see Annex A).

Section 1. Required Elements of a GNSO Guidance Process

The following elements are required at a minimum to develop GNSO guidance:

Formal initiation of the GNSO Guidance Process by the Council, including a GGP scoping document;
Identification of the types of expertise needed on the GGP Team;
Recruiting and formation of a GGP Team or other designated work method;
Proposed GNSO Guidance Recommendation(s) Report produced by a GGP Team or other designated work method;
Final GNSO Guidance Recommendation(s) Report produced by a GGP Team, or other designated work method, and forwarded to the Council for deliberation;
Council approval of GGP Recommendations contained in the Final Recommendation(s) Report, by the required thresholds;
GGP Recommendations and Final Recommendation(s) Report shall be forwarded to the Board through a Recommendations Report approved by the Council; and
Board approval of GGP Recommendation(s).

Section 2. GNSO Guidance Process Manual

The GNSO shall maintain a GNSO Guidance Process (GGP Manual) within the operating procedures of the GNSO maintained by the GNSO Council. The GGP Manual shall contain specific additional guidance on completion of all elements of a GGP, including those elements that are not otherwise defined in these Bylaws. The GGP Manual and any amendments thereto are subject to a twenty-one (21) day public comment period at minimum, as well as Board oversight and review, as specified at Section 11.3(d).

Section 3. Initiation of the GGP

The Council may initiate a GGP as follows:

The Council may only initiate the GGP by a vote of the Council or at the formal request of the ICANN Board. Initiation of a GGP requires a vote as set forth in Section 11.3(i)(xvi) in favor of initiating the GGP. In the case of a GGP requested by the Board, a GGP will automatically be initiated unless the GNSO Council votes against the initiation of a GGP as set forth in Section 11.3(i)(xvii).

The request to initiate a GGP must be accompanied by a GGP scoping document, which is expected to include at a minimum the following information:

Name of Council Member / SG / C
Origin of issue (e.g., board request)
Scope of the effort (detailed description of the issue or question that the GGP is expected to address)
Proposed GGP mechanism (e.g. WG, DT, individual volunteers)
Method of operation, if different from GNSO Working Group Guidelines
Decision-making methodology for GGP mechanism, if different from GNSO Working Group Guidelines
Desired completion date and rationale

In the event the Board makes a request for a GGP, the Board should provide a mechanism by which the GNSO Council can consult with the Board to provide information on the scope, timing, and priority of the request for a GGP.

Section 4. Council Deliberation

Upon receipt of a Final Recommendation(s) Report, whether as the result of a GGP Team or otherwise, the Council chair will (i) distribute the Final Recommendation(s) Report to all Council members; and (ii) call for Council deliberation on the matter in accordance with the GGP Manual.

The Council approval process is set forth in Section 11.3(xviii) as supplemented by the GGP Manual.

Section 5. Preparation of the Board Report

If the GGP recommendations contained in the Final Recommendation(s) Report are approved by the GNSO Council, a Recommendations Report shall be approved by the GNSO Council for delivery to the Board.

Section 6. Board Approval Processes

The Board will meet to discuss the GNSO Guidance recommendation(s) as soon as feasible, but preferably not later than the second meeting after receipt of the Board Report from the Staff Manager. Board deliberation on the GGP Recommendations contained within the Recommendations Report shall proceed as follows:

Any GGP Recommendations approved by a GNSO Supermajority Vote shall be adopted by the Board unless, by a vote of more than two-thirds (2/3) of the Board, the Board determines that such guidance is not in the best interests of the ICANN community or ICANN.
In the event that the Board determines, in accordance with paragraph a above, that the proposed GNSO Guidance recommendation(s) adopted by a GNSO Supermajority Vote is not in the best interests of the ICANN community or ICANN (the Corporation), 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.
The Council shall review the Board Statement for discussion with the Board as soon as feasible 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.
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 the then-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 two-thirds (2/3) of the Board determines that such guidance is not in the interests of the ICANN community or ICANN.

Section 7. Implementation of Approved GNSO Guidance

Upon a final decision of the Board adopting the guidance, the Board shall, as appropriate, give authorization or direction to ICANN staff to implement the GNSO Guidance. If deemed necessary, the Board may direct ICANN Staff to work with the GNSO Council to create a guidance implementation plan, if deemed necessary, based upon the guidance recommendations identified in the Final Recommendation(s) Report.

Section 8. Maintenance of Records

Throughout the GGP, from initiation to a final decision by the Board, ICANN will maintain on the Website, a status web page detailing the progress of each GGP issue. Such status page will outline the completed and upcoming steps in the GGP process, and contain links to key resources (e.g. Reports, Comments Fora, GGP Discussions, etc.).

Section 9. Additional Definitions

"Comment Site", "Comment Forum", "Comments Fora" and "Website" refer to one or more websites designated by ICANN on which notifications and comments regarding the GGP will be posted.

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

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:

Council. The ccNSO Council (in this Annex B, the "Council") may call for the creation of an Issue Report by documentation of support from at least seven of the members of the Council present at any meeting or voting by electronic means.
Board. The Board may call for the creation of an Issue Report by requesting the Council to begin the policy-development process.
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.
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.
Members of the ccNSO. At least ten members of the ccNSO from at least ten different Territories may call for the creation of an Issue Report at any meeting or by electronic means.

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.

2. Creation of the Issue Report and Initiation Threshold

Within fourteen (14) days after the receipt of a request as outlined in Item 1 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:

The proposed issue raised for consideration;
The identity of the party submitting the issue;
How that party is affected by the issue;
Support for the issue to initiate the PDP;
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:

The issue is within the scope of the Mission;
Analysis of the relevant factors according to Section 10.6(b) 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:
Implicates or affects an existing ICANN policy;
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 Section 10.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.

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 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:

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 electronic means.
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 Mission 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 electronic means, 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 electronic means), whether or not to appoint a task force to address the issue. If the Council votes:

In favor of convening a task force, it shall do so in accordance with Item 7 below.
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 electronic means, approve or amend and approve the PDP Time Line set out in the Issue Report.

5. Composition and Selection of Task Forces

Upon voting to appoint a task force, the Council shall invite each of the Regional Organizations (see Section 10.5) 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.
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.
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:

The issue to be addressed by the task force, as such issue was articulated for the vote before the Council that initiated the PDP;
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
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 electronic means. The quorum requirements of Section 10.3(n) 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:

A clear statement of any Supermajority Vote (being 66% of the task force) position of the task force on the issue;
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;
An analysis of how the issue would affect each Region, including any financial impact on the Region;
An analysis of the period of time that would likely be necessary to implement the policy; and
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

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.
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.
The Council shall formally request the Chair of the GAC to offer opinion or advice.
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 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.
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.
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

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.
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 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 clear statement of the Council's recommendation;
The Final Report submitted to the Council; and
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 lodged through their designated Emissaries. The 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 Emissaries lodge votes within the voting period, the resulting vote will 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 irrespective of whether at least 50% of the Emissaries 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 clear statement of the ccNSO recommendation;
The Final Report submitted to the Council; and
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.

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.
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.
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.
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").
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:

Issue Report;
PDP Time Line;
Comment Report;
Regional Statement(s);
Preliminary Task Force Report;
Task Force Report;
Initial Report;
Final Report;
Members' Report;
Board Report;
Board Statement;
Supplemental Members' Report; and
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 Section 10.6(b) 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 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:

Data is registered/maintained to generate a zone file,
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):

Entering data into a database ("Data Entry Function") and
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:

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.
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:

delineate and identify specific policy areas;
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.

Name Server Function (as to ccTLDs)

Level 1: Root Name Servers
Policy role: IETF, RSSAC (ICANN)
Executive role: Root Server System Operators
Accountability role: RSSAC (ICANN)

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 3: User's Name Servers
Policy role: ccTLD Manager, IETF (RFC)
Executive role: Registrant
Accountability role: ccTLD Manager

Data Entry Function (as to ccTLDs)

Level 1: Root Level Registry
Policy role: ccNSO Policy Development Process (ICANN)
Executive role: ICANN (IANA)
Accountability role: ICANN community, ccTLD Managers, (national authorities in some cases)

Level 2: ccTLD Registry
Policy role: Local Internet Community, including local government, and/or ccTLD Manager according to local structure
Executive role: ccTLD Manager
Accountability role: Local Internet Community, including national authorities in some cases

Level 3: Second and Lower Levels
Policy role: Registrant
Executive role: Registrant
Accountability role: Registrant, users of lower-level domain names

ANNEX D: EC MECHANISM

ARTICLE 1 PROCEDURE FOR EXERCISE OF EC'S RIGHTS TO APPROVE APPROVAL ACTIONS

Section 1.1. APPROVAL ACTIONS

The processes set forth in this Article 1 shall govern the escalation procedures for the EC's exercise of its right to approve the following (each, an "Approval Action") under the Bylaws:

Fundamental Bylaw Amendments, as contemplated by Section 25.2 of the Bylaws;
Articles Amendments, as contemplated by Section 25.2 of the Bylaws; and
Asset Sales, as contemplated by Article 26 of the Bylaws.

Section 1.2. APPROVAL PROCESS

Following the delivery of a Board Notice for an Approval Action ("Approval Action Board Notice") by the Secretary to the EC Administration and the Decisional Participants (which delivery date shall be referred to herein as the "Approval Action Board Notification Date"), the Decisional Participants shall thereafter promptly inform their constituents of the delivery of the Approval Action Board Notice. Any Approval Action Board Notice relating to a Fundamental Bylaw Amendment or Articles Amendment shall include a statement, if applicable, that the Fundamental Bylaw Amendment or Articles Amendment, as applicable, is based solely on the outcome of a PDP, citing the specific PDP and the provision in the Fundamental Bylaw Amendment or Articles Amendment subject to the Approval Action Board Notice that implements such PDP (as applicable, a "PDP Fundamental Bylaw Statement" or "PDP Articles Statement") and the name of the Supporting Organization that is a Decisional Participant that undertook the PDP relating to the Fundamental Bylaw Amendment or Articles Amendment, as applicable (as applicable, the "Fundamental Bylaw Amendment PDP Decisional Participant" or "Articles Amendment PDP Decisional Participant"). The process set forth in this Section 1.2 of this Annex D as it relates to a particular Approval Action is referred to herein as the "Approval Process."

Section 1.3. APPROVAL ACTION COMMUNITY FORUM

ICANN shall, at the direction of the EC Administration, convene a forum at which the Decisional Participants and interested parties may discuss the Approval Action (an "Approval Action Community Forum").
If the EC Administration requests a publicly-available conference call by providing a notice to the Secretary, ICANN shall, at the direction of the EC Administration, schedule such call prior to any Approval Action Community Forum, and inform the Decisional Participants of the date, time and participation methods of such conference call, which ICANN shall promptly post on the Website.
The Approval Action Community Forum shall be convened and concluded during the period beginning upon the Approval Action Board Notification Date and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 30th day after the Approval Action Board Notification Date ("Approval Action Community Forum Period"). If the EC Administration requests that the Approval Action Community Forum be held during the next scheduled ICANN public meeting, the Approval Action Community Forum shall be held during the next scheduled ICANN public meeting on the date and at the time determined by ICANN, taking into account any date and/or time requested by the EC Administration. If the Approval Action Community Forum is held during the next scheduled ICANN public meeting and that public meeting is held after 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 30th day after the Approval Action Board Notification Date, the Approval Action Community Forum Period for the Approval Action shall expire at 11:59 p.m., local time of the city hosting such ICANN public meeting on the official last day of such ICANN public meeting.
The Approval Action Community Forum shall be conducted via remote participation methods such as teleconference, web-based meeting room and/or such other form of remote participation as the EC Administration selects, and/or, only if the Approval Action Community Forum is held during an ICANN public meeting, face-to-face meetings. If the Approval Action Community Forum will not be held during an ICANN public meeting, the EC Administration shall promptly inform ICANN of the date, time and participation methods of such Approval Action Community Forum, which ICANN shall promptly post on the Website.
The EC Administration shall manage and moderate the Approval Action Community Forum in a fair and neutral manner.
ICANN and any Supporting Organization or Advisory Committee (including Decisional Participants) may deliver to the EC Administration in writing its views and questions on the Approval Action prior to the convening of and during the Approval Action Community Forum. Any written materials delivered to the EC Administration shall also be delivered to the Secretary for prompt posting on the Website in a manner deemed appropriate by ICANN.
ICANN staff and Directors representing the Board are expected to attend the Approval Action Community Forum in order to address any questions or concerns regarding the Approval Action.
For the avoidance of doubt, the Approval Action Community Forum is not a decisional body.
During the Approval Action Community Forum Period, an additional one or two Community Forums may be held at the discretion of the Board or the EC Administration. If the Board decides to hold an additional one or two Approval Action Community Forums, it shall provide a rationale for such decision, which rationale ICANN shall promptly post on the Website.
ICANN will provide support services for the Approval Action Community Forum and shall promptly post on the Website a public record of the Approval Action Community Forum as well as all written submissions of ICANN and any Supporting Organization or Advisory Committee (including Decisional Participants) related to the Approval Action Community Forum.

Section 1.4. DECISION WHETHER TO APPROVE AN APPROVAL ACTION

(a) Following the expiration of the Approval Action Community Forum Period, at any time or date prior to 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the Approval Action Community Forum Period (such period, the "Approval Action Decision Period"), with respect to each Approval Action, each Decisional Participant shall inform the EC Administration in writing as to whether such Decisional Participant (i) supports such Approval Action, (ii) objects to such Approval Action or (iii) has determined to abstain from the matter (which shall not count as supporting or objecting to such Approval Action), and each Decisional Participant shall forward such notice to the Secretary for ICANN to promptly post on the Website. If a Decisional Participant does not inform the EC Administration of any of the foregoing prior to the expiration of the Approval Action Decision Period, the Decisional Participant shall be deemed to have abstained from the matter (even if such Decisional Participant informs the EC Administration of its support or objection following the expiration of the Approval Action Decision Period).

(b) The EC Administration shall, within twenty-four (24) hours of the expiration of the Approval Action Decision Period, deliver a written notice ("EC Approval Notice") to the Secretary certifying that, pursuant to and in compliance with the procedures and requirements of this Article 1 of this Annex D, the EC has approved the Approval Action if:

(i) The Approval Action does not relate to a Fundamental Bylaw Amendment or Articles Amendment and is (A) supported by three or more Decisional Participants and (B) not objected to by more than one Decisional Participant;

(ii) The Approval Action relates to a Fundamental Bylaw Amendment and is (A) supported by three or more Decisional Participants (including the Fundamental Bylaw Amendment PDP Decisional Participant if the Board Notice included a PDP Fundamental Bylaw Statement) and (B) not objected to by more than one Decisional Participant; or

(iii) The Approval Action relates to an Articles Amendment and is (A) supported by three or more Decisional Participants (including the Articles Amendment PDP Decisional Participant if the Board Notice included a PDP Articles Statement) and (B) not objected to by more than one Decisional Participant.

(c) If the Approval Action does not obtain the support required by Section 1.4(b)(i), (ii) or (iii) of this Annex D, as applicable, the Approval Process will automatically be terminated and the EC Administration shall, within twenty-four (24) hours of the expiration of the Approval Action Decision Period, deliver to the Secretary a notice certifying that the Approval Process has been terminated with respect to the Approval Action ("Approval Process Termination Notice").

(d) ICANN shall promptly post to the Website any (i) Approval Action Board Notice, (ii) EC Approval Notice, (iii) Approval Process Termination Notice, (iv) written explanation provided by the EC Administration related to any of the foregoing, and (v) other notices the Secretary receives under this Article 1.

ARTICLE 2 PROCEDURE FOR EXERCISE OF EC'S RIGHTS TO REJECT SPECIFIED ACTIONS

Section 2.1. Rejection Actions

The processes set forth in this Article 2 shall govern the escalation procedures for the EC's exercise of its right to reject the following (each, a "Rejection Action") under the Bylaws:

PTI Governance Actions, as contemplated by Section 16.2(d) of the Bylaws;
IFR Recommendation Decisions, as contemplated by Section 18.6(d) of the Bylaws;
Special IFR Recommendation Decisions, as contemplated by Section 18.12(e) of the Bylaws;
SCWG Creation Decisions, as contemplated by Section 19.1(d) of the Bylaws;
SCWG Recommendation Decisions, as contemplated by Section 19.4(d) of the Bylaws;
ICANN Budgets, as contemplated by Section 22.4(a)(v) of the Bylaws;
IANA Budgets, as contemplated by Section 22.4(b)(v) of the Bylaws;
Operating Plans, as contemplated by Section 22.5(a)(v) of the Bylaws;
Strategic Plans, as contemplated by Section 22.5(b)(v) of the Bylaws; and
Standard Bylaw Amendments, as contemplated by Section 25.1(e) of the Bylaws.

Section 2.2. PETITION PROCESS FOR SPECIFIED ACTIONS

(a) Following the delivery of a Board Notice for a Rejection Action ("Rejection Action Board Notice") by the Secretary to the EC Administration and Decisional Participants (which delivery date shall be referred to herein as the "Rejection Action Board Notification Date"), the Decisional Participants shall thereafter promptly inform their constituents of the delivery of the Rejection Action Board Notice. The process set forth in this Section 2.2 of this Annex D as it relates to a particular Rejection Action is referred to herein as the "Rejection Process."

(b) During the period beginning on the Rejection Action Board Notification Date and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the date that is the 21st day after the Rejection Action Board Notification Date (as it relates to a particular Rejection Action, the "Rejection Action Petition Period"), subject to the procedures and requirements developed by the applicable Decisional Participant, an individual may submit a petition to a Decisional Participant, seeking to reject the Rejection Action and initiate the Rejection Process (a "Rejection Action Petition").

(c) A Decisional Participant that has received a Rejection Action Petition shall either accept or reject such Rejection Action Petition; provided that a Decisional Participant may only accept such Rejection Action Petition if it was received by such Decisional Participant during the Rejection Action Petition Period.

(i) If, in accordance with the requirements of Section 2.2(c) of this Annex D, a Decisional Participant accepts a Rejection Action Petition during the Rejection Action Petition Period, the Decisional Participant shall promptly provide to the EC Administration, the other Decisional Participants and the Secretary written notice ("Rejection Action Petition Notice") of such acceptance (such Decisional Participant, the "Rejection Action Petitioning Decisional Participant"), and ICANN shall promptly post such Rejection Action Petition Notice on the Website. The Rejection Action Petition Notice shall also include:

(A) the rationale upon which rejection of the Rejection Action is sought. Where the Rejection Action Petition Notice relates to an ICANN Budget, an IANA Budget, an Operating Plan or a Strategic Plan, the Rejection Action Petition Notice shall not be valid and shall not be accepted by the EC Administration unless the rationale set forth in the Rejection Action Petition Notice is based on one or more significant issues that were specifically raised in the applicable public comment period(s) relating to perceived inconsistencies with the Mission, purpose and role set forth in ICANN's Articles of Incorporation and Bylaws, the global public interest, the needs of ICANN's stakeholders, financial stability, or other matter of concern to the community; and

(B) where the Rejection Action Petition Notice relates to a Standard Bylaw Amendment, a statement, if applicable, that the Standard Bylaw Amendment is based solely on the outcome of a PDP, citing the specific PDP and the provision in the Standard Bylaw Amendment subject to the Board Notice that implements such PDP ("PDP Standard Bylaw Statement") and the name of the Supporting Organization that is a Decisional Participant that undertook the PDP relating to the Standard Bylaw Amendment ("Standard Bylaw Amendment PDP Decisional Participant").

The Rejection Process shall thereafter continue pursuant to Section 2.2(d) of this Annex D.

(ii) If the EC Administration has not received a Rejection Action Petition Notice pursuant to Section 2.2(c)(i) of this Annex D during the Rejection Action Petition Period, the Rejection Process shall automatically be terminated and the EC Administration shall, within twenty-four (24) hours of the expiration of the Rejection Action Petition Period, deliver to the Secretary a notice certifying that the Rejection Process has been terminated with respect to the Rejection Action contained in the Approval Notice ("Rejection Process Termination Notice"). ICANN shall promptly post such Rejection Process Termination Notice on the Website.

(d) Following the delivery of a Rejection Action Petition Notice to the EC Administration pursuant to Section 2.2(c)(i) of this Annex D, the Rejection Action Petitioning Decisional Participant shall contact the EC Administration and the other Decisional Participants to determine whether any other Decisional Participants support the Rejection Action Petition. The Rejection Action Petitioning Decisional Participant shall forward such communication to the Secretary for ICANN to promptly post on the Website.

(i) If the Rejection Action Petitioning Decisional Participant obtains the support of at least one other Decisional Participant (a "Rejection Action Supporting Decisional Participant") during the period beginning upon the expiration of the Rejection Action Petition Period and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 7th day after the expiration of the Rejection Action Petition Period (the "Rejection Action Petition Support Period"), the Rejection Action Petitioning Decisional Participant shall provide a written notice to the EC Administration, the other Decisional Participants and the Secretary ("Rejection Action Supported Petition") within twenty-four (24) hours of receiving the support of at least one Rejection Action Supporting Decisional Participant, and ICANN shall promptly post such Rejection Action Supported Petition on the Website. Each Rejection Action Supporting Decisional Participant shall provide a written notice to the EC Administration, the other Decisional Participants and the Secretary within twenty-four (24) hours of providing support to the Rejection Action Petition, and ICANN shall promptly post each such notice on the Website. SuchRejection Action Supported Petition shall include:

(A) a supporting rationale in reasonable detail;

(B) contact information for at least one representative who has been designated by the Rejection Action Petitioning Decisional Participant who shall act as a liaison with respect to the Rejection Action Supported Petition;

(C) a statement as to whether or not the Rejection Action Petitioning Decisional Participant and/or the Rejection Action Supporting Decisional Participant requests that ICANN organize a publicly-available conference call prior to the Rejection Action Community Forum (as defined in Section 2.3 of this Annex D) for the community to discuss the Rejection Action Supported Petition;

(D) a statement as to whether the Rejection Action Petitioning Decisional Participant and the Rejection Action Supporting Decisional Participant have determined to hold the Rejection Action Community Forum during the next scheduled ICANN public meeting, taking into account the limitation on holding such a Rejection Action Community Forum when the Rejection Action Supported Petition relates to an ICANN Budget or IANA Budget as described in Section 2.3(c) of this Annex D; and

(E) a PDP Standard Bylaw Statement, if applicable.

The Rejection Process shall thereafter continue for such Rejection Action Supported Petition pursuant to Section 2.3 of this Annex D. The foregoing process may result in more than one Rejection Action Supported Petition relating to the same Rejection Action.

(ii) The Rejection Process shall automatically be terminated and the EC Administration shall, within twenty-four (24) hours of the expiration of the Rejection Action Petition Support Period, deliver to the Secretary a Rejection Process Termination Notice, which ICANN shall promptly post on the Website, if:

(A) no Rejection Action Petitioning Decisional Participant is able to obtain the support of at least one other Decisional Participant for its Rejection Action Petition during the Rejection Action Petition Support Period; or

(B) where the Rejection Action Supported Petition includes a PDP Standard Bylaw Statement, the Standard Bylaw Amendment PDP Decisional Participant is not (x) the Rejection Action Petitioning Decisional Participant or (y) one of the Rejection Action Supporting Decisional Participants.

Section 2.3. REJECTION ACTION COMMUNITY FORUM

If the EC Administration receives a Rejection Action Supported Petition under Section 2.2(d) of this Annex D during the Rejection Action Petition Support Period, ICANN shall, at the direction of the EC Administration, convene a forum at which the Decisional Participants and interested parties may discuss the Rejection Action Supported Petition ("Rejection Action Community Forum"). If the EC Administration receives more than one Rejection Action Supported Petition relating to the same Rejection Action, all such Rejection Action Supported Petitions shall be discussed at the same Rejection Action Community Forum.
If a publicly-available conference call has been requested in a Rejection Action Supported Petition, ICANN shall, at the direction of the EC Administration, schedule such call prior to any Rejection Action Community Forum relating to that Rejection Action Supported Petition, and inform the Decisional Participants of the date, time and participation methods of such conference call, which ICANN shall promptly post on the Website. If a conference call has been requested in relation to more than one Rejection Action Supported Petition relating to the same Rejection Action, all such Rejection Action Supported Petitions shall be discussed during the same conference call.
The Rejection Action Community Forum shall be convened and concluded during the period beginning upon the expiration of the Rejection Action Petition Support Period and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the Rejection Action Petition Support Period ("Rejection Action Community Forum Period") unless all Rejection Action Supported Petitions relating to the same Rejection Action requested that the Rejection Action Community Forum be held during the next scheduled ICANN public meeting, in which case the Rejection Action Community Forum shall be held during the next scheduled ICANN public meeting (except as otherwise provided below with respect to a Rejection Action Supported Petition relating to an ICANN Budget or IANA Budget) on the date and at the time determined by ICANN, taking into account any date and/or time requested by the Rejection Action Petitioning Decisional Participant(s) and the Rejection Action Supporting Decisional Participant(s). If the Rejection Action Community Forum is held during the next scheduled ICANN public meeting and that public meeting is held after 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the Rejection Action Petition Support Period, the Rejection Action Community Forum Period shall expire at 11:59 p.m., local time of the city hosting such ICANN public meeting on the official last day of such ICANN public meeting. Notwithstanding the foregoing and notwithstanding any statement in the Rejection Action Supported Petition, a Rejection Action Community Forum to discuss a Rejection Action Supported Petition relating to an ICANN Budget or IANA Budget may only be held at a scheduled ICANN public meeting if such Rejection Action Community Forum occurs during the Rejection Action Community Forum Period, without any extension of such Rejection Action Community Forum Period.
The Rejection Action Community Forum shall be conducted via remote participation methods such as teleconference, web-based meeting room and/or such other form of remote participation as the EC Administration selects, and/or, only if the Rejection Action Community Forum is held during an ICANN public meeting, face-to-face meetings. If the Rejection Action Community Forum will not be held during an ICANN public meeting, the EC Administration shall promptly inform ICANN of the date, time and participation methods of such Rejection Action Community Forum, which ICANN shall promptly post on the Website.
The EC Administration shall manage and moderate the Rejection Action Community Forum in a fair and neutral manner.
ICANN and any Supporting Organization or Advisory Committee (including Decisional Participants) may deliver to the EC Administration in writing its views and questions on the Rejection Action Supported Petition prior to the convening of and during the Rejection Action Community Forum. Any written materials delivered to the EC Administration shall also be delivered to the Secretary for prompt posting on the Website in a manner deemed appropriate by ICANN.
ICANN staff (including the CFO when the Rejection Action Supported Petition relates to an ICANN Budget, IANA Budget or Operating Plan) and Directors representing the Board are expected to attend the Rejection Action Community Forum in order to address the concerns raised in the Rejection Action Supported Petition.
If the Rejection Action Petitioning Decisional Participant and each of the Rejection Action Supporting Decisional Participants for an applicable Rejection Action Supported Petition agree before, during or after the Rejection Action Community Forum that the issue raised in such Rejection Action Supported Petition has been resolved, such Rejection Action Supported Petition shall be deemed withdrawn and the Rejection Process with respect to such Rejection Action Supported Petition will be terminated. If all Rejection Action Supported Petitions relating to a Rejection Action are withdrawn, the Rejection Process will automatically be terminated. If a Rejection Process is terminated, the EC Administration shall, within twenty-four (24) hours of the resolution of the issue raised in the Rejection Action Supported Petition, deliver to the Secretary a Rejection Process Termination Notice. For the avoidance of doubt, the Rejection Action Community Forum is not a decisional body and the foregoing resolution process shall be handled pursuant to the internal procedures of the Rejection Action Petitioning Decisional Participant and the Rejection Action Supporting Decisional Participant(s).
During the Rejection Action Community Forum Period, an additional one or two Rejection Action Community Forums may be held at the discretion of a Rejection Action Petitioning Decisional Participant and a related Rejection Action Supporting Decisional Participant, or the EC Administration.
ICANN will provide support services for the Rejection Action Community Forum and shall promptly post on the Website a public record of the Rejection Action Community Forum as well as all written submissions of ICANN and any Supporting Organization or Advisory Committee (including Decisional Participants) related to the Rejection Action Community Forum.

Section 2.4. DECISION WHETHER TO REJECT A REJECTION ACTION

(a) Following the expiration of the Rejection Action Community Forum Period, at any time or date prior to 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the Rejection Action Community Forum Period (such period, the "Rejection Action Decision Period"), with respect to each Rejection Action Supported Petition, each Decisional Participant shall inform the EC Administration in writing as to whether such Decisional Participant (i) supports such Rejection Action Supported Petition and has determined to reject the Rejection Action, (ii) objects to such Rejection Action Supported Petition or (iii) has determined to abstain from the matter (which shall not count as supporting or objecting to such Rejection Action Supported Petition), and each Decisional Participant shall forward such notice to the Secretary for ICANN to promptly post on the Website. If a Decisional Participant does not inform the EC Administration of any of the foregoing prior to expiration of the Rejection Action Decision Period, the Decisional Participant shall be deemed to have abstained from the matter (even if such Decisional Participant informs the EC Administration of its support or objection following the expiration of the Rejection Action Decision Period).

(b) The EC Administration, within twenty-four (24) hours of the expiration of the Rejection Action Decision Period, shall promptly deliver a written notice ("EC Rejection Notice") to the Secretary certifying that, pursuant to and in compliance with the procedures and requirements of this Article 2 of Annex D, the EC has resolved to reject the Rejection Action if (after accounting for any adjustments to the below as required by the GAC Carve-out pursuant to Section 3.6(e) of the Bylaws if the Rejection Action Supported Petition included a GAC Consensus Statement):

(i) A Rejection Action Supported Petition relating to a Rejection Action other than a Standard Bylaw Amendment is (A) supported by four or more Decisional Participants and (B) not objected to by more than one Decisional Participant; or

(ii) A Rejection Action Supported Petition relating to a Standard Bylaw Amendment that is (A) supported by three or more Decisional Participants (including the Standard Bylaw Amendment PDP Decisional Participant if the Rejection Action Supported Petition included a PDP Standard Bylaw Statement) and (B) not objected to by more than one Decisional Participant.

(c) If no Rejection Action Supported Petition obtains the support required by Section 2.4(b)(i) or (ii) of this Annex D, as applicable, the Rejection Process will automatically be terminated and the EC Administration shall, within twenty-four (24) hours of the expiration of the Rejection Action Decision Period, deliver to the Secretary a Rejection Process Termination Notice.

(d) ICANN shall promptly post to the Website any (i) Rejection Action Board Notice, (ii) Rejection Action Petition, (iii) Rejection Action Petition Notice, (iv) Rejection Action Supported Petition, (v) EC Rejection Notice and the written explanation provided by the EC Administration as to why the EC has chosen to reject the Rejection Action, (vi) Rejection Process Termination Notice, and (vii) other notices the Secretary receives under this Article 2.

ARTICLE 3 PROCEDURE FOR EXERCISE OF EC'S RIGHTS TO REMOVE DIRECTORS AND RECALL THE BOARD

Section 3.1. NOMINATING COMMITTEE DIRECTOR REMOVAL PROCESS

(a) Subject to the procedures and requirements developed by the applicable Decisional Participant, an individual may submit a petition to a Decisional Participant seeking to remove a Director holding Seats 1 through 8 and initiate the Nominating Committee Director Removal Process ("Nominating Committee Director Removal Petition"). Each Nominating Committee Director Removal Petition shall set forth the rationale upon which such individual seeks to remove such Director. The process set forth in this Section 3.1 of Annex D is referred to herein as the "Nominating Committee Director Removal Process."

(b) During the period beginning on the date that the Decisional Participant received the Nominating Committee Director Removal Petition (such date of receipt, the "Nominating Committee Director Removal Petition Date") and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the date that is the 21st day after the Nominating Committee Director Removal Petition Date (as it relates to a particular Director, the "Nominating Committee Director Removal Petition Period"), the Decisional Participant that has received a Nominating Committee Director Removal Petition ("Nominating Committee Director Removal Petitioned Decisional Participant") shall either accept or reject such Nominating Committee Director Removal Petition; provided that a Nominating Committee Director Removal Petitioned Decisional Participant shall not accept a Nominating Committee Director Removal Petition if, during the same term, the Director who is the subject of such Nominating Committee Director Removal Petition had previously been subject to a Nominating Committee Director Removal Petition that led to a Nominating Committee Director Removal Community Forum (as discussed in Section 3.1(e) of this Annex D).

(c) During the Nominating Committee Director Removal Petition Period, the Nominating Committee Director Removal Petitioned Decisional Participant shall invite the Director subject to the Nominating Committee Director Removal Petition and the Chair of the Board (or the Vice Chair of the Board if the Chair is the affected Director) to a dialogue with the individual(s) bringing the Nominating Committee Director Removal Petition and the Nominating Committee Director Removal Petitioned Decisional Participant's representative on the EC Administration. The Nominating Committee Director Removal Petition may not be accepted unless this invitation has been extended upon reasonable notice and accommodation to the affected Director's availability. If the invitation is accepted by either the Director who is the subject of the Nominating Committee Director Removal Petition or the Chair of the Board (or the Vice Chair of the Board if the Chair is the affected Director), the Nominating Committee Director Removal Petitioned Decisional Participant shall not accept the Nominating Committee Director Removal Petition until the dialogue has occurred or there have been reasonable efforts to have the dialogue.

(i) If, in accordance with Section 3.1(b) of this Annex D, a Nominating Committee Director Removal Petitioned Decisional Participant accepts a Nominating Committee Director Removal Petition during the Nominating Committee Director Removal Petition Period (such Decisional Participant, the "Nominating Committee Director Removal Petitioning Decisional Participant"), the Nominating Committee Director Removal Petitioning Decisional Participant shall, within twenty-four (24) hours of its acceptance of the Nominating Committee Director Removal Petition, provide written notice ("Nominating Committee Director Removal Petition Notice") of such acceptance to the EC Administration, the other Decisional Participants and the Secretary. The Nominating Committee Director Removal Petition Notice shall include the rationale upon which removal of the affected Director is sought. The Nominating Committee Director Removal Process shall thereafter continue pursuant to Section 3.1(d) of this Annex D.

(ii) If the EC Administration has not received a Nominating Committee Director Removal Petition Notice pursuant to Section 3.1(c)(i) of this Annex D during the Nominating Committee Director Removal Petition Period, the Nominating Committee Director Removal Process shall automatically be terminated with respect to the applicable Nominating Committee Director Removal Petition and the EC Administration shall, within twenty-four (24) hours of the expiration of the Nominating Committee Director Removal Petition Period, deliver to the Secretary a notice certifying that the Nominating Committee Director Removal Process has been terminated with respect to the applicable Nominating Committee Director Removal Petition ("Nominating Committee Director Removal Process Termination Notice").

(d) Following the delivery of a Nominating Committee Director Removal Petition Notice to the EC Administration by a Nominating Committee Director Removal Petitioning Decisional Participant pursuant to Section 3.1(c)(i) of this Annex D, the Nominating Committee Director Removal Petitioning Decisional Participant shall contact the EC Administration and the other Decisional Participants to determine whether any other Decisional Participants support the Nominating Committee Director Removal Petition. The Nominating Committee Director Removal Petitioning Decisional Participant shall forward such communication to the Secretary for ICANN to promptly post on the Website.

(i) If the Nominating Committee Director Removal Petitioning Decisional Participant obtains the support of at least one other Decisional Participant (a "Nominating Committee Director Removal Supporting Decisional Participant") during the period beginning upon the expiration of the Nominating Committee Director Removal Petition Period and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 7th day after the expiration of the Nominating Committee Director Removal Petition Period (the "Nominating Committee Director Removal Petition Support Period"), the Nominating Committee Director Removal Petitioning Decisional Participant shall provide a written notice to the EC Administration, the other Decisional Participants and the Secretary ("Nominating Committee Director Removal Supported Petition") within twenty-four (24) hours of receiving the support of at least one Nominating Committee Director Removal Supporting Decisional Participant. Each Nominating Committee Director Removal Supporting Decisional Participant shall provide a written notice to the EC Administration, the other Decisional Participants and the Secretary within twenty-four (24) hours of providing support to the Nominating Committee Director Removal Petition. SuchNominating Committee Director Removal Supported Petition shall include:

(A) a supporting rationale in reasonable detail;

(B) contact information for at least one representative who has been designated by the Nominating Committee Director Removal Petitioning Decisional Participant who shall act as a liaison with respect to the Nominating Committee Director Removal Supported Petition;

(C) a statement as to whether or not the Nominating Committee Director Removal Petitioning Decisional Participant and/or the Nominating Committee Director Removal Supporting Decisional Participant requests that ICANN organize a publicly-available conference call prior to the Nominating Committee Director Removal Community Forum (as defined in Section 3.1(e) of this Annex D) for the community to discuss the Nominating Committee Director Removal Supported Petition; and

(D) a statement as to whether the Nominating Committee Director Removal Petitioning Decisional Participant and the Nominating Committee Director Removal Supporting Decisional Participant have determined to hold the Nominating Committee Director Removal Community Forum during the next scheduled ICANN public meeting.

The Nominating Committee Director Removal Process shall thereafter continue for such Nominating Committee Director Removal Petition pursuant to Section 3.1(e) of this Annex D.

(ii) The Nominating Committee Director Removal Process shall automatically be terminated and the EC Administration shall, within twenty-four (24) hours of the expiration of the Nominating Committee Director Removal Petition Support Period, deliver to the Secretary a Nominating Committee Director Removal Process Termination Notice if the Nominating Committee Director Removal Petitioning Decisional Participant is unable to obtain the support of at least one other Decisional Participant for its Nominating Committee Director Removal Petition during the Nominating Committee Director Removal Petition Support Period.

(e) If the EC Administration receives a Nominating Committee Director Removal Supported Petition under Section 3.1(d) of this Annex D during the Nominating Committee Director Removal Petition Support Period, ICANN shall, at the direction of the EC Administration, convene a forum at which the Decisional Participants and interested parties may discuss the Nominating Committee Director Removal Supported Petition ("Nominating Committee Director Removal Community Forum").

(i) If a publicly-available conference call has been requested in a Nominating Committee Director Removal Supported Petition, ICANN shall, at the direction of the EC Administration, schedule such call prior to any Nominating Committee Director Removal Community Forum, and inform the Decisional Participants of the date, time and participation methods of such conference call, which ICANN shall promptly post on the Website. The date and time of any such conference call shall be determined after consultation with the Director who is the subject of the Nominating Committee Director Removal Supported Petition regarding his or her availability.

(ii) The Nominating Committee Director Removal Community Forum shall be convened and concluded during the period beginning upon the expiration of the Nominating Committee Director Removal Petition Support Period and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the Nominating Committee Director Removal Petition Support Period ( "Nominating Committee Director Removal Community Forum Period") unless the Nominating Committee Director Removal Supported Petition requested that the Nominating Committee Director Removal Community Forum be held during the next scheduled ICANN public meeting, in which case the Nominating Committee Director Removal Community Forum shall be held during the next scheduled ICANN public meeting on the date and at the time determined by ICANN, taking into account any date and/or time requested by the Nominating Committee Director Removal Petitioning Decisional Participant and the Nominating Committee Director Removal Supporting Decisional Participant(s); provided, that, the date and time of any Nominating Committee Director Removal Community Forum shall be determined after consultation with the Director who is the subject of the Nominating Committee Director Removal Supported Petition regarding his or her availability. If the Nominating Committee Director Removal Community Forum is held during the next scheduled ICANN public meeting and that public meeting is held after 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the Nominating Committee Director Removal Petition Support Period, the Nominating Committee Director Removal Community Forum Period shall expire at 11:59 p.m., local time of the city hosting such ICANN public meeting on the official last day of such ICANN public meeting.

(iii) The Nominating Committee Director Removal Community Forum shall be conducted via remote participation methods such as teleconference, web-based meeting room and/or such other form of remote participation as the EC Administration selects, and/or, only if the Nominating Committee Director Removal Community Forum is held during an ICANN public meeting, face-to-face meetings. If the Nominating Committee Director Removal Community Forum will not be held during an ICANN public meeting, the EC Administration shall promptly inform ICANN of the date, time and participation methods of the Nominating Committee Director Removal Community Forum, which ICANN shall promptly post on the Website.

(iv) The EC Administration shall manage and moderate the Nominating Committee Director Removal Community Forum in a fair and neutral manner; provided that no individual from the Nominating Committee Director Removal Petitioning Decisional Participant or the Nominating Committee Director Removal Supporting Decisional Participant, nor the individual who initiated the Nominating Committee Director Removal Petition, shall be permitted to participate in the management or moderation of the Nominating Committee Director Removal Community Forum.

(v) The Director subject to the Nominating Committee Director Removal Supported Petition, ICANN and any Supporting Organization or Advisory Committee (including Decisional Participants) may deliver to the EC Administration in writing its views and questions on the Nominating Committee Director Removal Supported Petition prior to the convening of and during the Nominating Committee Director Removal Community Forum. Any written materials delivered to the EC Administration shall also be delivered to the Secretary for prompt posting on the Website in a manner deemed appropriate by ICANN.

(vi) The Director who is the subject of the Nominating Committee Director Removal Supported Petition and the Chair of the Board (or the Vice Chair of the Board if the Chair is the affected Director) are expected to attend the Nominating Committee Director Removal Community Forum in order to address the issues raised in the Nominating Committee Director Removal Supported Petition.

(vii) If the Nominating Committee Director Removal Petitioning Decisional Participant and each of the Nominating Committee Director Removal Supporting Decisional Participants for an applicable Nominating Committee Director Removal Supported Petition agree before, during or after the Nominating Committee Director Removal Community Forum that the issue raised in such Nominating Committee Director Removal Supported Petition has been resolved, such Nominating Committee Director Removal Supported Petition shall be deemed withdrawn and the Nominating Committee Director Removal Process with respect to such Nominating Committee Director Removal Supported Petition will be terminated. If a Nominating Committee Director Removal Process is terminated, the EC Administration shall, within twenty-four (24) hours of the resolution of the issue raised in the Nominating Committee Director Removal Supported Petition, deliver to the Secretary a Nominating Committee Director Removal Process Termination Notice. For the avoidance of doubt, the Nominating Committee Director Removal Community Forum is not a decisional body and the foregoing resolution process shall be handled pursuant to the internal procedures of the Nominating Committee Director Removal Petitioning Decisional Participant and the Nominating Committee Director Removal Supporting Decisional Participant(s).

(viii) During the Nominating Committee Director Removal Community Forum Period, an additional one or two Nominating Committee Director Removal Community Forums may be held at the discretion of a Nominating Committee Director Removal Petitioning Decisional Participant and a related Nominating Committee Director Removal Supporting Decisional Participant, or the EC Administration.

(ix) ICANN will provide support services for the Nominating Committee Director Removal Community Forum and shall promptly post on the Website a public record of the Nominating Committee Director Removal Community Forum as well as all written submissions of the Director who is the subject of the Nominating Committee Director Removal Supported Petition, ICANN and any Supporting Organization or Advisory Committee (including Decisional Participants) related to the Nominating Committee Director Removal Community Forum.

(f) Following the expiration of the Nominating Committee Director Removal Community Forum Period, at any time or date prior to 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the Nominating Committee Director Removal Community Forum Period (such period, the "Nominating Committee Director Removal Decision Period"), each Decisional Participant shall inform the EC Administration in writing as to whether such Decisional Participant (i) supports such Nominating Committee Director Removal Supported Petition, (ii) objects to such Nominating Committee Director Removal Supported Petition or (iii) has determined to abstain from the matter (which shall not count as supporting or objecting to the Nominating Committee Director Removal Supported Petition), and each Decisional Participant shall forward such notice to the Secretary for ICANN to promptly post on the Website. If a Decisional Participant does not inform the EC Administration of any of the foregoing prior to the expiration of the Nominating Committee Director Removal Decision Period, the Decisional Participant shall be deemed to have abstained from the matter (even if such Decisional Participant informs the EC Administration of its support or objection following the expiration of the Nominating Committee Director Removal Decision Period).

(g) The EC Administration shall, within twenty-four (24) hours of the expiration of the Nominating Committee Director Removal Decision Period, deliver a written notice ("Nominating Committee Director Removal Notice") to the Secretary certifying that, pursuant to and in compliance with the procedures and requirements of Section 3.1 of this Annex D, the EC has approved of the removal of the Director who is subject to the Nominating Committee Director Removal Process if the Nominating Committee Director Removal Supported Petition is (i) supported by three or more Decisional Participants and (ii) not objected to by more than one Decisional Participant.

(h) Upon the Secretary's receipt of a Nominating Committee Director Removal Notice, the Director subject to such Nominating Committee Director Removal Notice shall be effectively removed from office and shall no longer be a Director and such Director's vacancy shall be filled in accordance with Section 7.12 of the Bylaws.

(i) If the Nominating Committee Director Removal Supported Petition does not obtain the support required by Section 3.1(g) of this Annex D, the Nominating Committee Director Removal Process will automatically be terminated and the EC Administration shall, within twenty-four (24) hours of the expiration of the Nominating Committee Director Removal Decision Period, deliver to the Secretary a Nominating Committee Director Removal Process Termination Notice. The Director who was subject to the Nominating Committee Director Removal Process shall remain on the Board and not be subject to the Nominating Committee Director Removal Process for the remainder of the Director's current term.

(j) If neither a Nominating Committee Director Removal Notice nor a Nominating Committee Director Removal Process Termination Notice are received by the Secretary prior to 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the Nominating Committee Director Removal Community Forum Period, the Nominating Committee Director Removal Process shall automatically terminate and the Director who was subject to the Nominating Committee Director Removal Process shall remain on the Board and shall not be subject to the Nominating Committee Director Removal Process for the remainder of the Director's current term.

(k) Notwithstanding anything in this Section 3.1 to the contrary, if, for any reason, including due to resignation, death or disability, a Director who is the subject of a Nominating Committee Director Removal Process ceases to be a Director, the Nominating Committee Director Removal Process for such Director shall automatically terminate without any further action of ICANN or the EC Administration.

(l) ICANN shall promptly post to the Website any (i) Nominating Committee Director Removal Petition, (ii) Nominating Committee Director Removal Petition Notice, (iii) Nominating Committee Director Removal Supported Petition, (iv) Nominating Committee Director Removal Notice and the written explanation provided by the EC Administration as to why the EC has chosen to remove the relevant Director, (v) Nominating Committee Director Removal Process Termination Notice, and (vi) other notices the Secretary receives under this Section 3.1.

Section 3.2. SO/AC DIRECTOR REMOVAL PROCESS

(a) Subject to the procedures and requirements developed by the applicable Decisional Participant, an individual may submit a petition to the ASO, ccNSO, GNSO or At-Large Community (as applicable, the "Applicable Decisional Participant") seeking to remove a Director who was nominated by that Supporting Organization or the At-Large Community in accordance with Section 7.2(a) of the Bylaws, and initiate the SO/AC Director Removal Process ("SO/AC Director Removal Petition"). The process set forth in this Section 3.2 of this Annex D is referred to herein as the "SO/AC Director Removal Process."

(b) During the period beginning on the date that the Applicable Decisional Participant received the SO/AC Director Removal Petition (such date of receipt, the "SO/AC Director Removal Petition Date") and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the date that is the 21st day after the SO/AC Director Removal Petition Date (as it relates to a particular Director, the "SO/AC Director Removal Petition Period"), the Applicable Decisional Participant shall either accept or reject such SO/AC Director Removal Petition pursuant to the internal procedures of the Applicable Decisional Participant for the SO/AC Director Removal Petition; provided that the Applicable Decisional Participant shall not accept an SO/AC Director Removal Petition if, during the same term, the Director who is the subject of such SO/AC Director Removal Petition had previously been subject to an SO/AC Director Removal Petition that led to an SO/AC Director Removal Community Forum (as defined in Section 3.2(d) of this Annex D).

(c) During the SO/AC Director Removal Petition Period, the Applicable Decisional Participant shall invite the Director subject to the SO/AC Director Removal Petition and the Chair of the Board (or the Vice Chair of the Board if the Chair is the affected Director) to a dialogue with the individual(s) bringing the SO/AC Director Removal Petition and the Applicable Decisional Participant's representative on the EC Administration. The SO/AC Director Removal Petition may not be accepted unless this invitation has been extended upon reasonable notice and accommodation to the affected Director's availability. If the invitation is accepted by either the Director who is the subject of the SO/AC Director Removal Petition or the Chair of the Board (or the Vice Chair of the Board if the Chair is the affected Director), the Applicable Decisional Participant shall not accept the SO/AC Director Removal Petition until the dialogue has occurred or there have been reasonable efforts to have the dialogue.

(i) If, in accordance with Section 3.2(b), the Applicable Decisional Participant accepts an SO/AC Director Removal Petition during the SO/AC Director Removal Petition Period, the Applicable Decisional Participant shall, within twenty-four (24) hours of the Applicable Decisional Participant's acceptance of the SO/AC Director Removal Petition, provide written notice ("SO/AC Director Removal Petition Notice") of such acceptance to the EC Administration, the other Decisional Participants and the Secretary. SuchSO/AC Director Removal Petition Notice shall include:

(A) a supporting rationale in reasonable detail;

(B) contact information for at least one representative who has been designated by the Applicable Decisional Participant who shall act as a liaison with respect to the SO/AC Director Removal Petition Notice;

(C) a statement as to whether or not the Applicable Decisional Participant requests that ICANN organize a publicly-available conference call prior to the SO/AC Director Removal Community Forum (as defined in Section 3.2(d) of this Annex D) for the community to discuss the SO/AC Director Removal Petition; and

(D) a statement as to whether the Applicable Decisional Participant has determined to hold the SO/AC Director Removal Community Forum during the next scheduled ICANN public meeting.

The SO/AC Director Removal Process shall thereafter continue for such SO/AC Director Removal Petition pursuant to Section 3.2(d) of this Annex D.

(ii) If the EC Administration has not received an SO/AC Director Removal Petition Notice pursuant to Section 3.2(c)(i) during the SO/AC Director Removal Petition Period, the SO/AC Director Removal Process shall automatically be terminated with respect to the applicable SO/AC Director Removal Petition and the EC Administration shall, within twenty-four (24) hours of the expiration of the SO/AC Director Removal Petition Period, deliver to the Secretary a notice certifying that the SO/AC Director Removal Process has been terminated with respect to the applicable SO/AC Director Removal Petition ("SO/AC Director Removal Process Termination Notice").

(d) If the EC Administration receives an SO/AC Director Removal Petition Notice under Section 3.2(c) of this Annex D during the SO/AC Director Removal Petition Period, ICANN shall, at the direction of the EC Administration, convene a forum at which the Decisional Participants and interested parties may discuss the SO/AC Director Removal Petition Notice ("SO/AC Director Removal Community Forum").

(i) If a publicly-available conference call has been requested in an SO/AC Director Removal Petition Notice, ICANN shall, at the direction of the EC Administration, schedule such call prior to any SO/AC Director Removal Community Forum, and inform the Decisional Participants of the date, time and participation methods of such conference call, which ICANN shall promptly post on the Website. The date and time of any such conference call shall be determined after consultation with the Director who is the subject of the SO/AC Director Removal Petition Notice regarding his or her availability.

(ii) The SO/AC Director Removal Community Forum shall be convened and concluded during the period beginning upon the expiration of the SO/AC Director Removal Petition Period and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the SO/AC Director Removal Petition Period ( "SO/AC Director Removal Community Forum Period") unless the SO/AC Director Removal Petition Notice requested that the SO/AC Director Removal Community Forum be held during the next scheduled ICANN public meeting, in which case the SO/AC Director Removal Community Forum shall be held during the next scheduled ICANN public meeting on the date and at the time determined by ICANN, taking into account any date and/or time requested by the Applicable Decisional Participant; provided, that the date and time of any SO/AC Director Removal Community Forum shall be determined after consultation with the Director who is the subject of the SO/AC Director Removal Petition Notice regarding his or her availability. If the SO/AC Director Removal Community Forum is held during the next scheduled ICANN public meeting and that public meeting is held after 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the SO/AC Director Removal Petition Period, the SO/AC Director Removal Community Forum Period shall expire at 11:59 p.m., local time of the city hosting such ICANN public meeting on the official last day of such ICANN public meeting.

(iii) The SO/AC Director Removal Community Forum shall be conducted via remote participation methods such as teleconference, web-based meeting room and/or such other form of remote participation as the EC Administration selects, and/or, only if the SO/AC Director Removal Community Forum is held during an ICANN public meeting, face-to-face meetings. If the SO/AC Director Removal Community Forum will not be held during an ICANN public meeting, the EC Administration shall promptly inform ICANN of the date, time and participation methods of the SO/AC Director Removal Community Forum, which ICANN shall promptly post on the Website.

(iv) The EC Administration shall manage and moderate the SO/AC Director Removal Community Forum in a fair and neutral manner; provided that no individual from the Applicable Decisional Participant, nor the individual who initiated the SO/AC Director Removal Petition, shall be permitted to participate in the management or moderation of the SO/AC Director Removal Community Forum.

(v) The Director subject to the SO/AC Director Removal Petition Notice, ICANN and any Supporting Organization or Advisory Committee (including Decisional Participants) may deliver to the EC Administration in writing its views and questions on the SO/AC Director Removal Petition Notice prior to the convening of and during the SO/AC Director Removal Community Forum. Any written materials delivered to the EC Administration shall also be delivered to the Secretary for prompt posting on the Website in a manner deemed appropriate by ICANN.

(vi) The Director who is the subject of the SO/AC Director Removal Petition Notice and the Chair of the Board (or the Vice Chair of the Board if the Chair is the affected Director) are expected to attend the SO/AC Director Removal Community Forum in order to address the issues raised in the SO/AC Director Removal Petition Notice.

(vii) If the Applicable Decisional Participant agrees before, during or after the SO/AC Director Removal Community Forum that the issue raised in such SO/AC Director Removal Petition Notice has been resolved, such SO/AC Director Removal Petition Notice shall be deemed withdrawn and the SO/AC Director Removal Process with respect to such SO/AC Director Removal Petition Notice will be terminated. If an SO/AC Director Removal Process is terminated, the EC Administration shall, within twenty-four (24) hours of the resolution of the issue raised in the SO/AC Director Removal Petition Notice, deliver to the Secretary an SO/AC Director Removal Process Termination Notice. For the avoidance of doubt, the SO/AC Director Removal Community Forum is not a decisional body and the foregoing resolution process shall be handled pursuant to the internal procedures of the Applicable Decisional Participant.

(viii) During the SO/AC Director Removal Community Forum Period, an additional one or two SO/AC Director Removal Community Forums may be held at the discretion of the Applicable Decisional Participant or the EC Administration.

(ix) ICANN will provide support services for the SO/AC Director Removal Community Forum and shall promptly post on the Website a public record of the SO/AC Director Removal Community Forum as well as all written submissions of the Director who is the subject of the SO/AC Director Removal Petition Notice, ICANN and any Supporting Organization or Advisory Committee (including Decisional Participants) related to the SO/AC Director Removal Community Forum.

(e) Following the expiration of the SO/AC Director Removal Community Forum Period, ICANN shall, at the request of the EC Administration, issue a request for comments and recommendations from the community, which shall be delivered to the Secretary for prompt posting on the Website along with a means for comments and recommendations to be submitted to ICANN on behalf of the EC Administration. This comment period shall remain open until 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 7th day after the request for comments and recommendations was posted on the Website (the "SO/AC Director Removal Comment Period"). ICANN shall promptly post on the Website all comments and recommendations received by ICANN during the SO/AC Director Removal Comment Period.

(f) Following the expiration of the SO/AC Director Removal Comment Period, at any time or date prior to 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the SO/AC Director Removal Comment Period (such period, the "SO/AC Director Removal Decision Period"), the Applicable Decisional Participant shall inform the EC Administration in writing as to whether the Applicable Decisional Participant has support for the SO/AC Director Removal Petition Notice within the Applicable Decisional Participant of a three-quarters majority as determined pursuant to the internal procedures of the Applicable Decisional Participant ("SO/AC Director Removal Notice"). The Applicable Decisional Participant shall, within twenty-four (24) hours of obtaining such support, deliver the SO/AC Director Removal Notice to the EC Administration, the other Decisional Participants and Secretary, and ICANN shall, at the direction of the Applicable Decisional Participant, concurrently post on the Website an explanation provided by the Applicable Decisional Participant as to why the Applicable Decisional Participant has chosen to remove the affected Director. Upon the Secretary's receipt of the SO/AC Director Removal Notice from the EC Administration, the Director subject to such SO/AC Director Removal Notice shall be effectively removed from office and shall no longer be a Director and such Director's vacancy shall be filled in accordance with Section 7.12 of the Bylaws.

(g) If the SO/AC Director Removal Petition Notice does not obtain the support required by Section 3.2(f) of this Annex D, the SO/AC Director Removal Process will automatically be terminated and the EC Administration shall, within twenty-four (24) hours of the failure to obtain such support, deliver to the Secretary an SO/AC Director Removal Process Termination Notice. The Director who was subject to the SO/AC Director Removal Process shall remain on the Board and shall not be subject to the SO/AC Director Removal Process for the remainder of the Director's current term.

(h) If neither an SO/AC Director Removal Notice nor an SO/AC Director Removal Process Termination Notice are received by the Secretary prior to the expiration of the SO/AC Director Removal Decision Period, the SO/AC Director Removal Process shall automatically terminate and the Director who was subject to the SO/AC Director Removal Process shall remain on the Board and shall not be subject to the SO/AC Director Removal Process for the remainder of the Director's current term.

(i) Notwithstanding anything in this Section 3.2 to the contrary, if, for any reason, including due to resignation, death or disability, a Director who is the subject of an SO/AC Director Removal Process ceases to be a Director, the SO/AC Director Removal Process for such Director shall automatically terminate without any further action of ICANN or the EC Administration.

(j) ICANN shall promptly post to the Website any (i) SO/AC Director Removal Petition, (ii) SO/AC Director Removal Petition Notice, (iii) SO/AC Director Removal Notice and the written explanation provided by the EC Administration as to why the EC has chosen to remove the relevant Director, (iv) SO/AC Director Removal Process Termination Notice, and (v) other notices the Secretary receives under this Section 3.2.

Section 3.3. BOARD RECALL PROCESS

(a) Subject to the procedures and requirements developed by the applicable Decisional Participant, an individual may submit a petition to a Decisional Participant seeking to remove all Directors (other than the President) at the same time and initiate the Board Recall Process ("Board Recall Petition"), provided that a Board Recall Petition cannot be submitted solely on the basis of a matter decided by a Community IRP if (i) such Community IRP was initiated in connection with the Board's implementation of GAC Consensus Advice and (ii) the EC did not prevail in such Community IRP. Each Board Recall Petition shall include a rationale setting forth the reasons why such individual seeks to recall the Board. The process set forth in this Section 3.3 of this Annex D is referred to herein as the "Board Recall Process."

(b) A Decisional Participant that has received a Board Recall Petition shall either accept or reject such Board Recall Petition during the period beginning on the date the Decisional Participant received the Board Recall Petition ("Board Recall Petition Date") and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the date that is the 21st day after the Board Recall Petition Date (the "Board Recall Petition Period").

(i) If, in accordance with Section 3.3(b) of this Annex D, a Decisional Participant accepts a Board Recall Petition during the Board Recall Petition Period (such Decisional Participant, the "Board Recall Petitioning Decisional Participant"), the Board Recall Petitioning Decisional Participant shall, within twenty-four (24) hours of the expiration of its acceptance of the Board Recall Petition, provide written notice ("Board Recall Petition Notice") of such acceptance to the EC Administration, the other Decisional Participants and the Secretary. The Board Recall Petition Notice shall include the rationale upon which removal of the Board is sought. The Board Recall Process shall thereafter continue pursuant to Section 3.3(c) of this Annex D.

(ii) If the EC Administration has not received a Board Recall Petition Notice pursuant to Section 3.3(b)(i) of this Annex D during the Board Recall Petition Period, the Board Recall Process shall automatically be terminated with respect to the Board Recall Petition and the EC Administration shall, within twenty-four (24) hours of the expiration of the Board Recall Petition Period, deliver to the Secretary a notice certifying that the Board Recall Process has been terminated with respect to the Board Recall Petition ("Board Recall Process Termination Notice").

(c) Following the delivery of a Board Recall Petition Notice to the EC Administration by a Board Recall Petitioning Decisional Participant pursuant to Section 3.3(b)(i) of this Annex D, the Board Recall Petitioning Decisional Participant shall contact the EC Administration and the other Decisional Participants to determine whether any other Decisional Participants support the Board Recall Petition. The Board Recall Petitioning Decisional Participant shall forward such communication to the Secretary for ICANN to promptly post on the Website.

(i) If the Board Recall Petitioning Decisional Participant obtains the support of at least two other Decisional Participants (each, a "Board Recall Supporting Decisional Participant") during the period beginning upon the expiration of the Board Recall Petition Period and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 7th day after the expiration of the Board Recall Petition Period (the "Board Recall Petition Support Period"), the Board Recall Petitioning Decisional Participant shall provide a written notice to the EC Administration, the other Decisional Participants and the Secretary ("Board Recall Supported Petition") within twenty-four hours of receiving the support of at least two Board Recall Supporting Decisional Participants. Each Board Recall Supporting Decisional Participant shall provide a written notice to the EC Administration, the other Decisional Participants and the Secretary within twenty-four (24) hours of providing support to the Board Recall Petition. SuchBoard Recall Supported Petition shall include:

(A) a supporting rationale in reasonable detail;

(B) contact information for at least one representative who has been designated by the Board Recall Petitioning Decisional Participant who shall act as a liaison with respect to the Board Recall Supported Petition;

(C) a statement as to whether or not the Board Recall Petitioning Decisional Participant and/or the Board Recall Supporting Decisional Participants requests that ICANN organize a publicly-available conference call prior to the Board Recall Community Forum (as defined in Section 3.3(d) of this Annex D) for the community to discuss the Board Recall Supported Petition; and

(D) a statement as to whether the Board Recall Petitioning Decisional Participant and the Board Recall Supporting Decisional Participants have determined to hold the Board Recall Community Forum during the next scheduled ICANN public meeting.

The Board Recall Process shall thereafter continue for such Board Recall Supported Petition pursuant to Section 3.3(d) of this Annex D.

(ii) The Board Recall Process shall automatically be terminated and the EC Administration shall, within twenty-four (24) hours of the expiration of the Board Recall Petition Support Period, deliver to the Secretary a Board Recall Process Termination Notice if the Board Recall Petitioning Decisional Participant is unable to obtain the support of at least two other Decisional Participants for its Board Recall Petition during the Board Recall Petition Support Period.

(d) If the EC Administration receives a Board Recall Supported Petition under Section 3.3(c) of this Annex D during the Board Recall Petition Support Period, ICANN shall, at the direction of the EC Administration, convene a forum at which the Decisional Participants and interested parties may discuss the Board Recall Supported Petition ("Board Recall Community Forum").

(i) If a publicly-available conference call has been requested in a Board Recall Supported Petition, ICANN shall, at the direction of the EC Administration, schedule such call prior to any Board Recall Community Forum, and inform the Decisional Participants of the date, time and participation methods of such conference call, which ICANN shall promptly post on the Website. The date and time of any such conference call shall be determined after consultation with the Board regarding the availability of the Directors.

(ii) The Board Recall Community Forum shall be convened and concluded during the period beginning upon the expiration of the Board Recall Petition Support Period and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the Board Recall Petition Support Period ( "Board Recall Community Forum Period") unless the Board Recall Supported Petition requested that the Board Recall Community Forum be held during the next scheduled ICANN public meeting, in which case the Board Recall Community Forum shall be held during the next scheduled ICANN public meeting on the date and at the time determined by ICANN, taking into account any date and/or time requested by the Board Recall Petitioning Decisional Participant and the Board Recall Supporting Decisional Participants; provided, that, the date and time of any Board Recall Community Forum shall be determined after consultation with the Board regarding the availability of the Directors. If the Board Recall Community Forum is held during the next scheduled ICANN public meeting and that public meeting is held after 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the Board Recall Petition Support Period, the Board Recall Community Forum Period shall expire at 11:59 p.m., local time of the city hosting such ICANN public meeting on the official last day of such ICANN public meeting.

(iii) The Board Recall Community Forum shall have at least one face-to-face meeting and may also be conducted via remote participation methods such as teleconference, web-based meeting room and/or such other form of remote participation as the EC Administration selects. If the Board Recall Community Forum will not be held during an ICANN public meeting, the EC Administration shall promptly inform ICANN of the date, time and participation methods of the Board Recall Community Forum, which ICANN shall promptly post on the Website.

(iv) The EC Administration shall manage and moderate the Board Recall Community Forum in a fair and neutral manner; provided that no individual from the Board Recall Petitioning Decisional Participant or a Board Recall Supporting Decisional Participant, nor the individual who initiated the Board Recall Petition, shall be permitted to participate in the management or moderation of the Board Recall Community Forum.

(v) ICANN and any Supporting Organization or Advisory Committee (including Decisional Participants) may deliver to the EC Administration in writing its views and questions on the Board Recall Supported Petition prior to the convening of and during the Board Recall Community Forum. Any written materials delivered to the EC Administration shall also be delivered to the Secretary for prompt posting on the Website in a manner deemed appropriate by ICANN.

(vi) ICANN staff and the full Board are expected to attend the Board Recall Community Forum in order to address the issues raised in the Board Recall Supported Petition.

(vii) If the Board Recall Petitioning Decisional Participant and each of the Board Recall Supporting Decisional Participants for the Board Recall Supported Petition agree before, during or after the Board Recall Community Forum that the issue raised in such Board Recall Supported Petition has been resolved, such Board Recall Supported Petition shall be deemed withdrawn and the Board Recall Process with respect to such Board Recall Supported Petition will be terminated. If a Board Recall Process is terminated, the EC Administration shall, within twenty-four (24) hours of the resolution of the issue raised in the Board Recall Supported Petition, deliver to the Secretary a Board Recall Process Termination Notice. For the avoidance of doubt, the Board Recall Community Forum is not a decisional body and the foregoing resolution process shall be handled pursuant to the internal procedures of the Board Recall Petitioning Decisional Participant and the Board Recall Supporting Decisional Participants.

(viii) During the Board Recall Community Forum Period, an additional one or two Board Recall Community Forums may be held at the discretion of the Board Recall Petitioning Decisional Participant and the Board Recall Supporting Decisional Participants, or the EC Administration.

(ix) ICANN will provide support services for the Board Recall Community Forum and shall promptly post on the Website a public record of the Board Recall Community Forum as well as all written submissions of ICANN and any Supporting Organization or Advisory Committee (including Decisional Participants) related to the Board Recall Community Forum.

(e) Following the expiration of the Board Recall Community Forum Period, at any time or date prior to 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the Board Recall Community Forum Period (such period, the "Board Recall Decision Period"), each Decisional Participant shall inform the EC Administration in writing as to whether such Decisional Participant (i) supports such Board Recall Supported Petition, (ii) objects to such Board Recall Supported Petition or (iii) has determined to abstain from the matter (which shall not count as supporting or objecting to such Board Recall Supported Petition), and each Decisional Participant shall forward such notice to the Secretary for ICANN to promptly post on the Website. If a Decisional Participant does not inform the EC Administration of any of the foregoing prior to expiration of the Board Recall Decision Period, the Decisional Participant shall be deemed to have abstained from the matter (even if such Decisional Participant informs the EC Administration of its support or objection following the expiration of the Board Recall Decision Period).

(f) The EC Administration shall, within twenty-four (24) hours of the expiration of the Board Recall Decision Period, deliver a written notice ("EC Board Recall Notice") to the Secretary certifying that, pursuant to and in compliance with the procedures and requirements of this Section 3.3 of this Annex D, the EC has resolved to remove all Directors (other than the President) if (after accounting for any adjustments to the below as required by the GAC Carve-out pursuant to Section 3.6(e) of the Bylaws if an IRP Panel found that, in implementing GAC Consensus Advice, the Board acted inconsistently with the Articles or Bylaws) a Board Recall Supported Petition (i) is supported by four or more Decisional Participants, and (ii) is not objected to by more than one Decisional Participant.

(g) Upon the Secretary's receipt of an EC Board Recall Notice, all Directors (other than the President) shall be effectively removed from office and shall no longer be Directors and such vacancies shall be filled in accordance with Section 7.12 of the Bylaws.

(h) If the Board Recall Supported Petition does not obtain the support required by Section 3.3(f) of this Annex D, the Board Recall Process will automatically be terminated and the EC Administration shall, within twenty-four (24) hours of the expiration of the Board Recall Decision Period, deliver to the Secretary a Board Recall Process Termination Notice. All Directors shall remain on the Board.

(i) If neither an EC Board Recall Notice nor a Board Recall Process Termination Notice are received by the Secretary prior to the expiration of the Board Recall Decision Period, the Board Recall Process shall automatically terminate and all Directors shall remain on the Board.

(j) ICANN shall promptly post to the Website any (i) Board Recall Petition, (ii) Board Recall Petition Notice, (iii) Board Recall Supported Petition, (iv) EC Board Recall Notice and the written explanation provided by the EC Administration as to why the EC has chosen to recall the Board, (v) Board Recall Process Termination Notice, and (vi) other notices the Secretary receives under this Section 3.3.

Article 4 PROCEDURE FOR EXERCISE OF EC'S RIGHTS TO INITIATE MEDIATION, A COMMUNITY IRP OR RECONSIDERATION REQUEST

Section 4.1. MEDIATION INITIATION

(a) If the Board refuses or fails to comply with a decision by the EC delivered to the Secretary pursuant to an EC Approval Notice, EC Rejection Notice, Nominating Committee Director Removal Notice, SO/AC Director Removal Notice or EC Board Recall Notice pursuant to and in compliance with Article 1, Article 2 or Article 3 of this Annex D, or rejects or otherwise does not take action that is consistent with a final IFR Recommendation, Special IFR Recommendation, SCWG Creation Recommendation or SCWG Recommendation, as applicable (each, an "EC Decision"), the EC Administration representative of any Decisional Participant who supported the exercise by the EC of its rights in the applicable EC Decision during the applicable decision period may request that the EC initiate mediation with the Board in relation to that EC Decision as contemplated by Section 4.7 of the Bylaws, by delivering a notice to the EC Administration, the Decisional Participants and the Secretary requesting the initiation of a mediation ("Mediation Initiation Notice"). ICANN shall promptly post to the Website any Mediation Initiation Notice.

(b) As soon as practicable after receiving a Mediation Initiation Notice, the EC Administration and the Secretary shall initiate mediation, which shall proceed in accordance with Section 4.7 of the Bylaws.

Section 4.2. COMMUNITY IRP

(a) After completion of a mediation under Section 4.7 of the Bylaws, the EC Administration representative of any Decisional Participant who supported the exercise by the EC of its rights in the applicable EC Decision during the applicable decision period may request that the EC initiate a Community IRP (a "Community IRP Petitioning Decisional Participant"), as contemplated by Section 4.3 of the Bylaws, by delivering a notice to the EC Administration and the Decisional Participants requesting the initiation of a Community IRP ("Community IRP Petition"). The Community IRP Petitioning Decisional Participant shall forward such notice to the Secretary for ICANN to promptly post on the Website. The process set forth in this Section 4.2 of this Annex D as it relates to a particular Community IRP Petition is referred to herein as the "Community IRP Initiation Process."

(b) Following the delivery of a Community IRP Petition to the EC Administration by a Community IRP Petitioning Decisional Participant pursuant to Section 4.2(a) of this Annex D (which delivery date shall be referred to herein as the "Community IRP Notification Date"), the Community IRP Petitioning Decisional Participant shall contact the EC Administration and the other Decisional Participants to determine whether any other Decisional Participants support the Community IRP Petition. The Community IRP Petitioning Decisional Participant shall forward such communication to the Secretary for ICANN to promptly post on the Website.

(i) If the Community IRP Petitioning Decisional Participant obtains the support of at least one other Decisional Participant (a "Community IRP Supporting Decisional Participant") during the period beginning on the Community IRP Notification Date and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the Community IRP Notification Date (the "Community IRP Petition Support Period"), the Community IRP Petitioning Decisional Participant shall provide a written notice to the EC Administration, the other Decisional Participants and the Secretary ("Community IRP Supported Petition") within twenty-four (24) hours of receiving the support of at least one Community IRP Supporting Decisional Participant. Each Community IRP Supporting Decisional Participant shall provide a written notice to the EC Administration, the other Decisional Participants and the Secretary within twenty-four (24) hours of providing support to the Community IRP Petition. SuchCommunity IRP Supported Petition shall include:

(A) a supporting rationale in reasonable detail;

(B) contact information for at least one representative who has been designated by the Community IRP Petitioning Decisional Participant who shall act as a liaison with respect to the Community IRP Supported Petition;

(C) a statement as to whether or not the Community IRP Petitioning Decisional Participant and/or the Community IRP Supporting Decisional Participant requests that ICANN organize a publicly-available conference call prior to the Community IRP Community Forum (as defined in Section 4.2(c) of this Annex D) for the community to discuss the Community IRP Supported Petition;

(D) a statement as to whether the Community IRP Petitioning Decisional Participant and the Community IRP Supporting Decisional Participant have determined to hold the Community IRP Community Forum during the next scheduled ICANN public meeting;

(E) where the Community IRP Supported Petition relates to a Fundamental Bylaw Amendment, a PDP Fundamental Bylaw Statement if applicable and, if so, the name of the Fundamental Bylaw Amendment PDP Decisional Participant;

(F)where the Community IRP Supported Petition relates to an Articles Amendment, a PDP Articles Statement if applicable and, if so, the name of the Articles Amendment PDP Decisional Participant;

(G)where the Community IRP Supported Petition relates to a Standard Bylaw Amendment, a PDP Standard Bylaw Statement if applicable and, if so, the name of the Standard Bylaw Amendment PDP Decisional Participant; and

(H) where the Community IRP Supported Petition relates to a policy recommendation of a cross community working group chartered by more than one Supporting Organization ("CCWG Policy Recommendation"), a statement citing the specific CCWG Policy Recommendation and related provision in the Community IRP Supported Petition ("CCWG Policy Recommendation Statement"), and, if so, the name of any Supporting Organization that is a Decisional Participant that approved the CCWG Policy Recommendation ("CCWG Policy Recommendation Decisional Participant").

The Community IRP Initiation Process shall thereafter continue for such Community IRP Supported Petition pursuant to Section 4.2(c) of this Annex D.

(ii) The Community IRP Initiation Process shall automatically be terminated and the EC Administration shall, within twenty-four (24) hours of the expiration of the Community IRP Petition Support Period, deliver to the Secretary a notice certifying that the Community IRP Initiation Process has been terminated with respect to the Community IRP included in the Community IRP Petition ("Community IRP Termination Notice") if:

(A) no Community IRP Petitioning Decisional Participant is able to obtain the support of at least one other Decisional Participant for its Community IRP Petition during the Community IRP Petition Support Period;

(B) where the Community IRP Supported Petition includes a PDP Fundamental Bylaw Statement, the Fundamental Bylaw Amendment PDP Decisional Participant is not (x) the Community IRP Petitioning Decisional Participant or (y) one of the Community IRP Supporting Decisional Participants;

(C)where the Community IRP Supported Petition includes a PDP Articles Statement, the Articles Amendment PDP Decisional Participant is not (x) the Community IRP Petitioning Decisional Participant or (y) one of the Community IRP Supporting Decisional Participants;

(D)where the Community IRP Supported Petition includes a PDP Standard Bylaw Statement, the Standard Bylaw Amendment PDP Decisional Participant is not (x) the Community IRP Petitioning Decisional Participant or (y) one of the Community IRP Supporting Decisional Participants; or

(E) where the Community IRP Supported Petition includes a CCWG Policy Recommendation Statement, the CCWG Policy Recommendation Decisional Participant is not (x) the Community IRP Petitioning Decisional Participant or (y) one of the Community IRP Supporting Decisional Participants.

(c) If the EC Administration receives a Community IRP Supported Petition under Section 4.2(b) of this Annex D during the Community IRP Petition Support Period, ICANN shall, at the direction of the EC Administration, convene a forum at which the Decisional Participants and interested third parties may discuss the Community IRP Supported Petition ("Community IRP Community Forum").

(i) If a publicly-available conference call has been requested in a Community IRP Supported Petition, ICANN shall, at the direction of the EC Administration, schedule such call prior to any Community IRP Community Forum, and inform the Decisional Participants of the date, time and participation methods of such conference call, which ICANN shall promptly post on the Website.

(ii) The Community IRP Community Forum shall be convened and concluded during the period beginning on the expiration of the Community IRP Petition Support Period and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 30th day after the expiration of the Community IRP Petition Support Period ("Community IRP Community Forum Period") unless the Community IRP Supported Petition requested that the Community IRP Community Forum be held during the next scheduled ICANN public meeting, in which case the Community IRP Community Forum shall be held during the next scheduled ICANN public meeting on the date and at the time determined by ICANN, taking into account any date and/or time requested by the Community IRP Petitioning Decisional Participant and the Community IRP Supporting Decisional Participant(s). If the Community IRP Community Forum is held during the next scheduled ICANN public meeting and that public meeting is held after 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 30th day after the expiration of the Community IRP Petition Support Period, the Community IRP Community Forum Period shall expire at 11:59 p.m., local time of the city hosting such ICANN public meeting on the official last day of such ICANN public meeting.

(iii) The Community IRP Community Forum shall be conducted via remote participation methods such as teleconference, web-based meeting room and/or such other form of remote participation as the EC Administration selects and/or, only if the Community IRP Community Forum is held during an ICANN public meeting, face-to-face meetings. If the Community IRP Community Forum will not be held during an ICANN public meeting, the EC Administration shall promptly inform ICANN of the date, time and participation methods of such Community IRP Community Forum, which ICANN shall promptly post on the Website.

(iv) The EC Administration shall manage and moderate the Community IRP Community Forum in a fair and neutral manner.

(v) ICANN and any Supporting Organization or Advisory Committee (including Decisional Participants) may deliver to the EC Administration in writing its views and questions on the Community IRP Supported Petition prior to the convening of and during the Community IRP Community Forum. Any written materials delivered to the EC Administration shall also be delivered to the Secretary for prompt posting on the Website in a manner deemed appropriate by ICANN.

(vi) ICANN staff and Directors representing the Board are expected to attend the Community IRP Community Forum in order to discuss the Community IRP Supported Petition.

(vii) If the Community IRP Petitioning Decisional Participant and each of the Community IRP Supporting Decisional Participants for the Community IRP Supported Petition agree before, during or after a Community IRP Community Forum that the issue raised in such Community IRP Supported Petition has been resolved, such Community IRP Supported Petition shall be deemed withdrawn and the Community IRP Initiation Process with respect to such Community IRP Supported Petition will be terminated. If a Community IRP Initiation Process is terminated, the EC Administration shall, within twenty-four (24) hours of the resolution of the issue raised in the Community IRP Supported Petition, deliver to the Secretary a Community IRP Termination Notice. For the avoidance of doubt, the Community IRP Community Forum is not a decisional body and the foregoing resolution process shall be handled pursuant to the internal procedures of the Community IRP Petitioning Decisional Participant and the Community IRP Supporting Decisional Participant(s).

(viii) During the Community IRP Community Forum Period, an additional one or two Community IRP Community Forums may be held at the discretion of a Community IRP Petitioning Decisional Participant and a related Community IRP Supporting Decisional Participant, or the EC Administration.

(ix) ICANN will provide support services for the Community IRP Community Forum and shall promptly post on the Website a public record of the Community IRP Community Forum as well as all written submissions of ICANN and any Supporting Organization or Advisory Committee (including Decisional Participants) related to the Community IRP Community Forum.

(d) Following the expiration of the Community IRP Community Forum Period, at any time or date prior to 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the Community IRP Community Forum Period (such period, the "Community IRP Decision Period"), each Decisional Participant shall inform the EC Administration in writing as to whether such Decisional Participant (i) supports such Community IRP Supported Petition, (ii) objects to such Community IRP Supported Petition or (iii) has determined to abstain from the matter (which shall not count as supporting or objecting to the Community IRP Supported Petition), and each Decisional Participant shall forward such notice to the Secretary for ICANN to promptly post on the Website. If a Decisional Participant does not inform the EC Administration of any of the foregoing prior to the expiration of the Community IRP Decision Period, the Decisional Participant shall be deemed to have abstained from the matter (even if such Decisional Participant informs the EC Administration of its support or objection following the expiration of the Community IRP Decision Period).

(e) The EC Administration, within twenty-four (24) hours of the expiration of the Community IRP Decision Period, shall promptly deliver a written notice ("EC Community IRP Initiation Notice") to the Secretary certifying that, pursuant to and in compliance with the procedures and requirements of this Section 4.2 of this Annex D, the EC has resolved to accept the Community IRP Supported Petition if:

(i) A Community IRP Supported Petition that does not include a PDP Fundamental Bylaw Statement, a PDP Articles Statement, a PDP Standard Bylaw Statement or a CCWG Policy Recommendation Statement (A) is supported by three or more Decisional Participants, and (B) is not objected to by more than one Decisional Participant;

(ii) A Community IRP Supported Petition that (A) includes a PDP Fundamental Bylaw Statement, (B) is supported by three or more Decisional Participants (including the Fundamental Bylaw Amendment PDP Decisional Participant), and (C) is not objected to by more than one Decisional Participant;

(iii) A Community IRP Supported Petition that (A) includes a PDP Articles Statement, (B) is supported by three or more Decisional Participants (including the Articles Amendment PDP Decisional Participant), and (C) is not objected to by more than one Decisional Participant;

(iv) A Community IRP Supported Petition that (A) includes a PDP Standard Bylaw Statement, (B) is supported by three or more Decisional Participants (including the Standard Bylaw Amendment PDP Decisional Participant), and (C) is not objected to by more than one Decisional Participant; or

(v) A Community IRP Supported Petition that (A) includes a CCWG Policy Recommendation Statement, (B) is supported by three or more Decisional Participants (including the CCWG Policy Recommendation Decisional Participant), and (C) is not objected to by more than one Decisional Participant.

(f) If the Community IRP Supported Petition does not obtain the support required by Section 4.2(e) of this Annex D, the Community IRP Initiation Process will automatically be terminated and the EC Administration shall, within twenty-four (24) hours of the expiration of the Community IRP Decision Period, deliver to the Secretary a Community IRP Termination Notice.

(g) ICANN shall promptly post to the Website any (i) Community IRP Petition, (ii) Community IRP Supported Petition, (iii) EC Community IRP Initiation Notice, (iv) Community IRP Termination Notice, (v) written explanation provided by the EC Administration related to any of the foregoing, and (vi) other notices the Secretary receives under this Section 4.2.

Section 4.3. COMMUNITY RECONSIDERATION REQUEST

(a) Any Decisional Participant may request that the EC initiate a Reconsideration Request (a "Community Reconsideration Petitioning Decisional Participant"), as contemplated by Section 4.2(b) of the Bylaws, by delivering a notice to the EC Administration and the other Decisional Participants, with a copy to the Secretary for ICANN to promptly post on the Website, requesting the review or reconsideration of an action or inaction of the ICANN Board or staff ("Community Reconsideration Petition"). A Community Reconsideration Petition must be delivered within 30 days after the occurrence of any of the conditions set forth in Section 4.2(g)(i)(A), (B) or (C) of the Bylaws. In that instance, the Community Reconsideration Petition must be delivered within 30 days from the initial posting of the rationale. The process set forth in this Section 4.3 of this Annex D as it relates to a particular Community Reconsideration Petition is referred to herein as the "Community Reconsideration Initiation Process."

(b) Following the delivery of a Community Reconsideration Petition to the EC Administration by a Community Reconsideration Petitioning Decisional Participant pursuant to Section 4.3(a) of this Annex D (which delivery date shall be referred to herein as the "Community Reconsideration Notification Date"), the Community Reconsideration Petitioning Decisional Participant shall contact the EC Administration and the other Decisional Participants to determine whether any other Decisional Participants support the Community Reconsideration Petition. The Community Reconsideration Petitioning Decisional Participant shall forward such communication to the Secretary for ICANN to promptly post on the Website.

(i) If the Community Reconsideration Petitioning Decisional Participant obtains the support of at least one other Decisional Participant (a "Community Reconsideration Supporting Decisional Participant") during the period beginning on the Community Reconsideration Notification Date and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the Community Reconsideration Notification Date (the "Community Reconsideration Petition Support Period"), the Community Reconsideration Petitioning Decisional Participant shall provide a written notice to the EC Administration, the other Decisional Participants and the Secretary ("Community Reconsideration Supported Petition") within twenty-four (24) hours of receiving the support of at least one Community Reconsideration Supporting Decisional Participant. Each Community Reconsideration Supporting Decisional Participant shall provide a written notice to the EC Administration, the other Decisional Participants and the Secretary within twenty-four (24) hours of providing support to the Community Reconsideration Petition. SuchCommunity Reconsideration Supported Petition shall include:

(A) a supporting rationale in reasonable detail;

(B) contact information for at least one representative who has been designated by the Community Reconsideration Petitioning Decisional Participant who shall act as a liaison with respect to the Community Reconsideration Supported Petition;

(C) a statement as to whether or not the Community Reconsideration Petitioning Decisional Participant and/or the Community Reconsideration Supporting Decisional Participant requests that ICANN organize a publicly-available conference call prior to the Community Reconsideration Community Forum (as defined in Section 4.3(c) of this Annex D) for the community to discuss the Community Reconsideration Supported Petition; and

(D) a statement as to whether the Community Reconsideration Petitioning Decisional Participant and the Community Reconsideration Supporting Decisional Participant have determined to hold the Community Reconsideration Community Forum during the next scheduled ICANN public meeting.

The Community Reconsideration Initiation Process shall thereafter continue for such Community Reconsideration Supported Petition pursuant to Section 4.3(c) of this Annex D.

(ii) The Community Reconsideration Initiation Process shall automatically be terminated and the EC Administration shall, within twenty-four (24) hours of the expiration of the Community Reconsideration Petition Support Period, deliver to the Secretary a notice certifying that the Community Reconsideration Initiation Process has been terminated with respect to the Reconsideration Request included in the Community Reconsideration Petition ("Community Reconsideration Termination Notice") if the Community Reconsideration Petitioning Decisional Participant is unable to obtain the support of at least one other Decisional Participant for its Community Reconsideration Petition during the Community Reconsideration Petition Support Period.

(c) If the EC Administration receives a Community Reconsideration Supported Petition under Section 4.3(b) of this Annex D during the Community Reconsideration Petition Support Period, ICANN shall, at the direction of the EC Administration, convene a forum at which the Decisional Participants and interested third parties may discuss the Community Reconsideration Supported Petition ("Community Reconsideration Community Forum").

(i) If a publicly-available conference call has been requested in a Community Reconsideration Supported Petition, ICANN shall, at the direction of the EC Administration, schedule such call prior to any Community Reconsideration Community Forum, and inform the Decisional Participants of the date, time and participation methods of such conference call, which ICANN shall promptly post on the Website.

(ii) The Community Reconsideration Community Forum shall be convened and concluded during the period beginning on the expiration of the Community Reconsideration Petition Support Period and ending at 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 30th day after the expiration of the Community Reconsideration Petition Support Period ("Community Reconsideration Forum Period") unless the Community Reconsideration Supported Petition requested that the Community Reconsideration Community Forum be held during the next scheduled ICANN public meeting, in which case the Community Reconsideration Community Forum shall be held during the next scheduled ICANN public meeting on the date and at the time determined by ICANN, taking into account any date and/or time requested by the Community Reconsideration Petitioning Decisional Participant and the Community Reconsideration Supporting Decisional Participant(s). If the Community Reconsideration Community Forum is held during the next scheduled ICANN public meeting and that public meeting is held after 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 30th day after the expiration of the Community Reconsideration Petition Support Period, the Community Reconsideration Community Forum Period shall expire at 11:59 p.m., local time of the city hosting such ICANN public meeting on the official last day of such ICANN public meeting.

(iii) The Community Reconsideration Community Forum shall be conducted via remote participation methods such as teleconference, web-based meeting room and/or such other form of remote participation as the EC Administration selects and/or, only if the Community Reconsideration Community Forum is held during an ICANN public meeting, face-to-face meetings. If the Community Reconsideration Community Forum will not be held during an ICANN public meeting, the EC Administration shall promptly inform ICANN of the date, time and participation methods of such Community Reconsideration Community Forum, which ICANN shall promptly post on the Website.

(iv) The EC Administration shall manage and moderate the Community Reconsideration Community Forum in a fair and neutral manner.

(v) ICANN and any Supporting Organization or Advisory Committee (including Decisional Participants) may deliver to the EC Administration in writing its views and questions on the Community Reconsideration Supported Petition prior to the convening of and during the Community Reconsideration Community Forum. Any written materials delivered to the EC Administration shall also be delivered to the Secretary for prompt posting on the Website in a manner deemed appropriate by ICANN.

(vi) ICANN staff and Directors representing the Board are expected to attend the Community Reconsideration Community Forum in order to discuss the Community Reconsideration Supported Petition.

(vii) If the Community Reconsideration Petitioning Decisional Participant and each of the Community Reconsideration Supporting Decisional Participants for a Community Reconsideration Supported Petition agree before, during or after the Community Reconsideration Community Forum that the issue raised in such Community Reconsideration Supported Petition has been resolved, such Community Reconsideration Supported Petition shall be deemed withdrawn and the Community Reconsideration Initiation Process with respect to such Community Reconsideration Supported Petition will be terminated. If a Community Reconsideration Initiation Process is terminated, the EC Administration shall, within twenty-four (24) hours of the resolution of the issue raised in the Community Reconsideration Supported Petition, deliver to the Secretary a Community Reconsideration Termination Notice. For the avoidance of doubt, the Community Reconsideration Community Forum is not a decisional body and the foregoing resolution process shall be handled pursuant to the internal procedures of the Community Reconsideration Petitioning Decisional Participant and the Community Reconsideration Supporting Decisional Participant(s).

(viii) During the Community Reconsideration Community Forum Period, an additional one or two Community Reconsideration Community Forums may be held at the discretion of a Community Reconsideration Petitioning Decisional Participant and a related Community Reconsideration Supporting Decisional Participant, or the EC Administration.

(ix) ICANN will provide support services for the Community Reconsideration Community Forum and shall promptly post on the Website a public record of the Community Reconsideration Community Forum as well as all written submissions of ICANN and any Supporting Organization or Advisory Committee (including Decisional Participants) related to the Community Reconsideration Community Forum.

(d) Following the expiration of the Community Reconsideration Community Forum Period, at any time or date prior to 11:59 p.m. (as calculated by local time at the location of ICANN's principal office) on the 21st day after the expiration of the Community Reconsideration Community Forum Period (such period, the "Community Reconsideration Decision Period"), each Decisional Participant shall inform the EC Administration in writing as to whether such Decisional Participant (i) supports such Community Reconsideration Supported Petition, (ii) objects to such Community Reconsideration Supported Petition or (iii) has determined to abstain from the matter (which shall not count as supporting or objecting to the Community Reconsideration Supported Petition), and each Decisional Participant shall forward such notice to the Secretary for ICANN to promptly post on the Website. If a Decisional Participant does not inform the EC Administration of any of the foregoing prior to the expiration of the Community Reconsideration Decision Period, the Decisional Participant shall be deemed to have abstained from the matter (even if such Decisional Participant informs the EC Administration of its support or objection following the expiration of the Community Reconsideration Decision Period).

(e) If (i) three or more Decisional Participants support the Community Reconsideration Supported Petition and (ii) no more than one Decisional Participant objects to the Community Reconsideration Supported Petition, then the EC Administration shall, within twenty-four (24) hours of the expiration of the Community Reconsideration Decision Period, deliver a notice to the Secretary certifying that, pursuant to and in compliance with the procedures and requirements of this Section 4.3 of this Annex D, the EC has resolved to accept the Community Reconsideration Supported Petition ("EC Reconsideration Initiation Notice"). The Reconsideration Request shall then proceed in accordance with Section 4.2 of the Bylaws.

(f) If the Community Reconsideration Supported Petition does not obtain the support required by Section 4.3(e) of this Annex D, the Community Reconsideration Initiation Process will automatically be terminated and the EC Administration shall, within twenty-four (24) hours of the expiration of the Community Reconsideration Decision Period, deliver to the Secretary a Community Reconsideration Termination Notice.

(g) ICANN shall promptly post to the Website any (i) Community Reconsideration Petition, (ii) Community Reconsideration Supported Petition, (iii) EC Reconsideration Initiation Notice, (iv) Community Reconsideration Termination Notice, (v) written explanation provided by the EC Administration related to any of the foregoing, and (vi) other notices the Secretary receives under this Section 4.3.

Annex E: Caretaker ICANN Budget Principles

Principles

The caretaker ICANN budget (the "Caretaker ICANN Budget") is defined as an annual operating plan and budget that is established by the CFO in accordance with the following principles (the "Caretaker ICANN Budget Principles"):

It is based on then-current ICANN operations;
It allows ICANN to "take good care" and not expose itself to additional enterprise risk(s) as a result of the rejection of an ICANN Budget by the EC pursuant to the Bylaws;
It allows ICANN to react to emergency situations in a fashion that preserves the continuation of its operations;
It allows ICANN to abide by its existing obligations (including Articles of Incorporation, Bylaws, and contracts, as well as those imposed under law);
It enables ICANN to avoid waste of its resources during the rejection period (i.e., the period between when an ICANN Budget is rejected by the EC pursuant to the Bylaws and when an ICANN Budget becomes effective in accordance with the Bylaws) or immediately thereafter, by being able to continue activities during the rejection period that would otherwise need to be restarted at a materially incremental cost; and
Notwithstanding any other principle listed above, it prevents ICANN from initiating activities that remains subject to community consideration (or for which that community consideration has not concluded) with respect to the applicable ICANN Budget, including without limitation, preventing implementation of any expenditure or undertaking any action that was the subject of the ICANN Budget that was rejected by the EC that triggered the need for the Caretaker ICANN Budget.
Examples

Below is a non-exhaustive list of examples, to assist with the interpretation of the Caretaker ICANN Budget Principles, of what a Caretaker ICANN Budget would logically include:

i. the functioning of the EC, the Decisional Participants, and any Supporting Organizations or Advisory Committees that are not Decisional Participants;

ii. the functioning of all redress mechanisms, including without limitation the office of the Ombudsman, the IRP, and mediation;

iii. employment of staff (i.e., employees and individual long term paid contractors serving in locations where ICANN does not have the mechanisms to employ such contractors) across all locations, including all related compensation, benefits, social security, pension, and other employment costs;

iv. hiring staff (i.e., employees and individual long term paid contractors serving in locations where ICANN does not have the mechanisms to employ such contractors) in the normal course of business;

v. necessary or time-sensitive travel costs for staff (i.e., employees and individual long term paid contractors serving in locations where ICANN does not have the mechanisms to employ such contractors) or vendors as needed in the normal course of business;

vi. operating all existing ICANN offices, and continuing to assume obligations relative to rent, utilities, maintenance, and similar matters;

vii. contracting with vendors as needed in the normal course of business;

viii. conducting ICANN meetings and ICANN intercessional meetings previously contemplated; and

ix. participating in engagement activities in furtherance of the approved Strategic Plan.

Below is a non-limitative list of examples, to assist with the interpretation of the Caretaker ICANN Budget Principles, of what a Caretaker ICANN Budget would logically exclude:

i. hiring staff (i.e., employees and individual long term paid contractors serving in locations where ICANN does not have the mechanisms to employ such contractors) or entering into new agreements in relation to activities that are the subject of the rejection of the ICANN Budget by the EC pursuant to the Bylaws, unless excluding these actions would violate any of the Caretaker ICANN Budget Principles;

ii. in the normal course of business, travel not deemed indispensable during the rejection period, unless the lack of travel would violate any of the Caretaker ICANN Budget Principles;

iii. entering into new agreements in relation to opening or operating new ICANN locations/offices, unless the lack of commitment would violate any of the Caretaker ICANN Budget Principles;

iv. entering into new agreements with governments (or their affiliates), unless the lack of commitment would violate any of the Caretaker ICANN Budget Principles; and

v. the proposed expenditure that was the basis for the rejection by the EC that triggered the need for the Caretaker ICANN Budget.

Annex F: Caretaker IANA Budget Principles

Principles

The caretaker IANA Budget (the "Caretaker IANA Budget") is defined as an annual operating plan and budget that is established by the CFO in accordance with the following principles (the "Caretaker IANA Budget Principles"):

It is based on then-current operations of the IANA functions;
It allows ICANN, in its responsibility to fund the operations of the IANA functions, to "take good care" and not expose itself to additional enterprise risk(s) as a result of the rejection of an IANA Budget by the EC pursuant to the Bylaws;
It allows ICANN, in its responsibility to fund the operations of the IANA functions, to react to emergency situations in a fashion that preserves the continuation of its operations;
It allows ICANN, in its responsibility to fund the operations of the IANA functions, to abide by its existing obligations (including Articles of Incorporation, Bylaws, and contracts, as well as those imposed under law);
It allows ICANN, in its responsibility to fund the operations of the IANA functions, to avoid waste of its resources during the rejection period (i.e., the period between when an IANA Budget is rejected by the EC pursuant to the Bylaws and when an IANA Budget becomes effective in accordance with the Bylaws) or immediately thereafter, by being able to continue activities during the rejection period that would have otherwise need to be restarted at an incremental cost; and
Notwithstanding any other principle listed above, it prevents ICANN, in its responsibility to fund the operations of the IANA functions, from initiating activities that remain subject to community consideration (or for which that community consultation has not concluded) with respect to the applicable IANA Budget, including without limitation, preventing implementation of any expenditure or undertaking any action that was the subject of the IANA Budget that was rejected by the EC that triggered the need for the Caretaker IANA Budget.
Examples
1. Below is a non-exhaustive list of examples, to assist with the interpretation of the Caretaker IANA Budget Principles, of what a Caretaker IANA Budget would logically include:

i. employment of staff (i.e., employees and individual long term paid contractors serving in locations where the entity or entities performing the IANA functions does not have the mechanisms to employ such contractors) across all locations, including all related compensation, benefits, social security, pension, and other employment costs;

ii. hiring staff (i.e., employees and individual long term paid contractors serving in locations where the entity or entities performing the IANA functions does not have the mechanisms to employ such contractors) in the normal course of business;

iii. necessary or time-sensitive travel costs for staff (i.e., employees and individual long term paid contractors serving in locations where the entity or entities performing the IANA functions does not have the mechanisms to employ such contractors) or vendors as needed in the normal course of business;

iv. operating all existing offices used in the performance of the IANA functions, and continuing to assume obligations relative to rent, utilities, maintenance, and similar matters;

v. contracting with vendors as needed in the normal course of business;

vi. participating in meetings and conferences previously contemplated;

vii. participating in engagement activities with ICANN's Customer Standing Committee or the customers of the IANA functions;

viii. fulfilling obligations (including financial obligations under agreements and memoranda of understanding to which ICANN or its affiliates is a party that relate to the IANA functions; and

ix. participating in engagement activities in furtherance of the approved Strategic Plan.

Below is a non-limitative list of examples, to assist with the interpretation of the Caretaker IANA Budget Principles, of what a Caretaker IANA Budget would logically exclude:

i. hiring staff (i.e., employees and individual long term paid contractors serving in locations where the entity or entities performing the IANA functions does not have the mechanisms to employ such contractors) or entering into new agreements in relation to activities that are the subject of the rejection of the IANA Budget by the EC pursuant to the Bylaws, unless excluding these actions would violate any of the Caretaker IANA Budget Principles;

ii. in the normal course of business, travel not deemed indispensable during the rejection period, unless the lack of travel would violate any of the Caretaker IANA Budget Principles;

iii. entering into new agreements in relation to opening or operating new locations/offices where the IANA functions shall be performed, unless the lack of commitment would violate any of the Caretaker IANA Budget Principles;

iv. entering into new agreements with governments (or their affiliates), unless the lack of commitment would violate any of the Caretaker IANA Budget Principles; and

v. the proposed expenditure that was the basis for the rejection by the EC that triggered the need for the Caretaker IANA Budget.

ANNEX G-1

The topics, issues, policies, procedures and principles referenced in Section 1.1(a)(i) with respect to gTLD registrars are:

issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet, registrar services, registry services, or the DNS;
functional and performance specifications for the provision of registrar services;
registrar policies reasonably necessary to implement Consensus Policies relating to a gTLD registry;
resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names); or
restrictions on cross-ownership of registry operators and registrars or resellers and regulations and restrictions with respect to registrar and registry operations and the use of registry and registrar data in the event that a registry operator and a registrar or reseller are affiliated.

Examples of the above include, without limitation:

principles for allocation of registered names in a TLD (e.g., first-come/first-served, timely renewal, holding period after expiration);
prohibitions on warehousing of or speculation in domain names by registries or registrars;
reservation of registered names in a TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property, or (iii) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration);
maintenance of and access to accurate and up-to-date information concerning registered names and name servers;
procedures to avoid disruptions of domain name registrations due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility among continuing registrars of the registered names sponsored in a TLD by a registrar losing accreditation; and
the transfer of registration data upon a change in registrar sponsoring one or more registered names.

ANNEX G-2

The topics, issues, policies, procedures and principles referenced in Section 1.1(a)(i) with respect to gTLD registries are:

issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet or DNS;
functional and performance specifications for the provision of registry services;
security and stability of the registry database for a TLD;
registry policies reasonably necessary to implement Consensus Policies relating to registry operations or registrars;
resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names); or
restrictions on cross-ownership of registry operators and registrars or registrar resellers and regulations and restrictions with respect to registry operations and the use of registry and registrar data in the event that a registry operator and a registrar or registrar reseller are affiliated.

Examples of the above include, without limitation:

principles for allocation of registered names in a TLD (e.g., first-come/first-served, timely renewal, holding period after expiration);
prohibitions on warehousing of or speculation in domain names by registries or registrars;
reservation of registered names in the TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property, or (iii) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration);
maintenance of and access to accurate and up-to-date information concerning domain name registrations; and
procedures to avoid disruptions of domain name registrations due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility for serving registered domain names in a TLD affected by such a suspension or termination.

[1] When "1 October 2016" is used, that signals that the date that will be used is the effective date of the Bylaws.

BYLAWS FOR INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS | A California Nonprofit Public-Benefit Corporation (original) (raw)

ARTICLE 1 MISSION, COMMITMENTS AND CORE VALUES

Section 1.1. MISSION

Section 1.2. COMMITMENTS AND CORE VALUES

ARTICLE 2 POWERS

Section 2.1. GENERAL POWERS

Section 2.2. RESTRICTIONS

Section 2.3. NON-DISCRIMINATORY TREATMENT

ARTICLE 3 TRANSPARENCY

Section 3.1. OPEN AND TRANSPARENT

Section 3.2. WEBSITE

Section 3.3. MANAGER OF PUBLIC PARTICIPATION

Section 3.4. MEETING NOTICES AND AGENDAS

Section 3.5. MINUTES AND PRELIMINARY REPORTS

Section 3.6. NOTICE AND COMMENT ON POLICY ACTIONS

Section 3.7. TRANSLATION OF DOCUMENTS

ARTICLE 4 ACCOUNTABILITY AND REVIEW

Section 4.1. PURPOSE

Section 4.2. RECONSIDERATION

Section 4.3. INDEPENDENT REVIEW PROCESS FOR COVERED ACTIONS

Section 4.4. PERIODIC REVIEW OF ICANN STRUCTURE AND OPERATIONS

Section 4.5. ANNUAL REVIEW

Section 4.6. SPECIFIC REVIEWS

Section 4.7. COMMUNITY MEDIATION

ARTICLE 5 OMBUDSMAN

Section 5.1. OFFICE OF OMBUDSMAN

Section 5.2. CHARTER

Section 5.3. OPERATIONS

Section 5.4. INTERACTION WITH ICANN AND OUTSIDE ENTITIES

Section 5.5. ANNUAL REPORT

ARTICLE 6 EMPOWERED COMMUNITY

Section 6.1. COMPOSITION AND ORGANIZATION OF THE EMPOWERED COMMUNITY

Section 6.2. POWERS AND ACKNOWLEDGMENTS

Section 6.3. EC ADMINISTRATION

Section 6.4. CONSENT TO BOARD-INITIATED REMOVAL OF DIRECTOR WITHOUT CAUSE

ARTICLE 7 BOARD OF DIRECTORS

Section 7.1. COMPOSITION OF THE BOARD

Section 7.2. DIRECTORS AND THEIR SELECTION; ELECTION OF CHAIR AND VICE-CHAIR

Section 7.3.CRITERIA FOR NOMINATION OF DIRECTORS

Section 7.4. ADDITIONAL QUALIFICATIONS

Section 7.5. INTERNATIONAL REPRESENTATION

Section 7.6. DIRECTORS' CONFLICTS OF INTEREST

Section 7.7. DUTIES OF DIRECTORS

Section 7.8. TERMS OF DIRECTORS

Section 7.9. NON-VOTING LIAISONS

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

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

Section 7.12. VACANCIES

Section 7.13. ANNUAL MEETINGS

Section 7.14. REGULAR MEETINGS

Section 7.15. SPECIAL MEETINGS

Section 7.16. NOTICE OF MEETINGS

Section 7.17. QUORUM

Section 7.18. ACTIONS BY TELEPHONE MEETING OR BY OTHER COMMUNICATIONS EQUIPMENT

Section 7.19. ACTION WITHOUT MEETING

Section 7.20. ELECTRONIC MAIL

Section 7.21. BOARD RIGHTS OF INSPECTION

Section 7.22. COMPENSATION

Section 7.23. PRESUMPTION OF ASSENT

Section 7.24 INTERIM BOARD

Section 7.25 COMMUNICATION OF DESIGNATION

ARTICLE 8 NOMINATING COMMITTEE

Section 8.1. DESCRIPTION

Section 8.2. COMPOSITION

Section 8.3. TERMS

ARTICLE 9 ADDRESS SUPPORTING ORGANIZATION

Section 9.1. DESCRIPTION

Section 9.2. ADDRESS COUNCIL

ARTICLE 10 COUNTRY-CODE NAMES SUPPORTING ORGANIZATION

Section 10.1. DESCRIPTION

Section 10.2. ORGANIZATION

Section 10.3. ccNSO COUNCIL

Section 10.4. MEMBERSHIP

Section 10.5. REGIONAL ORGANIZATIONS

Section 10.6. ccNSO POLICY-DEVELOPMENT PROCESS AND SCOPE

Section 10.7. STAFF SUPPORT AND FUNDING

ARTICLE 11 GENERIC NAMES SUPPORTING ORGANIZATION

Section 11.1. DESCRIPTION

Section 11.2. ORGANIZATION

Section 11.3. GNSO COUNCIL