SRS Implementation Submission D Stokes
Response by Don Stokes to the Green Paper on the Implementation of a Shared Registry System for New Zealand
Introduction and Declaration
This is my response to the Green Paper. To declare my interests and background:
I have been involved in Internet provision since 1992, when I founded the Victoria University's Internetworking Group (later NetLink). My University role also included operating the govt.nz, mil.nz and iwi.nz domain name registry, delegated at the time by the Tuia Society's Technical Working Group, which I was actively involved in.
My association with NetLink and the University ended in 1997, when I left to operate as a freelance consultant, working primarily with ISPs.
Since mid 1999, I worked with Glazier Systems (later Advantage Group) to develop the DNS infrastructure associated with the Domainz systems, with which I continue to be involved. That said, my involvement with the DRS application itself has been minimal, beyond design of and assistance with the interface between the DRS and DNS systems and related issues.
I was a member of the SRS Working group, and author of the documents,
"Registry Design: Fundamental Questions", and "A Lighter Proposal for a Registry Model for .nz", the model described in the latter being the basis for the "Woodenman Model" on which the Final Report was based.
(I believe the Woodenman Model document provides a concise description of the model itself, and should be read alongside the Final report.)
Response to Green Paper
> 5. REMOVING THE REGISTRY FROM THE COMPANY >
> 5.1 Two methods have been identified to handle the split into
> Registry and Registrar and whichever is chosen there are basic
> questions which arise. The choices are between
> > 5.1.1 a literal split of the current NZIRL DRS and other
> systems, in which the Registry is divided off from current
> functions which are seen as Registrar functions; and
> > 5.1.2 the creation of a new Registry based on an SRS model.
I believe that there is no simple dichotomy between the options of splitting the company and creating a new registry. The reality is that Domainz currently operates resources that are clearly associces that are clearly associated with its registry role, and some that are clearly part of its role as a registrar. In addition there are many parts that will need to be duplicated, re-written or are completely new on both sides.
I will therefore address the question in sections 5.7 and 5.8, and not those in 5.9 through 5.11, as these largely overlap, and I believe questions 5.7 through 5.8 provide a better framework to air my views.
> A. Splitting the Company into a Registry and a Registrar
> > 5.7 The questions in relation to the new Registry which arise from > this approach are (in no particular order): > > 5.7.1 Who writes the code?
I believe this should be more properly phrased as, "who holds the intellectual property for the code?" This could be held by either ISOCNZ, or by the agency operating the registry; this would affect the ability of the registry contract to be re-assigned to another agency, and the initial cost; clearly, if the registry agency itself held the intellectual property associated with the registry code itself, they would be expected to develop it at their own cost; on the other hand, if ISOCNZ chooses to retain IP rights, ISOCNZ will need to fund the development.
Note that IP rights to the interface specification *must* remain with ISOCNZ as the TLD manager.
> 5.7.2 What input does the existing Company have to new code?
None, beyond the consultation and testing phases that all interested registrars need to be involved in.
However, it must be recognised that Domainz has a key role in the transition as the incumbent registrar for all .nz users; as such, the transition can not be completed until Domainz systems are ready.
> 5.7.3 Who maintains the legacy interfaces?
Domainz.
> 5.7.4 How much will the Registry redesign cost?
See 5.7.1 above. The database and its interfaces would not be complex, however they do need significant effort to ensure their robustness.
> 5.7.5 Who will run the Registry? > > a. internal to ISOCNZ
Running the registry internally to ISOCNZ places the Society in a similar position of risk as that which it faced prior to setting up NZIRL. In addition, there is a conflict between the roles of TLD manager and operational registry that would be better avoided by having a clear organisational split.
> b. new stand-alone company
This would partly (but not completely) address the conflict mentioned aboress the conflict mentioned above. On the other hand, it does involve setting up a new company and appointing directors, presumably from the Society's ranks. Many of the problems associated with the relationship between ISOCNZ and Domainz would simply transplant themselves to the relationship between ISOCNZ and the registry company.
Such an arrangement would also largely preclude the imposition of penalties for non-performance. > c. outsourced
Outsourcing the contract, if properly supervised, should permit the registry function to be operated fully independently of the TLD manager's operational (rather than policy) requirements. Penalties, up to re-assignment of the contract, should ensure performance.
However, the contractor must be selected with a keen eye toward conflicts of interest. The registry can not, for example, also operate a registrar, and should not be a major consumer of domain space in its own right. It also should not hold a dominant position other areas of Internet service provision that could tempt it to capture and misuse its hold in the national infrastructure.
In addition, the contractor will be operating essential national infrastructure; this may preclude overseas operations from taking up the job, especially if the contractor develops the system itself.
For the above reasons, with the provisos in the preceding provisos in the preceding paragraphs, I believe that outsourcing the registry is the preferred option.
> 5.7.5 What is the business model for the Registry and how can > the model ensure that the DNS remains viable as a business > operation for the foreseeable future to ensure the stability of
> the DNS?
> > a. public benefit
> > b. for-profit within limits
Experience to date suggests considerable difficulty with "public benefit" operation. Providing a profit motive to an contractor would provide an incentive to keep the system stable and highly usable, while retaining the ability to switch contractors should the first fail to achieve its objectives.
> 5.7.6 What will the Registry pricing model be?
As much of the cost associated with operating a registry involves support of individuals and organisations, regardless of the number of names held, the pricing should reflect that. Therefore, the following pricing model is suggested:
Each registrar is charged monthly based on the number of domains held under that registrar. There is a minimum charge per month. In addition, each registrar is charged a setup fee; this covers training and assistance in setting up their interface with the registry. There would athe registry. There would also need to be provision for additional assistance where the amount of assistance required by one registrar is excessive; this could be done via external consultants (billing the registrar directly) or sourced from (and billed) within the registry organisation.
The per-domain price would be set to include the ISOCNZ management fee, operation of the TLD manage office, ICANN TLD fees, operation costs to the registry and a margin to ensure that the registry operator can continue to develop the system and cover their risks.
> 5.7.7 How will self-Registrars be accommodated?
Any person or organisation may become a Registrar by paying the fees and setting up the necessary interfaces on their systems, regardless of the number of domain names held.
This does mean that becoming a self-registrar will not be cost-effective for most users. The benefits of operating a split registry would be lost if the registry had to have individual arrangements with a large number of single domain name holders paying minimal fees.
> 5.7.8 How will moderated Domains be accommodated?
Moderated domains should be handled by permitting specific registrars, at the moderators' discretion, to register names within those domains. Such registrars would be required to forward requests for moderarward requests for moderation prior to registration.
Moderators themselves may also become a registrar.
The registry should not be managing the moderation process itself, as it greatly complicates the interface and database requirements (due to having to handle pending registrations, and not being able to give an immediate completion notification) for a very small proportion of name registration activity.
This is consistent with para 113 of the Hine Report.
> 5.8 The questions in relation to the new Registrar which arise from
> this approach (in no particular order) are -
> > 5.8.1 Is the DRS an appropriate platform for a split as
> contemplated?
No. The DRS database is considerably more complex than that required for a shared registry, and its existing automated interfaces (based on the pre-DRS email interface) are unsuitable for a shared registry.
> 5.8.2 Is the current DRS so tightly intertwined that it cannot
> be productively split?
The DRS application itself does not appear to be suitable for SRS use, however infrastructure such as DNS servers can used by the new registry.
> 5.8.3 Is there a viable business operation in operating the non
> registry components of NZIRL as aistry components of NZIRL as a Registrar?
In the short term, yes. Existing name holders fall broadly into three categories:
1. Those fully served by their provider. These do not have a day to day relationship with Domainz; Domainz bills the provider, the provider bills the customer. As it is likely that providers operating this type of service will become registrars, these customers will fall away from Domainz quickly.
2. Those who use their provider for DNS services, and possibly for the initial registration process, but are billed by Domainz. In this case, for the provider to shift these users to a new registry requires that the provider build new systems and business models to take advantage of the SRS and pass those benefits to customers, and to start a process of migration of customers to the new service model. Thus, these users will be much slower in moving from Domainz, possibly taking 2-3 years before the majority have moved.
3. Those who operate their own systems and register directly with Domainz. For the most part, these will be disinclined to move, as doing so requires them to take action, for minimal benefit.
Category 2 represents the vast majority of users in NZ. I believe that it is highly unlikely that Domainz's existing customer base (ie excluding any new customers Domainz may attract) will have halved within the first year; it may take two or more if the company is o or more if the company is operated competitively.
This window, combined with existing cash reserves, offers an adequate opportunity to re-model Domainz's business to prosper in the new environment. However it must do so in a way that will attract new customers if it is to continue to be profitable in the longer term.
> 5.8.4 How much should ISOCNZ invest in establishing the non
> registry components of NZIRL as a Registrar?
None. Domainz should fund from its existing resources.
> 5.8.5 Should ISOCNZ own a competitive Registrar?
> > 5.8.6 If not, and if the ex-NZIRL Registrar is viable, and all
> is stable, when should the Registrar be sold?
> > 5.8.7 What is the definition of "stable" for the new SRS
> Registry?
(Addressing questions 5.8.5 through 5.8.7, and also section 6.)
I believe that once the new Registry is in place, the roles of Domainz with respect to ISOCNZ fall into two categories:
1. The requirement to provide stability to the existing users of the Domainz registry interfaces;
2. An income stream for the Society.
Role 1 is purely transitional, and is dependent on the contractual situation between Domainz and its customers, and the wishes of the Society.
Role 2 puts the valueiety.
Role 2 puts the value of Domainz to ISOCNZ, once transitional obligations are met, as purely that of an investment, that can retained or disposed of at will.
Domainz has considerable monetary value at present; I believe the ISOCNZ Council has an obligation to retain this value to further the Society's aims on behalf of its members. As such, it should not be simply permitted to fade (thereby bleeding off its value) as suggested in paragraph 6.6.5.
Thus the company should attempt to adapt to the new environment. This will mean considerable development of new systems and processes to augment and/or replace the existing ones. It should, once the competitive Registry is in place, actively seek new customers to replace those lost migrating to other registrars.
Once the transition is complete, and the future of Domainz is determined, the Society may choose to divest itself of the company.
There is a potential conflict in owning both a registrar and holding the TLD management role, however, this can largely be mitigated by ensuring adequate Chinese walls between the TLD management office and Domainz, and by outsourcing the actual operations of the registry to another company. These mechanisms would largely remove any mechanism by which Domainz could gain benefit from being owned by the TLD manager.
I believe that a hasty sale of the company may unnecessarily reduce its value due to the uncertainty of due to the uncertainty of the environment it is in. However, as long as arrangements (stated in the sale documents) are in place to ensure the medium term stability of the service provided to existing customers, a sale could go ahead without raising serious issues.
It may be that the society does not feel that its leadership and membership have the ability to lead Domainz through the transition from monopoly registrar to competitive registrar, and that an early sale is therefore the only option to preserve the service provided to existing name holders. If this is the case, the purchaser must be bound to continue to provide existing services through a long (up to two year) transition period.
> 5.8.8 Who should be allowed to purchase the ex NZIRL Registrar
> should it be sold? (i.e. would NSI or another foreign interest be
> acceptable to New Zealand?)
I believe that if the sale happens after the majority of users have had an opportunity to choose which registrar they wish to use (ie at a minimum of one billing cycle, one year, after the SRS go-live date, and preferably longer), there shouldn't be a problem. An early sale to an foreign entity may put ISOCNZ under some scrutiny.
> 6. OWNERSHIP OF THE COMPANY AS A COMPETITIVE REGISTRAR
My views on this are covered in my reshis are covered in my response to questions 5.8.5 through 5.8.7.
> 8. WHAT OBLIGATIONS DOSE THE SOCIETY HAVE DURING THE TRANSITION?
These questions appear to have been largely answered in the draft Position Description issued by the Implementation Oversight Committee.
> 8.4 Where is the Project Implementation Manager based and to whom > does s/he report?
I believe the person should report to the Implementation Oversight Committee in the first instance, and reside away from Domainz, as indicated in the draft Position Description.
> 8.5 Who writes the Policy arising from the Hine Report?
Council must retain overall responsibility for policy, however the voluntary nature of the Council means that the Project Manager should be responsible for seeing that the process is completed in a timely fashion.
> 8.7 Should the Project Implementation Manager assist with the
> preparation of the White Paper, or should the White Paper also specify
> the job of the Project Implementation Manager perhaps as an appendix?
> If so, would there be a conflict of interest in involving the Project
> Implementation Manager in drafting it?
The Project Manager should assist with Manager should assist with the White Paper, purely in the interests of getting the job completed on time.
Additional Views
The Green Paper does not raise questions about the technical structure of the SRS, and it is defined only in the most general terms in the Final Report. However, the strawman model, "A Lighter Proposal for a Registry Model for .nz", does define this; specifically it aims to define the registry database in such a way that the SRS can be treated as an output from registrars' databases, without the registrar needing to keep numerous individual database objects in synch or raising issues of ownership of database objects other than the domain name itself.
Ownership and management of individual objects other than the domain record itself is an issue with other registry models, such as the RIPE or NSI models, and I believe that a simpler data model is more suitable for the SRS.
The "Lighter Proposal" addresses most technical and structural issues, and is not contradicted (although is greatly added to, especially in the areas of contractual responsibility) by the subsequent Woodenman model and Final Report. I believe therefore that it should form the basis for an SRS development.
However, the "flat" database structure does not map well onto existing databases or interface definitions, such aterface definitions, such as the Tucows OpenSRS interface model, the NSI registry-registrar protocol interface, or the RIPE database interface. I believe the simplicity of the flat model means that the development of the registry database should be straightforward, as will building interfaces to it. In addition, the requirements defined by the SRS working group are in sufficient variance with existing models and interfaces that any off the shelf registry system will need some development anyway, most likely in excess of the cost of building from scratch.
The other models for registry databases and interfacing are largely based on legacy structures, intended for manual input. With the NZ SRS, there is an opportunity to build a structure designed from the ground up to be easy to interface to.
References
Review of Registry Structure of the .nz ccTLD, Final Report, SRS Working Group, 20 October, 2000 http://www.isocnz.org.nz/consult/SRS/FinalReport201000.html
Woodenman Model for the .nz ccTLD Registry, SRS Working Group, 13 October, 2000 http://www.isocnz.org.nz/consult/SRS/Woodenman.html
A Lighter Proposal for a Registry Model for .nz , Don Stokes (SRS Working Group), 13 September, 2000 http://www.isocnz.2.html">http://www.isocnz.org.nz/consult/SRS/thin2.html
Registry Design: Fundamental Questions, Don Stokes (SRS Working Group), 5 September, 2000 http://www.isocnz.org.nz/consult/SRS/Questions.html
Don Stokes, 27 February 2001
