[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [wg-c] Application Requirements?




Kendall,

how about we seporate out the common items and make that a general section
to the application and then develop appropiate questions for each instance
where policy could be diferent.

If the shaired or chartered items are necessassary then we can use 
those sections once they are developed.

at least this way we don't have to answer the questions of which
registry model is acceptable before we can move forward on developing the
applications. also, in developing the applications for shaired and
chartered TLDs we will probably come up with some good questions for the
group.

-rick

On Sat, 25 Mar 2000, Kendall Dawson wrote:

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