Thin Model Two 01/09/00

A Lighter Proposal for a Registry Model for .nz

Role of the Registry

The registry acts as the operational arm of the ccTLD Manager. That is, it forms contracts with registrars for access to the register, ensures the good running of the register (it may outsource or insource technical functions as appropriate), and maintains the register where appropriate.

The registry may accept instructions from registrants via registrars, eg to transfer a registration from one registrar to another, where the registrar does not have authorisation to do it themselves. The registry is responsible for ensuring such changes are properly authorised by the registrant.

Note that the registry does not act as an arbiter in any dispute beyond ensuring that the correct registrar handles the registrant. Other disputes should be settled externally (courts, arbitration etc).

The registry allows registrations, updates etc only through registrars under a current registrar contract. Any person or organisation may become a registrar by entering into a registrar contract and paying registry fees.

Data model

These are the key tables for the registry; obviously there will be other bits & pieces needed to make it work (eg billing).

Name table

Keyed by domain name, contains:

• Domain name
• Registrar pointer (ie the name of the registrar)
• Password
• Active flag / inactive expiry date
• Name server list
• Registrant name and contact details
• Optional domain tech/admin contacts

Registrar table

Keyed by registrar, contains:

• Registrar name and billing contact details
• Optional customer tech/admin contacts
• Optional whois and WWW referral addresses
• Registrar authentication information

The data model is largely unnormalised; this permits the registrar maximum flexibility and minimum complexity in how data is output from ther (presumably normalised) registrar's database into the registry.

In addition, all changes to the name records would be logged for troubleshooting and dispute resolution purposes.

Technical interfaces

Updates would be made only by authorised registrars, and then only to records identified as belonging to the registrar. Updates would be via simple, automation friendly mechanisms (eg registry-registrar protocol, XML or whatever), although providing web forms would not be a significant additional cost -- doing so would lower technical barriers for smaller registrars.

Registrars also need to be able to make queries on their data, eg "retrieve all my names", "retrieve all names associated with my name servers" etc. Registrars also need to reliably determine whether names are available.

Updates do need some level of validation, at least for technical data. This should involve syntax checks in names, name server names and IP addresses, and checks for duplicate but mismatching name servers.

There should be some mechanism to allow minimal updates to reduce the size of an update, eg an update to name servers only, leaving registrant data intact.

Public interfaces need to be available to query the register, for the purposes of:

• Checking availability (although this could be done via registrars)
• Obtaining technical contacts due to problems (technical failures, misuse etc)
• Obtaining registrant contact (eg trademark disputes)

In addition, registrants need to be able to check that the registration details written into the register are correct. This should be done through a simple web form and a whois server. The web form and whois server should output the same information, including the following fields:

• Domain name
• Registration status (and expiry if inactive)
• Registrant name and contact details
• Registrar
• Registrar's referral URL and/or whois server, if provided in registrar record
• Tech/admin contacts, from name record if provided, else from registrar record. May be omitted if referral whois/www address provided.
• Name servers and name server IP addresses

While it no doubt will be argued that the optional referral means more development in the registry, the actual effort required would be trivial, while allowing a wider range of service providers to become registrars.

Registry economics and charges

Charges should reflect the nature of the registry as a small customer base, high volume per customer, small unit cost business. To provide economic benefits, billing and support costs must be kept to a minimum.

Costs to the registry are a high startup cost for a new registrar due to support issues, a fixed recurring cost for simply maintaining the data, and running the registry, minor support issues and billing, and a volume cost proportional to the number of domain names held by the registrar to cover expansion, data volumes etc. An example charging scheme might be:

With 200 registrars and 100,000 names, this represents $1,200,000 of revenue per annum, excluding setup fees. Revenue would be higher if a significant proportion of registrars had less than 100 domain names.

Note that the current domain fees for Domainz resellers is about $2/month/name, thus the break-even under this structure to move from being a Domainz reseller is 50 names. It is lower when individual (non-reseller) names are involved, more like 20-30 names. This is low; an argument could be made for a smaller domain fee, plus an access fee, eg:

With 200 registrars and 100,000 names, this gives $1,800,000 per annum revenue (again excluding setup fees), but note that revenue growth is lower; at 500,000 names, the revenue is $4,200,000 vs $6,000,000 for the lower entry, minimum charge model. Similarly, a smaller number of registrars would reduce the income, eg if only 10 registrars sighed up (at the 100,000 name stage), the revenue would be only $624,000.

Ongoing support for a small registrar could be high if the registrar lacks competence. Attempting to use technical barriers to prevent low-competence registrars from entry will in fact just result in more support costs dealing with technical issues from registrars of borderline competence. Rather, an up-front fee should cover "normal" setup consultancy, with a set maximum number of hours that registry staff (or contractors) are available. Additional time would need to be charged for.

Changes and deletions

For the most part, all updates to the database are carried out with minimal supervision; the records are largely considered the registrars' to do as they will with. Changes are logged so that changes made in error (or through misuse) can be tracked.

Records can not be deleted by a registrar, rather they would be deactivated, and an expire date applied to the name, with a minimum two month expiry. Deactivated names are no longer published to the DNS, and are not charged for. Once expired, they would be removed from the register. If a new registrant wants to register a deactivated name before it expires, they need to do this with the co-operation of the registrar holding the deactivated name. There would need to be (contractual?) safeguards against use of this feature to squat on large numbers of names without paying for them.

Passwords and name transfer

The password in the name record is placed in the register by the registrar. This password may be updated at any time by the registrar along with any other field. The new password must be disclosed to the registrant (or obtained from the registrant).

Note that the password is not required for the registrar to change registration details; this is done via the registrar's own access to the register.

A registrar can thus take control of a name record from an incumbent registrar by updating the register, using the password obtained from the registrant as authentication. The registrar must then assign a new password and forward it to the registrant (or obtain the new password from the registrant).

If passwords are lost, a new registrar can apply to the registry with suitable authenticating documentation from the registrant (eg letter on letterhead) for the existing password. The registry will authenticate this with the data held in the register (and if necessary, in the change log) before disclosing the password. Passwords will not be disclosed to registrants by the registry; the request must come via an authorised registrar.

When a name is transferred from one registrar to another, the registry notifies the incumbent registrar. The incumbent must then take whatever action is required to respond to the removal. Operators of name servers are not notified by the registry; this is the registrar's responsibility.

Registrar contracts, remedies and termination

Registrars would need to enter into contracts with the registry. These contracts would require that registrars:

• pay registry fees on time;
• accurately and in a timely fashion represent the wishes of the registrant;
• ensure accuracy of information placed in the register, and if using referrals for tech/admin contacts, ensure that the information service referred to is operational and accurate;
• provide name passwords to registrants or their authorised agents on registration or on receipt of registrant authorisation in a timely manner, regardless of any dispute between registrar and registrant;
• accept that property rights to all data belong to the registrants and not the registrar, and must not claim such rights without authorisation from registrants (this includes in dispute situations, and includes a prohibition against harvesting data from the register for non-DNS purposes);
• may deactivate name (and permit subsequent expiry) for non-payment, only after sufficient is be given prior to deactivation, and all reasonable effort taken to ensure that registrant is notified of deactivation;
• ensure that registry data reflects actual services (eg DNS servers do not carry stale zones, mail servers don't attempt to handle mail for deleted or moved domains etc);
• not hold the registry liable in disputes;
• include indemnification of registry in contracts with registrants;

The usual remedy for the registry against a registrar that fails to honour the contract would be to terminate or suspend the registrar contract and deny access to the register by the registrar.

Suspension of a registrar contract would mean that new registrations from the registrar would be denied until the suspension was lifted. The registrar would still be liable for fees during the suspension.

If a registrar contract is terminated (whether by the registrar or the registry), names registered through that registrar become the responsibility of the registry. Where possible, the registry and registrar should attempt to arrange transfer of names to another registrar before cancellation of the contract takes effect.

Once a registrar contract is canceled, the registry must contact the registrants, notifying them that the names are no longer subject to a registrar contract and if not transferred to a new registrar, will be deactivated after a 3(?) month notice period, with a view to deletion after the usual expiry period if not transferred.

In addition, the registry may charge registrars for time and expenses incurred by the registry on unusual or registrar-specific issues.

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