ERC's Response to Comments Received on its ccNSO Recommendations
29 May 2003
Committee
on ICANN Evolution and Reform
Response to Comments Received on ERC's ccNSO Recommendations
29 May 2003
Introduction and General Comments
The ERC would like to thank the members of the ICANN community who submitted comments to the ERC's Fifth Supplemental Implementation Report (Recommendations for the ccNSO). The ERC particularly appreciates the contributions of the Governmental Advisory Committee, CENTR, APTLD, TWNIC, and the At-Large Advisory Committee in submitting comments on the ERC's recommendations on the ccNSO. The ERC has carefully reviewed the comments, and provides to the Public Comment Forum this response to the comments received.
In some cases, the ERC received comments that were inconsistent with existing recommendations and past advice ICANN has received. In reviewing all of the advice, the ERC believes that its recommendations, as elaborated in this response, strike a common ground between different stakeholders, and different views. The ERC believes this common ground reflected in its recommendations of the ccNSO is important to ensure the role the ccNSO upholds is within, and supports, the ICANN mission to ensure the stable and secure operation of the DNS based on consensus and participation of all stakeholders.
Shortly the ERC will post bylaws and a complete explanatory note on comments received to accompany the proposed bylaw amendments.
In connection with the establishment of a ccNSO, the ERC wishes to make clear that ccTLD membership to the ccNSO is independent of any individual relationship a ccTLD has with ICANN or its receipt of IANA services.
With regard to ccTLDs, ICANN's role is limited to those matters that need coordination at the global level to ensure the DNS's stable and secure operation. The ERC was pleased to see that in comments and related discussions on the ERC recommendations, there was strong endorsement of the role of ICANN in the stability and security of the DNS, and in this regard, the role of the ccNSO in consensus development of global policies in line with ICANN's responsibility. The ERC believes that the framework for the scope enables an approach that is as alive as the Internet is, and will be capable of adjusting to the future of the Internet. It provides a method to make certain that the ccNSO, through its processes based on consensus, defines the scope and thereby the issues that require global policy making.
ccNSO Council and NomCom Appointments
The NomCom appointment to the Council of a Supporting Organization is a fundamental part of the ICANN Reform. It is in no way intended to bring representatives from different constituencies into the Council. As stated by the NomCom itself,
The objective of ICANN's new nominating process is to balance the Supporting Organization-based and constituency-based selection of Directors and individuals for other positions to ensure that ICANN can benefit from participants of the highest integrity and capability who place the public interest ahead of any particular interest, but who are nevertheless knowledgeable about the environment in which ICANN operates.
The ERC considers this necessary to ensure that the reformed organization is, and is seen as, open and transparent at all levels.
The ERC notes that some comments reflected a view that the NomCom should have an increase in the number ccTLD delegates, that is, that one ccTLD delegate on the NomCom was insufficient given it was selecting three members for the ccNSO Council. The ERC believes that this is a matter that it cannot address at this stage, as the NomCom is formed, and it is completing a selection process for both Directors and the GNSO and ALAC NomCom members. The ERC understands the concern. The ERC believes however that the issue of whether there should be more NomCom delegates from the ccTLD community should be taken up during the scheduled periodic review of the NomCom.
Related to the Council, comments received from the At-Large Advisory Committee welcomed possible exchange of observers between the ccNSO and the ALAC. The GAC has also expressed the interest to ensure good communication between the GAC and the ccNSO. The ERC strongly supports good communications between and among entities in the ICANN structure.
In answer to the comment made by the GAC – that in case of a disputed delegation a ccNSO manager cannot be appointed to the ccNSO Council – the ERC directs attention to section 3(d) of its recommendation on Nominations and Qualifications: Any ccNSO member may nominate an individual to serve as a ccNSO Council member representing the ccNSO member's Region. Nominations must be seconded by another ccNSO member from the same Region. ccNSO Council members must support the policies committed to by ccNSO members.
Removal of a Council Member will require 12 votes in favor from the Council members. If the Council Member concerned disputes such a decision no replacement shall be elected until the dispute has been resolved. The ERC recommends that in principle such disputes will be directed to the Ombudsman.
The ERC did not specify a Council quorum because it elected to have decision taken by an absolute number of votes (14) in favor.
The ERC received several sets of comments with regard to the scope of the ccNSO.
In this regard, the ERC would like to provide a point of clarification. The ERC's Fifth Supplemental Implementation Report referred to the ccNSO Assistance Group's recommendations regarding scope with a link to the matrix which was presented there. To solidify this clarification, the ERC has transformed the matrix presented in the ccNSO Assistance Group's Recommendations on Scope into a Framework for the Scope of the ccNSO that should form the basis of an Annex to the bylaws. Comments on this Annex are welcomed.
The ERC is aware of the concern expressed that the scope of the ccNSO should remain limited to issues of a truly global nature that pertain to the stable and secure operation of the DNS and the Internet. The ERC shares the views expressed and therefore – following the ccNSO AG recommendations – put a great emphasis on the ability of the ccNSO to define the scope itself assisted by the Scope Matrix, now Framework. Thus, ccTLD managers will themselves serve as a control on what will constitute "global policy".
The other set of comments the ERC received with regard to scope involved whether there was a need for a definition of the scope, or that the scope should be limited to IANA matters only. The ERC strongly believes that there should be a framework for scope as developed by the ccNSO-Assistance Group. This belief lies in the view that the ccNSO itself should decide what matters are within the global policy realm. To this end a framework best assists to identify what falls within a global policy and what does not.
The ERC believes that the issues of global policy as defined this way, developed through the ccNSO using its policy development process, and adopted by the ICANN Board, will have to have a binding nature for these policies to be effective relating to the stable operation of the Internet. In the absence – for the time being – of contractual relations between ICANN and most ccTLD managers, the ERC considers it advisable that ccNSO members declare to follow these policies as part of the membership agreement. ccNSO members have a voice in the establishment of these policies.
The ccNSO differs substantially in its composition from the other Supporting Organizations. It has only one constituency: ccTLD Managers. Ideally, of course, all ccTLD Managers should be members of the ccNSO.
The ERC hopes that that goal will be achieved in due course. The primary role – as defined in the Fifth Supplemental Implementation Report – of the ccNSO is to "be a policy-development body . . . which shall be responsible for developing and recommending to the ICANN Board substantive policies relating to country-code top-level domains." The ERC appreciates as a secondary role the voluntary or cooperative consideration of best practices for ccTLD Managers. The former aspect of the ccNSO mandates in the view of the ERC a commitment of the ccNSO members to abide by global policies developed through the ccNSO PDP.
It shall be clear that ccNSO membership is not, and cannot be, a condition for access to or registration in the IANA database. As noted above, ccTLD membership to the ccNSO is independent of any individual relationship a ccTLD has with ICANN or the ccTLD's receipt of IANA services.
The term "Sponsoring Organization", is in this case used in the sense of Registrant in the IANA database, and should be understood as such. The ccNSO-AG, and the ERC, spent much time grappling with the term to use that would ensure that the appropriate entity represented the ccTLD in the ccNSO, and concluded that it was best to refer to the entity identified under the heading "sponsoring organization" in the IANA database. The ERC understands that there is history behind this, which it truly hopes will one day be fully addressed and resolved – perhaps by the ccNSO.
Some comments noted that there should not be a requirement for a "letter recognizing the role of the ccNSO", or other form of commitment to become a ccNSO member. The ERC notes, as above, that the ccNSO differs from other Supporting Organizations in that it consists of one set from the ICANN community, and a set that is mostly not under contractual obligation to adhere to global policies.
The GAC has noted that in case of a contested delegation both parties should be able to attend. The ERC does not consider this to be a problem as in principle meetings of the ccNSO will be open. The ERC points out however that the ccTLD manager as registered in the IANA database shall qualify for ccNSO membership.
The ERC has great sympathy for the comments made that an exemption based on national policy, etc., should be granted unless two-thirds of the ccNSO Council rejects such an exemption.
One of the points expressed by members outside the ccTLD community was the need for consultation and communication between the different ICANN constituencies. This relates not only to the ccNSO Policy-Development Process, but also in general. In particular, the GAC has expressed a desire for good working relations between the GAC and the ccNSO. The ERC has already incorporated this in its recommendations and believes that good communication between the GAC and the ccTLD community should be an ongoing effort.
Another point expressed in several of comments was the view that the Board's role is to ratify the recommendations out of the ccNSO, or to revert them back to the ccNSO for further work. The ERC believes it has been clear in endorsing the ccNSO Assistance Group's recommendations that if the Board does not adopt the recommendations reached through the ccNSO PDP, the status quo will continue.
The ERC understands the view that a minimum of 40 ccTLDs managers must have joined before a Policy-Development Process can be undertaken. However, the ERC suggests that the number of 20 ccTLD managers remain, to ensure that the ccNSO's work can get started without significant delays. Should 40 or more members join, that is even better, and increases the breadth of input that the ccNSO and the Policy-Development Process will have immediately.
A long debate ensued about the various options for decision-making in both the ccNSO Assistance Group and the ERC. The ERC believes that the present proposal offers a right balance of authority and responsibility. The ERC is conscious of the fact that any system can be subject to capture or blockage. Nevertheless the ERC hopes that the ccNSO Council vote will carry the weight and authority in the ccTLD community. Instead of establishing a quorum for Council decisions the needed vote will be specified in absolute numbers. In case of the member vote, the ERC decided to forego a quorum provision specifically to prevent another mechanism that could result in blockage through non-participation.
The ERC notes that some comments reflected a view that the staff support should not come from ICANN. As noted on prior occasions, the ICANN will make staff support available, should a Supporting Organization choose to use it. The GNSO, for example, sought staff support to assist with the operations and administration of the GNSO, as well as helping prepare and do support work for its Policy-Development Process. It is up to the ccNSO to determine if it wants such support as well, or not. The funding of the ccNSO is for determination by the ccNSO, and for the ccNSO itself. It is separate and aside from ccTLD contributions to ICANN, which as is noted in this years proposed budget, is not relied upon by ICANN.
Launching Group (was Transition)
The ERC in its recommendations labeled the section regarding the Launching Group as transition. The comments received indicated that this caused some confusion. The Launching phase is not a transition – there will not be a transition Council. It is the ERC's view that after adoption of the changes to the bylaws there will be the launching of the ccNSO, accepting membership applications, and organizing the Council elections, followed by the seating of the NomCom selections of three Council members. Once the ccNSO Council is in place, the ccNSO itself can begin on substantive work, not before. The Launching Group is responsible for implementing the structure once the bylaws are adopted.
The ERC notes that some comments suggested that the Launching Group should consist of all and any ccTLD managers. The ERC believes that the ccNSO Assistance Group's recommendations should be adopted for the following reasons. The Launching Group has the sole responsibility to "launch" the ccNSO, and only that. There is much work to undertake, and the ERC would hope that within a short time the ccNSO would be launched, and the real work can be undertaken. For practical reasons, the ERC believes that a Launching Group based on inviting all ccTLD managers will prove to be impractical, and the burden of work will end up causing a delay in the ccNSO's formation. Additionally, because the Launching Group is solely for the purposes of launching the ccNSO, including arranging for the organization of the election of the first ccNSO Council, the ERC does not believe that members of the Launching Group should be prohibited from standing for election of the first Council.
The ERC agrees that the further ccTLD representation should be elected or appointed by the ccTLD community, in the regional manner described in the recommendations on ccNSO Council, with appropriate assistance of regional organizations where they exist.
Annex
Framework for the Scope of the ccNSO
The purpose of the ccNSO is to engage and provide leadership in activities relevant to country-code top-level domains, specifically by:
1. Developing policy recommendations to the ICANN Board;
2. Nurturing consensus across the ccNSO’s community, including the name-related activities of ccTLDs; and
3. Coordinating with other ICANN Supporting Organizations, Committees, and constituencies under ICANN.
The scope of the ccNSO's authority and responsibilities must recognize the complex relation between ICANN and ccTLD managers/registries with regard to policy issues. This framework shall assist the ccNSO, the ccNSO Council, and ICANN Board and Staff in delineating relevant global policy issues
The ccNSO's policy role ban be based on an analyses of the following functional model of the DNS:
1. Data is registered/maintained to generate a zone file,
2. A zone file is in turn used in TLD name servers.
Within a TLD two functions have to be performed (these are addressed in greater detail below):
1. Entering data into a database (Data Entry Function) and
2. Maintaining and ensuring upkeep of name-servers for the TLD (Name Server Function).
These two core functions must be performed at the ccTLD registry level as well as at a higher level (IANA function and root servers) and at lower levels (such as secondary 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).
1. Data Entry Function (DEF):
Looking at a more detailed level to the first function, entering and maintaining data in a database that should be fully defined by a naming policy. This naming policy must specify the rules and conditions:
(a) under which data will be collected and entered into a database or data changed (at the TLD level among others, data to reflect a transfer from registrant to registrant or changing registrar) in the database.
(b) for making certain data generally and publicly available (be it, for example, through Whois or nameservers).
2. The Name-Server Function (NSF)
The name-server function involves essential interoperability and stability issues at the heart of the domain name system. The importance of this function extends to nameservers at the ccTLD level, but also to the root servers (and root-server system) and nameservers at lower levels.
On its own merit and because of the interoperability and stability aspects, proper functioning nameservers isof utmost importance to the individual, as well as 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 policies in this area by adhering to the relevant RFCs, among others RFC 1591.
Respective Roles with Regard to Policy, Responsibilities, and Accountabilities
It is in the interest of ICANN and ccTLD managers to ensure the stable and proper functioning of the domain name system. ICANN and the ccTLD registries each have a distinctive role to play in this regard that can be defined by the relevant policies. The Scope of the ccNSO cannot be established without reaching a common understanding of the allocation of authority between ICANN and ccTLD registries.
Three roles can be distinguished as to which responsibility must be assigned on any given issue:
- Policy role: i.e. the ability and power to define a policy;
- Executive role: i.e. the ability and power to act upon and implement the policy; and
- Accountability role: i.e. the ability and power to hold the responsible entity accountable for exercising its power.
Firstly, responsibility presupposes a policy and this delineates the policy role. Depending on the issue that needs to be addressed those who are involved in defining and setting the policy need to be determined and defined. Secondly this presupposes an executive role defining the power to implement and act within the boundaries of a policy. Finally, as a counter-balance to the executive role the accountability role, needs to defined and determined.
The framework below offers an aid to:
1. delineate and identify specific policy areas;
2. define and determine roles with regard to these specific policy areas.
The framework presents a method to identify the allocation of authority among ccTLD managers and other stakeholders.
Level 1: the Root
Policy role: IETF , RSSAC (ICANN)
Executive role: Root Server System Operators
Accountability role: RSSAC (ICANN), (DoC-ICANN MoU)Level 2: ccTLD Registry Name Server
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 governmentLevel 3: User's Name Server
Policy role: ccTLD Manager, IETF (RFC)
Executive role: Registrant
Accountability role: ccTLD Manager
Level 1: ICANN (IANA): (name server changes, transfers, contact detail, changes)
Policy role: ccNSO Policy Development Process (ICANN)
Executive role: ICANN (IANA)
Accountability role: ICANN community, ccTLD Managers, DoC, (national authorities in some cases)Level 2: ccTLD Registry (registrations, transfers, deletions, Whois, dispute resolution)
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 casesLevel 3: Second and lower level Name Servers
Policy role: Registrant
Executive role: Registrant
Accountability role: Registrant, users of lower-level domain names
Questions concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.
Page Updated
26-Jan-2007
©2003 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.