World Wide Alliance of Top Level Domain-names

On the formation of the ccSO

 Home | Meetings | AdCom | ccTLD | Participants 

Adopted by the ccTLD Constituency in Marina del Rey, November 2001


The g-TLD registry constituency wrote:

At the Stockholm meeting in early June, the ccTLD managers present voted unanimously to withdraw from the DNSO and form a ccTLD Supporting Organization.

The gTLD Registry Constituency of the DNSO recently formed a task force to survey the contractual and other issues raised by the possible formation of a ccTLD SO. We ask the ICANN community to consider the following questions.

The following is the draft response from the ccTLD constituency.

  1. Contractual questions

    • A.1 Will it be a condition of creation of a new SO that the ccTLDs be required to enter into a contract with ICANN?


      There may be some, indeed many, cc managers who may not choose to enter a contract now, or in the forseeable future with ICANN. They may be content to rely on the present, or .legacy. arrangement.

      The SO will be the forum in which the issues surrounding contractual negotiation is expected to be carried out. That will help reduce the problem the Staff currently face in attempting to sign up 242 separate contracts. It will also prevent repeats of the misunderstandings we have previously seen, in which the staff have drafted two contracts without apparent regard for the ccTLD contract, which has been drafted after long and difficult consensus formation by the cc managers. Those contracts mistakenly appear to have adopted the principles adopted by the Government Advisory Committee, which have not been adopted by the ICANN board, (because they have not been through the ICANN consensus process of policy formation) and have not been accepted by the cc Community.

      It is expected that many cc managers will adopt a contract formed by a negotiation process conducted by the ccSO, and which preserves the principles of the current contract. Membership of the ccSO will be open to all those who manage a cctld, regardless of the nature or existence of their contract with ICANN.

      It is important to note that a major difference between ccTLDs and gTLDs is that the latter depend for their existence on a contract with ICANN, whereas the ccTLDs do not.

    • A.2 Will that contract require compliance with consensus policies?

      Probably, but this is subject to three limitations of concern to ccTLDs.

      First, a key feature of ccTLD participation in ICANN, which differs from gTLD participation, is that the range of issues on which ICANN policy can be made and which will affect cc.s, will be subject to cc agreement.

      By contrast with gTLDs, which derive their existence from an ICANN contract, and which are governed and regulated by ICANN, not all aspects of ccTLD management can be separated from the overriding obligation imposed by RFC 1591 that a cc manager must operate the cctld in the interests of the local internet community. In addition, a cc manager needs to respect the local law of the government of the territory to which the cc relates. The issues which cc managers agree will be subject to ICANN-type policy making are those issues which necessarily require international co-operation and agreement.

      Second, the cc managers are concerned that any developing need to regulate the activity of the gtlds, if such can be established, should be strictly constrained to fall within the scope of the ICANN project.s intention, according to White Paper principles, and limited to technical management of internet names and numbers.

      The concept of a cc manager .reserving. its position in relation to any policy which it feels is in conflict with its RFC1591 obligations, or sovereign law, is accepted, if incompletely defined as yet.

    • A.3 If not, especially with regard to open ccTLDs, would that constitute inequitable treatment in violation of ByLaw and contract requirements?

      No. Nothing in the bylaws of ICANN can abrogate a ccTLD.s rights to develop its policies in accordance with its own view of its obligations under RFC1591, nor its necessity to comply with applicable national law. In this respect, all cc.s are equal. They are not equal with gTLDs, and cannot be compelled under a false premise of equality with gTLDs to adopt gTLD rules.

    • B. What should be the relationship between a ccTLD-ICANN contract on re-delegation to a general ICANN policy on presumptive right to renewal for uTLDs (unsponsored TLDs) or sTLDs (sponsored TLDs)?

      It is not clear to us that the ccTLD contract with ICANN has anything to do with .re-delegation..

      Again, this juxtaposition this may stem from an incomplete differentiation between cc and gTLDs.

      CC mangers have the right to manage the ccTLD without a contract with ICANN.

      Any contract which the parties enter may be limited to the services ICANN will provide, primarily by way of root server service. Whereas at the end of a contract with a gTLD registry, continuation is required before that party can continue as a registry, the end of a contract between a cc manager and ICANN does nothing to affect the status of that manager. It remains the ccTLD manager. It does not require a presumptive right.

      And, g-TLD contracts are for a limited and definite term. Existing ccTLD contracts are without limit.

      The answer therefor is that there is no relationship.

  2. Reasons to have SOs

    • A. If the rationale for creation of a ccTLD SO is (at least in part) based on ensuring the payment of fees to ICANN, would that rationale also support creation of other SOs more directly reflecting the interests and views of others who also pay a high portion of ICANN fees?

      There is almost nothing in the rationale for a ccSO that is based on the payment of fees to ICANN. The cc community, without an SO, contributes approximately one million dollars annually to ICANN without an SO at present. Creating SO.s on the basis that their members fund ICANN would ignore the fact that all money flows from registrants, and would explicitly disenfranchise such groups as the trade mark owners, who do not contribute directly. It ignores the wide range of voices ICANN needs to hear.

    • B. If the rationale for a ccTLD SO involves assuring adequate representation on the ICANN Board of those whose interests may diverge and who are bound by contracts with ICANN, would that support creation of numerous additional SOs to reflect the distinct interests of gTLDs, sTLDs, registrars, registrants, etc.?

      It is a matter of judgement whether an interest group sufficiently distinguishes itself from others so as to justify an SO.

      It is important that SOs contain a balance of views on the common subject matter of the SO. In the DNSO it is appropriate that the g-registries take their place with their registrars, their customers and other interested parties in making domain name policy for g-tlds.

      It is equally important that the board not become the forum for policy debate that should occur at wider and more open forums in the organisation. The contractual similarities between g and s TLDs, and the common contractual rules which bind them, and the commonality of their market rules, all suggest they belong in a single SO. The differences between them and ccTLDs is clear and distinct.

    • C. Are sTLDs sufficiently differently situated from uTLDs, with respect to their contractual relationships with ICANN and the role of Sponsoring Organizations in the development of policies, that they should have their own SO?


  3. Creation of policies

    • A. If ccTLDs had their own SO, would domain name policy issues be required to be referred, routinely, to two or more SOs? Will that increase or diminish the difficulty of developing and documenting consensus policies?

      Section 2 of the Bylaws of the Corporation reads:

      d) Any recommendation forwarded to the Board by a Supporting Organization shall be transmitted to all other Supporting Organizations so that each Supporting Organization may comment to the Board regarding the implications of such a recommendation on activities within their individual scope of primary responsibility.

      Accordingly, reference to one or more SO.s is an expected practice.

      In fact, ICANN has, so far, dealt with no domain name issues of consequence to ccTLDs.

      CcTLD managers have taken part in discussions about such gTLD issues as UDRP because those managers represent the interests of generic domain name holders in their local internet community. The continuing focus on gTLD issues in ICANN means that those issues will likely continue to attract little ccTLD attention.

      Similarly, the narrow range of issues which the cc managers consent to passing through a ccSO process will be of little relevance to gTLD registries and registrars.

      CCTLD consumers will be able to respond through their local internet community mechanisms, as presently. There would appear to be little prospect of duplication. When and if the risk of duplication does occur, we expect a combined working group or task force would minimise that risk.

    • B. Would a ccTLD SO have multiple constituencies, allowing groups affected by ccTLD policies to participate in ccTLD policy creation?

      No. In our experience, the self-interest of constituencies is not a model to follow. Nor is it appropriate, in dealing with cc managers, responsible under RFC 1591 to the whole of their local community. It is important to appreciate that ccTLD managers typically develop policies in their countries as a compromise development between the competing interests in play in each ccTLD- including trade mark, commercial registrar , the application of public law, the government and other interests.

      However, mechanisms to assure input of all affected parties are under consideration.

    • C.1 Would gTLD registries have input into ccTLD SO deliberations

      See the provision in the Bylaws, above.

    • C.2 . or would ccTLDs have input into DNSO deliberations?

      See the provisions in the bylaws, above.

    • C.3 If not, how would disagreements be resolved?

      The Bylaws provide the following in case of dispute:

      .If, after reasonable efforts, the Board does not receive a recommendation from the Supporting Organization that it finds meets the standards of Section 2(e) of this Article VI or, after attempting to mediate any disputes or disagreements between Supporting Organizations, receives conflicting recommendations from Supporting Organizations, and the Board finds there is a justification for prompt action, the Board may initiate, amend or modify and then approve a specific policy recommendation..

      See Article 2 (f)

    • C. 4 Would the Board resolve such disputes?

      Possibly, subject to the fact that the Board has no authority to compel an individual ccTLD to amend any of its polices. This is widely appreciated by Board and staff. Fortunately, the existence and nature of any disputes between SO.s is highly speculative.

    • C. 5 How would consensus among affected parties be developed and documented?

      In the same way it is in the ccTLD constiuency.

  4. Effect on the DNSO

    • A. If a ccTLD SO were created, what structural changes in any remaining DNSO would be necessary?

      We see no changes necessary in the DNSO consequent upon our departure.

      The cc managers have for some time taken little formal part in the DNSO. The constituency has provided no, or few formal direction to its DNSO representatives, who have, in turn, not advanced an authoritative cc perspective on many issues. The reality is that the business of the DNSO has been much taken up with gTLD issues, which is likely to remain its primary focus.

      We should be concerned, in fact, if our departure was seen as anything other than removing a non-gTLD component from an organisation well suited, and currently devoted to debating gTLD issues,. We note the difficulties the DNSO has with its relationship with the General Assembly, and the lack of representation of individual domain name holders, but leave aside comment on how those might be resolved within the DNSO. Neither seems a reason to break up the DNSO.

      However, it might be that we should express no view, in light of our departure.

    • B. Would current contractual documents be required to be revised if the Names Council no longer existed or if it was not a definitive source of judgment on consensus policies impacting gTLD registries? Should gTLD registries agree to any such changes?

      If by "current" contracts, you mean g-Registry/registrar agreements, possibly, but this seems an issue outside the scope of this debate. To the extent those contracts depend on proof of a developed consensus, and the Names Council is part of that proof, yes, but we see no reason deriving from the formation of the ccSO, to change the DNSO.

  5. Board membership

    • A. If a ccTLD SO were allowed to elect a specified number of members of the ICANN Board, would that diminish the role of the DNSO in selecting Board members?

      Not necessarily. Our proposal for the formation of an SO does not contain a prescription as to the source of Board seats, so does not prescribe any diminution in DNSO seats.

    • A.2 Would it increase the number of Board members familiar with registry operations?

      It would provide the board with spokespeople familiar with the development of policies relating to the ccTLDs.

    • B.1 Would creation of an sTLD SO increase the representation of the "registry voice" on the Board?

      There is no "registry voice". The issues relating to cctlds are dissimilar from those affecting gtlds, and on which the board has decided policies. CcTLD issues have not yet reached the board.

    • B.2 If sTLDs declined to continue to participate in the DNSO, would that force the creation of a separate SO for each category of registry?

      See response above.

    • C. If the main job of the Board is to recognize documented consensus, should Board membership be reallocated to assure that every group that could prevent a consensus (or unmask a false claim of consensus) on important policy issues has an appropriate voice?

      No. Every group, in each of the existing SO.s that feels a council decision does not represent consensus is free to make that position known to the board and the whole internet community. Board seats are not the way to unmask false consensus. Taking such a debate to the board confuses the role of the board between building consensus (through debate) and recognising consensus. We are opposed to moves which seek to dilute the policy-making role of the SO.s, and in particular, if this is achieved by shifting policy debate to the board which should occur within the SO.s.

  6. Structural proposals

    • A. What structural changes will make sense in light of ICANN's purpose?

      This is not the place for a wholesale review of ICANN s structure against its purpose. We propose a new SO, something contemplated under the by laws, and which need not affect other components, except consequentially. The Names Council Task Force on re-structuring is a better forum for that debate.

    • B. Should restructuring provide an occasion for reallocating fees and costs across a wider array of groups?

      We suggest that disruption be minimised, by making only those changes for which a comprehensive rationale exists, and which has the support of a wide range of ICANN constituents. The .spoiling. effect imposed by attempting to attend to multiple changes at once are a well known feature of organisational change failure, and one to be avoided.

    • C. Should a restructuring lead to substantial innovations in meeting structure and use of online deliberation tools?

      These are advantages which should be pursued for their own merit. Re-structuring is not a pre-requisite for improving techniques.

    • D. Would a realignment of interests around SOs, combined with separate at large elections of a few Board members and the creation of an open forum for public participation in each SO, help to resolve disputes concerning representation of registrants and individuals, diminish complaints regarding capture of the DNSO by particular constituencies and overlaps between DNSO constituencies, fix the dysfunctional performance of the General Assembly and Names Council, and remedy other problems?

      Possibly. These appear to be issues facing the remaining DNSO members.

© ccTLD Managers
Page updated : 2003-05-26 19:17:56