[wg-c] Application Requirements?

[Kendall Dawson <kendall@motif1.obs-us.com>]

A week or so ago Rick brought up the topic of application requirements for 
potential registries. He submitted a list of possible inclusions on such an 
application. The co-chair commented that it sounded like a good idea and 
encouraged WG-C members to work on one.

There were some suggestions by members of the group which I have tried to 
include in the original list (see below). Also, Roeland sent a URL for his 
very comprehensive list located here-

http://www.dnso.net/library/dnso-tld.mhsc-position.shtml

which, he wrote was "intended it to be a running start". Does anyone else 
have any existing documents of their own but, with different requirements 
than Roeland has proposed?

Some major sticking points that seem to come up -- the "shared vs. 
non-shared" and  "chartered vs. non chartered" debate. Is it possible to 
work out some common elements which would be shared by either of these 
models? Or, do we just have multiple sets of requirements depending on 
which type they are?

Kendall

---

"A man with a hammer sees every problem as a nail." - Abraham Maslow



------------------------------------------------------------------------
Application document requirements (from 3/16/00)
------------------------------------------------------------------------

1) general information, applicant name, address, contact information and 
list of directors.

2) business capabilities - an overview of the business, business plan 
technical capabilities, estimated volume. The applicant should also 
describe the proposed protocol and if it will maintain and manage whois 
information (like the CORE model) or provide a referal whois (like the NSI 
model)

3) estimated volumes of registrations.

4) descriptions of communications systems - network and telephone systems 
technical support etc.

5) security - how this applies to the protocol used for registrations and 
what physical security mechanisms would be in place. how should the issue 
of bonds be addressed?

6) backup and disaster recovery, Service Level, and QOS issues

7) what should happen in the case of business failure, bankruptcy, 
insurance requirements

8) restrictions of current registrar status, is the applicant a gTLD or 
ccTLD registry or a ICANN accredited Registrar.

9) fees - price and billing requirements, how will the registry bill their 
clients

10) operational issues - what reports and are generated for registrars *if 
the registry is shared*, how are the gTLD root servers operated and updated?

11) would the applicant run the root for the gTLD(s) in question. o what 
gTLD(s) do they propose to run.