Personal tools
You are here: Home Proceedings Committee Proceedings .nz Oversight Committee Archive 2001 The SRS - Draft Operational/Business Rules Version 1.3 14/08/01

The SRS - Draft Operational/Business Rules Version 1.3 14/08/01

This paper has been prepared by the SRS Implementation Manager to provide a draft of the operational/business rules for the SRS in .nz. It is not intended to be a re-statement of the policies for registering domain names in .nz. These policies will remain in place except where there is a clear conflict with the SRS model. A separate review of the policies will be undertaken later and amendments proposed to bring them into line with the new accountability arrangements. Where there is a conflict between current policy and a statement in this paper, the statement in this paper should be taken as an indication of future policy.

The status of this paper is that of a discussion draft and your feedback is sought on its contents. A summary of specific areas where feedback is sought is outlined directly below. The feedback will be reviewed and summarised. Decisions on the SRS implementation are made by the InternetNZ Council.

Your comments should be sent to srs-implementation@isocnz.org.nz by 14 September.

Areas for Feedback

Your feedback is sought both on the contents of this draft and whether there are significant gaps and omissions. Square brackets, [ ], have also been used to elicit comment on specific issues.

There are a number of specific issues where feedback is sought. These are outlined below.

Registrars

The Hine Report stated that the barrier to entry for registrars must be low and that registrant's rights must be safeguarded. These two requirements need to be in balance - the lower the barrier to entry, the tighter the protection required for registrant's rights.

  • Should registrars be required to be an incorporated entity [e.g. company?]
  • What is a reasonable level for the general liability insurance cover required to be held by registrars [NZ$250,000?]
  • What is a reasonable period of notice to cease being a registrar? [2 months?]
  • The non-transferability of the registrar's authorisation status to a third party
  • The grounds under which a registrar's authorisation can be cancelled (see para 24)

Registrant Changing Registrars

The Hine Report stated that a registrant should be able to change registrar at any time. This should not impact their use of the name in question. An authentication field will enable a registrant to transfer a name to a new registrar without reference to the current registrar

  • The draft business rules have been drafted without provision for a block by the "losing" registrar. Are there any circumstances that would justify enabling a losing registrar to activate a time-limited block on the transfer?
  • Are there any other issues that should be considered for transfers between registrars? 

 

Registrar Cancellation

Where a registrar's authorisation is cancelled, it is proposed there will be an automated process from the registry asking the registrant to choose a new registrar.

  • What should be the process when registrant(s) do not respond to this request to select a new registrar? Allocation of the registrants across all other authorised registrars?

 

Registry Charges

The Hine report stated that the registry should charge the registrars to recover both its costs and the costs of the ccTLD manager, and that the separate costs of these two operations should be clearly transparent.

The proposed principles of the charging regime are:

  • All registrars are charged on the same basis regardless of the number of registrations for which they are the designated registrar
  • Registrants can, at their discretion, elect to purchase multiple time periods for their domain name registration(s)
  • Where a registrant elects to purchase in multiple time periods, the designated registrar is obliged to make this entry/transaction in the register
  • If the charges to registrars are based on a monthly registrar connection fee [between $100-500], and a monthly fee for each domain name on the register for which they are the designated registrar, how long should registrars be required to carry a domain name for a registrant who has missed payments before canceling the domain name registration?
  • Does the principle of being able to purchase multiple time periods for registrations (for example, for 6 months if the standard time period is one month) unnecessarily complicate the registry operations, and/or does it provide opportunities for points of differentiation between different registrars? What protections can be put in place for registrants if the only time period for billing is one month?

1. Authorised Registrar Requirements

 1. Anyone accessing the .nz registry will have to be an authorised registrar. This will involve:

  • a contractual relationship with the Office of the ccTLD manager/InternetNZ
  • signing the connection agreement with the registry
  • meeting the minimum technical requirements for interfacing with the register
  • meeting the financial requirements of doing business with the registry
  • operating in accordance with the .nz policies and a Code of Practice.

2. Being an authorised registrar gives an entity a non-exclusive, non-transferable right to access the register, subject to meeting the minimum technical and financial requirements of the registry.

3. There will be no limit on the number of registrars authorised to operate in the .nz domain name space.

 

1.1 Contractual Requirements

4. This will be the first formal step in the process of becoming an authorised registrar. The intending registrar will need to:

  • pay a one-off, non-refundable application fee to the ccTLD manager (the fee will be set at a level to reflect the costs of reviewing the application and the registrar-registrant agreement) [no greater than NZ$5,000]
  • sign the registrar authorisation agreement with the ccTLD manager.
  • sign the connection agreement with the registry
  • submit their registrar-registrant agreement for approval.

5. Registrars will have to comply with the following criteria (at the time of authorisation and while they are registrars):

  • Be an incorporated entity [?]
  • Be solvent (a letter from their bank recommending the registrar as an entity that can pay its day to day bills)
  • No conviction for dishonesty/fraud/misuse of funds/misuse of information/breach of the Privacy Act in the last [10] years or awaiting trial for such/under active investigation for such

6. The contents of the registrar authorisation agreement and the registry connection agreement will be the subject of a separate consultation.

 

1.2 Technical Requirements

7. Registrars will be required to meet and maintain minimum specified standards set by the registry from time to time. These will be contained in a document (series of documents) [The Technical Requirements]. Minimum specified standards will include the following:

  • Given the policy of "first to register", the registrar needs to enter the data into the registry as soon as the registrant has given them the information.
  • Robust and scalable operations capable of handling the registration volumes projected by the registrar (Note - there will be no minimum threshold for registration volumes)
  • Achieve a reliable and readily usable daily data backup and archival of all registration data
  • Provision of a "whois" or similar service from their system
  • Security standards (see below).

8. The registry-registrar committee will provide a formal forum for discussing changes to The Technical Requirements, except in those instances where the urgency of a security breach requires immediate action.

9. The registry will provide a test facility to enable registrars to test their system against. All registrars will be required to pass a formal acceptance test before they are given access to the production database(s). Once passed, the registry will issue the registrar's user ID and passwords and digital certificates.

10. Registrars will also be required to implement security features established by the registry. This is to ensure that there is security both of their own databases that interface with the register, and of their interface with the register. The security standards will be of a substantial level and conforming with industry best practice.

11. The registry will have the authority to check that registrars are maintaining the minimum standards and upgrading these as required from time to time (for example - that the name servers are authoritative). Registrars will be required to provide the information requested by the registry in a timely manner ([7] days).

 

1.3 Financial Requirements

12. The registry will establish, in consultation with each registrar, their credit limit for use of the register. The registry may require a deposit of funds up to and not exceeding the credit limit, or letter of credit for such. All payments by registrars for use of the register will be made by direct debit no later than the 20th of the month following the invoice date. A registrar has to maintain a New Zealand bank account with sufficient funds for this purpose.

13. The registrar will be required to hold general liability insurance to the value of [$250,000].

 

1.4 .nz Code of Practice

14. There will be a general statement of rights, obligations and ethics for all those operating in the .nz domain name space. This will contain the standard statements of good faith, honesty, probity and integrity of conduct.

For example, registrars, registrants, the registry and the ccTLD manager are required to act in good faith at all times in their dealings with each other.

 

1.5 Registrar Status Categories

15. There will be four categories :

  • Authorised inactive (met ccTLD manager requirements but has not passed the registry's formal acceptance test/agreed the credit limit).
  • Authorised active (able to interface with the register)
  • Suspended (only a practical, viable option if a total suspension for very short periods as it effectively undermines registrant's rights. Could operate as a partial suspension - of not being able to do new registrations or fee-based transactions)
  • Cancelled (could be voluntary cancellation by the registrar or involuntary cancellation by the ccTLD manager)

16. Registrars will not be able to assign, delegate, sell, alienate, transfer or dispose of their registrar authorisation unless they meet the following requirements:

  • Approval by the ccTLD manager, including signing a registrar authorisation agreement (application fee applies), and the registry connection agreement. Includes submission of the registrant notification plan.
  • If a new technical interface, this will require formal acceptance testing by the registry
  • Agreement on the credit limit with the registry.

The registry will transfer all domain names to the new registrar on completion of the approval process.

17. In the case of a sale etc, the authorised registrar will be responsible for maintaining all register-related services for registrants for which they are the designated registrar until such time as the approvals/technical interfaces etc are in place for the new registrar (i.e. registrants rights etc should not be placed at risk by a sale/transfer etc by the registrar)

18. To cease being a registrar, [2] months notice in writing to the ccTLD manager is required, along with a draft registrant transition plan (which requires the ccTLD manager's approval).

2. ccTLD Manager

 

2.1 Functions

19. The ccTLD manager has eight key functions:

  • Maintaining the policy for .nz domain name management. This includes recommending changes to existing policies/new policies and setting the pricing policy for domain names on the .nz register.
  • Contracting for registry services.
  • Establishing and maintaining contracts with registrars
  • Running the process for the creation of new second level domain names and appointing moderators for moderated second level domains
  • Facilitating effective decision-making/information flows amongst key stakeholders through running/servicing the Registry-Registrar Standing Committee
  • Monitoring of and influencing international developments in relation to the management of the DNS, in so far as they may impact on the .nz domain name space.
  • Ensuring the .nz name space is future proofed (technical rather than business-oriented)
  • Facilitating the disputes resolution procedures (role to be determined)

2.2 Registrar Interface

20. The ccTLD manager has the right, from time to time, to amend the terms and conditions of the registrar authorisation contract, the code of practice and the technical requirements for interfacing with the register. These changes will be effective [30] days after ccTLD manager gives notice to registrars, with the exception of technical changes as noted below. Please note that these are the sort of issues that would be discussed in the registry-registrar standing committee first; and that there would be a longer timeframe for compliance where it was a technical upgrade unless it is an urgent matter concerning security.

21. For technical upgrades, the registry will be required to maintain more than one version of the software - and there will be clear dates given for final compliance with what version.

2.3 Suspension of Registrar Authorisation

22. Total suspension is only a viable option for very short periods as it effectively undermines a registrant's rights. The ccTLD manager may wish to suspend a registrar pending investigation of a serious breach of the ccTLD manager-registrar agreement, the Technical Procedures or the Code of Practice. In doing so, the ccTLD manager would need to be sure that the investigation could be completed to a satisfactory conclusion within a few days. It is likely that prior to this, the ccTLD manager would have had the registrar under "active watch" where the ccTLD manager has been proactive in monitoring the registrar's operations (including active encouragement to the registrar to correct operating defects (the latter may include technical assistance from registry on a fee for service basis))

The suspension could be a partial one (for example, not enable a registrar to make new registrations and/or renewals).

23. In the case of a serious security breach, a registrar may be suspended immediately but not before there has been an attempt to speak to the registrar or their representative.

2.4 Cancellation of Registrar Authorisation

24. Only the ccTLD Standing Committee (on the recommendation of the Office of the ccTLD manager) can cancel/de-authorise a registrar. Reasons for a cancellation include:

  • Failure to meet their obligations and duties under the authorisation agreement
  • Provision of false or misleading information in the application for authorisation
  • Failure to remedy breaches of the ccTLD manager-registrar agreement within [5] business days after receipt of notification from the ccTLD manager
  • Failure to transact with the register in real time
  • Accumulating/warehousing domain name registrations or assisting someone else to do this through acting as their registrar
  • Registering domain names in their own name rather than the registrants (would need to be a pattern here rather than a one-off instance)
  • Technical incompetence (security breaches, unauthorised access, disruption to the register)
  • Failure to pay registry fees (debt to the registry is recoverable by civil action but ongoing financial incompetence should also be a ground for cancellation. The situation may not have reached the insolvency stage.) [? whether this should be a remedy only for the registry]
  • Insolvency, bankruptcy, liquidation or receivership, a receiver or statutory manager is appointed (registrar required to notify the ccTLD manager)
  • Conviction of an offence involving dishonesty/fraud/misuse of funds/misuse of information/breach of the Privacy Act by the registrar or director, partner (business), officer or controlling shareholder of the registrar [views please]
  • Death or incapacity where the registrar is a natural person (executor, legal representative required to notify the ccTLD manager) [assumes that the registrar does not have to be an incorporated entity]
  • Failure to comply with the Dispute Resolution Procedures
  • By their actions or conduct, bringing .nz ccTLD into disrepute or acting in a way that may be detrimental to the proper conduct of the .nz ccTLD [note that the Canadian requirements are explicit and include not defaming or contributing to the defamation of anyone, unlawful discrimination, violating or contributing to the violation of intellectual property rights or other rights of any other person, engaging in direct or indirect activity that is designed to bring or may have the effect of bring the registry into disrepute or which interferes with the registry's operations]

25. The ccTLD manager can cancel the agreement at any time. Depending on the reason for the cancellation, the ccTLD manager may give written notice of the breach and require that the breach is corrected within [x] days of the date of notification. In the case of a serious security breach, a registrar may be suspended immediately but not before there has been an attempt to speak to the registrar or their representative.

26. Where the cancellation is for breach of the obligations under the registrar authorisation agreement, the notice period is at the discretion of the ccTLD manager acting for the ccTLD Standing Committee. For all other reasons, the notice period is a minimum of [one] month.

27. On cancellation, the ccTLD manager notifies the registry and the registry disables the access authorities for the registrar. The ccTLD manager also authorises the registry to contact the registrants of that registrar and take other actions, in line with the pre-approved and tested plan for registrant transfers in the event of registrar default.

2.5 Moderated Domains

28. The operating principles are:

  • That approval for use of the moderated name occurs prior to the registrar registering the domain name in the register.
  • The registry will not be involved in the approval process
  • Moderators will either need to establish themselves as a registrar or set up a relationship with a registrar(s).
  • Moderators will be responsible for notifying the Office of the ccTLD Manager and the registry of their accredited registrar(s).

2.6 Limitation of Liability

29. The ccTLD manager is not responsible for the use or right to use a domain name registered in the register, nor any conflict or dispute in relation to the use of that name etc (except as set out in the [Dispute Resolution Procedure])

30. There is no liability by the ccTLD manager for any damages (exemplary, indirect etc) or for economic loss arising from loss of access and/or use of the register, lost business revenue, lost profit or third party damages arising from a registry/ccTLD manager event, arising out of:

  • an access delay or access interruption
  • data non-delivery, data misdelivery (in both directions)
  • any unauthorised use or misuse of any registrar access information/authority
  • any error, omission or misstatement by the registry
  • deletion or failure to restore access to the register
  • computer bug, virus or other system malfunction
  • failure or refusal to register a domain name or undertake any other transaction in relation to the information held against a domain name
  • any breach by the registrant or a registrar of their rights and obligations under the various agreements
  • any action or omission by a registrar or registrant in relation to their domain name registration
  • application of the dispute resolution procedure or compliance with a court order in relation to a domain name registration
  • the use of any domain name in the registry and any conflict or dispute arising in respect of that registration

This will be expressed in the authorisation agreement as a general disclaimer of liability.

3. The Registry

31. The key operating principles are that

  • All registration/amendment/transfer etc functions between the register and registrars will be through an automated interface.
  • All authorised registrars will be treated equally by the registry

3.1 Performance

32. The register will be a 24 x 7 x 365 operation; with service availability of between 99.5 - 99.9%.

33. But there is no warranty or representation (stated or implied)

  • that the register will be available at all times and/or
  • with respect to functionality (e.g. may be able to register etc but not interrogate the billing data), and/or
  • freedom from bugs or viruses, and/or
  • compatibility or inter-operability of the register and associated systems with the registrars systems, and/or
  • other???

34. In addition, there will be target, processing time, performance standards set for specific transactions by the register. For example, to process a registration, amendment or deletion of a registration - [3] seconds.

3.2 Limitation of Liability

35. The registry is not responsible for the use or right to use a domain name registered in the register, nor any conflict or dispute in relation to the use of that name etc. Nor does registration imply or create a proprietary right in respect of that name. Nor does the entry of the name in the "whois" database be construed as implying ownership or evidence of ownership of that name.

36. No liability by the registry or ccTLD manager for any damages (exemplary, indirect etc) or for economic loss arising from loss of access and/or use of the register, lost business revenue, lost profit or third party damages arising from a registry/ccTLD manager event, arising out of

  • an access delay or access interruption
  • data non-delivery, data misdelivery (in both directions)
  • any unauthorised use or misuse of any registrar access information/authority
  • any error, omission or misstatement by the registry
  • deletion or failure to restore access to the register
  • computer bug, virus or other system malfunction
  • failure or refusal to register a domain name or undertake any other transaction in relation to the information held against a domain name
  • any breach by the registrant or a registrar of their rights and obligations under the various agreements
  • any action or omission by a registrar or registrant in relation to their domain name registration
  • application of the dispute resolution procedure or compliance with a court order in relation to a domain name registration
  • the use of any domain name in the registry and any conflict or dispute arising in respect of that registration

This will be expressed in the connection agreement as a general disclaimer of liability.

3.3 Credit Limits and Failure to Pay Registry Fees

37. The level of credit limit established by the registry for each registrar is a business matter for agreement between the registry and registrar. It is not an issue that the ccTLD manager should be involved in.

38. When a registrar reaches their credit limit, the system will block them from doing further fee-paying transactions until their account has credit available.

39. Where a registrar fails to pay the fees owing to the registry, the registry can:

  • charge them interest on the unpaid amount
  • stop accepting fee paying transactions from them
  • call up any letter of credit given by the registrar
  • apply any funds held by the registry to the outstanding amount
  • charge the registrar for any reasonable costs associated with collecting the outstanding money owed.

4. Registrants

 4.1 Rights are to be Protected

40. The SRS removes the direct access rights of registrants to the register, unless a registrant chooses to meet the requirements of becoming an authorised registrar. It is therefore paramount that the rights of registrants are protected and that the SRS environment fosters adequate competition to provide registrants with genuine choice.

41. Registrants will not be able to interface directly with the register to register a domain name or change information associated with their domain name unless a registrant is also an authorised registrar.

42. Registrants will be able to confirm the information held on the register associated with their domain name.

43. Registrants will be able to request their designated registrar to purchase a registration in respect of their registered domain name for multiple time periods.

44. Registrants will not receive any communication from the registry in respect of their domain name except where their designated registrar is terminated (i.e. loses their authorisation to be a registrar).

45. Registrants have the right to contact the Office of the ccTLD manager to lodge a complaint about their registrar [some of this may be covered in the DRP but we will need to develop guidelines around this].

4.2 Registrant's Obligations

46. Registrants will be required to sign a registrar-registrant agreement prior to a registrar registering a domain name on their behalf. This agreement will need to be broader than acceptance of terms and conditions posted on the registrar's website with implicit agreement through using the services of the registrar. Why? Because this will be where the registrant signs up to the policies of .nz and accepts certain contractual obligations.

47. Registration of a domain name does not create any proprietary right for the registrant. Registrants will be responsible for the use of the domain name for which they are the designated name holder. Any legal action arising from the registrant's use of that name will be their responsibility.

4.3 Registrant Changes Registrar

48. Registrants must be able to freely transfer between authorised registrars. A registrant should be able to approach a new registrar and with sufficient authentication (either an electronic key of some sort or clearly defined other criteria), enable a new registrar to become their designated registrar. The existing registrar should not be able to stop a registrant changing registrars. It will be important not to put registrars in the position of having to determine the level of authentication required by a registrant in the "pull registrant" situation.

49. If you are an acquiring registrar then prior to sending a transfer of registrar request to the registry, you have to obtain from the registrant the following:

  • the contents of the registrant authentication field; and
  • enter into a written agreement with the transferring registrant in a form which has been approved by the ccTLD manager (unless the standard contract is used).

50. At the time the registry processes the transfer request, a new registrant authentication code will be issued. When the new registrar receives confirmation of the transfer, they need to provide the registrant with advice of this containing the: domain name, name of the transferring registrant, name of acquiring registrar, [registration period] and the new registrant authentication code.

51. In summary:

  • Registrants rights are paramount and are to be safeguarded/protected
  • The registry staff will not be involved in the transfer process.
  • The process should be automated
  • The existing registrar cannot block the transfer.

4.4 Registrant Transfer Process on Registrar Cancellation

52. The key operating principles are:

  • Registrants rights are paramount and are to be safeguarded/protected
  • The registry staff will not be directly involved except where it is an involuntary cancellation.
  • Automated process

53. If a voluntary cancellation by a registrar ([2] months notice is required), it is the existing registrar's responsibility to ensure that all registrants transfer to a new authorised registrar. This needs to be with the registrant's consent (if registrant doesn't respond within [30] days, the registrar can transfer them to another registrar implied consent which will be included in the registrant contract).

54. If a sale, assignment, delegation, then the registrants are transferred to the new entity provided the ccTLD manager has consented to the new entity. (implied consent which will be included in the registrant contract).

55. If an involuntary cancellation, then the registry will contact each registrant (an automated process) informing them that their registrar is no longer authorised, with a list of alternative registrars to choose from. The registrant will be asked to select a new registrar within x days. If not, the working principle will be that the registry will allocate the registrants across all authorised active registrars in proportion to their total number of active domain names on the register they are designated registrar for.

5. Registry Charging Policy

 56. There are two aspects to this - charges for services provided by the registry, and charges for transactions on the register.

5.1 Registry Service Charges

57. The registry will provide registrars with the following type of support:

  • Self-help services (FAQs, useful static information)
  • Telephone support (billing issues and responding to simple technical questions)
  • Technical support - some of which will be chargeable.

58. The registry will have competent technical support available for registrars in both the test and production environments. Registrars will be provided with a facility to test their client system and there will be a designated amount of technical support granted to each registrar. However the registry will reserve the right to charge for support over and above this where a registrar is having difficulty with testing their interface. Similarly for the production environment.

5.2 Register Charges

59. Registrars will independently set their own fees for registering domain names in the register.

60. The proposed principles of the charging regime are:

  • All registrars are charged on the same basis regardless of the number of registrations for which they are the designated registrar
  • Registrants can, at their discretion, elect to purchase multiple time periods for their domain name registration(s)
  • Where a registrant elects to purchase in multiple time periods, the designated registrar is obliged to make this entry/transaction in the register

61. The issue of what the register fees fund is covered in a separate document, The SRS - The Business Model for Running the Register.

62. There are a number of options available (including a combination of these):

  • A monthly registrar connection fee
  • A monthly charge of a fee/domain name on the register for which they are the designated registrar ($[x]/ name/month).
  • An annual fee for each domain name on the register for which they are the designated registrar
  • A transaction fee for every addition/change to the data held in the register or associated databases

63. The monthly registrar connection fee recognises that there is a certain level of minimum support required for each registrar. To maintain a competitive registrar environment, this needs to be set at a level that does not deter smaller registrars from participating in the SRS. It is envisaged that this fee would be in the range of $[100 - 500].

64. A monthly charge of a fee/domain name on the register is administratively simple as it takes the emphasis away from individual domain names (which appears to be a major issue in the current DRS). The fee could be based on the monthly average of names on the register over the month.

65. The main benefit of the monthly arrangement is that this fits with the billing processes of most ISPs, although most do seem able to generate one-off charges as required. There is a risk to the registrant from the monthly arrangement that if there is a gap in their payments to the registrar (either through non-payment for whatever reason or a dispute) there appears to be less protection for the registrant as they could lose their access to the domain name. One solution proposed is that the register could auto-generate an email to the registrant directly if a domain name for which they are the registrant drops into the pool.

66. An annual charging regime could add more complexity if the idiosyncrasies of the current system are retained (which is not proposed). Registrants may feel that their "rights" to use a domain name are more protected under an annual billing system and psychologically, it may make it easier to move registrars.

67. The option to charge a transaction fee for every addition/change to the data held in the register or associated databases has the potential to skew registrar behaviour (by limiting the changes they make in the database to those which they consider to be absolutely essential) which would not be in the long term interests of .nz. It also ignores the fact that a name with no changes still has costs associated with it.

©2001 InternetNZ
Last updated 15 August 200

Document Actions