Personal tools
You are here: Home InternetNZ Activity Archive SRS Implementation SRS Implementation Green Paper 02/02/01
Navigation
 

SRS Implementation Green Paper 02/02/01

Issued by the S.R.S. Implementation Oversight Committee

Green Paper on the Implementation of a Shared Registry System for New Zealand

TABLE OF CONTENTS

1.  Introduction
2.  Process
3.  Existing Documents
4.  Key Issues
5.  Removing the Registry from the Company
6.  Ownership of the Company as a Competitive Registrar
7.  What Obligations Does the Company Have During the Transition?
8.  What Obligations Does the Society Have During the Transition?
9.  Relationship With the Company
Appendix One - SRS Final Report Recommendations - October 26 2000
Appendix Two - The AGM Motions
Appendix Three - Terms of Reference for Green Paper
Appendix Four - Extracts From Email Discussions On The Implementation Of The SRS

1.   INTRODUCTION

PURPOSE OF THIS GREEN PAPER

1.1   This Green Paper is the first stage in the implementation of the recommendations arising from the 'Final Report from the Review of Registry Structure of the .nz ccTLD' ("The Hine Report"). The Hine Report recommendations were accepted in principle by the Council of the Internet Society of New Zealand on October 26 2000 and there has since been ongoing discussion amongst Council, the Membership, and participants in the New Zealand internet community as to the best way to implement those recommendations (for a summary of email extracts see Appendix Four). The June 23 2000 AGM of the Society pre-empted some of the discussion by mandating certain courses of action (see below).

1.2   This first stage of implementation addresses essential steps implementation addresses essential steps in implementing a competitive SRS in New Zealand. Other recommendations will be addressed independently or upon completion of that implementation.

1.3   This Paper sets out the context in which the issue of a competitive SRS arises and lists the various implementation options which exist, and the issues which consequentially arise. It does not attempt to select a preferred course. After public comment on this Green Paper, the IOC will issue a White Paper in which an implementation course will be outlined, its consequences detailed with an implementation budget and timetable.

1.4   The implementation course chosen will inevitably have implications for the Society and the wider community, and to date little work has been done to investigate the ramifications of making radical changes to the structure of the New Zealand Internet Registry Ltd (trading as Domainz) as recommended. Those ramifications are beyond the scope of the Green Paper, and will need to be investigated before the White Paper is issued.

 

2.   PROCESS

2.1B

2.1   This Green Paper is based on a draft prepared by the ISOCNZ Executive Director, Sue Leader.

2.2   The process used by the Executive Director to meet the Terms of Reference for the "Draft Green Paper" (see Appendix Three) was to review all correspondence on both the Council-discuss and isocnz-members mailing lists which dealt with the SRS Implementation process. The email was then winnowed down to approximately 80 emails (which, as it happens, were fairy evenly divided between the two lists) which dealt with issues of substance. The opinions were then summarised by way of extracts (see Appendix Four) and form the basis of the Green Paper.

2.3   The IOC believes this Green Paper fairly represents those discussions.

2.4   The Draft Green Paper was provided to the IOC on 19 December 2000 with a view to being published for public comment on January 15, 2001. Because of delays over the Christmas period this was extended by the Chair to January 29, 2001.

3.   EXISTING DOCUMENTS

  1. The Hine Report Recommendations

3.1   The SRS Working Groups final report is available at www.isocnz.org.nz/consult. Final recommendations are in Appendix One to this Paper. The key recper. The key recommendation is that:

Recommendation 1. ISOCNZ should alter its policy to remove the registration function from the registry. The registry should focus on registrars as its customers.

3.2   The other nine recommendations flow from this basic recommendation (see Appendix One).

The AGM Motions

3.3   The June 23 2000 AGM Motions arose from Draft Two of the Hine Report and included the adoption of Draft Recommendations One, Two, Three, Six, Seven, and Nine (see Appendix Two).

3.4   The AGM determined how Recommendation One should be interpreted by passing the following motion:

AGM22 (MOVED: Farrar/Mott) THAT in order to implement the policy of "removing the registration function from the registry, with the registry focusing on registrars as its customers", the Registry function be removed from Domainz and Domainz is maintained as a Registrar.

3.5   The AGM determined how to implement the AGM resolutions, passing the following motion:

AGM23 (MOVED: Farrar/Mott) THAT ISOCNZ Council be directed to hire or contract a Project Manager to put together options on the details of the implementation of the AGM resolutions; to work with a working group which shall seek consensus and recommend and report to Council on said dncil on said details; to put together a business plan for the implementation and transition; and when approved to oversee the implementation and transition..

4.   KEY ISSUES

4.1 The key implementation issues which arise from the Hine Report Recommendations, AGM Motion 22 and online discussions are:

4.1.1 How to remove the Registry function from the Company

4.1.2 Maintaining the integrity and functioning of the Domain Name System (DNS) during the transition to the Shared Registry System (SRS).

4.1.3 Maintaining the functions for current .nz Service Providers (Accredited and otherwise) who do not wish to become Registrars on Day One of the SRS.

4.1.4 How to make the first (Domainz) Registrar viable for at least the transition period after Day One of the SRS

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

4.1.6 How to protect Registrant rights

4.1.7 Ensuring that domain name holders (Registrants) do not find themselves subject to Registrar capture by ens 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.

4.1.8. Identifying and complying with obligations to the Shareholder in splitting the asset

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.

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

5.3   Once the Legacy Registrar is operating it must exist for a period to be determined, in order for existing services to be provided during the transition and until it is certain that the SRS is stable.

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

5.5   The selection of one of these options is affected tions 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.

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 transferred, and then prospective Registrars invited to participate in the new SRS.

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?

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

5.7.3   Who maintains the legacy interfaces?

5.7.4   How much will the Registry redesign cost?

5.7.5   Who will run the Registry?

  • internal to ISOCNZ
    1. new stand-alone company
    2. outsourced

    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 fu the foreseeable future to ensure the stability of the DNS?

  • public benefit
    1. for-profit within limits

    5.7.6   What will the Registry pricing model be?

    5.7.7   How will self-Registrars be accommodated?

    5.7.8   How will moderated Domains be accommodated?

    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?

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

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

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

    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 Rege, when should the Registrar be sold?

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

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

    B.     Creating a new Registry, leaving the Company to function as a Registrar

    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.

    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?

    5.10.2   What exactly is rewritten:

    1. the database?
    2. the registration interfaces?
    3. the business interfaces?
    4. everything?
    5. other?

    5.10.3&nbs

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

    5.10.4   Who bears the cost of this?

    5.10.5   Should a spending limit be imposed?

    5.10.6   How will the project be managed?

    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?

    1. public benefit
    2. for-profit within set limits

    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?

    5.10.12   Who should do the costings?

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

     

    6.   OWNERSHIP OF THE COMPANY AS A COMPETITIVE REGISTRAR

    6.1   In order to maintain stability of the DNS and to ensure that currDNS 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.

    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

    6.3   The Hine 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

    6.5   Other comment is divided with some pointing out that there is nothing in the Articles to prevent such ownership and others provs 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.

    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:

    1. the need to maintain stability in the DNS
    2. the uncertainty over the amount of the existing 80,000+ domain names .nz service providers who would choose to become Registrars
    3. the requirement to provide service for the following twelve months to existing Registrants
    4. the contractual relationships with Accredited .nz Service Providers and Resellers

    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.

    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 wery 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:

    1. the SRS has been operational for x months (the suggestion was x = 6)
    2. there are at least y Registrars accredited to the Registry (the suggestion was y = 5)
    3. The Company is Registrar for less than z% of the names in the registry (the suggestion was z = 75%)

    6.6.4   Using these criteria as a loose guideline a Consultant be retained to recommend when to sell.

    6.6.5   That there be no plan to sell the Registrar and that the shareholder 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.

     

    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:

    7.1.1  &n

    7.1.1   Contractual relationships with Accredited .nz Service Providers

    7.1.2   Contractual relationships with Resellers

    7.1.3   Contractual relationships with Registrants

    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 gaining unfair advantage after Day One of the SRS.

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

     

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

    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 to whom does s/he report?

    1. at the Company, reporting to Council?
    2. at the Company, reporting to the Executive Director?
    3. at the Society's Offices, reporting to Council?
    4. at the Society's Offices, reporting to the Executive Director?

    8.5   Who writes the Policy arising from the Hine Report?

    • the Council
    • the Project Manager

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

    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?

    Registrants Rights

    8.8   There needs to be established terms and conditions (technical and leonditions (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

    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)

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

    8.9.3   pricing structures which give lock-in to new Registrars

    8.9.4   penalties for breaches of Registrant's rights

    8.9.5   establishing criteria for accreditation of new Registrars

    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 drafted prior to day one of the SRS.

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

     

    9.   RELATIONSHIP WITH THE COMPANY

    9.1   ISOCNZ should have regard to the performance of the company during transition, including:

    1. amending the terms of the existing contract with the Company;
    2. ensuring that Staff are not materially disadvantaged with the change in function;
    3. working to create an environment which minimises staff turnover during the transition and investigating risks associated with failing to retain staff;
    4. ensuring all legal obligations are met and laws followed.


    APPENDIX ONE

    SRS Final Report Recommendations - October 26 2000

    An asterisk (*) indicates that the Recommendation was accepted at the June 23 2000 AGM of the Society.

    *Recommendation 1. ISOCNZ should alter its policy to remove the registration function from the registry. Th from the registry. The registry should focus on registrars as its customers.

    *Recommendation 2. A standing committee be established to maintain communication between the registry and registrars. The standing committee should be chaired by a member of the ISOCNZ Council and should include technical representatives from the registry and a minimum of two different registrars and/or agents.

    Recommendation 3. A registrant authentication field should be included in the register. The designated registrar shall make the contents of the authentication field available to the registrant on demand.

    Recommendation 4. Registry information.

    • All information that the ccTLD manager requires to be available should be held in the registry and should be public (other than the authentication field which would only be available to the registrant and its designated registrar).
    • The registry should operate both a basic whois service and a web based information service to provide this information to the public.
    • There should be no change to the information required to be publicly available. This information should remain consistent with the requirements of RFC 1591:

    domain name,

    registrant name,

    nameservers,

    administrative contact information,

    and technical contact information.

    To this should be added the designated registrar's name and url as well the registrant authentication field.

    Recommendation 5. ISOCNZ, acting as ccTLD manager, should ensure that a contract structure along the lines of that described in paragraphs 82 to 93 is put in place to support the proposed SRS framework.

    Recommendation 6. The registry should maintain an audit of all transactions against the register capable of reproducing the state of the register at any point in time as well as recording all transactions. The audit should be kept indefinitely. Subject to privacy/confidentiality requirements and any necessary cost recovery, any person involved in a claim or dispute involving a domain name will be able to obtain a certified copy of the relevant audit records from the registry. Those records shall also be made available at the same time to the ccTLD manager.

    Recommendation 7. ISOCNZ should accurately define the role of ccTLD manager and establish the office of "ccTLD Manager" with adequate resources to develop, promulgate and administer policy; to negotiate and manage contracts; and to administer the resolution of disputes. This office should be paid for by the internet community.

    *Recommendation 8. ISOCNZ should revise its charging policy to encourage registry charging to:

      • Be focused on the registrar as a customer.
      • Reflect a registrar's use of the register.
      • Be independent of any contract or agreement between registrar and registrant.

    The registry should charge the registrars to recover both its costs and the costs of the ccTLD manager. While the registry will act as a single collection agent the separate costs of registry and ccTLD manager operations should be clearly transparent, though not necessarily separate line items in the invoice.

    *Recommendation 9. ISOCNZ adopt a best practice policy.

    Recommendation 10. Organisations that have decided or wish to moderate their own second level domains within .nz shall be responsible for ensuring that moderation is done as part of the registration process.


    APPENDIX TWO

    The AGM Motions

    The AGM Motions arose from Draft Two of the Hine Report (June 19 2000).

    AGM10 "THAT ISOCNZ adopt a Best Practice policy".

    AGM11 "A standing committee be established to maintain communication between the n between the registry and registrars. The standing committee should be chaired by a member of the ISOCNZ Council and should include technical representatives from the registry and a minimum of two different registrars and/or Agents."

    AGM13 "THAT ISOCNZ should alter its policy to remove the registration function from the registry. The registry should focus on registrars as its customers." (same as Recommendation One)

    AGM14 " THAT Recommendation Two in the report be adopted.

    This reads "THAT ISOCNZ should revise its charging policy to encourage registry charging to:

    • Be focused on the registrar as a customer.
    • Reflect a registrar's use of the register.
    • Be independent of any contract or agreement between registrar and registrant.

    (The third bullet point which sought to "include either a fixed or minimum monthly charge set at a level to discourage registrars managing less than 100 names" was removed by amendment)

    AGM16 (MOVED: Hine/Linton) THAT Recommendation Three in the report be adopted.

    This reads "THAT ISOCNZ establish policy setting standards for the proper governance of the relationship between registry, registrar and registrant.".

    AGM17 (MOVED: Hine/March) THAT Recommendation Six in the report be adopted.

    This reads "Additional discussion and study should be undertaken to better understand the advantand the advantages and disadvantages of a structural versus a contractual solution to the question of protecting the registrant's rights to their name. Within a structural solution itwill be necessary to accurately assess the level of authentication that would be appropriate.".

    AGM18 (MOVED: Hine/Farrar) THAT Recommendation Seven in the report be adopted.

    This reads "The criteria for accreditation should be reviewed once the structure of the registry is determined.".

    AGM19 (MOVED: Farrar/MacEwen) THAT Recommendation Eight be withdrawn.

    AGM20 (MOVED: Hine/Farrar) THAT Recommendation Nine in the report be adopted.

    This reads "The working group should continue to resolve and develop the relative advantages and disadvantages of the structural and contractual approaches to a registry model".

    AGM22 (MOVED: Farrar/Mott) THAT in order to implement the policy of "removing the registration function from the registry, with the registry focusing on registrars as its customers", the Registry function be removed from Domainz and Domainz is maintained as a Registrar.

    AGM34 (MOVED: Gary/Mott) THAT this AGM directs the incoming Council to adopt and promote the use of the ICANN definitions of 'registrar' and similar words and to the greatest extent possible oblige Domainz to do the same.


    APPENDIX THREE

    Terms of Reference for Green Paper

    2/12/00

    "Commissioning a Green Paper: Towards a Competitive Shared Registrar System for .nz".

    Dear Sue,

    Further to our exchange, please begin preparation of a draft Green Paper on the options for the implementation in .nz of a competitive shared registrar system.

    You should begin with a statement of the objectives, which you can identify from the AGM resolutions and the SRS working group's report.

    Then, it requires a synthesis of the options raised on the various council and public lists as to what needs to be done.

    The primary points seem to be to be:

    *setting up/splitting out from domainz and maintaining the registry in a safe and stable manner-

    *setting up/splitting off from domainz its current registrar functionality, continuing its contractual obligations in relation to those functions in a way independent of any registry function,

    *establishing the terms and conditions of secure access to the data base by registrars (technical and legal)

    *establishing the terms and conditions of registrants cogistrants contracts with registrars

    *amending the terms of the current contract with domainz to provide for transition

    *providing for what happens domainz and its customers after the transition.

    *defining the job for an implementation manager.

    You should find all this and more on the lists and in council minutes. The key thing is to set out the various options - as several have commented, its been going on for long enough to be clear now what these are.

    Do not try to deal with the consequential political and structural issues which will flow, and which can distract. (committees, fees, the delegation, etc)

    Please let me have your draft Green Paper by December 31. I shall be happy to assist with drafting and consultation before then I am sure other memebrs of the IT will be ready to assist also.

    The Implementation Team will publish the Green Paper in final form, calling for comment over a shortish time frame, in view of the history.

    After digesting that feedback, the IT will (undoubtedly with your further assistance) draft a series of final recommendations by way of a White Paper. This will amount to election of a programme, with a timetable, budget etc.

    After a further brief period of public comment, this will go to council for final approval.

    I anticipate this occuring over the next 12 weeks. If you think it can be accomplished more swiftly than that,includeat,include that as a recommendation.

    Many thanks

    Peter Dengate Thrush

    Chair

    ISOCNZ


    APPENDIX FOUR

    Extracts From Email Discussions On The Implementation Of The SRS

    Contributors who made substantive comment: ***

    Councilors: Rick Shera, John Hine, David Zanetti, Andy Linton, Andrew Mason, Richard Bourne, Jordan Carter, Keith Davidson, Peter Dengate Thrush, Simon Blake, Jennifer Northover

    Domainz Directors: Bob Gray, Keith Davidson

    Members: (other than Councilors and Directors) Ewen McNeill, John Rumsey, David Farrar, Joe Abley, Peter Mott, Carl Armstrong, Don Stokes, Jenny Shearer

    *** several others made comment which was not substantive

    The Position from SRS Report

    1) Create SRS and start offering service. The details of the interface to be derived by consultation with customers including Domainz.

    2) Domainz adjusts to new SRS interface and being a registrar.

    3) ISOCNZ sells Domainz 3-12 months after SRS starts service, i.e. ISOCNZ sells a stable, operating registrar service.

    My problem is that I have no idea how this sits with Domainz and the maintenance of ISOCNZ's value in Domainz. Thus I need input from Domainz in order to fairly compare this strategy with another, eg. shutting down Domainz.

    ==========

    The clear resolution as we stated in the SRS report was that ISOCNZ (ie Domainz) should not own a registrar business at the same time as owning a registry and/or being the ccTLD manager - that is an obvious conflict of interest and is one of the primary reasons the whole review kicked off in the first place - clearly Domainz was moving down that track.

    It was also concluded as a result of the SRS consultation that Domainz the registrar (in the form of its relationships to registrants and agents through its contracts and through its interfaces) needed to be kept for a period because otherwise there would be too much disruption to everyone and cost to those who had adapted their systems to the interfaces. Of course at the time we were told that the DRS was stable ...

    ===============

    > It is conceivable that a big ISP like Xtra, with its known aversion to

    > signing contracts that don't leave it holding all the cards, may find

    > dealing with DomaiNZ preferable to dealing with the new registry

    > directly.

    >

    Thats certainly what they told us when we visited them as did several other ISPs we managed to talk to. That is the driving force behind not scrapping the DRS (ie at its bluntest, splitting off the registry). If the technically savvy say that its better to create a new registry from scratch then thats ok but it doesn't alter the original premise.

    The Alternatives

    The clear and valid options (not in any order) are:

    1. To close Domainz down after a short sunrise period of the new registry.

    2. To sell Domainz's registrar business on day one of the SRS.

    3. To sell Domainz's registrar business at some stage 3- 6 months after removal of the SRS.

    4. To continue to run Domainz as a competitive registrar in the future.

    Within each option, there are obviously some sub-options. For example, within option 4, would Domainz compete on the basis of contributing ongoing profits back to ISOCNZ, or profits to an "Internet Foundation" for public good, or at zero profitability to ensure that the competitive registrar business is very cost-competitive?

    The Questions

    First Consideration - Domainz Comment

    How about the basic premise by which the *.nz registry is governed?

    a) As a service to the internet population or

    b) As a revenue generatievenue generating exercise (or business)

    If the society go with a) then there is no need for new products and services, marketing and no concern if users (name holders) drift off to the new gTLD's. There will be revenue for ccTLD management and little (nothing?) more.

    OTOH if the society stick with b) then there is need for investment, continued marketing of *.nz as an attractive name space and new products and services. With good management (and a little luck) the societies revenue will continue at higher levels.

    Once this decision is made then issues such as outsourcing become self evident.

    Second Consideration - Domainz Comment

    The AGM decided that the registry should be spilt from Domainz, that does not inherently make the remaining registrar business viable. The AGM was silent on spending money on Domainz's registrar business however I'd be happy to make a guess at what the members would think of that. :)

    Third Consideration - Council Comment

    It would be easy for Council and Domainz directors to focus purely on the registry, and watch what may well be a saleable item become valueless in the process. It may also be argued by some (councillors or members) that the balance of Domainz after removal of the registry should perish. Alternatively too, there may be some justification in criticism that ISOCNZ/Domainz did not seek to maximise a return on investment in an ordern orderly disposal of the registrar part of the business. It could be also argued that ISOCNZ is in the business of the "registry" and musn't also be in the business of "registrar", or from the opposing viewpoint, that ISOCNZ has a golden goose in its registrar business and must not slaughter it. And from my perspective, as I have said in the past, we currently have something, we are about to make it two things, and outside of the technical ramifications alluded to via the Hine committee, we have not examined any other perspective as to what it is we are breaking, why we are breaking it, how we are going to break it, and what we want to do after it is broken. In fact Domainz directors have no clear mandate to act until ISOCNZ gives some clearly defined policy as to whether or not the Council believes it is in a position to be (or not to be) a competitive registrar. The only thing we cling to tenaciously is the resolutions from the AGM commanding us to break it. And this is despite the fact that part of the potential reasons that gave rise to the command from the AGM (POB and JH) having been removed from the equation.

    ==

    We need to examine the braoder aspects of the businesess of Domainz rather than purely the technical issues of splitting the registry from the registrar. For example, are we adding to the potential costs of registering domain names by introducing inefficiencies through lack of economies of scale etc? What is the value of the thing we are breaking apart, and will the value of the bits be greater than, or less than the value of the whole?

    ===========

    So lets dispel the myth that Domainz will retain any captive customers after removal of the registry. It may be that my own ISP, with about 150 .nz names, may be a bigger registrar than Domainz...

    Wider Consultation

    > For that reason, we need to ensure the debate is open to all of the

    > internet community, not merely the (often stridently and repetitively

    > expressed) views of the registrar/ISP community

    This is perhaps the only consensus that has been reached in this thread so far. There have been a wide range of views expressed (which are probably representative of the wider community) and appear difficult to reconcile.

    It is also vital that the proposed resolutions receive the same level of industry approval as is evident in the SRS report. Any entry into an unstructured public debate about the future of Domainz has the potenhe potential to be very destabilising and a disaster for the operation of the company.

    Business Split - Reporting

    We have planned to (once Council accepts the SRS report) to split the business in a financial reporting sense into two operating divisions registry/registrar and report to council on the financial performance of both halves.

    Technical Mgr - Domainz Comment

    The CEO is also preparing a job description for a technical person with 'clue' to investigate and subsequently action the technical split of the registry from the DRS.

    ====

    Note that it would be a clear part of the job to consider outsourcing of the registry function as suggested by Andy Linton.

     

    Competitive Registrar

    The company has offered financial inducements (cheaper fees) to channel partners to become accredited .nz service providers (previously registrars) and feels it would be improper to now invest in a competitive system to deal direct.

    During the split

    During this period (while the technical split is made) think the detailed role of the Office of the ccTLD Manager could be defined by the society and the governance mechanisms and inter-relationships with the registry developed as well as drafts of the accreditation and dispute resolution procedures as well as contracts and so forth.

    =h.

    ========

    Domainz registrar should be sold in the medium term once the SRS is up and running

    - Until then Domainz the registrar should be run in a "maintain the status quo" manner subject of course to making sure it improves its customer relations, fixes bugs and complies with the law (and I'm thinking here of competition law re predatory pricing which is what a reduction to a cost recovery regime would effectively be)

    - Any major initiatives - changes of direction by Domainz in that interim period (which could possibly be 6 months - 1 year or so) should be approved by shareholder.

    Post Split

    I have only one issue and that is that Domainz (and by implication the society) have committed to a (now) largish number of vendors that the e-mail interface will remain available regardless of the SRS implementation. This commitment has led to companies developing to that interface (regardless of it's horribleness or otherwise)

    ====

    No, I don't see the argument here, stopping Domainz being a registrar _by no means_ mandates the withdrawal of the e-mail interfaces. In fact what it would allow is the accredited .nz service providers tiders to become registrars (which is what most of them signed up to anyway) if that is their wish.

    In fact nothing I have seen precludes the registry continuing to offer this interface as a 'legacy' to those who wish to be registrars but do not wish to reinvest in what is (as yet) a non existent and undefined interface.

    ========

    > No prospect of conflict. Our job includes preparing for the

    > sale of the registrar.

    Sorry where did that bit come from? I recall no agm motion mandating this nor indeed any other discussion. Feel free to put me on the right track

    ==============

    > all. There is still a market for registrars not affiliated with ISPs to

    > service nameholders like these.

    rare-domains.com.au, asia on-line, asv.com, magic-moments.com, and vi.net are some of the worldwide "accredited" .nz name providers. Geography is not an issue either. My *little* ISP hosts .nz and .com domain names on behalf of residents of Australia, USA, UK, Mexico etc.

    ===============

    There are two situations:

    1. Customers that deal directly with Domainz to get their names entered into the reginto the registry (Domainz as a registrar)

    2. Customers that deal with a reseller who gets Domzins to put their names into the registry (Domainz as a registrar providing a reseller friendly interface)

    ==================

    It wouldn't make any difference to what Domainz would be doing now (outside very very unlikely things like Domainz being shut down on day 1 of the SRS leaving customers stranded -- which is completely at odds with ISOCNZ AGM resolutions).

    ==========

    The provision of name registration service by a potential competing registrar would require either:-

    a) The registrant terminating the contract with domainz and establishing a new contract with the new registrar

    or

    b) Domainz assigning the contract to a competing registrar

    If we assume domainz intends to continue its core business of being a registrar, option b) would seem unlikely.

    Therefore, at SRS launch date, domainz has all the contracts (customers) and new registrars have to attract potential customers to facilitate them terminating their contract with domainz and entering into a new contract with themselves.

    =============

    If they become a Domainz reseller, they still contribute to the income of Domainz.

    ============

    How should the Split be Managed?

    You can't split if you don't have terms of reference. This is like the Siamese Twin operatise Twin operation referred to as an analogy. We need to decide if we want to a) have a low risk to one twin and a certain death to the other _or_ b) higher risk to both but some hope that both will live.

    ===========

    We could literally interpret "split" as a verb and put a sharp knife through Domainz building a new interface as we go. The steps would be

    1. Technical split of function within Domainz, followed by
    2. Split of business function into two companies (registry/registrar),

    and finally,

    3) Invitation to new registrars to join in.

    Alternatively we could interpret "split" as only a description of the final state in which case we might 1) Build a new registry, then 2) On some d-day transfer the register to it, followed by 3) All registrars (including Domainz) start use.

    Note: in either case the new interface should have broad consultation within the industry.

    ==

    Note that this issue could be viewed as important to the project managers job description. In the later case the project is clearly to get the new registry up. All registrars will have to work at being ready to use it. In the first case the pst case the project manager has to work with Domainz on splitting the DRS function as well as establishing the new business.

    ============

    Would it not be considerably easier to build the new SRS in complete seperation from Domainz's systems to SRS-specific specifications from scratch? That way, Domainz's systems are left alone, except for the changes other registrars are making anyway. We also have a fall-back if (and I really hope this doesn't happen) the SRS fails the inital rollout.

    ============

    I have come to the same conclusion as David. In my experience, attempting to split a system into two isolated yet functional parts is usually very difficult (read "expensive"). I suspect that the quality of build of the "new" DRS would make it even harder. Add that to my suspension that Advantage would like to wash their hands of Domainz, I would suggest that the only way forward would be to build a new SRS with the appropriate links to the current DRS.

    ===========

    > Richard wrote:

    >

    > > I would suggest that

    > > the only way forward would be to build a new SRS with the

    > appropriate links

    > > to the current DRS.

    >

    > This is the process the WG anticipated.

    >

    > jh

    >

    I had always thought that this was the intention. From my knowledge of the DRS I don't think anything else would really be feasible.

    ============

    There is no assumption by the board that the DRS code would be used for the new registry or indeed anything else. The opposite appears to be the case.

    ==

    > Domainz involvement in it and the splitting of activities

    > into different cost centres, would be to take a knife and

    > slowly cut the two apart.

    There seems little option but to do this since (as has been noted elsewhere) both registry and registrar functions are handled in the one organization. We are talking about processes and identifying what is which.

    ============

    Domainz's interfaces are interfaces to _Domainz_, and not to be roughly tacked on to this new registry. The whole point of spliting it this way is Domainz's remains more or less as it is, just the back end changes to a more acceptable interface

    =======

    I have a real aversion to tacking on a large number of interfaces to this registry, it will simply inflate the cost of building and maintaining it. There should be _one_ interface, suitable for the 95% of registrars, not the mom-and-pop registrars who want a "simpler" "simpler" interface over insecure email.

    =============

    I would be disappointed with the process for the SRS if every ISP was not able to be a registrar on day one. If the consultative process is followed, all ISP's should be in a solid position should they elect to be.

     

    The Process - Council Comments

    If Domainz needs more clairification on this issue, then Council should direct Domainz on this matter clearly. IMO, that is:

    - Domainz will become a registrar

    - Domainz will get the interface to the registry on day -60 like every other registrar

    - The Society will be selling Domainz as soon as practical

    ===============

    Good logic. So let's say that isocnz agree, should the directors be told to a) maximise the potential return (by for example investing in the registrar business) or b) ignore the sale issue and concentrate on facilitating the switch to the SRS or c) something else?

    Note that in the absence of instructions to the contrary I would think the directors may well be obligated to do a) by the companies constitution.

    =================

    Under current

    > contracts that revenue is not at risk because even if every single

    > customer buggered off you would not have to refund them a cent.

    That's not the point. The point is that if Domainz was deprived of revenue to sell new names and/or renew existing ones (say as part of the SRS process) the money would have to be used to maintain the service for the subsequent 12 months. Think of it like a magazine with annual subscriptions. You might not make a single sale after a certain date but you still have to produce a further 52 weeks' copies with no revenue.

    It's not simply correct accounting procedure but good sense. Think of it like pre-funding ACC or national super :)

    ===================

    ?????????

    >these were registered directly with Domainz by the individual

    >nameholders. It may be that the new registry will still enable straight

    >interaction with these 5,000 nameholders as individual registrars.

    No - this is not going to happen. There will be a minimum billing amount which would make this unprofitable.

    =================

    The Process - Membercess - Members Comments

    Broadly speaking there are three periods in which such ownership can be divested. they are:

    1) before the SRS is implemented

    2) at the time the SRS is implemented

    3) after the SRS is implemented

    I oppose (1) as private owners of DOMAINZ could then start to do a NSI and do everything possible to delay the move to the SRS and want to retain monopoly profits for as long as possible.

    I also oppose (2) as even though the transition to the SRS iwll be complete we will still have a situation on day 1 of the SRS where DOMAINZ holds 100% of names and everyone else owns none. A privately owned DOMAINZ would still be in a position to abuse its dominant market position by making transfers difficult etc. There is also the practical difficulty of trying to sell something in advance of a certain day where a price has already been settled but the cost of changes has not been finalised.

    Therefore in my opinion the only logicial conclusion is that ISOCNZ should divest itself of ownership of DOMAINZ some time after the SRS goes operational. They key is that the new SRS is stable and that competition is working. Some suggested criteria are that all the conditions are met:

    a) The SRS has been operational for x months (suggest x = 6)

    b) There are at least y Registrars accredited to the Registry (suggest y = 5)

    c) DOMAINZ is Registrar for less than z% o than z% of the names in the registry (suggest z = 75%)

    Once these criteria have been met (or just before they are met if there is a clear trend) ISOCNZ divests itself of DOMAINZ by offering it for sale. If within xx (say 9) months no buyer has been found then DOMAINZ will be closed down within yy (say 12) months and its customer records transferred to another Registrar as a commercial transaction.

    ===========

    This is obviously the right track, but these criteria are surely too restrictive. It could be optimal to sell Domainz after three months, all added registrars could be no good etc and the worst case, that no proper competitive market emerges... Maybe, given the problems of the past, we could employ an independent consultant to give the green light when the competitive system is stable?

    Should ISOCNZ Own a Registrar?

    Council Comments

    #1. ISOCNZ has no place operating or owning (or controlling a third party doing so) a competitive registrar no matter how arms length it may be. This was the unanimous view of those who made submissions to, and held discussions with, the SRS WG both before and *after* the AGM. It is an obvious conflict flict of interest for the ccTLD manager to be running a profit driven participant in its DNS space.

    #2. The fact that ISOCNZ did end up owning a registrar which was in the process of trying to become competitive (whilst holding a monopoly position) was a mistake due in some part to a lack of direct oversight by ISOCNZ and is in direct contradiction to its own policy on the DNS which was to keep the monopoly part as narrow as possible. The fact that Domainz the registrar *may* have some value or be saleable should be looked at in this context.

    #3. If it is accepted that ISOCNZ should not own/operate/control a competitive registrar and that the current registrar function of Domainz is a mistake, then there seem to me to be two options: (1) do as John H suggests and try to reign Domainz back in by putting a blow torch to its registrar bits; or (2) split the registry off the back and focus on that as the ccTLD manager's main role (in addition to any other public good roles ISOCNZ should have). The problem with (1) was mainly that this would involve destroying the interfaces that the SRS WG was advised various "agents" had spent $$$$$ integrating with and which many name holders are used to interacting with. It also seems to indicate a complete waste of a lot of $$$ spent on those interfaces only very recently.

    #4. Therefore, I continue to believe that (2) (splitting off the #registry) was and is the only optionion.

    .

    #6. The question that is still to be answered, since it was outside the SRS WG's ToR, is what happens to the registrar bit. We have Bob's advice that to make it competitive would take some investment. We don't know how much but presumably quite a bit. I have to come back to #1 above; this is not something ISOCNZ should be doing. To do it now in anticipation of a sale must surely involve putting in place measures which rely on the current monopoly position and on domain name fees that were never intended for that. To do it in anticipation of keeping the registrar bit (owning, licensing it or somehow maintaining some control of it) and therefore reaping income from it, is a conflict of interest, is a misuse of the relationship with name holders that arises out of the monopoly ccTLD management, and is outside ISOCNZ's not for profit origins. I also don't think that ISOCNZ is currently equipped to run/own or control a competitive registrar.

    #7. My suggestion re the registrar bit is therefore that we just leave it for the moment. It will be left behind when we split off the registry and that is the time to decide. My view at this stage is that we would then sell it on an "as is where is" basis without (IMHO) "misspending" name holders' money on something that was never intended - the creation of a competitive commercially profit driven registrar. However, it is not something that needs to be or should be decided now - to do so must involve all of the problems in #6 above.

    =============

    The conflict in our setting the rules and at the same time owning a player was precisely the sort of conflict of interest that lay behind the request for the domainz split in the first place.

    ====

    Any period of ownership resulting from the split must be for a minimal time.

    =============

    Should ISOCNZ Own a Regsitrar - Domainz Comments

    Just so we are all clear, does isocnz actually _want_ to invest in and own a competitive registrar? There is a considerable way to go to makeover Domainz into this and make this happen and _no_ guarantee whatsoever of success. Moreover how would the internet community at large (esp. registrars) feel about ISOCNZ doing this?

    Should ISOCNZ Own a Regsitrar - Members Comments

    >Is there a viable competitive registrar business long term?

    Yes.

    >Should isocnz be in it/invest it?

    In the long term, no. In the long term ISOCNZ should sell off Domainz. In the short term Domainz must invest in the new systems, customer service, et al, in order to (a) provide a smooth transition, and (b) remain competitive, so as to be able to be sold as a viable business.

    ========

    At what point in the separation of

    > the Registry and Domainz would you see the sale occuring?

    I guess I'd thought immediately once the split was managed and Domainz was trading independently. I suppose it would then have been OK for Bob, yourself, Roger et al to throw some money at making sure the asset was in best shape for sale. But <sigh> its clear that there is too much uncertainty in how the marketplace is going to be to justify such a strategy, and stability has to come first.

    But now I guess the equity principle demands that Domainz be run conservatively, and it looks like by the time it actually is sold that everyone will have a good idea of what its really worth :-( I was contemplating pie in the sky perhaps.

    ========

    Given Peter Mott's approach it is clear that the stability of the system comes first and that Domainz should stay operational under ISOCNZ control until competition is working.

    ========

    The first questions is whether long-term it is desirable for ISOCNZ as TLD manager and policy setter for the Registry to also be owning a Registrar. I beleive it is not desirable as there is a serious perception of a conflict of interest plus several potetial actual conflicts of interests (making decisions good for the registrar community but bad for the asset we own)

    ========

    ISOCNZ should _not_ be in the registrar business, and should _not_ invest in any such business.

    ISOCNZ has an obligation to maintain NZIRL in the medium term as a functional registrar, because ISP's and others have spent their dosh to set up interaction with NZIRL's interfaces. They should not suddenly be forced to spend money developing their own interfaces.

    Once that interim has gone (and the time probably needs to be debated) then ISOCNZ should dispose of NZIRL, preferably by selling it.

    ========

    I don't see that operating a commercial registrar is incompatible with the objectives of ISOCNZ. Nameholders will have more registrars to choose from, so it has to be good for them. Provided the registrar market is a true "level playing field" I don't see that other registrars could have any valid objection.

    I think ISOCNZ has a duty to .nz nameholders and existing to keep DomaiNZ running for quite some time (at least a year) after the SRS starts, in year) after the SRS starts, in order to ensure a smooth transition.

    Selling off DomaiNZ early in the process could be seen by new registrars as giving a competitive edge to the purchaser - an early sale could cause more unhappiness amongst registrars than keeping it would.

    ========

    There are two scenarios here.

    If DomaiNZ is still managing lots of domain names, it would be an attractive proposition for a profitable registrar to take over, thereby expanding their customer base and improving their economies of scale.

    If DomaiNZ is managing very few domain names, it will have negligible value. If no buyers can be found for the business, it would have to be closed down and the assets liquidated.

    ========

    On the other hand, the SRS means that the billing and customer relations component of domain registration gets handed to to the registrar to deal with, which can potentially be much more efficient.

    I suspect that Domainz will lose a fairly small percentage of its customer base quickly after the cutover -- maybe 20% -- as the ISPs that already on-bill bring up systems to interact with the SRS. The next maybe 50-60% loss would be slower, as not only SRS interfacing need to be brought up, but business models and systems to run the them need to be developed as well.

    ========

    I think, however, that if ISOCNZ wants to run a competitive registrar business, they should facilitate the formation of some other neutral body to be TLD manager, and request IANA to transfer the delegation.

    Running a competitive registrar and being TLD manager simultaneously would be a conflict of interests.

    ========

    Costs of Investing to Create the Registrar - Domainz Comments

    OK, Off the top of the head:

    1. How about a new, easy to use, web site (along the lines of 2day.com perhaps) with name servers?

    2. Standby production and development hardware might be of use too.

    3. Some sort of load-balancer/failover system to allow two sets of production hardware to be in use to give adequate uptime

    4. Additional products and services to give some continuity of income to the business

    ====

    My experience is that tendering out is generally not the best way to get a good service (profit for the contractor tends to be inversely proportional to effort) and that here you have limited the contenders to a point where your assertion certainly isn't the case.

    ================

    There are a number of issues which _may_ require investment to resolve and the members must accept that the Board's priorities for expenditure will be operational issues (stability of systems and so forth), improved customer service, SRS implementation, etc. with dividends to the owner being out of what remains. Lack of funds is not the excuse, uncertainty about the expenditure required to meet the societies expectations is the reason.

    ================

    Costs of Investing to Create the Registrar - Council Comments

    The Society must diverge itself of Domainz, it has no place to own it. If that means spending a reasonable amount to make it go away, then I would support that. If it means burning its cash reserves and putting ISOCNZ and nameholders at risk, then Domainz will come second. IMO :)

    =======

    That depends of course on what we decide to do. On SRS day one, ISOCNZ will be left with a registrar. Anything which is done in the implementation which has the effect of strengthening that registrar's position seems to me to indicate a conflict.

    ==============

    I'd support spending whatever is needed to get Domainz functioning as a Registrar, and working well with the new Registry. Beyond that, making it "competitive" (web page tartups, changes to the DRS, whatever) should be the responsibility and decision of whomever owns Domainz post SRS introduction. At that point, I think I'd agree that ISOCNZ doesn't want to commit to the costs involved in "competitivisation" of Domainz, and we should sell it Aainz, and we should sell it ASAP, while the majority of name holders still use it as a registrar.

    I would strongly oppose Domainz changing it's frontend *and* registry interface at the same time - that seems like history we don't need to repeat.

    Costs of Investing to Create the Registrar - Members Comments

    reseller, and there's upwards of a $10-20,000 cost to set up the systems to be a registrar on a large scale (ie, one of the existing resellers) particularly if they then need to take over the billing of customers.

    =============

    I think ISOCNZ has an obligation to .nz nameholders and their agents to keep DomaiNZ "business as usual" throughout the transition to the SRS, and this is most easily achieved by retaining ownership of DomaiNZ. I believe this overrides any argument for selling DomaiNZ ASAP in order to realise the greatest return.

    =============

    But, it does require that Domainz be prepared to offer services above and beyond simple registration. Otherwise the trend can only be downward, and the value that (rightly or wrongly) has been developed and vested in ISOCNZ will be lost. I think it's worth retaining.

    =================

    Running the Registry

    Who-ever the registry is tendered out to (assuming it's tendered out, and I'd suggest it's the best way to get a good service for a lower cost) shouldn't be a player in registering names. That probably eliminates most ISPs from picking up the reigstry, unless they were prepared to never become a registrar.

    Secondly, the advantage is minimal at best, since the reigstry does NOT set policy, and it does not make decisions about registrars. ISOCNZ does that. The registry runs a database and a few machines. Nothing more.

    =====

    In all seriousness, if it's a choice between pain for nameholders and the namespace, and pain for Domainz, ensuring nameholders and the 'net is as unaffected as possible must be our highest priority.

    =======

    And Domainz is entirely the wrong structure to run the registry, it's far too top heavy with a board of directors, CEO, etc. It's the sort of task you would want to tender out to someone who's already absorbing all that cost across other things. You want an entity that collects the $n/mth from registrars, delivers the service for a fixed cost of $y, and hands the rest back to the Society.

    ==========

    On the other hand, turning Domainz into a registrar is relatively simple, nameholders don't need to immediately find a new contract, ".nz Service Providers" continue to work with the same interfaces and contracts that have, and Domainz only needs to add an interface to the registry off the side of it's existing system.

    =============

    5 lines of perl is perhaps an exageration, but the registry is not a

    difficult task. A couple of tables, a script to dump one of them into the zone file, and few other bits to talk to registrars.. It's just not that difficult to build and maintain _if_ we keep it clean.

    Clutter it with too many interfaces as well as legacy interfaces from Domainz, you'll end up with another DRS monster with a price tag to match.

    =========

    Merely because Domainz currently hosts the data does NOT mean it should design any part of the SRS. Note: DESIGN, not help migrate.

    > The registry must be extracted from the DRS _without_incident_.

    That's migration, not design. By all means, once the SRS schema is nailed down, involve Domainz in what's going to be involved to migrate the data itself. That has NOTHING to do with the registrar-registry interface.

    ================

    >BTW, the $12 figure came from the fact the .com space registry charges

    >(IIRC) US$6/name/year, so it made sense to take it as a rough estimate..

    If that is the going rate and I've no doubt it is then perhaps we should just outsource our registry to one of the overseas specialists. Why are we so intend on building our own registry?

    This needs to be on the agenda for the implementation manager.

    ================

    [currently] All the resellers must send their information to Domainz in a format of Domainz's choosing[0]. There is no generic industry-agreed-upon interface.

    =================

    BTW Domainz has confirmed in writing to at least one major customer that it will retain the existing automated interface for a considerable period come what may. This is _not_ the issue I seek clarified.

    ===============

    The Implementation Manager

    The comment I'd like to make is this: the Implementation Manager should be hired in time to make a substantive input into the White Paper; or, to be ready to drive the process once the feedback has come in.. Seems to me that the IM could be doing the stuff Sue is being asked to do, while Sue could focus on the myriad other lobbying tasks that lie ahead and the strategic planning etc.

    =========

    We can get the implementation manager to either execute a plan that council has devised or we can identify a small number of possible options e.g.

    1) build our own registry using employees of ISOCNZ (or some wholly owned entity) 2) outsource it to a local contractor who builds it for us (sounds familiar)

    3) outsource it someone who is already doing this

    and get clearly identified set of costs and timelines, make a decision and get on with it.

    There may be other options.

    Preventing Registrar Capture

    Ahem, the overwhelming fear of many re the introduction of an SRS was/is registrar abuse of power. Mechanisms which are designed to try to prevent or at least to punish such abuses are critical IMO. see the SRS WG report.

    ===

    To the extent that charging policies could be used by registrars to "capture" registrants, we need to be concerned about this up front.

    =========

    Agreed. Mine to, from reports of practices in the US. Does this need special attention in the Green paper?

    ==============

    I think you are also assuming something that will not be true. If say ICONZ wishes to become a Registrar that does not mean every single customer of DOMAINZ who is hosted by ICONZ will be automatically transferred to ICONZ the Registrar. Each name holder is supreme as to who is their Registrar and ICONZ will have to ask/persuade/bribe them to transfer and inertia is bound to mean a few will not.

    ==============

    Obviously it depends on what is meant by competitive. That is why the Commerce Commission is vaguely interested. If, despite the best efforts of all of us, there occurred:

    - a barrier to entry of other registrars

    - the creation of a(nother) monopolist registrar

    - material disincentives/difficulties in a nameholders right to transfer their name

    - a reduction in the ability of registrars to offer enhanced services by virtue of the structure adopted

    Then that would impact significantly on people who have yet to acquire domain names. Golly, they might even decide to forsake .nz altogether and register in another space.

    ==============

    Consider too the overseas holders of .nz names, who don't use NZ ISPs at all. There is still a market for registrars not affiliated with ISPs to service nameholders like these.

    ==============

    Whatever we do there will be people accusing ISOCNZ of looking after its own interests ahead of other registrars - particularly from registrars who are trying to embarrass ISOCNZ into doing something different. I don't see why ISOCNZ should bend over backwards to make life easier for new registrars to its own detriment.

    ==============

    What type of Registrar?

    Inhat type of Registrar?

    In which case, why sell it? Would ISOCNZ members have some tolerance for the concept of passing accrued profits to a newly established "Internet Foundation" type body who could use the dosh to support worthwhile Internet causes?

    Alternatively, could Domainz be run as a "public good" registrar, to essentially break even, and force other registrars to offer good value for money to compete - or would this be seen as anti-competitive?

    ===============

    This member has zero tolerance for such a distribution.

    ====

    It is a fact the the encumbent monopoly registrar will have a head start with its cash assets and registrant contracts. To then operate it on a cost recovery basis after so many years of running as a profit centre would be seen as hostile by competing registrars entering the market.

    ===============

    There is NO mandate for DomaiNZ to transfer profits to any other schemes, no matter how worthy. Aside from being a "Good Corporate Citizen" (whatever that means, but which can include modest charity or community involvement donations), any huge grants to foundations as suggested should more properly be done by the owner from the dividend or distribution, which surely would attract the appropriate debate.

    ===============

    Even I can see the "apparent and actual conflicts of interest" that arise from ABSOLUTELY ANY involvement in the competitive registry. We HAVE to divest DomaiNZ as soon as possible after the SRS is stable. There is no credible alternative.

    ===============

    I think that would be seen as anti-competitive. I wouldn't be happy with that option

    White Paper Issues - Council Comments

    There are issues though, that may take the White Paper to clarify. If we do a split of domainz, are they responsible for both bits -only one? which one? how do they relate to/with the CEO?..... And, should they be involved in drafting the WP, or "merely" implementing it?// (?????? Implementation Manager?????)

    ======

    I am assuming the Green paper will list known expressions of view as to our options, in summary form. Comment hopefully will be rather more editiorial than about principles. Its the White Paper -wher choices are made, and consequences, where more comment will occur.

    Subject: Re: [isocnz-members] Matters Arising - Nov Council

    To: isocnz-members@isocnz.org.nz

    Date sent: Tue, 05 Dec 2000 21:47:55 +1300

    From: Ewen McNeill <ewen@naos.co.nz>

    Send reply to: isocnz-members@isocnz.org.nz

    This happens to be a somewhat convenient post in the fairly lengthy thread today.

    Disclaimer: IANAL. This advice comes with absolutely no warrenty or guarentee. If you break it, you own both parts. Some user assembly may be required. Do not fold or spindle. Keep away from children. Do not expose to naked flame.

    In message <001501c05e44$14001270$c870030a@local.net.nz>, "Robert Gray" writes:

    >Good logic. So let's say that isocnz agree, should the directors be told to

    >a) maximise the potential return (by for example investing in the registrar

    >business)trar

    >business) or b) ignore the sale issue and concentrate on facilitating the

    >switch to the SRS or c) something else?

    GIVEN:

    1. Domainz currently makes (all of) its revenue from providing name registration services to its customers (ie, as a registrar). (The registry portion of Domainz is a cost.[0])

    2. Domainz is currently the monopoly registrar and does not face (strong) competitive pressures because of this.

    3. The monopoly is going to be broken (soon), and a competitive environment (the SRS) introduced.

    4. Domainz's shareholder has decided that Domainz will continue to be a registrar until further notice.[1]

    5. The registry portion of Domainz will be removed from Domainz.[2]

    6. Another registry will be set up.[3]

    7. In order to remain a registrar Domainz will need to interface with this new registry.[4]

    WE CAN CONCLUDE:

    1. Domainz's value as an going concern comes from Domain name registration (the registrar functionality) (G1 and G2).

    2. The introduction of competition in this arena poses a risk to the profitability of Domainz, becausainz, because some of Domainz's customers may choose to change to one of its new competitors, and competitive pressures may force prices down. (G3)

    3. In view that the shareholder wishes Domainz to continue as a

    registrar (G4), Domainz should take steps to mitigate the risk to its profitability.[5]

    4. Domainz should take steps to prepare to interface to the new registry system. (G6 and G7)

    5. Domainz should improve its customer service, and customer visible interfaces with a view to retaining as many of its customers after the introduction of a competitive environment. (C3)

    6. The more lead that Domainz has on its competitors in providing "top notch" service that its customers wish to use, even when offered a choice, the more likely it is to retain most of its customers, and hence most of its profitability. (C5)

    7. Domainz should start improving its customer service, and customer interfaces immediately with a view to changing public opinion immediately. (C6)

    8. Domainz should concentrate on customer visible interfaces over "internal" interfaces, except where those internal interfaces impact on its customers directly. In particular it should not spend money on improving the registry portion of its software except where required for more flexiblity/reliabilty to meet other business objectives such as better customer visible interfaces, or in preperation for interfacing to the new regnew registry system. (G5, G6, C1, C6)

    9. One of the major risks to Domainz's goodwill, and its ability to retain customers is the smoothness of the transisition to a competitive environment. Ideally from Domainzs point of view for customers it should be as if nothing has changed, and they can confortably remain Domainz customers secure in the knowledge they are getting the best service possible. (C1, C2)

    10. Domainz should take active steps, probably even including the offer of financial support, to ensure that the competitive environment mandated by its shareholder is introduced in a way that does not unnecessarily harm its existing business.[6] (C9)

    11. As a matter of urgency Domainz should consult with as many of its customers as practical to ascertain what they want from a registrar. This should include both "bulk" customers ("agents" or whatever you want to call them), and also individual customers to the extent practical. (C7)

    12. Domainz should investigate ways that it can "add value" to its business, to mitigate the risk of competitive pressures forcing the prices down. (C2)

    FAQ

    Q: What about all these putive other registrars? Shouldn't Domainz play nicely with them?

    A: No. Domainz should compete with them. It should not engage in anti-competive behaviour (if nothing else that would open it up to a legal risk), but it has no mandate from its shareholder to "let them inthem in" or "share customers", hence it should aim to retain all of its customers through strong competition.

    Besides which the putive other registrars can easily decide for themselves whether they can do a better job than Domainz and hence attract customers. They do not need Domainz to "let them in".

    And finally there has been no indication from the shareholder that Domainz should refrain from being profitable, or "play nicely" (apart from not actively preventing the transition to the SRS).

    Q: What about if Domainz were to be sold?

    A: Irrelevant. Domainz's value is its assets-in-hand plus its potential to generate income. Providing it is a profitable business it will not be sold for less than its assets-in-hand. If Domainz has not taken active steps to adapt to the competitive environment then its ability to generate income will be reduced, and hence its value will be reduced. If many of Domainz's customers actively wish to change to another supplier, then its goodwill is reduced. From this it follows that spending capital to make the business better liked by its customers (adding good will), and more suitable for the likely future environment (ie, competipetition) is the best way to protect the value of Domainz to its shareholders.

    Thus either way you look at it, adapting to the forseeable future environement is the option Domainz should be taking.

    Besides which no one has actually said Domainz will be sold, only that in the future it may be an option.

    Q: What if Domainz were be closed down? Shouldn't it conserve its funds so that it can be shut down with money left?

    A: No. If Domainz were to be closed down at any given point it would have to spent considerable amounts of money ensuring continuity of service for its current customers (or declare bankruptcy, which I hope no one is seriously considering), which would eat into a large chunk of its value. Furthermore it would not have any ongoing business, so there would be no goodwill, and no revenue stream.

    Furthermore Domainz's shareholder has given no (serious) indicating that it will be closed down. Most talk has focused on the possibility of selling Domainz at some point. So considering Domainz being closed down in business planning is an irrelevancy.

    Finally avoiding doing things because the business might close down is almost certain to bring about that very thing (the business closing) since it will stagnate, lose customers (who fear it is preparing to close), etc.

    Q: Is there even a viable business in being a registrar?

    A: The registry is not going to deal wi deal with the public directly.[7] Ergo there will need to be at least one registrar. Domainz is the incumbent registrar, and as such in the best position to be the main registrar. It currently has a very profitable business doing so. With a reduced cost for the registry component (the cost is shared with other registrars) it should remain a profitable business.

    The only situation in which it would not be a profitable business would be at least one other registrar offered the service as a loss leader, sparking a price war. While not inconceivable, the appropriate plan of attack in this situation is to branch out into other related areas, not abandon the whole business because there is a risk. Business is _about_ risk. Starting with a large fortune it is difficult not to at least end up with a small fortune.

    Q: What if Domainz does such a good job that no one wants to change, won't this SRS and so on have been a waste of time?

    A: No. Currently many Domainz customers wish for an alternative. If providing the option for an alternative, which is not taken, results in those customers not wanting an alternative, then the desired result has been achieved.

    No one has suggested that we should have competition for competition's sake. Competition has been postulated as a way of producing better service from suppliers, so providing that is the outcome everyone should be happy, even if it does not take much competmpetition to bring it about.

    Now can we _PLEASE_ stop rehashing this problem over and over again. It's a non-problem. Whichever way you look at it Domainz should be taking steps to ensure that its customers want to be customers, and will remain with it after being offered a choice. Whichever way you look at it, Domainz should improve its customer service, and its customer interfaces, starting immediately.

    At some point Domainz might be sold, but it's more than likely to be sold as a viable business in which case the steps taken to adapt to the new environment, and cultivate happy customers can only add to the value of the business as a going concern.

    My comments above differ only in verbosity from comments I've been making _for_the_past_6_months_. Domainz has lost a full 6 months of lead on improving its good will, producing happy customers who tell their friends about how wonderful Domainz is. I fear at this rate Domainz may squander all of its lead while it is parallized in indecision about what it should be doing.

    FWIW, I believe that conclusion 10 at least partly answers the "how should the implementation be paid for". IMHO it is in Domainz's intereserest (as a business) that the implementation of the SRS be done properly, and it would be a wise investment to spend some money on ensuring that happens.

    >Note that in the absence of instructions to the contrary I would think the

    >directors may well be obligated to do a) by the companies constitution.

    Indeed. And since following that through to the conclusion leads exactly to the desirable aims (Domainz treats its customers better, and more customers want to stay, and Domainz provides a seamless transition to the SRS for its customers), there is no problem.

    Ewen

    [0] Reasoning: If Domainz did not have to run the registry portion, nor pay anyone else to do so, and could still have the same number of customers paying the same amount, it would make a bigger profit.

    [1] Reasoning: The ISOCNZ AGM resolved that Domainz would remain a registrar through the introductin of the SRS, and did not set any point at which it would not be a registrar, would be closed, or whatever.

    [2] Reasoning: ISOCNZ AGM resolution to that effect.

    [3] Reasoning: Follows from G5

    [4] Reasoning: A registrar which cannot put entries into the registry is not likely to be very popular, thus if Domainz could not it would loose customers, and hence be less profitss profitable, and hence its value to the shareholder would drop.

    [5] Reasoning: Domainz is set up to run at a profit. If it is not profitable, then it cannot continue to run indefinitely. If it is not profitable, its value will be reduced, reducing the its value to the shareholder (on, eg, sale).

    [6] Reasoning: Domainz should be involved from its business point of view, because this is _the_ major risk to its profitability. That's not to say that ISOCNZ should allow Domainz to dictate everything, but it should be involved.

    [7] Reasoning: Follows from ISOCNZ resolutions, and the SRS WG final report (which is still not accepted, but seems likely to be accepted unchanged given that the councillors who were reported to have expressed concerns have not voiced those concerns when offered the opportunity to do so).

    _ _ _ _ _ _ _ _ 

    go to http://listserver.actrix.co.nz/mailman/listinfo/isocnz-members

    for subscription and unsubscription information.

    _ _ _ _ _ _ _ _ 

    Top

    ©2001 The Internet Society of New Zealand
    Last updated 2 February 2001

    Document Actions