Personal tools
You are here: Home Proceedings Committee Proceedings .nz Oversight Committee Archive 2002 SRS Implementation Report to Council 13/04/02

SRS Implementation Report to Council 13/04/02

Report Adopted by the Council Meeting of 13 April 2002

SRS Implementation Team Report

Update March 2002

SRS Development

The draft technical architecture was completed on 26 March and posted to the InternetNZ web-site just before Easter. A message will be sent to the .nz provider mailing list advising of its availability.

The draft architecture was fully reviewed by Knossos Networks during March, which involved numerous discussions with the Catalyst team and subsequent enhancements to the architecture. Comment has also been sought from the Society&8217;s Technical Committee.

A draft review of the security architecture was also commissioned from Optimation. This has been sent to Catalyst for comment, and their comments and all Optimation&8217;s recommendations will be addressed by the Technical Project Manager and sent to the SRS IOC for approval.

A summary of the key features of the technical architecture is in Appendix I.

In addition, an external QA of the project structure, documentation and communication has been commissioned to occur at regular intervals throughout the project. The first review focused on the RFI and RFP processes and the report on this was sent to the Chair of the IOC.

Domainz signed the second schedule of the development contract (the prototyping phase) on 11 March. The memorandum of understanding between Domainz and InternetNZ is awaiting input from Domainz&8217;s legal advisors.

In terms of the prototyping phase, the systems software has been installed on the prototype computers and Catalyst are beginning to develop the transaction handling protocol. Catalyst will use a replication of the register data where appropriate.

Also about to commence is the detailed analysis phase. This is starting two weeks ahead of schedule.

Doug is establishing a small group of potential registrars who will be involved (along with Domainz) in the testing of the software and interfaces.

The project plan has been revised and Catalyst is confident they have the resources to meet the key milestones for the project. Confirmation of the implementation date will be made once Domainz completes its planning for the changes they are implementing.

Communications

The first monthly newsletter was sent to .nz providers during March. This contained an update on the project and what is happening at the Domainz end (supplied by Domainz).

A draft communications plan has been developed and this will be discussed with Domainz. This builds on the communications strategy that was developed and agreed during February. It is critical that comment in the media on the project from both InternetNZ and Domainz is restricted to official spokespersons.

Registry Establishment

New Zealand Domain Name Registry Limited was incorporated on 15 March. The registry director selection process proceeded during March and is the subject of a separate communication to Council.

Candidate CVs have been received for the registry manager position, and these await the appointment of the board before a selection panel can be convened.

Office of the Domain Name Commissioner

The selection interviews were held on 27 March, a week later than originally planned due to the availability of candidates for interviews. It is hoped than an announcement can be made on the appointee before the Council meeting.

The two support positions in the Office of the DNC have been scoped and consulted on within InternetNZ and the role descriptions for these positions will be sent to Domainz staff in early April.

SRS Funding

The cashflow forecasts for the SRS were sent to Domainz, who are preparing forecasts for their activities based on the same assumptions. As at the end of March, the Domainz cashflow forecasts are still being prepared by their accountants, but are expected in early April.

Taskforce and Transition Activities

A list of transition activities for all entities was prepared and this was sent to the Taskforce. Draft principles for the stabilising registrar role were also prepared, as were two scenarios for registrar uptake in the SRS. Domainz is using the scenarios in their forecasts.

Analysis has commenced on the 21,427 domain names that are currently listed as &8220;unallocated&8221; providers in the register.

Willis, the insurance brokers, have now received quotes from insurers for the professional indemnity insurance for .nz. I will receive these later this week.

Rose Percival
SRS Implementation
2 April 2002

Appendix I

Technical Architecture - Phase Completion

The technical architecture phase of the project was successfully completed on March 22nd with the delivery of the final draft architecture document from Catalyst IT Limited. The bulk of the document was completed on schedule in the first week of March, enabling the following phase, prototyping, to start on schedule the following week.

The document was subjected to two quality assurance reviews: one by Knossos Networks which looked at the architecture in general and the other by Optimation which focussed specifically on the security architecture. The two reviews have been forwarded to Catalyst for comment and will be delivered to the IOC as soon as possible, accompanied by an explanation of how it is intended to address the individual issues raised. Neither report raises issues that question the fundamentals of the draft architecture.

In keeping with the spirit of an open approach to developing the SRS, the draft document has been published on the InternetNZ web site and all potential .nz registrars on our mailing list have been notified of its availability. A copy of the document has also been delivered to IOC members, the InternetNZ Technical Committee and Domainz.

The technical architecture will not be signed-off until after the prototyping phase, which is currently under way. It is likely that the architecture, or at least the document, will require some fine-tuning, to incorporate any issues discovered during prototype testing or raised by the two quality assurance reviews.

Architecture Summary

The following paragraphs provide an overview of some key features of the technical architecture. For more detailed information please refer to the draft architecture document itself.

The SRS will use a purpose-built XML-based protocol that provides all the transactions necessary to permit registrars to carry out their business with the registry, based on an n-tier application model. Registrar systems communicate with a front-end web server which accepts and validates XML-formatted transactions. These are sent to a business logic process running on a back-end server that initiates transactions in a database on the same back-end server. Public key/private key cryptography is used to provide authentication, integrity and non-repudiation of requests and responses.

The architecture is based entirely on Open Source products, including: the Apache web server, the Perl programming language and the PostgreSQL database. The operating system for web, application and database servers is Debian Linux with OpenBSD used for infrastructure firewalling and other security platforms. In addition, all client and server software developed for the SRS will be released as Open Source under the GNU General Public License.

The architecture includes significant failover capability. Two sites will operate concurrently, probably at Auckland and Wellington, and the database will be replicated at both sites in real-time. The Wellington site will contain two replicated instances of the database and the system will continue to accept update transactions only if at least two database instances are accepting transactions. In the event that only one database instance is available, the system will continue to operate in read-only mode. The failover architecture can easily be extended to include additional replicated database instances should future circumstances make this necessary. The registrar test system will be housed at Auckland and will be easily re-configurable as a production system in the event of a major disaster.

Document Actions