Thin Model One 01/09/00

A "Thin" Structural Registry Model

Summary

This approach is primarily based on structure changes to the existing .nz name space. A secondary use of contracts and policy will be used to provide 'flesh' around the structural 'bones' to provide flexibility and openness.

The objective of a SRS is not opening to competition for the sake of it but to provide flexibility and choice to the users, both registrants and aspiring .nz registrars. By introducing competition it should provide this flexibility in the market as well as provide an avenue for `premium' and `self serve' registrars to emerge.

To achieve this objective a `thin' registry model is being proposed to allow each registrar to determine what level of service they wish to provide, as long as it adheres to the requirements of interacting with the .nz registry.

It should be noted that the .nz space currently has less than 80,000 domain names with the expectation of 100,000 by March, 2001. Due to the relatively small size of .nz with regard to gTLD's and other larger ccTLD's some of the approach used in this model may provide an excessive burden to the operation of the .nz name space.

Entities in the .nz name space

ccTLD Manager

This is the role of ISOCNZ and holds .nz `in trust'. The ccTLD creates, and enforces, policy to ensure the operation of the .nz name space. This is to ensure the technical operation of the registry servers as well as provide recourse for those that have a grievance of a domain name or a registrar (escrow and arbitration). The ccTLD manager is also expected to liase with ICANN on the over all direction of domain names and related issues.

Registry

The registry is the systems and software required to interact with registrars and name service providers. The role is to provide the minimum required for the operation of the registry in a 24 by 7 by 365 manner. The only customers it interacts with are registrars. The manner of interaction has been mutually agreed by the registry and the registrars and is expected to be via eMail, Web forms, and a registry API, to name a few. A high level of security and authentication will be required for any access to the data held in the registry.

As well as interacting with registrars, the registry will also interact with name service providers and those querying domain name details. While neither of these two groups are `customers' they are both key stakeholders and users of the data contained within the registry.

Escrow

The escrow is the `insurance policy' for the situations in which a registrar ceases operation or refuses to carry out an instruction because of dispute with the registrant. While the registry maintains no actual registrant details, other than an identifying unique ID the escrow agent has the entire information on the registrant, registrar, as well as a history of all changes that have occurred on the domain name. However, none of this data is available in a public sense and is only the `record keeper'. This information could be used in case of a defunct registrar to update the newly assigned registrar and thus not relying on a registrant to take an active role, if they so desire. It also provides an independent location of registrant details in case of dispute between two or more parties. Therefore once arbitration has occurred the information in the escrow can be used to update new registrars and the registry.

The other side of the escrow is for those registrants that need to change their domain name details but for whatever reason are unable too, i.e., employee resigned, registrar issued password lost, name gained as asset of acquired company, etc. The escrow would then manually authenticate the registrant by the ccTLD Manager approved means and then inform the registrar and/or registrant of the authorised change. This is expected to be a rare event and not as a way of avoid dealing with the registrant's registrar. It is also expected that this service would not be free but a charge levied on the registrant. This would ensure that the registrants do not abuse this process but do have recourse on name changes. An analogy is that if a driving license is lost the driver does have to prove who they are and also pay a fee to get a new license issued.

The escrow approach could be thought of as the `registrar of the registrars' as well as a failsafe for the ccTLD manager.

Dispute Resolution

A registrant must have recourse on domain name and registrar related issues. It is expected that a dispute process would be documented and `certified' arbitrators would be used (which can be initiated by only one party in the dispute) to review the dispute based on the public and defined process. Should either party refuse to observe the ruling of the arbitrator the arbitrator could then direct the escrow agent to `enforce' the ruling and make the changes accordingly. The escrow agent would then inform all the involved stakeholders of the required changes and ensure that the changes are implemented. It is expected that this dispute process would be a fee for service to reduce abuse and malicious dispute filings.

Registrars

Registrars interact with the registry via agreed methods. They are the agent for the registrant and act on their behalf to ensure the registry has the data it requires. The registrar also is responsible for providing, to the public at large, the details of the domain name and the registrant. It is expected that it will provide this information via an industry acceptable WHOIS server. As the registry does not hold the entire domain name data it is expected that a decentralised WHOIS approach will be used, similar to the .com/.net model with the registry providing the basic information on the domain name and the registrar providing the remaining data.

The registrar will also need to interact with the escrow for ALL activities and changes on the domain name details to ensure that the escrow has the complete and accurate details on the domain name and the registrant.

The registrar must also agree to all policy and procedures from the ccTLD Manager including, but not limited to, the dispute process and escrow service. The registrar must be able to provide input and direction to any future policy changes to ensure all stakeholders are involved in this process.

Domainz

Domainz will interact with the registry as per any other registrar. It can also continue with the Domainz Service Provider programme for those entities that wish to provide service to registrants but do not wish to become registrars. In all other respects it is the same as any other registrar but by default it will have all the existing 80,000 plus domain names as it customer base. This is because any registrant that does not decide to change to a `new' registrar will remain a client of Domainz.

Registrants

A registrant will only be able to registrar a name via a registrar. They will be able to choose from any registrar they decide and also have the ability to move their domain names from one registrar to another as they desire. They will have recourse to the disputes resolution process if they believe they are being 'abused' by their registrar.

Name Service Providers

These are the ISP's and Web hosting companies and such like that provide actual DNS service. While not a direct part of the operation of a registry they are involved when changes are made to domain names. A name service provider may or may not be a registrar. The registry needs to ensure that these providers are informed on changes in a timely fashion.

Key Issues Relating To Contracts

This model is dependant of contracts existing between numerous parties. The following are the key contractual relationships.

ccTLD Manager and Registry

The manager must have the contract in place to allow them to have confidence that the registry can operate to an agreed level of service while providing the least cost to registrars. The contract must also include what events must occur for the manager to remove the registry function from the company operating it.

CcTLD/Registry and Escrow service

The contract must include the process that the escrow uses to `force' changes in the Registry. Also must include SLA to ensure that when the service of the escrow is required that it occurs in a speedy and known timeframe.

ccTLD and Dispute service

The manager must document the guidelines or approach that the arbitrators must use. As the dispute service is expected to be one of the few manners of recourse on domain names, outside of the courts, it must operate in a predictable fashion. It must be impartial as well as seen to be impartial.

Registry and Registrar

The key agreement in this entire process. This contract should be the same for every registrar, including level of discounts, if any, for volume, SLA for each party, the exact requirements for each party. Also needs to include a dispute process between the parties and what occurs should one party not adhere to the terms of the agreement. The final recourse for this would either be an agreed arbitration process ot the ccTLD manager.

Registrar and Escrow service

As part of being a registrar the registrar must use an approved escrow agent on the behalf and their registrants. This agreement will include how the data will be exchanged as well as the SLA.

Registrar and Registrant

The agreement between these two parties should include items such as who owns the domain name, the length of the contract, documentation on the disputes process, details on the escrow system being used, plus any other relevant information.

Data Model (Source)

The only entities that hold data as part of the model are:

• Registry
• Registrars
• Escrow

Registry

The registry would have the smallest possible `footprint' of domain name information to achieve its mandate. The following is fields it would support:

• Domain Name
• Registrar
• Unique ID
• Name Servers
• Name Status

The role is of the Unique ID is to match the registrant with the domain name between the registry, registrar and the escrow service. This is because the `owner ship' of domain names can change and therefore any history relating to the registrant cannot be solely linked via the domain name. An example is foo.co.nz has a possible one to many relationship with registrants, i.e., name can be sold, etc. Therefore to ensure only the `current' details on foo.co.nz are recorded in the registry a Unique ID is allocated by the registry for that instance of the name. This allows the escrow service, and registrar if they wish, to record the historical details of the domain name, compared to the registrant.

This means the escrow could have a list of all registrants related to a domain name by using the privacy neutral Unique ID's which than can be linked to the historical registrant details.

Authors Note: It is possible the requirement for this Unique ID is redundant based upon further review of this model.

Registrars

The registrar can maintain as much data is it desires on the name. This is up to the registrar and their business model about what information they wish to record and any privacy concerns. However, the following is the minium fields they will need to support:

• Domain Name
• Unique ID
• Registrant Name
• Registrant Contact Details

Escrow

• Domain Name
• Registrar
• Registrar Contact Details
• Unique ID
• Name Servers
• Name Status
• Registrant Name
• Registrant Contact Details
• Initial Registration Date
• Last Modified Date
• History of Domain Name Changes (Unique ID's or per changes by the same Registrant)  

© 2000 The Internet Society of New Zealand
Last updated 1 September 2000