Report on .bank Application 24/04/01

Overall Process

As this was the first use of a 4-year-old policy the overall application went better than expected. My understanding is that it was never envisaged that the 2LD policy would take nearly 4 years to receive its first application.

The policy in my opinion is based on the concept that it would be difficult yet not impossible to add a new 2LD as well as it would not be a swift process. I believe that the policy as written adheres to these concepts. People may disagree with these concepts but it was created based on input received at the time.

The principal issue I had with the policy is that some key aspects were only briefly mentioned or omitted entirely. This lead to having to "fill in the blanks" in a manner that was consistent with the remaining policy to ensure fairness to the applicant and the greater community the policy is aimed at. (Please refer to the paper provided to the February council meeting on voting).

Execution of Policy

Based on the duties required for this application I am of the belief that the majority of the work is not governance or policy related but that of operations. Aspects of governance and policy naturally exist and the impact of applications are significant on the .nz name space, however, the handling of an application under this policy is primarily an operational issue and the policy and governance aspect is secondary.

Due to the nature of a volunteer Working Group the Applicant and the voting process could have been better served by the ISOCNZ office taking care of the administrative aspects and the Working Group to assist as requested based on questions resulting from policy or the application. Perhaps the WG being responsible for ensuring the RFV was run etc. but the office doing the actual event.

Communication with Applicant

Several formal meetings were held with the applicant as well as some written communication. It is my belief that each applicant would have different expectations and requirements for communication between the applicant and the WG/Society. The method of the communication between the society and the applicant, letter, fax, email, etc would, within reason, should be at the request of the applicant, i.e., one applicant may find email acceptable where as another may require written notification. The preferred type of communication should be determined as soon after receipt of the application as possible. At a minimum any future applicants should receive the following:

• ISOCNZ Receipt of the application.
• Offer of meeting between the society and the applicant, if the applicant desires.
• Entire timeline for application for each stage of the process (including the submission process with the qualification that this is only valid should it pass the RFV).
• Operational details of the RFV, i.e., dates, voting details, scrutineer request, and statement that ISOCNZ will do &8216;best effort&8217; on promoting this RFV but applicant is responsible to &8216;get out the vote&8217;.
• Notification to the applicant at the same time as council, but before any media or members are informed of the results of the vote.

Voting

The administrative aspects of the vote unfortunately hit at a time all the officers of the society as well as the Executive Director were preparing to leave for an ICANN meeting as well as significant turmoil occurring in my professional and private life. This lead to a less than acceptable approach on my part in the set up of all the information needed for people to understand the voting process as well as delay in making some of the society announcements of the RFV. Please note that the detailed press release went out on time and over 12 articles were written on the RFV.

Future RFV&8217;s should take less effort to initiate as most questions have already been addressed and will only require recreating the &8216;help files&8217; for the voting process. I took each stage in isolation and I did not really think about the next stage until the previous one was near completion, this lead to a reactive approach to the voting process rather than a proactive approach. In future I would recommend that the entire timeline would set in advance to allow the most possible time for the planning of each phase of the policy.

The two channels for the RFV had different issues associated with them.

Web - election.com

The use of election.com for web based voting did allow us to proceed in a timely manner for this RFV. However, the software was designed more for a known voting pool rather than an public/open voting electorate. Overall I found the staff at election.com in NZ to be excellent and would call me after hours and on weekends to advise me on updates on the voting site (both while in testing and production). The web site did have some technical troubles in the first few days with some people being unable to vote or the voting process producing error messages. These were fixed in the first 72 hours.

One aspect that due to late request from me could not be supported was email confirmation of the actual vote being recorded. In hindsight it would have provided comfort to the vote that their vote was recorded (subject to it being ruled valid etc).

Email

The email voting was trivial to set-up but also provided much greater effort to review as a large number of the votes did not conform to the ballot requirements. In the first 72 hours I would estimate that over 80% of the votes were obviously invalid as the address of the vote was released by the applicant without any detail on the requirements of votes to be ruled valid. In future the email address should not be released unless full details of the requirements are included with it (an example of the message used on USEnet where a sample ballot was provided as well as full details.

Results

The appointment of 2 scrutineers, one from the applicant and one appointed by council, as well as the Voting Officer provided independence and the ability to review the results in a fair manner. The one change I would suggest is that the scrutineers and the Voting Official arrange to meet soon after the voting ends to determined the final results. Face to face (or at least a real time mode of communication like IRC) would be better go over any disputed votes rather the delays that were encountered using email.

Invalid results

A significant number of votes were deemed invalid. The reasons fall under 3 broad reasons:

• Incomplete ballot
• Duplicate voting
• Other reasons

Incomplete ballots varied from email votes that only had "yes" as the message to voters putting N/A under their address details to nonsense data being inputted. These could be reduced in future by ensuring that people voting by email understand the information they need to provide and for those using the web site that the reasons for the field being completed with valid data are understood.

Duplicate voting occurred where people with the same name used multiple email addresses to vote (election.com would only allow one vote per .nz email address). These people knowingly used multiple email addresses to record votes and thus were ruled invalid.

Other reasons include votes being sent before the voting period opened or after it closed or other misc. reasons that the vote did not comply with the policy and voting procedure.

Further Recommendation

My recommendation is to merge the Discussion period with the voting period to allow people to discuss the merits of the application and then vote on it. This would merge the separate RFD and RFV phases into one phase to allow people to review the application, follow or participate in a discussion and vote when they wish while they are still "interested" in the application rather than wait further time before they can lodge their vote.