SRS Implementation Submission R Shearer

Comments to Green Paper on SRS Implementation

Warning, this post is long. I apologise, but there is not much option... Even then, the following comments are not exhaustive, but more a starting point from one opinion. There is some repetition in comments, but this is for clarity in the point being discussed.

1.

Thanks to writers. A good start.

2.

4.1.5 Whether ISOCNZ should own a Registrar business once the SRS is stable

Argue that this is a conflict of interest (if ISOCNZ own the SRS registry).

3

4.1.7 Ensuring that domain name holders (Registrants) do not find themselves subject to Registrar capture by ensuring, for example, that there is a mechanism by which Registrants give permission to change to a new Registrar on Day One of the SRS or thereafter.

This is definitely required but mechanism must consider that contractual relationships will be changing, eg contract with registrar 1 terminating, and contract with registrar 2 initiating.

4.

5.1 Two methods have been identified to handle the split into Registry and Registrar and whichever ihandle 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.

Would suggest 5.1.2 is only option due to in built inadequacies in the way the DRS handles registrar interface.

5.

5.2 In both cases, the Registrars portion of the company continues to function as a Registrar.

Owned by whom?

6.

5.4 The interfaces to the new Registry would be agreed by broad industry consultation.

OK, there should only need to be one real-time standard interface to the SRS open to all registrars on a standard agreement.

7.

5.5 The selection of one of these options is affected by recent announcements by the CEO and directors of the company that the DRS software may not be stable, and may not be further supported by its current contractor.

Hence opinion why 5.1.2 is only option

8.

5.6 The Company intends to create an administrative split between currently performed Registry and Registrar functions with the intention of clarifying costs associated with each activity. In this approach the technical functions would first be split, then the business functions, the Register trat, then the business functions, the Register transferred, and then prospective Registrars invited to participate in the new SRS.

The best approach would be to call for tenders for design/ development/ operation/ maintenance of the new SRS (including migration of the existing database). Award of this tender would be based on a detailed contract specifying interfaces, performance levels, etc. Tenders might tender on a per domain basis or whatever. ISOCNZ chooses the lowest priced technically compliant bid.

This approach does not require capital outlay if the tenderer bids on a fee for services basis. eg we will build you a SRS and charge you $xx per year per domain. You are effectively giving an entity a licence to make money based on provision on a service. The competitive nature of the tender would yield the best result for the society and the public.

While it would be owned by ISOCNZ, would you really want to run and maintain it - liaising with a 3rd party developer?

9.

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?

The successful tenderer

5.7.2 What input does the existing Company have to new code?

Should have no input. ISOCNZ should write the specification based on consultation

5.7.3 Who maintains the legacy interfaces?

If any registrar wishes to use "lega

If any registrar wishes to use "legacy" interfaces they should maintain such themselves. The SRS should have one interface open to all registrars on a standard agreement.

Presumably this would be whoever ends up owning Domainz if it were to be sold, or otherwise users of legacy interfaces would have the option of choosing a new registrar to set up an interface through. It would follow that this may not cost the user of the interface any money, as there would be a commercial incentive to the registrar to develop an interface to the users requirements.

5.7.4 How much will the Registry redesign cost?

Doesn't need to cost anything if you tender it out. You simply select the tenderer who gives you the best price per domain per year to design and run the registry. The requirements for the registry would need to include some "kiwi share" type conditions that the fee per domain can be adjusted equal to inflation etc etc, and contain required performance of the SRS, eg 24/7 operation, emails responded to in xx time, etc etc.

5.7.5 Who will run the Registry?

internal to ISOCNZ

new stand-alone company

outsourced

The successful tenderer runs the registry to performance specifications set by ISOCNZ. 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 thensure the stability of the DNS? public benefit for-profit within limits

The successful tenderer does the sums and works out what fee he needs to charge. ISOCNZ picks the best priced technically compliant tender. 5.7.6 What will the Registry pricing model be?

The successful tenderer (Registry) earns a fee per domain per year, paid to them by the registrars. ISOCNZ would be paid a per domain per year fee by the registry (say a few $) to cover its costs.

5.7.7 How will self-Registrars be accommodated?

What are self registrars? Anyone can become a registrar based on the standard terms and conditions for being a registrar.

Any self registrars could select to operate through a new registrar, or perhaps existing self registrars could set up a cooperative.

5.7.8 How will moderated Domains be accommodated?

Probably the responsibility of ISOCNZ in some mechanism specified into the new SRS. However, the moderating organisation should bear the costs and set the terms for moderation. This cost may need to be passed on to the registrant..

10.

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?

Dont believe so. I dont believe any tenderer would want to or should be hindered by a DRS that was not dshould be hindered by a DRS that was not designed to operate as anything other than a DRS, eg an SRS.

5.8.2 Is the current DRS so tightly intertwined that it cannot be productively split?

It would appear so

5.8.3 Is there a viable business operation in operating the non registry components of NZIRL as a Registrar?

Yes, but it could not be owned by ISOCNZ. It should be sold after a stabilisation period of the SRS and once there were a predetermined number of competitive registrars operating in the new SRS, say minimum 2 or 3.

There is the ethical debate over what to do with Domainz in any case..

Dont know the details of Domainz profitability after a split...

5.8.4 How much should ISOCNZ invest in establishing the non registry components of NZIRL as a Registrar?

Nothing. This is a direct conflict of interest and should not even be able to be considered?

5.8.5 Should ISOCNZ own a competitive Registrar?

No! It cant because it "owns" the registry

5.8.6 If not, and if the ex-NZIRL Registrar is viable, and all is stable, when should the Registrar be sold?

Would suggest within 12 months of SRS going live.

5.8.7 What is the definition of "stable" for the new SRS Registry?

"Stable" could be determined by ISOCNZ in consultation with registrars. Bugs would be managed properly with a bug list, incl planned fixld be managed properly with a bug list, incl planned fix, priority, etc etc.

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?)

Anyone meeting the terms of sale and with the money. Dont think you could prevent an offshore co??

11.

5.9 In this approach a new Registry would be created by writing the SRS registry database code from the start, or purchasing and customising an existing alternative system. The Company would transfer the Register to the new SRS registry database and function thereafter as a competitive Registrar. All Registrars and potential Registrars, including the Company, would receive the new interface to the new Registry (say) sixty days before the transition to the SRS.

Suggest 90 days.

5.10 The questions in relation to the new registry which arise from this approach are (in no particular order): 5.10.1 Who pays for the new SRS to be written or acquired and customised?

The successful tenderer

5.10.2 What exactly is rewritten:

the database?

the registration interfaces?

the business interfaces?

everything?

other?

Everything

5.10.3 Given the need to provide legacy interfaces, who provides these - the Registry or the Registrar?

The registrar who wishes to operate legacy interfaces. Presuistrar who wishes to operate legacy interfaces. Presumably this would be the purchaser of Domainz.

5.10.4 Who bears the cost of this?

That registrar

5.10.5 Should a spending limit be imposed?

No spending should be required. ISOCNZ should not have to pay for the SRS to be built. The successful tenderer would build the registry and earn a fee from registrars per domain.

If ISOCNZ invest in building the registry itself (which presumably the would have to contract out) they become open to ongoing conflict with their subcontractor and costs are uncontrollable. This has already been suggested to be the case with the existing Domainz/ DRS relationship.

5.10.6 How will the project be managed?

ISOCNZ would have a project manager. The tender would specify a reasonable set of milestone dates, with "live" date I would guess being 6 ish months after award.

5.10.7 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?

public benefit

for-profit within set limits

Explained above.

5.10.8 What will the Registry pricing model be?

5.10.9 How will self-Registrars be accommodated?

5.10.10 How will moderated Domains be accommodated?

5.10.11 What is the definition of 'stable' with relation to the new

Registry?

As per above.

5.10.12 Who should do the costings?

ISOCNZ need to determine what fee they need to earn to carry out their business. The registrant pays the registrar, the registrar pays the registry, the registry pays ISOCNZ.

The registry will set its own costings, and ISOCNZ award the job to the lowest priced technically compliant tender.

5.11 The questions arising from this approach relating to the new Registrar, are those raised in paragraph 5.8 above.

12.

6.1 In order to maintain stability of the DNS and to ensure that current contractual obligations to .nz service providers and registrants are met, it is agreed that the Company must function as a Registrar until it is decided that the SRS is stable. The questions which arise relate to whether ISOCNZ should own a competitive Registrar, and if not, what should be done with the asset. In the interim there are also questions in relation to current contractual relationships.

Believe 6.6.5 is the most ethically correct option, but will comment on all options.

Should ISOCNZ own a competitive Registrar?

6.2 Opinion is divided:

The Hine Report does not specify what happens once the Company is split into two functions

Not under the model suggested above

6.3 The Hine Report draws heavily on the ICANN model for split Report draws heavily on the ICANN model for splitting Network Solutions (NSI) into a Registry and a Registrar and which did not mandate selling the Registrar.

6.4 Subsequently "Hine Commission" members state that it was understood that the Registrar would be sold at some stage as it was seen as a conflict of interest to both run the Registry and a competitive Registrar

Agree

6.5 Other comment is divided with some pointing out that there is nothing in the Articles to prevent such ownership and others providing guidelines for sale dates. There have been clear statements from Directors of Domainz that the point may well be moot as there is doubt that the Company, whose core business is a Registry, can function as a Registrar.

Then sell it to someone who can run it.

What should be done with the Company post-SRS?

6.6 The options suggested are:

6.6.1 To close the Company down after a short sunrise period of the new Registry. This option was not seriously supported in discussions because of the following: the need to maintain stability in the DNS the uncertainty over the amount of the existing 80,000+ domain names .nz service providers who would choose to become Registrars the requirement to provide service for the following twelve months to existing Registrants the contractual relationships with Accredited .nz Service Providers and Resellers

Would concur with this thinking.

6.6. this thinking.

6.6.2 To sell the Company's Registrar business on day one of the SRS. This option was opposed as it would give the purchaser an unfair advantage in the new competitive Registrar environment.

This is also probably not feasible for reasons mentioned in 6.6.1

6.6.3 To sell the Company's Registrar business at some stage after removal of the Registry. This option generated the most discussion and a variety of scenarios were suggested, key to all of which were the assumptions that sufficient investment by the shareholder was provided to ensure creation of a commercial functioning Registrar, (uncosted) the new SRS is stable and that competition is working, for example, when: the SRS has been operational for x months (the suggestion was x = 6) there are at least y Registrars accredited to the Registry (the suggestion was y = 5) The Company is Registrar for less than z% of the names in the registry (the suggestion was z = 75%)

This is where the ethics come in. Why should it be sold anyway? What would ISOCNZ do with the money? One could argue that any proceeds from sale should be redistributed back to its registrants. 6.6.4 Using these criteria as a loose guideline a Consultant be retained to recommend when to sell.

Probably not a bad idea, but the ethical basis still needs to be established.

6.6.5 That there be no plan to sell the Registrar and that the shareholder spend no mareholder spend no money on developing and maintaining it. On the assumption over time all Registrants will be working through other Registrars. The Company can be wound up once a level is reached that is untenable to remain in business and the remaining records sold to another Registrar.

This is probably the most ethically correct solution.

7. WHAT OBLIGATIONS DOES THE COMPANY HAVE DURING THE TRANSITION?

7.1 Regardless of how long the Company operates as a Registrar there are issues which need addressing. These include:

It depends on which option 6 is taken.

7.1.1 Contractual relationships with Accredited .nz Service Providers

Would suggest 12 months

7.1.2 Contractual relationships with Resellers

This all depends on which option 6, as if Domainz is sold, then this is an issue for the new owners. If wound up, then a period say 12 months is needed to allow resellers to either become a registrar, or work with a registrar as a reseller.

7.1.3 Contractual relationships with Registrants

Again, depends on above. If sold, then contractual relationship is passed to new owner, if wound up, the registrant transfers within say 12 months to a new registrar

7.1.4 Maintaining 'Business as Usual' (in terms of the contract with ISOCNZ) in the interim and making necessary investments in relation to the stability of the DRS without gtion to the stability of the DRS without gaining unfair advantage after Day One of the SRS.

Isn't this just saying that ISOCNZ continues to operate as both registry and registrar?

7.1.5 Complying with shareholder wishes to change the nature and future of the company.

The share holders wishes should be to serve in the best interests of the customer, while providing a world class registry for NZ. I am sure the current Domainz staff would be snapped up by registrars, or even the new registry contractor.

8. WHAT OBLIGATIONS DOES THE SOCIETY HAVE DURING THE TRANSITION?

I guess the Job/ Contract description for the PM now supercedes this section to some extent, but will comment below...

8.1. To manage change in a non-disruptive way consistent with its obligation as ccTLD manager.

The Project Implementation Manager

8.2. The June 2000 AGM directed the Society to implement the AGM resolutions by employing a Project Manager to seek consensus on details of that implementation, put together a business plan and oversee implementation and transition.

8.3. Appointment of a Project Manager remained pending while the Hine report was being completed. A specification for the position was under preparation by the SRSWG, the Domainz Board and the Executive Director. It is now the responsibility of the IOC.

8.4 Where is the Project Implementation Manager based and roject Implementation Manager based and to whom does s/he report? at the Company, reporting to Council? at the Company, reporting to the Executive Director? at the Society's Offices, reporting to Council? at the Society's Offices, reporting to the Executive Director?

Only acceptable option is at the Society's Offices, reporting to Council - however via the ED.

8.5 Who writes the Policy arising from the Hine Report? ? the Council ? the Project Manager

Presumably ISOCNZ determine the way to proceed (White paper or policy), and the PM researches and drafts the SRS specification/ tender documents with support as necessary.

8.6 What notice provisions, and consultation process should the Project Manager follow?

This is best split into two components;

a. the actual policy development already has a consultation process - ie this list etc, so the PM should receive a completed policy from the society

b. The implementation of the policy ie drafting the specification will require industry input, as well as legal and accounting advice. Perhaps the industry input could be gained by a list, and meetings.

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 Projecinterest in involving the Project Implementation Manager in drafting it?

I would say there is a conflict of interest and the PM should not write the White Paper (also refer to as the policy, above). I would say it is also not in the societys best interest to have anyone other than the society draft the white paper.

Registrants Rights

8.8 There needs to be established terms and conditions (technical and legal) for secure access to the database by Registrars after Day One. The DRS contracts may provide a model as will NSI's Registrar Agreement

This is true, but there are many inadequacies with the existing DRS contracts, so would favor a new contract based on the workings of the SRS. This contract should be simple, and specify performance targets etc.

8.9 The terms and conditions of Registrants contracts with Registrars, and Registrars contracts with ISOCNZ, need to protect Registrants' rights, by at least: 8.9.1 the requirement of, and mechanism for, gaining Registrants' permission to change Registrars after Day One of the SRS (i.e., no automatic transfer to new Registrars)

Yes, but as per comments made above, the transfer process needs to formally take into account the termination of one contract and initiation of a new contract.

8.9.2 preventing material disincentives/difficulties in a Registrant's right to transfer their name to another Registrar

The registrant should have supreme control at all times, unless he is breaching the terms of his contract with his registrar.

Some scenarios that must me prevented are;

- the registrant pays the registrar,, then transfers, then charges back his card leaving the 1st registrar out of pocket - the registrant fails to pay by the due date, then attempts to transfer, leaving the 1st registrar with a debt to the registry.

There are however means around these problems, a look at the dot com world would be a good place to start.

8.9.3 pricing structures which give lock-in to new Registrars

not quite sure what is meant here, but the registry should only have one pricing structure, but this may be over multiple periods, eg 1 years registration - ten years registration...

8.9.4 penalties for breaches of Registrant's rights

ISOCNZ would need a means to deal with this

8.9.5 establishing criteria for accreditation of new Registrars

Again, a look at the dot com world would be a good place to start

8.10 The rights of registrants are paramount. The rights need to be protected from a variety of potential challenges. One that has been mentioned is from registrars. The Hine report proposes a contract structure (See Regulation 5 and paragraphs 82 95). 8.11 Appropriate contracts and terms for new registrants will need to be s for new registrants will need to be drafted prior to day one of the SRS.

Thats right, and same should be viewed prior to intending registrar being approved by ISOCNZ.

8.12 Provision will need to be made to apply those terms to all existing registrant contracts

yes, but comes back to which of option 6 is taken.

9. RELATIONSHIP WITH THE COMPANY

9.1 ISOCNZ should have regard to the performance of the company during transition, including: amending the terms of the existing contract with the Company;

ensuring that Staff are not materially disadvantaged with the change in function;

working to create an environment which minimises staff turnover during the transition and investigating risks associated with failing to retain staff;

ensuring all legal obligations are met and laws followed.

yes, but comes back to which of option 6 is taken.

Phew!

Regards

Richard Shearer

www.webfarm.co.nz

www.freeparking.co.nz

Tel: +64 6 7572881

Fax: +64 6 7572883