ccNSO Assistance Group: Update to the Evolution and Reform Committee

22 October 2002

ccNSO Assistance Group
Update to the Evolution and Reform Committee
22 October 2002

Since formed, the ccNSO Assistance Group has been discussing the issues surrounding the implementation of the ccNSO, and possible recommendations to the Evolution and Reform Committee (ERC). On 4 October the Assistance Group provided the ERC with its Status Report on the progress of its work-plan, which is to come up with recommendations on 5 category areas identified out of the Blueprint. These are: scope of the ccNSO as a global policy-development body; process of policy development in the ccNSO; ccNSO membership; structure of the ccNSO; ccNSO Council.

In approaching its work plan, the ccNSO AG is cognizant of prior work by both the ccTLD registry community, as well as other Assistance Groups to the ERC. The existence of prior work is of great assistance to the ccNSO AG efforts in working towards recommendations.

Since its 4 October Progress Report, the Assistance Group has continued discussions on these recommendations and objectives, through on-line discussions and weekly conference calls.

As noted in its 4 October Progress Report, one area that the Assistance Group has focused on is that of scope. The Assistance Group believes that the outcome of the discussions on the scope of the ccNSO will be instrumental in determining the outcome of the discussions in the other areas identified in the Blueprint and is the starting point to build confidence in the ccNSO.

With regard to scope, the Blueprint notes that the ccNSO will be responsible for engaging in activities relevant to country-code top-level domains, "specifically (1) developing policy recommendations to the ICANN Board; and (2) nurturing consensus across the ccNSO's constituencies, including the name-related activities of ccTLDs." While recognizing there are global policy issues relating to ccTLDs, the Assistance Group also recognizes the challenge in identifying what they are, or what criteria are used to determine what they are.

That is, the approach the Assistance Group is taking is one that seeks to mould a high-level framework to assist in the formation of a Supporting Organization that has the components and tools to focus authoritatively on the needs for effective global co-ordination at ICANN whilst providing a forum that fully represents the local context for ccTLD operations. The Assistance Group recognizes the complex history of DNS management and has determined a framework that may provide a sound methodology for the future to define openly responsibilities and other roles in functional areas of the DNS management.
In light of this, the Assistance Group recommends:

• seeking structured input during the upcoming Shanghai meeting on the framework it has been discussing to address scope, attached in Annex A.
• that subsequent to the Shanghai meeting, it proceed with incorporating the structured input received on the framework and prepare further its recommendations for the 5 work-plan areas for public comment and for the ERC to consider.

The Assistance Group, together with the ERC, would request the ccTLD Administrative Committee to provide time on the ccTLD managers meeting to brief the ccTLDs on the framework and receive input on the draft framework.

Annex A

Introduction¹

According to the Blueprint the purpose of the ccNSO is to be engaged in activities relevant to country-code top-level domains, specifically:

(1) developing policy recommendations to the ICANN Board; and

(2) nurturing consensus across the ccNSO’s constituencies, including the name-related activities of ccTLDs.

This paper only addresses the first set of activities, the development of policy. It seeks to offer a framework to delineate bits and pieces of the complex relation between ICANN and ccTLD managers/registries with regard to policy issues. Feedback and discussion is sought on the framework as a way to proceed.

Defining Roles of ccTLD Managers and ICANN with Regard to Policy, and Respective Responsibilities and Accountabilities

In the interests of both ICANN and ccTLDs to ensure the stability and proper functioning of the domain name system, it is recognized that both ICANN and the ccTLD registries each have a distinctive role to play. These roles are defined by the relevant policies.

The principal underlying issue in the discussion on scope is the different views with regard to responsibilities of the ccTLD manager vis-à-vis the responsibility of ICANN (that is, the local versus global responsibility issue). This underlying issue is constantly arising when discussing and trying to identify the different functions to be performed.
The responsibilities issue covers three elements or roles:

Policy role: meaning the ability and power to define a policy;

Operational role: meaning the ability and power to act upon and implement the policy; and

Accountability role: meaning the ability and power to hold the responsible entity accountable for exercising its power.

In this approach, first, a fully defined policy delineates the policy role. Depending on the subject of the policy those who are involved in defining and setting the policy are determined and defined. Second, within in this, defining the power to implement and act within the boundaries of a policy, that is, the responsibility to act upon a policy. Finally, a well-defined policy clearly identifies the accountability role as a counter-balance to the responsibility role. Policy areas

With regard to the policy area, there is the following functional role/model of a TLD:

1. Data are registered/maintained to generate a zone-file,

2. Which in turn is then used in TLD name servers.

Therefore within a TLD two functions have to be performed, addressed in greater detail below:

1. Entering data into a database (DEF) and

2. Maintaining and ensuring upkeep of name-servers for the TLD (NSF)

Looking at the domain name system as a whole, these two functions do not only need to be performed at the level of TLDs but also at the hierarchical higher level (IANA function of ICANN and Root Servers) and at lower levels (such as, for example, the .eu.com). This mechanism is pointedly stated in RFC 1591 is recursive.

"There are no requirements on subdomains 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 subdomains shall be allowed to operate their own domain name servers, providing in them whatever information the subdomain manager sees fit (as long as it is true and correct)."

Clearly, in the last five to six years, the number of domain names registered has increased exponentially due to the rapid growth of the Internet. As a consequence of this growth the impact on, and requirements by, society with respect to the domain name system increased. As a result, the first function (DEF) became more important in its own right (in hindsight: from auxiliary to name server function to second core-function).

For the same reasons some latent, or secondary functions, have become important in their own right over time as well (such as, for example, WHOIS). However, these added functions derive from and are only secondary to the two core functions mentioned above and are not necessary to run a TLD.

The Core Functions

1. Data entry function (DEF):

Looking at a more detailed level to the first function, entering and maintaining data in a database, it should be fully defined by a naming policy. This policy specifies the rules and conditions:

(i) Under which data will be entered or data changed (at the TLD level among others, data to reflect a transfer from registrant to registrant or changing registrar) in the database.

(ii) For making (some) data general and publicly available (be it, for example, WHOIS or name-servers).

2. The Name-Server Function (NSF)

With regard to name-server functions, interoperability and stability issues of the domain name system are addressed. The whole purpose of using domain names is reflected in this function of the domain name system. It does not only cover name-servers at the TLD level, but also the root-servers (system) and name-servers at lower levels. Without a proper working of this function there is no use to collect and maintain the data.

On its own merit and because of the interoperability and stability aspects, the proper functioning name-servers are of utmost importance to the individual, the local and the global community.

With regard to this function therefore, again policies need to be defined and established. By their nature these policies are more technical and some people would even call them technical standards. In fact, most parties involved including ccTLD managers have more or less accepted this implicitly by adhering in the past to the appropriate RFC’s, among others RFC 1591.

In referring to RFC 1591, or even ICP-1, from this perspective it is clear this area is not fully defined. For example, RFC 1591 no longer captures all relevant aspects of ensuring the proper working of name-server function. As the use of domain names has increased, the aspects necessary or beneficial to ensuring proper functioning nameservers likewise has changed over time.

Framework for Analyses

Combining these two perspectives, policy and functions, the following framework emerges:

The framework as presented above offers the possibility to:

1. Delineate and identify specific policy areas;

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

With regard to the delineation of the specific policy areas one has to be aware of the trade off between precision/granularity and practical use.

The sample below is as presented in the original paper provided to the assistance group. It is presented here as an example to show the use the framework to describe the current state of affairs:

Note:

1. This paper is based on a paper of Bart Boswinkel and Jaap Akkerhuis, working with SIDN, the registry for .nl. The original paper was contributed to the ccNSO Assistance Group for its discussion on scope. The Assistance Group is grateful for the contribution, and has found the framework presented extremely useful to focus thinking. It recommends to the ERC that the framework presented is provided to the community to discuss and provide feedback and input on this type of framework, for further consideration by the ccNSO Assistance Group.

Page updated 22-Oct-2002
©2002 The Internet Corporation for Assigned Names and Numbers. All rights reserved.