SRS Progress Report to the IOC 21/11/01
Business Rules and Processes
Following our visits to .nz providers during October and the presentation to the last Council meeting, the SRS Implementation Team went to the main centres to present the Business Framework and Rules for the SRS to .nz providers.
All accredited .nz providers were invited to the presentations as were all other .nz providers managing more than 50 domain names. Invitations were sent to 154 providers, and representatives of 33 attended the sessions.
A presentation for members was held in Wellington.
There continued to be useful suggestions made during the sessions with providers and members and these refinements have been incorporated as appropriate. I attach a list of the key suggestions made.
The final version of the Framework and Business Rules has been prepared for Council approval.
SRS Register Development
The RFI process is now complete and four respondents have been selected to proceed to the next stage. All those who responded to the RFI will be notified of the outcome of the evaluation process on 22 November, with the RFP scheduled to be issued by the close of business on 23 November.
All participants in the RFP will be invited to a presentation on the SRS, where there will be the opportunity for respondents to clarify issues.
It is possible that some of the organisations (or associated entities) shortlisted for the RFP could become registrars in the future, raising issues about conflicts of interest. Another area of potential conflict is where one of the RFP respondents employs a Council member/officer.
Careful management will be required to ensure that no conflict occurs and that the successful respondent does not receive any significant advantage as a registrar through their involvement in the development. It is worth noting the following project controls that will be in place:
- the development will be project managed by the Technical Project Manager and not the RFP respondent;
- the development process will be staged so that if issues arise at any stage, the contract can be terminated;
- the development will be subject to a formal external QA process and this will include ensuring the software developed doesn't favour the developer in any way;
- a strict confidentiality agreement will be enforced with the developer.
On balance after discussion with the IOC Chair, it was decided to proceed with the four shortlisted respondents recognising that while the potential for conflict could be perceived, it is not in the project's best interests to exclude the best RFP proposals because of a conflict that is perceived rather than real.
.nz Board
The paper outlining the role and responsibilities for the .nz Board has been through several iterations with a more corporate model recommended for implementation. The membership of this Board, the skills of its chair, and the way it operates will be critical to successfully establishing the governance arrangements for .nz.
Domain Name Migration from .nz Providers to Registrars
This issue is going to require careful analysis and some robust legal advice before any business rules on the allocation of domain names to registrars can be communicated. The rules for the allocation of domain names to providers during the transition to the DRS were not documented although we have access to the general principles used.
No progress has been made on this issue over the last month as there was a misunderstanding within Domainz as to the scope of the data required to start the analysis for this project. This has now been clarified and I hope to start this work in December.
Transition Issues
I have prepared a paper for Council outlining some general principles upon which to proceed with the transition. If these are agreed, then detailed planning and consultation with Domainz staff can commence.
Rose Percival
SRS Implementation Manager
Appendix I
Issues raised at presentations to .nz providers and members
The following is a list of the key issues raised by at the SRS presentations held during November.
| Issue Raised | Action Required |
|
There is an increased risk of cyber-squatting with a low domain name registration fee (and combined with the monthly registration period) |
Yes but the policies/contracts will be more explicit that this is not acceptable. |
|
Provide guidelines for registrars around authenticating registrants when a registrant requests that the domain name is transferred to a new registrant, when a registrant requests that a domain name registration is cancelled and when a registrant requests the unique domain authentication ID from their registrar |
Agreed. These will be drafted and sent out for comment. |
|
Why doesn't government fund the internet developments in NZ |
Not the appropriate forum for this issue. |
|
When a domain name is transferred between registrars, the register should automatically reset the billing term to [1]. |
Agreed. |
|
Want to be able to query the "whois" during the zone push. Not possible in the current set-up |
Will incorporate this if possible. |
|
The whois query used by the public - the domain name that is being searched should print out with the information available through the whois. This does not happen on the current system. |
To be incorporated as a requirement. |
| Define in detail the documentation that registrars should retain. |
Will provide guidelines on this. |
|
The field containing the optional registrant customer ID needs to clear when a domain name is transferred between registrars. |
Agreed |
|
Should there be a standard timeframe set around the response to a request by a registrant for the UDAI for their domain name |
No as registrars will have different terms of business - needs to be a reasonable timeframe given the registrar's terms of business. |
|
At what stage will an organisation be able to state that they are an authorised registrar When they have signed the authorisation agreement or when they have an operational interface with the register |
The latter. Will refine the contract wording to ensure this is clear. |
| Issue Raised | Action Required |
|
Rather than having a registrar maintain a public record of domain names registered to them and subsidiaries, propose that they maintain a list that is notified to the ccTLD manager (or as requested). The ccTLD manager would need to keep this information confidential as it may contain future business strategies. |
Agreed. The contracts etc will be amended. |
|
Will need to monitor use of the cancellations during the initial 5 day grace period to ensure that this is not used to park names for free on a rolling basis. This functionality is being abused in other registries. |
Agreed. At the members presentation, we identified a solution of charging a registrar the standard one months fee for each cancellation during the registration grace period. This will ensure that this functionality is not used to park names. The instances of names being cancelled during the registration grace period due to errors in registration (an error in the domain name) should be low. |
|
That the losing registrar is notified of who the gaining registrar is in the transaction telling them that the domain name has been transferred. |
Agreed |
|
The current contracts with Domainz are focused on domain name registration and do not refer to publishing the domain name/address to the Internet. This should be included in the SRS. |
The requirements on the ccTLD manager are set out in RFC 1591 and the Best Practice Guidelines for ccTLD Managers. |
|
Concerned that by collecting registration fees for 10 years, could be exposing InternetNZ to fiscal risks and a risk that these services will be provided 10 years out. |
The fiscal risk can be managed through prudent financial management and an annual review of costs and revenue. The risk of a suit for services in the future will be covered in the contracts.
|
|
Be explicit in the contracts that referring to compliance with New Zealand law. |
Will check this in all the contracts. |
|
Ensure that the registrant responsibilities extend to anyone to whom they delegate their sub-domain. |
Will check this in the contracts. |
|
Standard registrar-registrant terms and conditions. Format these both as a standard contract and an appendix that can be attached to other contracts used by registrars. |
Agreed |
|
Checking for lame name servers - is this a role for the registry |
? |
