Skip to main content

ICANN Opens Public Comments on ccNSO Recommendations for Proposed Bylaws Changes

Introduction:

On 26 June 2003, the ICANN Board at its public meeting in Montreal, Canada, discussed and adopted amendments to the ICANN Bylaws to include the country code Names Supporting Organization (ccNSO).

On 6 June 2005, the ccNSO Council initiated a country code Policy Development Process (ccPDP) to encourage ccTLD managers to become members of the ccNSO. This process culminated in the ccNSO Council's adoption of the ccPDP Board Report in Vancouver and a request that the Issue Manager forward the Board Report to the ICANN Board for consideration. The Initial, Final, Members and Board reports prepared as part of this process are available on the ICANN website.

The Recommendations to the Board pertain to Article IX (ccNSO), Annex B (ccNSO Policy Development Process) and Annex C (the scope of the ccNSO) of the ICANN Bylaws. The ccNSO makes these recommendations as an improvement and clarification of the ICANN Bylaws on the ccNSO and the ccPDP in the interests of the ccNSO membership, the ccNSO Council and other stakeholders.

Each ccNSO Recommendation is outlined below and contains a summary of the matter of concern and the considerations as contained in the ccPDP Final Report. Proposed amendments are as follows: Deleted text is shown in strikeout type; or added text is underlined.

The Board has directed staff to post the recommendations for public comment and these can be provided via the link below.

 

ccNSO Recommendation 1

Background

Under the conditions enumerated in Article IX section 4.10 a ccNSO policy shall apply to members of the ccNSO by virtue of their membership. Is this language sufficiently clear?

Under the current bylaws the core aspects of joining the ccNSO are set out, in combination with the method of joining (application form). Although ICANN is not a membership organization, in section 4.2 it is stated that a member of the ccNSO can resign by sending a written notice at any time. From a logical point of view the core effect of resignation could be set out as well.

Proposed amendment of Article IX section 4.2

"Any ccTLD manager may become a ccNSO member by submitting an application to a person designated by the ccNSO Council to receive applications. Subject to the provisions of the Transition Article of these Bylaws, the application shall be in writing in a form designated by the ccNSO Council. The application shall include the ccTLD manager's recognition of the role of the ccNSO within the ICANN structure as well as the ccTLD manager's agreement, for the duration of its membership in the ccNSO, (a) to adhere to rules of the ccNSO, including membership rules, (b) to abide by policies developed and recommended by the ccNSO and adopted by the Board in the manner described by paragraphs 10 and 11 of this Section, and (c) to pay ccNSO membership fees established by the ccNSO Council under Section 7(3) of this Article. A ccNSO member may resign from membership at any time by giving written notice to a person designated by the ccNSO Council to receive notices of resignation. Upon resignation the ccTLD manager ceases to agree to (a) adhere to rules of the ccNSO, including membership rules, (b) to abide by policies developed and recommended by the ccNSO and adopted by the Board in the manner described by paragraphs 10 and 11 of this Section, and (c) to pay ccNSO membership fees established by the ccNSO Council under Section 7(3) of this Article. In the absence of designation by the ccNSO Council of a person to receive applications and notices of resignation, they shall be sent to the ICANN Secretary, who shall notify the ccNSO Council of receipt of any such applications and notices."

 

ccNSO Recommendation 2

Background

At article IX section 4.3 it is stated that a ccTLD manager's receipt of IANA services is independent of membership of that ccTLD manager in the ccNSO Is this language sufficiently clear?

Article IX of the bylaws and its annexes relate to the ccNSO and its membership. With regard to this particular matter the issue was if the established principle that receipt of IANA services is independent of membership of the ccNSO was sufficiently clear in the bylaws. From the input received during the ccPDP it became clear that the wording could be improved.

Proposed amendment of Article IX Section 4.3

"Neither membership in the ccNSO nor membership in any Regional Organization described in Section 5 of this Article shall be a condition for access to or registration in the IANA database. Membership in the ccNSO is independent of any individual relationship a ccTLD manager has with ICANN or the ccTLD manager's receipt of IANA services. 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."

 

ccNSO Recommendation 3

Background

Under the current bylaws there is a provision (Article IX section 6) that deals with changes to Annex B and Annex C of the bylaws.

Should the ICANN Board only be able to change or amend Article IX, Annex B and Annex C after consultation and the consent of the members of the ccNSO?

In considering the suggested solutions one needs to take into account the following arguments:

1. The ccNSO is the organization under the ICANN umbrella that deals with ccTLD issues (see Clarification General Counsel, Question 1). The ccPDP is an open and transparent process designed to deal with ccTLD policy issues. A change to the process itself or the scope for setting policies, both part of the bylaws, can only be made by using the ccPDP. It is only consistent to use the same mechanism for modifying the bylaws on the ccNSO itself.

2. As Article IX relates to the ccNSO and its members, a modification of this Article should for that reason involve the ccNSO and its members.

3. As to the consent of 66% of the ccNSO members this will be achieved if for all modifications of article IX, Annex B and Annex C because the ccPDP is used (Annex B section 13).

Proposed amendment Article IX section 6.

1. The scope of the ccNSO's policy-development role shall initially be as stated in Annex C to these Bylaws ; any modifications to the scope shall be recommended to the Board by the ccNSO by use of the procedures of the ccPDP, and shall be subject to approval by the Board.

2. In developing global policies within the scope of the ccNSO and recommending them to the Board, the ccNSO shall follow the ccNSO Policy-Development Process (ccPDP). The ccPDP shall initially be as stated in Annex B to these Bylaws ; modifications shall be recommended to the Board by the ccNSO by use of the procedures of the ccPDP, and shall be subject to approval by the Board.

3. Any change of this article IX shall be recommended to the Board by the ccNSO by use of the procedures of the ccPDP as stated in Annex C to these bylaws, and shall be subject to approval by the Board.

Further, the last full sentence of Annex B Section 2(e) should be amended to read:

In all events, consideration of revisions to Article IX of the bylaws, 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.

 

ccNSO Recommendation 4

Background

Under the current bylaws (Article IX section 4.10) a member of the ccNSO shall be bound by an ICANN policy if, and only to the extent that this policy (a) has been developed through the ccPDP and (b) has been recommended as such by the ccNSO to the Board, and (c) is adopted by the Board as a policy.

Should a policy only be binding on members if and only to the extent the policy is on an issue that is within Scope and has been developed through the ccPDP and is adopted by the Board?

After extensive consultation of the relevant stakeholders it is clear a policy should only be binding if and only to the extent that:

  1. the issue the policy addresses is within scope of the ccNSO (Annex C),

  2. has been developed by use of the ccPDP (Annex B),

  3. has been recommended as such by the ccNSO and

  4. is adopted by the Board. Condition a. needs to be added to section 4.10.

However, resolving this issue as suggested raises another issue: the ccNSO should at least be able to co- determine whether or not an issue is within or outside scope of the ccNSO. Currently (Annex B section 2) this is at first determined by ICANN's General Counsel. However the ccNSO Council may initiate a ccPDP with a supermajority even if the issue is not within scope of Mission Statement or the scope of the ccNSO (Annex B section 3 b).

The current bylaws in particular Annex B section 3 b on the initiation of a ccPDP were designed to overcome a disagreement on whether an issue was in or outside the Mission Statement of ICANN or the scope of the ccNSO and henceforth on the initiation of a ccPDP. As the recommendation will be to limit a ccPDP to only those issues which are within scope of the ccNSO a mechanism should be introduced to balance the respective roles and responsibilities and resolve the potential disagreement between General Counsel and the ccNSO. It should be noted that the discussion only focuses on the scope of the ccNSO and not on the scope of ICANN's mission statement. The determination whether an issue is within or outside ICANN's Mission Statement will be the prerogative of General Counsel.

The starting point and not disputed is the current role of General Counsel to determine whether an issue is within scope of the ccNSO should be maintained. General Counsel should remain as the first to give an opinion whether the issue considered is properly within the scope of the ccNSO. It should also be maintained that this opinion is part of the Issues Report on the basis of which the Council may initiate a ccPDP to resolve the issue.

However, in the event General Counsel is of the opinion the issue raised is not properly within Scope of the ccNSO, the Issue Manager should inform the Council of this opinion of General Counsel. The ccNSO Council may then consider this opinion of General Counsel. In the event the Council is of the opinion the issue is within scope, contrary to the opinion of General Counsel, the

Council and General Counsel should engage in a dialogue as appropriate and in accordance with agreed procedures to resolve their disagreement.

In the event agreement is reached, the Issue Manager will then proceed to make a recommendation on whether the Council should move to initiate a ccPDP supported by the opinion of General Counsel whether the issue is in scope.

If after the reconciliation the disagreement is not resolved, the Council may decide with a supermajority of 15 or more members of the Council that it is of the reasoned opinion that despite the opinion of the General Counsel, the issue is within scope for a policy development process of the ccNSO. According to the rules and procedures of the ccNSO as established this decision of the Council can be ratified or vetoed by the members of the ccNSO if called for by 10% or more of the members.

In the event the Council is of the opinion the issue is within scope and General Counsel is of another opinion, the Issue Manager shall proceed to come to a recommendation on whether or not to initiate a ccPDP, incorporating both the reasoned opinion of the Council and General Counsel in the Issues Report.

After receipt of the Issues Report (including the opinion of General Counsel or General Counsel and the Council as the case may be) the Council shall then vote on the initiation of a ccPDP. According to the rules and procedures of the ccNSO this decision can again be ratified or vetoed by the members of the ccNSO.

Proposed amendment of Article IX Section 4.10 and Annex B section 2, 3 and 15.

Proposed wording Article IX section 4.10

"Subject to clause 4(11), ICANN policies shall apply to ccNSO members by virtue of their membership to the extent, and only to the extent, that the policies

(a) Only address issues that are within scope of the ccNSO according to Article IX, Section 6 and Annex C;

(b) Have been developed through the ccPDP as described in Section 6 of this Article , and

(c) Have been recommended as such by the ccNSO to the Board, and

(d) Are adopted by the Board as policies, provided that such policies do not conflict with the law applicable to the ccTLD manager which shall, at all times, remain paramount. In addition, such policies shall apply to ICANN in its activities concerning ccTLD's."

Proposed wording Annex B Section 3. Initiation of PDP

"The Council shall decide whether to initiate the PDP as follows:

a. Within 21 days after receipt of an Issue Report from the Issue Manager, the Council shall vote on whether to initiate the PDP. Such vote should be taken at a meeting held in any manner deemed appropriate by the Council, including in person or by conference call, but if a meeting is not feasible the vote may occur by e-mail.

b. A vote of ten or more Council members in favour of initiating the PDP shall be required to initiate the PDP provided that the Issue Report states that the issue is properly within the scope of the ICANN mission statement and ccNSO Scope. In the event that the Issue Report states it is not properly within the scope of the ICANN mission statement or the ccNSO Scope, then a vote of twelve or more Council members in favor of initiating the PDP shall be required to initiate the PDP."

Proposed wording Annex B section 2 Creation of the Issue Report and Initiation Threshold

"Within seven days after an affirmative vote as outlined in Item 1(a) above or the receipt of a request as outlined in Items 1 (b), (c), or (d) above the Council shall appoint an Issue Manager. The Issue Manager may be a staff member of ICANN (in which case the costs of the Issue Manager shall be borne by ICANN) or such other person or persons selected by the Council (in which case the ccNSO shall be responsible for the costs of the Issue Manager).

Within fifteen (15) calendar days after appointment (or such other time as the Council shall, in consultation with the Issue Manager, deem to be appropriate), the Issue Manager shall create an Issue Report. Each Issue Report shall contain at least the following:

a. The proposed issue raised for consideration;

b. The identity of the party submitting the issue;

c. How that party is affected by the issue; and

d. Support for the issue to initiate the PDP;

e. A recommendation from the Issue Manager as to whether the Council should move to initiate the PDP for this issue (the "Manager Recommendation"). Each Manager Recommendation shall include, and be supported by, an opinion of the ICANN General Counsel regarding whether the issue is properly within the scope of the ICANN policy process and within the scope of the ccNSO. In coming to his or her opinion, the General Counsel shall examine whether:

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

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

In the event that the General Counsel reaches an opinion in the affirmative with respect to points 1 and 2 above then the General Counsel shall also consider whether the issue:

3) Implicates or affects an existing ICANN policy;

4) Is likely to have lasting value or applicability, albeit with the need for occasional updates, and to establish a guide or framework for future decision-making.

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

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

f. In the event that the Manager Recommendation is in favour of initiating the PDP, a proposed time line for conducting each of the stages of PDP outlined herein (PDP Time Line).

g. If possible, the issue report shall indicate whether the resulting output is likely to result in a policy to be approved by the ICANN Board. In some circumstances, it will not be possible to do this until substantive discussions on the issue have taken place. In these cases, the issue report should indicate this uncertainty. Upon completion of the Issue Report, the Issue Manager shall distribute it to the full Council for a vote on whether to initiate the PDP."

Proposed wording Annex B section 15.5.

"5. In the event circumstances where

(i) T the Board determines not to accept a ccNSO Supplemental Recommendation, and

(ii) The opinion of the General Counsel pursuant to Item 2.e. was that the issue was within the scope of the ccNSO pursuant to the ccNSO's Scope,

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.

 

ccNSO Recommendation 5

Background

Can the ccNSO potentially set binding policies on its members on activities not defined in Article IX section 1 but authorised by its members? If so, is this an issue? If not, should the ccNSO be able to do so?

According to all comments and inputs received in the course of the policy development process policies that apply by virtue of membership can and should only be developed through the cc policy development process and be adopted by the Board as such. In order to avoid further confusion and to clarify the intention it is recommended to amend the relevant section (1) of Article IX of the bylaw.

Proposed amendment of Article IX section 1:

Article IX section 1

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

  1. developing and recommending to the Board global policies relating to country-code top-level domains;

  2. Nurturing consensus across the ccNSO's community, including the name-related activities of ccTLDs; and

  3. Coordinating with other ICANN Supporting Organizations, committees, and constituencies under ICANN.

In addition to the above core responsibilitiesPolicies that apply to ccNSO members by virtue of their membership are only those policies developed according to section 4.10 and 4.11 of this Article. However, the ccNSO may also engage in other activities authorised by its members, including. Adherence to the results of these activities will be voluntary and such activities may include: seeking to develop 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.

ccNSO Recommendation 6

Background

The use of the word "initially" in Article IX section 6 implies the scope for setting binding policies (and the ccPDP) will change over time. Should the ccNSO be able to change the Scope and the ccPDP over time?

The core of the concern is the use of the word "initially" in section 6. Based on the comments received there is no objections to the mechanism in section 6 to change the scope of the ccNSO (Annex C) or the policy development process (Annex B).

Proposed amendment of Article IX section 6

Article IX Section 6

"1. The scope of the ccNSO's policy-development role shall initially be as stated in Annex C to these Bylaws; any modifications to the scope shall be recommended to the Board by the ccNSO by use of the procedures of the ccPDP, and shall be subject to approval by the Board.

2. In developing global policies within the scope of the ccNSO and recommending them to the Board, the ccNSO shall follow the ccNSO Policy-Development Process (ccPDP). The ccPDP shall initially be as stated in Annex B to these Bylaws; modifications shall be recommended to the Board by the ccNSO by use of the procedures of the ccPDP, and shall be subject to approval by the Board."

ccNSO Recommendation 7

Background

According to the current bylaws (Annex B section 13) a vote of the members is valid without a quorum. Should a vote of ccNSO members only be valid if at least 50% of the members have lodged a vote irrespective of the round of voting?

The current bylaw language is an attempt to balance the role of active members of the ccNSO versus apathy. Under the current bylaw language, in the second round of voting, those members who do not vote are effectively not counted. If a ccPDP is on an issue that is of importance to the membership and the broader community - running the ccPDP is already an indication - a reasonable quorum like 50 % as suggested should not be too high a threshold. It is also an indication of the support of a policy in the ccTLD community if a recommendation will be passed to the Board with at least a substantial part of the ccNSO members actively in favour of such a recommendation.

Proposed Amendment of Annex B Section 13

"Following the submission of the Members Report and within the time designated by the PDP Time Line, the ccNSO members shall be given an opportunity to vote on the Council Recommendation. The vote of members shall be electronic and members' votes shall be lodged over such a period of time as designated in the PDP Time Line (at least 21 days long).

In the event that at least 50% of the ccNSO members lodge votes within the voting period, the resulting vote will be 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 if at least 50% of the ccNSO members lodge votes. In the event that more than 66% of the votes received at the end of the voting period shall be in favour of the Council Recommendation, then the recommendation shall be conveyed to the Board in accordance with Item 14 below as the ccNSO Recommendation."

ccNSO Recommendation 8

Background

Under the current bylaws the Board can reject a recommendation of the ccNSO where the Board determines by a vote of more than 66% that such policy is not in the best interest of the ICANN community or of ICANN (Annex B section 15).

Should the ICANN Board only be able to reject a Recommendation or Supplemental Recommendation as the case may be in 'exceptional circumstances'?

In the event the ICANN Board rejects a ccNSO Recommendation in the first instance then, according to Annex B section 15, a reconciliation process will be initiated at the end of which the ICANN Board should decide a second, final time. The matter as raised should be viewed in the context of this two step decision process and the open, multi-stakeholder nature of the policy development process as described in Annex B of the bylaws.

If a more rigorous criterion would be applied in both instances of the Board's decision-making process the character of the reconciliation process would change. The risk being that the reconciliation process as defined in section 15 of Annex B would turn into a debate on the interpretation of exceptional circumstances such as a breach of the fiduciary duties of ICANN directors. To maintain the current flexibility and open and multi-stakeholder nature of the ccNSO policy development process it is therefore recommended to maintain the current wording for the initial Board vote on a ccNSO recommendation and to change the criterion for the decision in the final, second instance as proposed.

Proposed amendment of Annex B Section 15(2c).

Annex B section 15

" a. The Board shall meet to discuss the ccNSO Recommendation as soon as feasible after receipt of the Board Report from the Issue Manager, taking into account procedures for Board consideration.

b. The Board shall adopt the ccNSO Recommendation unless by a vote of more than 66% the Board determines that such policy is not in the best interest of the ICANN community or of ICANN.

1. In the event that the Board determines not to act in accordance with the ccNSO Recommendation, the Board shall (i) state its reasons for its determination not to act in accordance with the ccNSO Recommendation in a report to the Council (the "Board Statement"); and (ii) submit the Board Statement to the Council.

2. The Council shall discuss the Board Statement with the Board within thirty days after the Board Statement is submitted to the Council. The Board shall determine the method (e.g., by teleconference, e-mail, or otherwise) by which the Council and Board shall discuss the Board Statement. The discussions shall be held in good faith and in a timely and efficient manner, to find a mutually acceptable solution.

3. At the conclusion of the Council and Board discussions, the Council shall meet to affirm or modify its Council Recommendation. A recommendation supported by 14 or more of the Council members shall be deemed to reflect the view of the Council (the Council's "Supplemental Recommendation"). That Supplemental Recommendation shall be conveyed to the Members in a Supplemental Members Report, including an explanation for the Supplemental Recommendation. Members shall be given an opportunity to vote on the Supplemental Recommendation under the same conditions outlined in Item 13. In the event that more than 66% of the votes cast by ccNSO Members during the voting period are in favour of the Supplemental Recommendation then that recommendation shall be conveyed to Board as the ccNSO Supplemental Recommendation and the Board shall adopt the recommendation unless by a vote of more than 66% of the Board determines that such policy is not in the best interest of the ICANN community or of ICANN that acceptance of such policy would constitute a breach of the fiduciary duties of the Board to the Company."

Please submit your comments by 16 January 2006.

Comments may be posted to <ccnso-bylaws-changes@icann.org>. Please note that to submit email your email address must first be verified; upon your first submission you will receive a message asking you to confirm your email address.

Submitted comments may be viewed at <http://forum.icann.org/lists/ccnso-bylaws-changes> .


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