Personal tools
You are here: Home → Proceedings → Task Force Proceedings → Archive → wg-domainz-model-review → Woodenman Model 10/10/00
Navigation
 

Woodenman Model 10/10/00

Woodenman Model for the .nz ccTLD Registry

Introduction

The SRS Working Group posted three Strawmen models for discussion by the Internet community. Having considered the comments made on those models and made its own assessment of the desired outcome, the Working Group now presents a single Woodenman model which should be viewed as a draft of a final model for comment. The working group intends to publish its final report later this month.

The Players

The working group has identified eight distinct roles which it believes should be present in the ccTLD model for New Zealand.

  • Registrant (Name Holder)
  • Registrar
  • Register management
  • Provision of public information
  • Audit log
  • Policy development
  • Contract management
  • Dispute resolution

A registrant holds the right to use a domain name. The registrants are the ultimate customers of the system described here and their rights are supreme.

The registrars will be responsible for the initial registration and subsequent maintenance of a domain name registration.

A registry will be responsible for maintenance of the .nz register (including transfer to the zone files), an audit trail of changes to the register , and the provision of basic public information.

The ccTLD manager is responsible for the correct and efficient operation of the domain name registration process within .nz. The ccTLD manager will develop policy, manage a set of appropriate contracts, and may facilitate a dispute resolution process to an extent to be determined.

The following sections expand on each of these roles and the relationships between the roles and the entities implementing the roles.

The Registrant

The system is designed to facilitate the registration of domain names within the .nz namespace. This makes the registrant the ultimate customer of all entities in the system. In considering the submissions the working group believes their are three key rights held by all registrants.

  1. 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.
  2. 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.
  3. The ability to confirm information held in the register about a name.

The working group also notes that name holders currently 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 working group recognises that this normal behaviour for customers of a service and believes that registrants should be able to continue this practice in the new framework.

Registrars

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 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. The ccTLD manager should maintain a standing committee comprising representatives of the registrar community, registry and ccTLD manager to ensure this interface meets the reasonable needs of all interested parties.

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, the number of changes of registration agent is approaching two hundred per week. This is a sufficiently common activity that the working group proposes that a choice of mechanisms be available to registrants for the purpose of changing registrar.

  1. A registrant authentication field should be included in the register. This 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. We envisage 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 request.
  2. Each registrar will be expected to provide a "change of registrar" function as visible and easy to use as any other function, e.g. "change of technical contact". The registrant need only identify the new registrar to complete the transaction.
  3. As always a registrant unable to make use of the authentication field will be able 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.

The ccTLD-registrar contract discussed below will specify the detail of the registrars' obligations.

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.

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.

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. Therefore we conclude:

  • 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.

The working group recommends that there 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 operation of the proposed ccTLD structure 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 parties 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 each group of participants in the ccTLD (eg ccTLD manager, registry, registrars, 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 any person who may benefit from obligations undertaken by a party to a contract should be entitled to enforce those obligations even where that person is not a party to the contract. Specific reference should be made to these privity of contract rights in the contract in question.

Once it is understood that protections can be implemented for all participants without the necessity of any direct contractual relationship, the process of forming the necessary contracts can be simplified. In the working group's view, 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.

ccTLD Manager - Registry

This is essentially a service level agreement. Details of the particular terms of the contract are outside the scope of this report, however, this contract should cover at least the following:

  • best practice operation of the register on a 24x7x365 basis;
  • technical liaison through a standing committee comprising registry, registrar and ccTLD manager representation;
  • recognition of benefit to registrars and registrants therefore giving them privity of contract and enforcement rights alongside those of the ccTLD manager;
  • 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.

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.

Disputes

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

  1. 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.
  2. 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 recommends that the ccTLD manager consider the establishment of a disputes resolution procedure paralleling ICANN's Universal 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.

Audit Log

A system based on contracts and including a dispute resolution procedure requires an audit trail of actions against the register. The working group suggests an audit service that provides this function. The audit log 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 ccTLD Manager

The ccTLD manager has three functions:

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

Contract management and the dispute resolution procedure have been discussed above. Policy development is outside the scope of this report.

Charging

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.

The working group wishes to minimise any barriers to becoming a registrar. On the other hand it must balance against this the desire to reduce costs by significantly reducing the billings of the registry. Therefore 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 number of registered names designated to the registrar and the number of transactions against the register.

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 the appropriate balance between low barriers to entry on the one hand and necessary technical ability on the other, is maintained. The fixed monthly charge (including registry costs) represents the cost of being a registrar, regardless of the number of names registered.

© 2000 The Internet Society of New Zealand
Last updated 10 October 2000

Document Actions