SRS Working Group Final Report 20/10/00

Review of Registry Structure of the .nz ccTLD

Final Report

Document Status

Status: Final Report.
Date: 20 October 2000.
Authorship: SRS Working Group (John H. Hine, Chair; Steven Heath; Rick Shera; Don Stokes).

This is the final report of the SRS Working Group. The report will be considered by the Council of ISOCNZ at its meeting on 26 October, 2000.

The working group thanks the many members of New Zealand's internet community who have contributed in ways big and small to the production of this document. A number of people have taken considerable time to provide careful and insightful analysis of our various drafts and to suggest alternative components. This effort has been greatly appreciated.

Executive Summary

The working group's second draft was considered at the ISOCNZ AGM and recommendations one through five of that draft were approved (with minor amendment) by the AGM. Of the five passed at the AGM four are incorporated into this final report, renumbered and identified. The fifth, recommendation three, was "ISOCNZ establish policy setting standards for the proper governance of the relationship between registry, registrar and registrant." This recommendation is now covered by an extensive section on contracts and has not survived verbatim in the final report.

The recommendations of the final report follow. Those marked with an asterisk (*) have already been approved from the second draft presented to the AGM.

*Recommendation 1. ISOCNZ should alter its policy to remove the registration function from the registry. The registry should focus on registrars as its customers.

*Recommendation 2. A standing committee be established to maintain communication between the registry and registrars. The standing committee should be chaired by a member of the ISOCNZ Council and should include technical representatives from the registry and a minimum of two different registrars and/or agents.

Recommendation 3. A registrant authentication field should be included in the register. The designated registrar shall make the contents of the authentication field available to the registrant on demand.

Recommendation 4. Registry information.

All information that the ccTLD manager requires to be available should be held in the registry and should be public (other than the authentication field which would only be available to the registrant and its designated registrar).
The registry should operate both a basic whois service and a web based information service to provide this information to the public.
There should be no change to the information required to be publicly available. This information should remain consistent with the requirements of RFC 1591:

domain name,
registrant name,
nameservers,
administrative contact information, and
technical contact information.

To this should be added the designated registrar's name and url as well the registrant authentication field.

Recommendation 5. ISOCNZ, acting as ccTLD manager, should ensure that a contract structure along the lines of that described in paragraphs 82 to 93 is put in place to support the proposed SRS framework.

Recommendation 6. The registry should maintain an audit of all transactions against the register capable of reproducing the state of the register at any point in time as well as recording all transactions. The audit should be kept indefinitely. Subject to privacy/confidentiality requirements and any necessary cost recovery, any person involved in a claim or dispute involving a domain name will be able to obtain a certified copy of the relevant audit records from the registry. Those records shall also be made available at the same time to the ccTLD manager.

Recommendation 7. ISOCNZ should accurately define the role of ccTLD manager and establish the office of "ccTLD Manager" with adequate resources to develop, promulgate and administer policy; to negotiate and manage contracts; and to administer the resolution of disputes. This office should be paid for by the internet community.

*Recommendation 8. ISOCNZ should revise its charging policy to encourage registry charging to:

Be focused on the registrar as a customer.
Reflect a registrar's use of the register.
Be independent of any contract or agreement between registrar and registrant.

The registry should charge the registrars to recover both its costs and the costs of the ccTLD manager. While the registry will act as a single collection agent the separate costs of registry and ccTLD manager operations should be clearly transparent, though not necessarily separate line items in the invoice.

*Recommendation 9. ISOCNZ adopt a best practice policy.

Recommendation 10. Organisations that have decided or wish to moderate their own second level domains within .nz shall be responsible for ensuring that moderation is done as part of the registration process.

Mandate

Within New Zealand responsibility for the .nz domain name space rests with the Internet Society of New Zealand. The Objects of the Society include:

To promote the competitive provision of internet access, services and facilities in an open and uncapturable environment;
To develop, maintain, evolve, and disseminate standards for the Internet and its inter-networking technologies and applications; and
To coordinate activities at a national level pertaining to good management of centralised systems and resources which facilitate the development of the Internet, including but not limited to the Domain Name System;

At the Society's AGM held in December 1999 a motion was carried:

That ISOCNZ Council set up an open working group to investigate a full proposal on possible shared registration systems and other registry models after consultation with Domainz.

The working group was established at the Council meeting of 31 March 2000. The membership of the working group was:

John H. Hine, Victoria University of Wellington (Chair)
David Farrar, Office of the Leader of the Opposition
Steven Heath, SeraNova
Rick Shera, Lowndes Jordan Barristers & Solicitors
Don Stokes, Independent Consultant
Peter Dengate-Thrush (ex-officio) Chair of ISOCNZ
Sue Leader (ex-officio) Executive Director of ISOCNZ

David Farrar resigned from the Working Group on 18 April and Peter Dengate-Thrush withdrew on 19 April 2000.

Definitions

The Domain Name System (DNS) is the system used by the Internet to translate domain names such as isocnz.org.nz into network addresses that allow one computer to connect to another. There are approximately 250 top-level domains. The majority of these are country code top level domains, ccTLDs . These names all use the two letter ISO-3166 standard abbreviations for country names. There are also seven generic top level domains, gTLDs . Ideally these would all be international in nature. For historic reasons some such as .org and .com are and others are focused on the United States.

Within the .nz ccTLD there are currently ten second level domains ( 2LDs ), each representing a separate community of interest.

In discussing the roles that are found in the management and operation of the DNS the working group has chosen to adopt terminology already broadly accepted in the internet community.

Registrant
An entity with rights to the use of a domain name within the .nz name space. (Current practice within New Zealand also often refers to the registrant as the name holder .) The registrants are the ultimate customers of the system described here and their rights are supreme.

Register
The central database holding all information required by the Domain Name System, and possibly additional data, for .nz. The register is the authoritative source for the creation of the primary zone files for .nz.

Registry
The organisation holding and operating the register, including the transfer to the zone files. The nature of the Domain Name System requires that there is one register. It's operation is a natural monopoly.

Registrar
An entity that registers names with the registry on behalf of registrants. Registration of domain names is seldom the core business of a registrar.

Agent
An entity that registers names through a registrar on behalf of registrants. An agent is usually differentiated from a registrar on the basis of indirect access to the register compared with a registrar's direct access.

Name Service Provider

An organisation that provides name-address translation with the DNS for a delegated zone. The name service provider will often be the registrant's ISP or web host, but this is not necessarily the case.

ccTLD Manager
The ccTLD Manager is responsible for setting policy and for ensuring the correct and efficient overall operation of the DNS within New Zealand. For .nz the ccTLD Manager is ISOCNZ.

Terms of Reference

The terms of reference of the working group as resolved by the Council of ISOCNZ on 31 March 2000 are:

Ascertain the requirements and views of the New Zealand internet community with respect to the appropriate framework for a shared registration system including the rights, responsibilities and relationships among the registry, registrars and registrants.
Determine any constraints placed on a shared registry system by any RFC or other national or international convention applicable to the .nz name space.
Recommend to the ISOCNZ membership new and/or revised policy on a shared registration system including:
1. Rights, responsibilities, obligations and duties of registrants, registrars and the registry.
2. Any limitations that should be placed on the business or technical relationships between registrant/registry, registrant/registrar and registrar/registry.
3. Any quality of service performance requirements that should be placed on the registrars, registry and/or registrants.

Background

ISOCNZ was established in 1995 to maintain a degree of "public good" control over the development of the Internet in New Zealand. This included the operation of the Domain Name System (DNS). At the time the University of Waikato managed and operated the register. Both the University of Waikato and Victoria University of Wellington accepted new registrations, each looking after a different set of second level domains within .nz.

ISOCNZ established a number of working groups and committees throughout 1996 and 1997 to establish policy governing the .nz ccTLD and to take over the management and operation of the DNS for .nz. The following summarizes the outputs of these efforts and the current situation.

A company, the New Zealand Internet Registry Ltd., was established to take responsibility for the day-to-day management of the DNS. NZIRL trades as Domainz. ISOCNZ retained the policy making role for .nz including the DNS.

Domainz has progressively migrated the various components of the operation of the DNS from the Universities to itself. This migration was completed in May 2000 when Domainz took responsibility for the operation of the register from the University of Waikato.

In August 1997 the Council of ISOCNZ approved as policy the document Future Development of the .nz Domain Name Space [ 1 ]. This document is principally concerned with names within .nz.

A second policy document, DNS Administration within New Zealand [ 2 ], was also approved by Council in August 1997. This document envisioned NZIRL acting in the role of contract manager with much of the operational components of the DNS tendered to different companies. Tendering has not proceeded. Comment on the lack of progress with tendering can be found in [ 3 ].

A further policy document is The New Zealand Domain Name Structure [ 4 ]. This document clearly states the "first come, first served" principal upon which names are allocated within all unmoderated 2LDs within .nz. The working group is unsure of the authorship and authority of this document which combines various ISOCNZ and Domainz policies.

The paper DNS Administration within New Zealand is current ISOCNZ policy and has provided the framework within which Domainz and ISOCNZ have developed DNS management and services. It states a set of values:

ISOCNZ views the following items as important when discussing the future provision of DNS services:

Of paramount importance is the continued reliability of the Internet.

We wish to ensure that the New Zealand Internet remains "open and uncapturable".

Consequently we wish to allow and promote competition in service provision as far as possible.

Areas where competition is not possible should be strictly delineated and put up for tender.

The document envisions Domainz operating a registry function with registrants having the choice of registering names directly with the registry or through a value added agent such as an ISP. The analogy is with the insurance industry. This document predated the distinction drawn today between a registrar and an agent.

Concurrent with developments in New Zealand the international situation has also changed dramatically. Control of the generic top level domains that are not United States centric has been passed from the United States Government to the Internet Corporation for Assigned Names and Numbers (ICANN).

The World Intellectual Property Organisation (WIPO) has also increased its interest in the Internet and in domain names in recent years. While the organisation's focus is on intellectual property rights the The Final Report of the WIPO Internet Domain Name Process [ 5 ] contains considerable input on the operations of registrars and to a lesser extent registries.

In his paper, Governance in the .NZ DNS - A Position Paper [ 6 ] presented to ISOCNZ's April 1999 Summit on DNS developments, Patrick O'Brien, CEO of Domainz, cited a number of possible impacts of the ICANN process on the .nz domain name space.

ICANN addressed the issue of the monopoly operation of the registry for the gTLDs by developing a model of a shared registry system (SRS). O'Brien suggested that this model or some variant may be appropriate for use in ccTLDs such as .nz.

ICANN has required gTLD registrars to make use of a dispute resolution procedure in situations where disagreements arise over the rights to the use of a name. To date the requirement to use this procedure is restricted to the gTLDs, however the intellectual property lobby would like to see that requirement extended to the ccTLDs.

ICANN imposes strict accreditation guidelines on registrars in gTLD name spaces. It is possible that it may seek to impose similar guidelines on registrars in lightly regulated ccTLDs.

ICANN requires gTLD registrars to submit a daily escrow of their registers. It is possible that it may seek to extend this requirement to ccTLDs as well as gTLDs.

Since O'Brien's paper was written ICANN has developed one SRS model to include a registry that offers no services to registrants, holds minimal information in the register and deals solely with accredited registrars. ICANN has not progressed the remaining issues having higher priority concerns. One reasonable certainty is that ICANN will be seeking contractual arrangements with all ccTLDs as a method for securing funding. This will provide an opportunity for ICANN and the ccTLD to negotiate on other issues.

Domainz and the .nz Name Space

The statistics included in the following description of the services currently provided by Domainz have been supplied by Domainz.

As of mid October there are approximately 74,500 domain names registered within .nz. The vast majority of these are in the .co second level domain.

Domainz is the authoritative source for contact information for 100% of names within the .nz name space.

Consistent with the policy expressed in [ 2 ] Domainz accepts new registrations directly from registrants and also through intermediaries. Approximately 95% of the names currently registered have been registered through an intermediary and 5% have been registered directly with Domainz. Approximately 185 intermediaries have registered 30 or more names.

In October 2000 the top 10 intermediaries had registered the following numbers of names:

Xtra	11,900
IHUG	4,550
Clear	4,500
Register.com	4,000
Asia On Line (NZ)	2,350
Paradise	2,050
Free Parking	1,400
NetLink	1,150
Digiweb NZ Ltd.	950
Wave Internet Services	950

(2Day Internet were listed as the second largest intermediary in the 2nd draft report. Since then they have ceased to act as an intermediary for Domainz, however there are still 7,800 names registered with a 2day name service.)

These top ten account for just under half of all names registered within .nz. The 5% of names registered directly with Domainz places it just below Register.com.

Of the names registered about 50% have had contact information changed by an intermediary, 30% have been changed by the registrant and 20% have had no changes. Thus a higher percentage of registrants have been willing to effect changes of information than to establish a new name. The working group believe that this reflects the technical expertise required to initially establish a name as opposed to the ease with which a field can be changed using a web-based form.

In September 2000 the number of registrants changing their intermediary was running up to 200 per week. While it is difficult to confirm both the working group and Domainz staff believe essentially all of these changes are done in conjunction with a change of service that involved name service provision, e.g. ISP or web host.

Maintaining the accuracy of contact details has been a problem. In 1998 40% of registrant contact details were invalid. This was measured by the percentage of invoices that were initially returned because the address was invalid. Today that figure is down to 10-15%.

Domainz charges registrants on an annual basis. Today Domainz invoices 70% of registrants directly and the remaining 30% through about 200 intermediaries. Domainz's stated goal is to reverse these figures reducing direct invoices to 25% of registrants.

While the focus of this review is on the relationships between registry, registrar and registrant we should not forget that the end goal is the functioning of the DNS. Domainz currently builds new zone files twice daily, seven days a week.

ISOCNZ policy clearly makes a registrant's control of its name(s) paramount. Currently, a registrant always has recourse to Domainz to rectify problems. Domainz achieves authentication with a password system, issuing a password to each registrant. The password may be used by the registrant to gain direct access to their record in the register.

A portion of second level domains within .nz are moderated. The names registered within these domains are less than 1% of all registrations. Registration of a new name within a moderated domain used to require manual intervention, but is now handled by automatically forwarding an e-mail request to the moderator.

Customer enquiries are an important aspect of Domainz's day to day operations. Currently 50% of enquiries are billing related, less than 5% are technical and about 10% relate to lost passwords.

Domainz does not provide additional services to registrants. In particular, Domainz does not host domain names.

Consultations and Submissions

Input was solicited in a variety of ways.

The working group established a project web site at http://www.isocnz.org.nz/dns/dns-dmr00-index2.html and a discussion mailing list, model-review@isocnz.org.nz, for the project.
The working group sent announcements to the relevant on-line mailing lists indicating that the terms of reference and background information were available on the web site. These lists included ISOCNZ's public and members lists and the New Zealand network operators group list.
The working group mailed an announcement of the review and the terms of reference to:

ISOCNZ's list of internet industry businesses,
relevant professional groups such as TUANZ and ITANZ,
relevant government departments, and
miscellaneous organisations such as the Consumers Institute.

A total of 122 organisations were contacted directly and asked to contribute.

All announcements welcomed submissions and these have been posted on the project web site to promote further discussion.
The working group held open forums in Auckland and Wellington.
The working group visited four of the top ten users of the current system and has made three visits to Domainz. One of those was specifically targeted at learning about the new Domainz Registration System.
The working group sought information from the web sites of ICANN, CENTER, and a number of ccTLDs. Additional input was sought and obtained from the Swedish NIC and Canada's CirA
The working group released and posted a number of draft documents:
- A first draft dated 19 May and discussed by Council on 26 May. This draft was posted to the web site on 2 June.
- A second draft , which constituted a major milestone, was published on 19 June 2000.
- Three strawmen models of a framework were posted on 11 September.
- The strawmen were followed by a woodenman model on 10 October 2000.
The June 19th draft was circulated to over a hundred of the organisations that had received the original announcement of the review.
Some or all of the working group held meetings with the Commerce Commission and the Privacy Commission to discuss any concerns that may have been raised by the June 19th draft.
Members of the working group have participated in the discussions on the model-review mailing list.

Appendix A lists the input the working group received. The working group appreciates the time individuals have taken to assist it with its work.

The working group was disappointed with the results of its initial efforts to generate input. The publication of the draft report and the subsequent strawmen and woodenman models have generated more interest and useful discussion. Still name holders have shown little interest, which may indicate that the issue is too arcane to motivate the typical internet user. In many cases input was received from employees of organisations rather than from the organisations themselves. This may reflect that name registration is seldom a significant part of an organisation's business but a key responsibility for technical staff.

While input has been limited it has often been of high quality. The working group has heard from and/or met with a number of the larger users of the current system. The working group believes that the lack of additional input supports the conclusion that the community is satisfied that input received to date is consistent with their own views. The following paragraphs present the key issues that have been raised through the consultation process.

Ownership of Names . The community is united in support for the current policy that a registrant's rights over their domain name(s) is paramount. A registrant's instructions should always be followed in full whether issued to an agent, a registrar or the registry. No instructions should be actioned without the registrant's authority.

Registrant Benefits . The system should be run for the benefit of the registrants. The current system successfully and rapidly registers names. From May 2000 the cost of registration, which was not seen as an issue, was reduced.

Business Relationships . Registering a domain name is simple and the consequences should also be simple. Registrants do not want multiple contracts or invoices and other communication from a registry they are unaware of. Registrants are confused about who to contact with problems, they contact their ISP about domain name problems and Domainz about network problems. These multiple relationships also cause problems for registrars/agents.

The Domain Name Market . There is a developing market which is seeing a requirement for varied needs: permanent registration, short-term registration, parking, trustee registration (e.g. company start up situation). Potential registrars include law firms acting on behalf of clients to register names in the same way that they incorporate companies online at the Companies Office on behalf of clients. The current "one model fits all" approach is inadequate; there is no single registrar that is right for all registrants.

Ownership of Register Data . The community asserts that the data held in the register is not owned or controlled whether structurally or by contract) by any registrar or the registry. The data is held on behalf of the registrants. The ownership of the register itself (schema, software, etc.) is less an issue as long as the registry is owned or controlled by ISOCNZ.

Monopoly and Competition . The role of the registry in managing the register for the .nz domain name space is a natural monopoly. The management of the monopoly operation should not have the potential to use its position to (1) artificially increase the price of a domain name; (2) reduce the range of services available to registrants; or (3) hinder the development of registrars or agents making use of its services.

Best Practice . A registry owned by ISOCNZ should operate in a manner consistent with ISOCNZ's stated objects. It is also a monopoly and as such should not fear competition or the risk of disclosure of corporate information. Rather it should operate in a cooperative manner to foster the broadest development of the Internet within New Zealand.

Combined Registry/Registrar . It is unfair to make other registrars compete against a registrar that controls the registry. A single business performing as both a registrar and a registry has an obvious conflict of interest and is likely to focus on the registrar business at the expense of the registry business. The current situation is given as evidence of this.

A SRS Architecture . Several submissions proposed specific alternative frameworks for the DNS within New Zealand. While differing in some detail they were generally consistent in the major aspects of the architecture.

The registry is the necessary monopoly. As such it should be minimal and should not constrain competition amongst multiple registrars.

Registrars would directly update the register through an interface provided by the registry.

Registrars would be free to set fees and design services as they see fit.

The registry should be run independently of any registrar and on a cost recovery basis.

A "special case" must be made for moderated domains. Suggestions included a registry function that would make moderation transparent to registrars and registrars dedicated to specific moderated domains.

The register should contain relatively minimal information. The double storage of identical information in two databases should be minimised.

Any barrier to becoming a registrar should be minimal.

The registry should have a "technical" focus with an emphasis on providing robust and highly available services. There should be regular (e.g. weekly) liaison between the registry and the registrars to ensure a seamless operational interface.

The "customer" focus should be the responsibility of the registrar. Registrants deal only with registrars and/or agents.

Registrant Rights . Both forums spent considerable time discussing how the rights of a Registrant might be upheld in a SRS model as described above. There were two key conclusions:
- The registrant should always be able to confirm the information held in the register about their name and themselves.
- The registry must be able to initiate contact with the registrant if for any reason the linkage through a registrar becomes broken; for example, if the registrar were to fail.

Discussion subsequent to the publication of the 2nd draft report and the strawmen models confirmed the first of the above and identified two further rights:

Unimpeded use of their domain name at a fair price. No action by a registrar or the registry should prevent or unnecessarily delay the full use of a domain name on the Internet.
Free choice of registrar. The registrant should be able to change registrar at any time. This should not impact their use of the name in question.

Policy . ISOCNZ policy making is valuable and should be paid for by those that benefit. With respect to the DNS the beneficiaries are registrants and registrars.

Change . Change always incurs a cost, however change to an interface used by several hundred organisations can incur considerable cost. If possible, the current interface should be preserved for a reasonable period.

Findings

The working group considers it appropriate to consider both the performance of the current model and the performance of ISOCNZ and Domainz within the current model against both the objects of the Society and the values set out in DNS Administration with New Zealand [ 2] and paragraph 12.

Domainz has been very successful in migrating domain name registration from a volunteer project at Waikato and Victoria Universities to a business.

It supports approximately 74,500 registered domain names within the .nz namespace as of October 2000.

Its performance with respect to registration has been outstanding, indeed in terms of the efficiency of its registration system it justifiably claims to be a world leader.

The DNS itself, i.e. the translation of names to addresses has functioned without problem under Domainz's control.

It has successfully resolved issues such as the validity of the first come first served policy.

Through April 2000 Waikato physically managed the register under contract to Domainz, while Domainz developed the business of registering names, invoicing etc. Within the strict definitions of registrar and registry Domainz served as a registrar and Waikato University was the registry. This has confused the role of Domainz in the eyes of the community. From May 2000, with the introduction of its new registration system, Domainz has clearly assumed the role of registry, looking after the register directly as well as continuing with the registration of names. Domainz also continues to offer direct registration to registrants and thus also plays the role of a registrar. In October 2000 it was the registry's fifth largest customer.

In other areas Domainz's operations may be viewed as confusing the roles of registry and registrar, but this largely depends on the functions one assigns to each role. The set of functions that should be assigned to a registry and registrar are not clearly defined. Domainz currently maintains a billing relationship with 70% of its registrants and a password for 100%. Other ccTLD registries have similar relationships with registrants.

The United Kingdom's Nominet has a contractual relationship between the registry and the registrant. Registrants may be billed directly and are issued identifying certificates to handle authentication.

The Swedish NIC requires all registrations to be done through a registrar, but that is the end of the relationship between registrar and registrant. The registry issues certificates to registrants to be used as authentication if needed and bills them directly. DNS operators such as ISPs handle initial and subsequent delegations.

Internet Names Australia is responsible for the com.au second level domain. It maintains a contractual relationship with each registrant, carries out billing and issues passwords.

Canada's new registry, CirA, is developing a model similar to Nominet. CirA plans to involve the registrant directly in all transactions, receiving notifications for non-critical changes and being required to acknowledge critical changes as part of the process. Billing is done through registrars. Thus, while CirA will not deal directly with registrants they will need to issue authentication keys to all registrants.

Domainz is also acting consistently with Nominet in attempting to reduce direct billing to a minimum by introducing significant price differentials favouring the use of a registrar. CirA, while borrowing heavily from Nominet's design has anticipated this trend and will do all billing through registrars.

In its own submission Domainz acknowledges that it views its business as being more than looking after the register. It states "We also recognise that certain categories of customer such as patent lawyers take an active interest, and in future, special facilities may need to be provided for such users ...". Elsewhere it states "... we believe that the country code registries may need to be even more competitive (price and service) given the opening up of the gTLD space." Both of these statements envision enhancing services above and beyond the minimal monopoly that ISOCNZ has mandated and confuse the issue of whether or not Domainz acts as a registrar.

Domainz's position as both a registry and a registrar creates a conflict of interest with respect to the operations of the registry for the benefit of other registrars.

Ideally Domainz would present the same registry interface to all registrars including itself. This interface would be designed to have minimal impact on the nature of services that registrars might offer to registrants. Instead we find that Domainz uses a single business model for both registrant and registrar.

The annual billing cycle does not fit well with some registrar's business systems. Consequently these registrars have chosen not to re-bill and Domainz has billed directly. Customers are often confused by the bills received from Domainz.
Customers lose their password, or may never have been given it, and expect their registrar to help them re-establish authentication. Registrar's cannot do this.
Customers are often confused by unsolicited messages from Domainz.

Domainz has provided an excellent service to registrants who are happy to register a name on a long term basis and make annual payments to Domainz for that registration. This reflects a customer focus on registrants which is wholly appropriate for those registrants who register directly with Domainz. This model has also been the only one available to registrars. The working group has been told that this has inhibited the development of alternative services that some registrars would like to offer and confused registrants as to whether the registrar or Domainz is responsible for resolution of a particular problem.

Domainz accredits other registrars to use the registry. While there is no evidence that this has been abused there is a clear conflict of interest.

The working group interprets the objects of ISOCNZ and the values given in [ 2 ] to mean that the registry should operate in a cooperative fashion to facilitate the operation and development of the Internet in New Zealand and should not abuse its monopoly status. There has been broad based comment and complaint about Domainz's lack of consultation, particularly on technical interfaces. The working group notes that Domainz is not perceived as operating in the fashion just described.

At the time original policy for the .nz namespace was being developed there was deep concern for the rights of name holders (registrants). With respect to the DNS the phrase "open and uncapturable" was interpreted to mean that no rightful registrant of a name could have that name taken away or constrained in a manner that prevented the registrant from having a free choice of service provider.

The working group believes that the "rights" that a registrant can expect are better understood today.

A registrant has the use of any name for which it holds intellectual property rights, e.g. trademarks.
A registrant is free to choose its preferred supplier of any internet related service, including domain name registration and name service provision.
A registrant's instructions with respect to its domain name(s) will be followed promptly and accurately.
No instructions with respect to a registrant's domain name(s) will be followed unless they are issued with the authority of the registrant (either directly or indirectly).
The cost of domain name registration within .nz will be internationally competitive with due consideration for the scale of the name space.
The market for services related to domain names will be open and competitive with no significant barriers to the entry of new services.

The preceding list reveals conflicting pressures in current ISOCNZ policy. Domainz's current position as both registry and registrar is at odds with the intent of ISOCNZ in [ 2 ] to establish a minimal service representing only the monopoly component of the DNS operation. However this position arose because ISOCNZ required registrants to have direct access to the registry as a way of protecting their rights to their domain name(s). Domainz has chosen to provide this protection by issuing an ID and password to all registrants.

The requirement for annual and direct billing of registrants will also be found in [ 2 ]. Thus it is ISOCNZ policy that has established the relationships that Domainz now holds with registrants. It is also ISOCNZ policy that has led to significant customer support efforts which lift the cost of a domain name.

It has become evident to the working group that the range of relationships that may exist among a registrant, a registrar and the registry is a source of considerable confusion and may be a principal problem.

A registrant may deal directly with the registry assuming all responsibility for registration, maintenance of information and payment.
A registrant may have its name initially registered by a registrar, but may then be asked to assume subsequent maintenance and payment.
A registrant may have a registrar do initial registration and provide ongoing maintenance but expect the registrant to handle payment.
A registrar may handle initial registration, ongoing maintenance and payment but provide the registrant with the registry user id and password.
A registrant may have the registry hidden by a registrar that does the initial registration, rolls payment into its other charges and provides ongoing maintenance. Such a registrant may be surprised when it receives a communication from the registry.

Key Issues

As the working group has come to fully understand the issues involved it has become clear that the question is not so much "Should ISOCNZ adopt a shared registry?" but "What form of shared registry should ISOCNZ policy specify?" It has always been the intent of ISOCNZ that what is now called the registry should be shared amongst competing users, today identified as registrars. The key questions were identified as:

What are the appropriate interfaces between registry, registrar and registrant?
Should the organisation that is the registry be able to also act as a registrar?

In its second draft report the working group presented and analysed three distinct models composed of different answers to the preceding questions.

A thick registry model similar to that used in many ccTLDs that do not allow direct registration by registrants.

A thin registry model similar to the ICANN model for gTLDs.

A combined thick registry and registrar close to the current Domainz model which could be achieved by modifications to Domainz's current practices.

In that report the working group was convinced of the advantages of a separate registry, but was not prepared to choose between the thick registry model or the thin registry model.

The following recommendation has been accepted by the June AGM of ISOCNZ.

Recommendation 1. ISOCNZ should alter its policy to remove the registration function from the registry. The registry should focus on registrars as its customers.

The principal advantages are seen to be:

This change should create a level playing field that will foster competition in the registrar market and lead to a greater range of services and options for registrants.

The registry will be an entity independent of any registrar and will have as its sole focus the efficient operation of the register and the DNS.

The sum of the expectations of registrants ( para 55 ) will best be maximised by a separate registry and all of the rights can be preserved without direct access to the registry.

ISOCNZ will, in due course, have a much simpler business to govern allowing it to focus on all of its objects.

To foster further discussion on the advantages and disadvantages of the thick and thin registry models the working group posted three strawmen models of a framework for the .nz ccTLD.

A thin model with no interaction between a registrant and the registry. It introduced the concept of an escrow as a combined form of audit of registry operations and backup of registrant information. The model depended on a contract between each registrar and the ccTLD manager to enforce reliability of operations.

A lighter model also removed all interaction between the registry and registrants. It held more information within the registry and depended on a contract between registrars and the registry for reliable operation.

A thick model drawing on attributes of the Canadian and UK models. This model used structural safeguards including a certificate and electronic notification of operations to ensure reliable operation.

There was considerable discussion of these models with a number of valuable contributions. The working group used this input to refine its ideas to a single woodenman model . The woodenman combined aspects of the light and thin models with useful observations from the internet community. Comments on the woodenman have led to some fine tuning in the working group's final recommendations.

A SRS for the .nz ccTLD

Any organisation that manages domain names in the .nz register as part of its business is a registrar. The working group expects that most registrars will register names as a small part of their overall business. The working group recognises that many businesses and business models related to the Internet are rapidly evolving. We believe it would be a mistake to unduly restrict the ability of an organisation to become a registrar.

Name registration is a process that can be largely of fully automated. The interface(s) between the registrars and the registry should meet the business needs of the registrars subject to not imposing undue cost on the registry. Cooperation is required to facilitate this.

The following recommendation has been accepted by the June AGM of ISOCNZ.

Recommendation 2. A standing committee be established to maintain communication between the registry and registrars. The standing committee should be chaired by a member of the ISOCNZ Council and should include technical representatives from the registry and a minimum of two different registrars and/or agents.

Registrar Obligations. In selecting a model with minimal structure the working group is placing substantial trust in registrars to observe best practice and honour the wishes of registrants. Of key importance is the ability of the registrant to freely choose their registrar and to easily move the designated authority for a name from one registrar to another. This freedom of choice was emphasised by the Commerce Commission and many submissions as an important attribute of any successful design.

Currently name holders change their registration agent by approaching a new agent rather than through their current agent. Often this is done as part of a broader transaction, for example relocating a web site. The number of changes of registration agent is approaching two hundred per week. This is a sufficiently common activity that a straightforward mechanism must be available to registrants.

Recommendation 3. A registrant authentication field should be included in the register. The designated registrar shall make the contents of the authentication field available to the registrant on demand.

The authentication field will be managed by the registrar in the same manner as other fields in the record. The presence of this field will enable a registrant to transfer a name to a new registrar without reference to the current registrar. The working group envisages that this field will initially be a password, but may well evolve to become a public key certificate or similar. Each registrar will be responsible for providing its registrants with the contents of this field on demand.

There are several consequences of an authentication field managed by the registrar.

Cooperative changes of registrar such as a merger may be completed by the registrar without reference to the registrant.

A registrant should not reuse an authentication device such as a password from one registrar to the next. A responsible registrar will see that this is done by issuing a new authenticator.

As always a registrant unable to make use of the authentication field will be obliged to approach a new registrar with sufficient documentation (as defined by that registrar) and give that registrar authority for a name. The registrar will need to provide to the registry an assertion that adequate documentation has been provided by the registrant.

We would also expect the registrar community, through the committee already mentioned, to agree maximum times to effect a change of registrar instruction from a registrant.

All registrars will be expected to immediately notify all stake holders whenever a change is made to a domain name record.

The ccTLD-registrar contract discussed

below

Register Management The register will hold information about each domain name registered in .nz. This information will be managed by the registrar with designated authority for the domain name.

The registry will not have a business relationship with individual registrants.
Each registrar will require secure authentication with the registry.
The registry will bill registrars for their use of the register.

The working group does not wish to fully specify the interfaces between the registrars and the registry. This should be the job of the committee mentioned above. However, we envision that these interfaces will be relatively simple and give the registrars the ability to:

Register a new name.
Update existing information for names for which the registrar has designated authority.
Search for and retrieve all names for which the registrar has designated authority.
Perform a general search of the database on any of a set of fields agreed by the committee mentioned above.

The working group believes that registrars should have greater search abilities than the general public. However the exact details that would balance the utility for the registrar against the ease with which a competitor might retrieve information should be agreed by the registrars themselves.

Public Information It has been argued that information about registered names should be provided by registrars. It has also been argued that this information should be provided by the registry. Those arguing the second option most often cite a registrant's desire to confirm information held in the registry.

The working group is persuaded by the arguments in favour of a registrant's ability to confirm registry information and note that this is consistent with New Zealand's privacy regime.

Recommendation 4. Registry information.

All information that the ccTLD manager requires to be available should be held in the registry and should be public (other than the authentication field which would be available to the registrant and its registrar).
The registry should operate both a basic whois service and a web based information service to provide this information to the public.
There should be no change to the information required to be publicly available. This information should remain consistent with the requirements of RFC 1591:

domain name,
registrant name,
nameservers,
administrative contact information, and
technical contact information.

To this should be added the designated registrar's name and url as well the registrant authentication field.

Contract Management The working group recognises that many name holders have been confused by the fact that they receive communications (including invoices) from the registry when, in many cases, they are only aware of the relationship they have with the third party who obtained their domain name for them.

The contractual relationships which underpin the SRS should avoid that confusion if at all possible. It is also crucial that they be (among other things):
- simple : written in plain English so that all participants in the SRS can easily understand their rights and obligations;
- flexible : flexible enough to cope with the rapid development of the Internet and associated business models;
- best practice protection : sufficiently robust to protect the rights of the participants in the SRS in a manner which reflects or exceeds international best practice;
- consensual : put in place through a transparent, non-discriminatory and consultative process to ensure general acceptance and speed of implementation.

It is apparent to the working group that all participants in the SRS (eg ccTLD manager, registry, registrars, name service providers, and registrants) will benefit if these ideals are observed. Therefore, in any contracting situation, the rights of others and not just the rights of the directly contracting parties will be relevant. For example, the obligations of registrars in a registrar accreditation agreement are to a large extent designed to protect registrants, however registrants are not parties to those agreements.

This concept, where a third party benefits from a contract that it is not a party to, is called "privity of contract". In New Zealand, this concept is helpfully enshrined in the Contracts (Privity) Act 1982 which, among other things, provides that a person who benefits from a contract may enforce it even where that person is not a party.

The working group therefore recommends that, where appropriate, contracts should be implemented which make specific reference to privity of contract rights.

Since it is the ccTLD manager's responsibility to ensure that the SRS "works properly" (in the widest sense), and to ensure equality, transparency and flexibility, the ccTLD manager should play an integral role in implementing and overseeing all contracts.

The working group envisages contractual relationships as shown in the following figure will be required. This includes explicit contracts between the ccTLD manager and the registry, between the manager and the registrars and between registrars and registrants. Privity of contract may be used to ensure overall performance as outlined above.

(image of contractual relationships)

ccTLD Manager - Registry
This is essentially an agreement granting the registry the right to maintain the register in return for payment of certain fees to the ccTLD manager to cover specific DNS related activities. The scope of those activities is outside the terms of reference of this working group, however, suggestions have been made that these activities need to be clearly defined. Details of the particular terms of the contract are outside the scope of this report, however, this contract should cover at least the following:

technical liaison through a standing committee comprising registry, registrar and ccTLD manager representation;
right of review by ccTLD manager including a right to tender register operation and termination provisions;
mechanism for implementation of changed policy and force majeure provisions to cater for changes in international and .nz DNS structure and policy;
obligation to abide by dispute resolution outcomes;
obligation to run a separate audit log showing all changes to the register available as of right to any affected participant (subject to security/privacy and possible cost recovery);
acknowledgement that the registry is prohibited from engaging in any direct communication or relationship with registrants (other than arising out of any dispute resolution or enforcement action taken against or involving it). The only exception to this would be in an exceptional circumstance where approved by the ccTLD manager. The working group cannot currently envisage a situation where the registry would need to contact a registrant directly, however, it is important to preserve this flexibility for unforeseen situations.

Registry - registrar
This is a standard form contract applicable to all accredited registrars. Among other things, it will cover:

best practice operation of the register on a 24x7x365 basis;
direct contractual commitments of registry to registrar reflecting those agreed with the ccTLD manager, subject to variation agreed by the standing committee;
recognition of benefit to ccTLD manager and registrants therefore giving them privity of contract and enforcement rights alongside those of the two parties;
mechanism for implementation of changed policy and force majeure provisions to cater for changes in international and .nz DNS structure and policy;
obligation to abide by dispute resolution outcomes;
acknowledgement that the registry is prohibited from engaging in any direct communication or relationship with registrants (other than arising out of any dispute resolution or enforcement action taken against or involving it). The only exception to this would be in an exceptional circumstance where approved by the ccTLD manager.
charging regime;
mechanisms for technical liaison and day to day interaction between registry and its customer registrars (eg addition/alteration to interfaces).

ccTLD Manager - Registrar
This is essentially an accreditation agreement. Among other things, it should cover:

accreditation criteria;
ongoing charges;
obligations to registrants including in particular the obligations (1) to provide a simple and efficient mechanism to enable a registrant to transfer any or all of their domain names from one registrar to another, and (2) to provide the registrant's authentication information on demand;
technical liaison through a standing committee comprising registry, registrar and ccTLD manager representation;
recognition of benefit to registry and registrants therefore giving them privity of contract and enforcement rights alongside those of the ccTLD manager;
obligation to provide to a registrant prior to entering into relationship with it a standard form plain English contract (in a form approved by the ccTLD manager) to be accepted by the registrant (and a copy retained by the registrar). It is envisaged by the working group that a certain set of minimum standards will be agreed between the ccTLD manager, registrars and (if possible) registrant representatives, which will cover such things as an FAQ re the DNS and the SRS/participants in the SRS, mechanisms for transfer of domain names from one registrar to another etc;
acknowledgement that registry is not liable for any breach of third party intellectual property rights and indemnity by the registrar in respect of any such liability;
escalating penalty and termination provisions for defaults;
mechanism for implementation of changed policy and force majeure provisions to cater for changes in international and .nz DNS structure and policy;
obligation to abide by dispute resolution outcomes.

Registrar - Registrant
Each registrar will have its own plain English standard form contract approved in advance by the ccTLD manager (with any changes also requiring prior approval). It would cover such things as:

The minimum obligations of the registrar referred to above;
Acknowledgement that in respect of obtaining a domain name and any subsequent operations involving that name (up until a transfer is effected), the registrar is acting as the agent of the registrant (and therefore has fiduciary obligations to the registrant, including, in particular, the duty not to act in conflict with the interests of the registrant for personal gain);
obligations of registrant to indemnify all participants in SRS in respect if any infringement by the registrant of a third party's intellectual property rights;
mechanism for implementation of changed policy and force majeure provisions to cater for changes in international and .nz DNS structure and policy;
recognition of benefit to registry and ccTLD manager therefore giving them privity of contract and enforcement rights alongside those of the registrars and registrants;
obligation of registrant and registrar to abide by dispute resolution outcomes including, in particular, acknowledgement that this may involve a direction to the registrar to transfer any or all infringing domain names;
other terms particular to the service that the registrar chooses to provide, which shall be up to the registrar/registrant provided they do not adversely impact on the standard minimum obligations of the registrar and registrant.

There are of course other terms that will be included in these contracts.

Recommendation 5. ISOCNZ, acting as ccTLD manager, should ensure that a contract structure along the lines of that described in paragraphs 82 to 93 is put in place to support the proposed SRS framework.

The Audit Log A system based on contracts and including a dispute resolution procedure requires an audit trail of actions against the register. An audit trail should be a timestamped sequence of records recording all changes to the register. Each record should contain a timestamp, the old name record, the new name record and the authority (registrar) making the change. The working group sees no reason why this function should not be maintained by the registry. The information should be retained indefinitely.

Recommendation 6. The registry should maintain an audit of all transactions against the register capable of reproducing the state of the register at any point in time as well as recording all transactions. The audit should be kept indefinitely. Subject to privacy/confidentiality requirements and any necessary cost recovery, any person involved in a claim or dispute involving a domain name will be able to obtain a certified copy of the relevant audit records from the registry. Those records shall also be made available at the same time to the ccTLD manager.

Consequential Issues

Disputes There are two broad areas in which disputes between parties involved in the ccTLD system may arise:

Rights to a name. There have been cases in New Zealand and overseas where disputes have arisen with respect to rights to a name. The backgrounds to the disputes have included trademark claims, speculative warehousing, and names lost through registry or registrar error.

ccTLD contracts. In our design the ccTLD manager maintains the operating environment through contracts. Disputes concerning failure to adhere to a contract may be brought by any of a registrant, a registrar, the registry or the ccTLD manager. Where possible it is preferable to resolve these disputes without reference to the courts.

Dispute resolution concerning a registrant's rights to a name is outside the terms of reference of the working group. However, the working group believes that some policy in this area is required to complete the framework of the .nz ccTLD. The working group suggest that ISOCNZ separately consider the establishment of a disputes resolution procedure paralleling ICANN's Uniform Dispute Resolution Procedure.

In respect of disputes arising out of the contracts outlined above, the working group considers that it would be useful to provide a dispute resolution process. This may be no more than an escalating procedure of mediation, arbitration and ultimately recourse to the courts.

It is important that the ccTLD manager only has responsibility for setting policy and performing an administrative role in resolving disputes. Disputes must be considered and decided by an independent body as it is possible that the ccTLD manager may be a participant in the dispute.

The ccTLD Manager The working group has identified three functions of the ccTLD manager:

policy development,
contract management, and
administration of the dispute resolution procedure.

The working group does not believe that these functions can be carried out in a timely fashion by volunteers.

Recommendation 7. ISOCNZ should accurately define the role of ccTLD manager and establish the office of "ccTLD Manager" with adequate resources to develop, promulgate and administer policy; to negotiate and manage contracts; and to administer the resolution of disputes. This office should be paid for by the internet community.

Registrar Accreditation and Charging An accredited registrar is able to directly access the register and be the designated maintainer of domain names in the register. The working group considered a number of conditions that might be imposed on a registrar as a prerequisite for accreditation. Given the immaturity of the industry, the size of the New Zealand market and a national culture that believes in letting anyone have a go the working group has concluded that no subjective barriers should apply.

One of the working group's goals has been to reduce the cost of the registry by reducing its billing load. This is primarily addressed by focusing on registrars as customers of the registry and billing the registrar for services. This will eliminate invoicing for about 50,000 names annually based on current numbers. This advantage would be at risk if it was possible for anyone to become a registrar for the purposes of registering a name or two. Thus the barriers should not be so small as to be effectively removed.

An organisation or individual will need to sign contracts with both the ccTLD manager and the registry to become a registrar. This implies a legal ability to enter into a contract and the ability to meet the terms of those contracts. The working group believes that this plus a charging regime that avoids any cross subsidy from large to small registrar will be sufficient to meet its goals.

The working group suggests that the billing model should consist of two monthly components.

A fixed monthly component representing not less than the cost of maintaining a registrar's accreditation including billing, technical support etc.
A variable monthly component based on the cost of the number of registered names stored by a registrar, and/or the number of transactions completed by the registrar.

Additionally, separate charges should be made for items such as initial accreditation, excessive technical support, etc.

It is difficult to know how to allocate the ccTLD manager's costs between the fixed monthly component and the variable monthly component. Rather than try to determine this the working group believes the ccTLD manager should monitor this to ensure that no excessive barrier to entry is being created.
The following recommendation has been accepted by the June AGM of ISOCNZ.

Recommendation 8. ISOCNZ should revise its charging policy to encourage registry charging to:

Be focused on the registrar as a customer.
Reflect a registrar's use of the register.
Be independent of any contract or agreement between registrar and registrant.

The registry should charge the registrars to recover both its costs and the costs of the ccTLD manager. While the registry will act as a single collection agent the separate costs of registry and ccTLD manager operations should be clearly transparent, though not necessarily separate line items in the invoice.

Best Practice The registry is a monopoly owned by a public, not-for-profit society. The working group believes the registry should observe the objects of the Society and the principles of RFC 1591 in its operation. In particular, the registry should be concerned with "responsibilities and service to the community." The working group knows of two efforts to develop a statement of best practice for ccTLD administration: the

CENTR: Best Practice Guideline for ccTLD Managers

Alternate ccTLD Best Practices Draft

The following recommendation has been accepted by the June AGM of ISOCNZ.

Recommendation 9. ISOCNZ adopt a best practice policy.

Moderated Domains Moderated domains require a slightly modified processing model in that a name must be approved by the moderator before it is entered in the register. The working group believes that it is appropriate to give the moderator the responsibility for arranging this. This gives the flexibility for several solutions.

Some registrars may choose to offer a "moderation enhanced" process as a value added service.
An active moderator, e.g. the government, may choose to establish their own registrar and combine the functions.

Recommendation 10. Organisations that have decided or wish to moderate their own second level domains within .nz shall be responsible for ensuring that moderation is done as part of the registration process.

References

The Internet Society of New Zealand, Future Development of the .nz Domain Name Space, May 1997.
The Internet Society of New Zealand, DNS Administration within New Zealand, (link to document) , May 1997.
The Internet Society of New Zealand, DNS Operational Tendering Issue, (link to document) , August 1998.
The Internet Society of New Zealand, New Zealand Domain Name Structure, (link to document) , November 1998.
World Intellectual Property Organisation, The Final Report of the WIPO Internet Domain Name Process, http://ecommerce.wipo.int/domains/process/eng/processhome.html , April 1999.
O'Brien, Patrick, Governance in the .NZ DNS - A Position Paper, (link to document) , March 1999.

Appendix A: Input Received by the Working Group

Auckland Forum Attendees

Chris O'Donoghue
Peter Mott, 2Day.com
Ray Lewis
Bob Gray
Len Gray

Wellington Forum Attendees

Michael Stevens, CPS Systems
Jim Higgins, Networking Edge and Domainz
Ewen McNeill
David Zanetti
Sean Liddall; Victoria University Information Technology Services
Hamish MacEwen
David Harpham

Consultations

Patrick O'Brien, Jim Higgins, James Scott and David Bain, Domainz
Patrick O'Brien, Domainz and Andrew Mason, BSA re the Domainz Registration System
Craig Anderson and Jim Benson, IPROLINK
Karen Wynder, Xtra
Andy Linton, NetLink
Roger Hicks, Past Chair of ISOCNZ
Andrew McGhie, Domainz
Mark Dingle and Thomas Thursby, Commerce Commission
Terry Debenham, Privacy Commission

Submissions

Jenny Shearer, Submission to the Review of the Registry/Registrar Structure for .nz
Robert Gray, Roles and Responsibilities in the DNS by Joe Abley and Peter Mott
Ewen McNeill, A Shared Registry for the .nz CCTLD
Jim Higgins, A Submission to the Registry/Registrar Model Review
Roger Hicks, Submission, Registry/Registrar Review
Lin Nah, Registry Review Submission
David Harpham, Shared Registry for *.nz
David Zanetti, SRS Working Group Submission
Andy Linton, Domainz Working Group
Frank March, A critique of the Review of The Registry/Registrar Framework for the .nz ccTLD
Craig Anderson, Comments on the 19 May draft of the Review of The Registry/Registrar Framework for the .nz ccTLD
The Board of Domainz, 12 June.
John Rumsey, Submission to the SRS working group, 7 July.
Egon Guttke, ISOCNZ draft report, 14 August.
Ron Segal, Comments on Registry/Registrar Framework for the .nz ccTLD, 25 August.
Auckland District Law Society, ADLS Law and Technology Committee response to the ISOCNZ Draft Report.

Sections

Personal tools