SRS Implementation Newsletter March 2002

.nz Provider Update March 2002

This is the first in what will be a regular update on progress with the implementation of a shared registry system for .nz domain name registrations.

We have targeted this update at all currently accredited providers for .nz domain names, and other providers who are listed in the current register who are managing fifty or more domain names on behalf of name holders. If you know of someone else who would like to receive a copy of this update, please feel free to pass it onto them or have them e-mail office@internetnz.net.nz to be added to the mailing list for the next update.

If you came to the .nz provider workshops we held around New Zealand during November, you may recall that we outlined the proposed roles, obligations and responsibilities of the different entities in a shared registry environment. If you did not make it to the workshop, a copy of the presentation is on the InternetNZ website at (link)

Other background documents can also be found at this URL. If you want to start at the beginning of the SRS documents, we suggest you start with the Hine Report.

At the workshops we talked about the ccTLD manager's Office which is InternetNZ's role of stewardship of the .nz domain name space. The position of Domain Name Commissioner (previously called the ccTLD Manager) has been advertised and we are planning to interview candidates for this position before the end of March. The appointee to this position will oversee the implementation to the shared registry environment, working closely with Domainz and the new registry.

We are also making progress with establishing the new registry - applications have been called for directors for the registry and the registry manager's position has been advertised.

We will report progress on these appointments in our next update.

The rest of this update provides information on progress with the development of the new registry software and what Domainz is doing to prepare for the changes.

For most of you, the last major update received from us on the status of the project will have been at our November 'roadshow' or perhaps earlier than that during our consultation meetings in September and October. We are pleased to report that there have been no significant changes to the SRS since the roadshow presentation and everything is proceeding to plan.

At the roadshow, many were interested to know the project schedule, with an obvious interest in when the system will be ready to connect registrars. At that stage we were only able to tell you that we were planning to perform the development work in the first half of 2002 and the implementation in the second half. This is still our position, meaning we fully expect to be ready to connect registrars before the end of this year.

Over the next few weeks we plan to revise and confirm our project plan, to enable us to provide you with a more specific timeframe. This is not a trivial exercise as there are several entities involved, all of whom need to work together to a co-ordinated plan (Domainz, the Domain Name Commissioner's office, the Registry, InternetNZ, the software developers, .nz providers, etc). We are determined to make what could be a difficult migration run as smoothly as possible and we will not be rushed unnecessarily.

Following is a brief update on what we've been doing over the past few months and what we are planning to do over the coming months.

Technical Implementation

The SRS technical architecture is still in the draft stage and not yet available for general distribution but as soon as it is sufficiently stable we will make it publicly available and you will be notified. This is likely to occur before the end of March. In the meantime, we have included some information about the architecture below to give you advance notice of some key technical issues and directions.

Open Source

The SRS will, as much as possible, be built on an open source platform, particularly software meeting the licence approval conditions of the Open Source Initiative (see http://www.opensource.org/licenses/index.html ), So long as the security requirements of the system are not compromised, this means that the source code of the system will be available to all and with no licence fees.

The primary operating system is likely to be Debian GNU/Linux, the primary programming language is likely to be Perl, and the web-server is likely to be Apache. At least two options are being evaluated for the database with the most likely candidate being PostgreSQL.

Registry-Registrar Protocol

The SRS team has performed an extensive investigation of current registry protocols and alternative options. In an effort to re-use existing protocols and widely available libraries (to ease registrar implementation), we plan to base the

registry-registrar protocol on HTTP and HTTPS. The connection set-up overhead of HTTP and the encryption negotiation overhead for a HTTPS connection mean that minimum end-to-end turnaround times on requests will be in the order of 1-2 seconds. Requests that require a lot of processing on the server, such as global updates, will obviously require more time. We considered aiming for a sub-second response time but to be certain of this would require a more complex protocol, probably involving persistent connections.

We carefully considered using EPP which is a more recent protocol adopted by some gTLDs but it uses a different data model from the .nz register. EPP suggests different objects for nameservers, contacts, etc while the .nz register model is a single object containing all these details, which can be updated at once. We could have modified EPP to fit the .nz model but it would be a different protocol from EPP and a relatively complex one to implement, with no real advantages once we are outside what other people are doing. EPP is also in a state of flux and it is possible that even if we implemented EPP as it is today, it may not be compatible with the final version of EPP. An EPP interface could be added to the .nz registry later, once the protocol has been standardised.

Non-repudiation

Our chosen registry-registrar protocol assumes that non-repudiation is an important requirement, in both directions. This means that sufficient information is sent so that the registry can prove that the given registrar sent the request and the registrar can prove that the registry sent the response, without relying on the other end's records. This will be implemented using public key/private key cryptography and digital signatures.

Low-overhead/High-overhead Requests

Some requests are likely to be more common than others and turnaround time is likely to be more of a concern for some requests than others. In particular, single-record query requests (eg. determining if a name already exists, obtaining the 'whois' details of a single name) are likely to be more frequently made than other requests (eg. updates, billing enquiries, etc). Frequently made query-type requests will be made through a lower overhead, less secure channel, making near 1 second response times much more likely for these requests. Update-type requests will be made through a more secure, higher overhead channel for security, and will likely take closer to 2 seconds.

To implement this dual approach, HTTP will be used for the low-overhead requests and HTTPS for the high-overhead requests. This means that information in the low-overhead requests will be passed over the Internet in the clear. All information in most query-type requests is publicly available anyway, through the public registry 'whois' feature, etc. Any updates and anything containing things like the registrant's Authentication ID will still be sent encrypted. If we didn't send query-type requests in the clear, then the application would need a more complex strategy for low-overhead requests or need to do encryption at the application layer.

Any Comments?

If you have any questions or concerns about the technical implementation, please don't hesitate to contact Doug Mercer at doug@internetnz.net.nz. As we progress towards implementation, we expect to increase our communication with you to ensure you have as much information as possible, as early as possible, to enable you to plan your transition to the SRS.

Domainz

Accounting System Replacement

Domainz have a small project underway to replace the accounting package used in their back office. They currently use Quickbooks for general ledger reporting, with the interface between DRS and Quickbooks being a number of manual journals. The current system no longer meets their requirements from a customer service, efficiency or reporting point of view. The new system will be implemented in time to interface with the SRS.

Last month they released an RFI seeking responses from vendors and implementers for suitable package solutions. There was considerable interest and by the deadline they had received 17 proposals. Right now they are finalising the shortlist and hope to make a final decision on what package they will implement by the end of March.

Process Review

Also underway is a complete review of all of their business processes. This is particularly relevant to .nz providers as many of the changes identified have been prompted by the need to revise procedures in line with the proposed SRS business rules. Perhaps the most important of these is the timing of the billing and the rule whereby if a domain name is active 5 days after the anniversary date, the registrar (Domainz) will be billed. They have not yet finalised how they will handle this but it is clear it will change the procedures around how providers are billed.

With any process change there are two main issues; timing the introduction of the change and minimising the impact on you, the customer. Domainz are keen to explore ways of implementing the new rules in a way that enables them to transition to the new processes rather than a 'big bang' approach. Once they have determined the detail of the changes they will provide you with specifics.

SRS Implementation Team

March 11^th 2002

E-mail: rose@internetnz.net.nz, doug@internetnz.net.nz

Phone: (04) 471-1190

©2002 The Internet Society of New Zealand
Last updated 12 March 2002