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