[ga-org] Starting Point for Policy Discussions

["Danny Younger" <webmaster@babybows.com>]

The comments cited below were all rather quickly taken from assorted
background documents (some comments were edited) and do not necessarily
reflect any of my views; rather, they are solely intended to promote
discussion in a manner that might lead to establishing consensus.  Each
remark is numbered to better facilitate dialogue.  Most of the discussion
points were raised in the context of evaluating registry proposals for new
TLDs, but policy implications for .org abound throughout these statements.

We only have three weeks left within which to submit our comments to the
names Council.  Hopefully this might serve to speed up our deliberations...


1. A Starting Point for Discussions on Policy Recommendations for the .org
TLD
2. Policy issues:

Designation or establishment of an appropriate entity -- whether to select
an existing entity to succeed VeriSign as responsible for operation of the
.org TLD, or to establish a new entity.
3. To apply to sponsor or operate a TLD, one must submit a detailed,
multi-part proposal accompanied by extensive supporting documentation. The
effort and cost of preparing a sufficient proposal should not be
underestimated. The proposal must be based on a thoroughly formulated plan
for the establishment and viable long-term operation of the TLD. The
application should clearly and effectively describe the plan, show that the
necessary resources have been arranged (or that firm commitments have been
obtained) to implement the plan, and demonstrate that the proposal would be
superior to others.
4. Successful proposals will effectively address complex technical,
financial, business, and legal problems presented by operation of a TLD.
Those who are planning to apply are strongly urged to secure now the
professional assistance of technical experts, financial and management
consultants, and lawyers to assist in formulation of their proposals and
preparation of their applications.
5. The ICANN staff intends to place significant emphasis on the completeness
of the proposals and the extent to which they demonstrate that the applicant
has a thorough understanding of what is involved, has carefully thought
through all relevant issues, has realistically assessed the business,
financial, technical, operational, and marketing requirements for
implementing the proposal, has procured firm commitments for all necessary
resources, and has formulated sound business and technical plans for
executing the proposal.
6. At a minimum, factors that should be addressed are:
7. Services to be provided -- A full description of the registry services to
be provided.
8. Revenue model -- A full description of the revenue model, including rates
to be charged for various services.
9. Market -- Market definition, size, demand, accessibility.
10. Marketing plan -- Advertising, publicity, promotion strategy,
advertisement development strategy, relationship with advertising firm. Use
of registrars and other marketing channels.
11. Estimated demand for registry services in the .org TLD -- Projected
total demand for registry services in the TLD, effect of projected
registration fees, competition. Please provide estimates for at least 10%,
50%, and 90% confidence levels.
12. Resources required to meet demand -- Provide a detailed estimate of all
resources (financial, technical, staff, physical plant, customer service,
etc.) required to meet the estimated demands, using at least the 10%, 50%,
and 90% confidence levels.
13. Plans for acquiring necessary systems and facilities -- Describe plans
for acquiring all necessary systems and facilities for providing the
proposed services at each estimated demand level. Provide details as to the
scope, cost, and vendor for any significant planned outsourcing.
14. Staff size/expansion capability --  Plans for obtaining the necessary
staff resources, capacity for expansion, hiring policy, employee training,
space for additional staff, staffing levels needed for provision of expanded
technical, support, escrow, and registry services.
15. Availability of additional management personnel -- How will management
needs be filled?
16. Term of registry agreement -- State assumptions regarding the term of
any registry agreement with ICANN or the sponsoring organization. Note that
the .com/.net/.org registry agreement has a basic term of four years.
17. Capital requirements -- Quantify capital requirements in amount and
timing and describe how the capital will be obtained. Specify in detail all
sources of capital and the cost of that capital (interest, etc.). Evidence
of firm commitment of projected capital needs will substantially increase
the credibility of the registry operator's proposal.
18. Expected revenue associated with the operation of the proposed
registry -- Please show how expected revenue is computed at each estimated
demand level.Expected costs associated with the operation of the proposed
registry --  Please break down the total estimated operational costs by the
sources of the costs for each estimated demand level. Be sure to consider
the TLD's share of ICANN's cost recovery needs.
19. Pro-forma financial projections -- Please provide detailed pro-forma
financial projections, consistent with your business plan, for the demand
scenarios that you estimate.  The pro-formas should show revenue and expense
estimates broken down by detailed categories and should be broken down into
periods no longer than quarterly.
20. Supporting documentation -- The following documentation should be
provided in support of the Business Capabilities and Plan section:
21. Registry failure provisions. Please describe in detail your plans for
dealing with the possibility of registry failure.
22. Registry operator's organizational documents. Documents of incorporation
(or similar documents).
23. Business risks and opportunities -- Describe upside and downside
contingencies you have considered and discuss your plans for addressing
them.
24. References -- A list of significant trade and credit references.
25. Annual report -- The registry operator's most recent annual financial
report (or similar document). Audited financials are preferred.
26. Proof of capital -- Provide evidence of existing capital or firm
commitments of capital. Demonstrated access to necessary capital will be
carefully scrutinized.
27. Proof of insurance. Please provide.
28. The registry operator is responsible for provisions of all aspects of
registry services, including accepting registration requests (whether from
registrars or directly from registrants), maintaining a database of the
necessary registration data, generating zone files, and providing
nameservers to publish the zone file data throughout the Internet.  The
Registry Operator's Proposal may propose subcontracting services to other
vendors; in this case the proposal must be accompanied by firm commitments
by the proposed subcontractors, as well as detailed descriptions of their
capabilities.
29. Fees -- The application fee for each new TLD application is US$ 50,000.
This fee must be paid before ICANN will consider the application. It is
intended to cover ICANNs costs of receiving and evaluating the application,
including performing technical, financial, business, and legal analyses, as
well as ICANNs investigation of all circumstances surrounding the
applications and follow-up items. The application fee is non-refundable and
ICANN's only obligation upon accepting the application and fee is to
consider the application.  Each application (whether for a sponsored or an
unsponsored TLD) requires
payment of a US$ 50,000 fee.
30. It is anticipated that only a few of the applications that are received
will be selected for further negotiations toward suitable contracts with
ICANN.  Those submitting applications that are not selected for
negotiations, or that are selected but do not result in successful
negotiation of mutually satisfactory agreements, will not be refunded their
application fee, nor will ICANN reimburse their (probably larger) cost of
preparing the application.
31. selection criteria for the entity or its organizers - the
characteristics of the entity to be selected or established:
32. Geography -- positive aim of re-balancing the geographical distribution
of registry locations.
33. Non-Profit -- Registry operations should be unique not-for-profit
services; Competition -- established at the registrar level
34. No organization should be considered for the delegation of more than one
gTLD
35. Applications assessed against a benchmark test of expanding the growth
of the Internet
36. No preferential treatment should be given to any applicant who has been
involved in pre-registration activities. On the contrary such activities
should be frowned upon as an act of bad faith as this clearly went against
ICANN advice.
37. Viability -- Every effort must be made to substantiate that all new
Registries involved in the domain name space are viable. If any level of
doubt exists, ICANN should not consider the matter further without concrete
evidence to dispel those concerns.
38. The Business Capabilities and Plan section of the Registry Operator's
Proposal must include a comprehensive, professional-quality business plan.
This business plan will require detailed, verified business and financial
information about the proposed registry.   We strongly recommend securing
professional assistance from financial and management consultants to aid in
the formulation of your business plan, in securing the necessary sources of
financing, and in preparation of the Registry Operator's Proposal.
39. As is customary in formal business and financial plans for significant
projects, the following topics should be addressed fully:  company
information, current and past business operations, registry/Internet related
experience and activities, mission, target market, expected costs/expected
budget, expected demand, capitalization, insurance, revenue model, marketing
plan, use of registrars and other marketing channels, management and
employees, staff size/expansion capability, long-term commitment/registry
failure provisions.  Required supporting documentation will include:
documents of incorporation (or similar documents), company references,
annual report (or similar document), proof of capital and/or proof of firm
commitment of capital, proof of insurance, personnel resumes and references.
40. Performance -- Reliability alone will not command customer support.
Customers want, and require, performance. Poor performance, like a lack of
reliability, will drive users away and encourage them to satisfy their needs
through other techniques. Performance means that wait times, processing
delays and complicated procedures must be kept to a minimum and, wherever
possible, eliminated. Quite a few organizations and even individuals are
capable of patching together the minimum requirements to present a working
registry. That is not to say that such registries would preserve the
Internet's stability; in fact, many could jeopardize its reliability or
performance. The price of reliability and performance is substantial capital
and substantial expertise. Any entity that would be a credible candidate to
operate a registry must be prepared to commit both. Despite having increased
its daily volume by 500%, VeriSign Global Registry Services has reduced its
down time by over 75% in the same period. Performance such as this must be a
core part of the commitment made by any significant TLD registry or there
will be a loss of confidence in the Internet.
41. Marketing Efforts -- While there will almost certainly be continued
strong growth throughout the Internet, there is no assurance of sharing in
this growth, unless new registries themselves support a major marketing
effort that stimulates demand for services among end users.

What will distinguish the TLD from existing or other proposed TLDs? How will
this distinction be beneficial?
42. What community and/or market will be served or targeted by this TLD? To
what extent is that community or market already served by the DNS?
43. Please describe in detail how your proposal would enable the DNS to meet
presently unmet needs.
44. How would the introduction of the TLD enhance the utility of the DNS for
Internet users? For the community served by the TLD?
45. How would the proposed TLD enhance competition in domain-name
registration services, including competition with existing TLD registries?
46. Outreach -- But informing and educating the end-user marketplace about
the opportunities offered by a top-level domain will be neither inexpensive
nor quick. We anticipate that a multi-year, multi-million dollar marketing
campaign will be necessary to support each new TLD after the initial spurt
of registrations.
47. Coordination Efforts -- details about the multilingual domain name test
bed, access to the gTLD Whois database ("Whois"), publication of the
registry-registrar protocol ("RRP"), password-protected services for Global
Registry Services customers, a description of a Customer Affairs Office and
DNS Programs Office, and employment listings. Most of these are essential
for smooth coordination.
48. Monthly Reports -- on performance to ICANN's Domain Name Supporting
Organization ("DNSO"). On a monthly basis, certain performance and
transaction measurements are presented in statistical form, thereby making
it much easier for ICANN, the entire Internet community of registrars and
other interested parties to track this data. This is another example of a
simple tool whose uniform use by gTLD registry operators would contribute to
the long-term development of this nascent industry. Information such as the
number of registrars accredited by ICANN, completed SRS releases and daily
transaction ranges are recorded.
49. Registrar Relations Office -- the Office is responsible for initiating
and maintaining the business and contractual relationship with the
accredited registrars. This department works with newly-accredited
registrars to ensure a smooth and quick ramp-up process and is available to
help the registrars understand the requirements of contracting and doing
business with Global Registry Services. After a registrar becomes
operational, the office remains available to answer questions, as well as
assist registrars with ongoing contractual and business issues. The Office
also works with operational registrars to ensure that they comply with the
terms of the Registrar License and Agreement. This may involve working with
one or multiple registrars to resolve disputes between registrars, or
complaints from other third parties.  Any successful new registry will have
to support a similar, major registrar liaison group. As the number of
accredited registrars continues to increase on a global basis, this
relationship management will become even more important to the fluid manner
in which registry operations are conducted among many parties. At a minimum,
Global Registry Services provides the following items equally to all
registrars: maximum number of IP addresses for connecting to the Shared
Registry System ("SRS"); the current version of RRP Software Development
Kits ("SDKs") and updates; customer support access; access to dispute
resolution resources; data to reconcile registration activities; resources
to perform basic account management functions; and the absence of algorithms
or protocols in the SRS that differentiate among registrars.
50. Surveys -- twice per year, an outside party is hired by to conduct a
customer survey of all operational accredited registrars and to establish a
baseline measurement of performance. uses the responses received from the
registrars in an on-going effort to improve customer satisfaction.
51. Standards -- In addition to serving its customers (i.e. accredited
registrars), a registry needs to play a role in the emerging standards that
affect Internet domain name registrations.
52. Commitment to Qualitative Investment -- Providing the highest-level gTLD
systems and zone processes is one of the most important responsibilities of
Global Registry Services. The business resources
necessary to realize a nearly flawless level of continuous and global
resolution service, including personnel in multiple regions of the world and
ordinary capital investment in systems hardware and software upgrades, are
significant.  For example, the "A" root name server, which currently also
serves as a gTLD server, doubled transaction growth in one quarter to over
five thousand queries per second with peaks of up to eight thousand queries
per second. Though invisible to the end user, the coordination efforts used
to make sure that all zone files are propagated properly entail significant
planning and constant care. Again, although not all open gTLD registries
should employ the exact practices as VeriSign Global Registry Services, all
registry operators need to be able to commit to these highest levels of
performance and scalability requirements.
53. Security -- In addition to reliance on a skilled management and staff to
execute their respective responsibilities, effective gTLD registries require
a highly secure facility to house their main operations.  Providing physical
and logical security for TLD registries is of utmost importance. These
requirements also add to the already-significant capital required by a TLD
registry operator. The direct correlation between investment in enduring
security and the relatively low occurrence of security breaches is an
important planning item for ICANN and for new registries.
54. Technical Qualifications -- any applicant interested in operating and
maintaining a gTLD registry must demonstrate that it likely can perform its
obligations by showing in its application that it possesses certain
technical qualifications.
55. The Technical Capabilities and Plan section must include a
comprehensive, professional-quality technical plan for establishment and
operation of all aspects of the registry. The technical plan will require
detailed, specific information regarding the technical capabilities of the
proposed registry. It should be developed with reference to the standard
technical capabilities of major providers of Internet services. We strongly
recommend that those who are planning to apply secure professional
assistance from engineers and/or other technical consultants to aid in the
formulation of the technical plan and the preparation of the Technical
Capabilities and Plan section of the Registry Operator's Proposal.
56. At least the following topics should be addressed fully: physical
plants, hardware, software, facility and data security, bandwidth/Internet
connectivity, system outage prevention, system restoration capabilities and
procedures, information systems security, load capacity, scalability, data
escrow and backup capabilities and procedures, Whois service, zone file
editing procedures, technical and other support, billing and collection,
management and employees, staff size/expansion capability, and provisions
for preserving stability in the event of registry failure. Required
supporting documentation will include: company references, diagrams of
systems (including security) at each location, personnel resumes and
references.
57. The customer service components -- used by customer service
representatives to perform registry data maintenance functions when
customers need help. Based on experience with .com, .net and .org, we
anticipate that the market is likely to continue to expect these areas of
support and service.  We believe that the operational and technical
specifications and best practices used in connection with .com, .net and
.org offer the security and stability required of all open gTLD operators.
Such operations must be prepared to provide services to a global and
demanding marketplace 24x7x365.
58. Connectivity -- requires multiple DS3 connections. These connections are
used to configure both the wide-area network and the local-area network
("LAN") in the network architecture. High-capacity routers are used along
with fast Ethernet router/switches to configure several virtual LANs within
the system. Load-balancing devices are used for load sharing and for
balancing high-volume network services to the RRP gateways, Whois servers
and Web servers. All firewall systems are hosted on multi-processor UNIX
servers. Network connectivity throughout the LAN architecture is provided
through switched 100BaseT over CAT5 cable.
59. Architecture -- The Internet services segment of the .org registry
resides outside the firewall system and includes multiple DNS servers, mail
servers, DNS servers, RRP gateways, Whois servers, and Web servers. All
gateways and servers are hosted in a UNIX environment on multi-processor
servers. A storage array provides for the registry database and all
back-office applications servers. RISC-architecture processors are used with
additional megabytes of external cache, additional gigabytes of main memory
and multiple input/output channels, which are able to support internal
hot-swappable storage and have redundant hot-swappable power and cooling.
The enterprise storage system uses a storage array to provide a vehicle that
pushes data out to external public servers through a SCSI channel. This
architecture permits communication to external networks without compromising
security by opening additional holes through the firewall. To meet the
requirements for availability, accurate data from VeriSign Global Registry
Services is distributed remotely to a global network of gTLD servers. The
system architecture includes protocols and services as well as the database
system. The system provides data for all registry products, including zone
files, transaction logs and Whois snapshots. The external public services
comprise the Whois servers, which manage database queries and the RRP
gateways. These gateways provide a protocol interface to registrars and
perform the following functions:
60. Add - register a domain name or domain name server
61. Check - check availability of a domain name or name server
62. Delete - delete a domain name or server
63. Describe - return the latest RRP version number
64. Modify - update a domain name or name server
65. Quit - close an RRP session
66. Renew - extend the registration of a domain name
67. Session - create an RRP session
68. Status - query a domain name or name server
69. Transfer - transfer a domain name from one registrar to another.
70. Technical Capabilities and Plan. This section must include a
comprehensive, professional-quality technical plan that provides a detailed
description of the registry operator's current technical capabilities as
well as a full description of the operator's proposed technical solution for
establishing and operating all aspects of the registry. The technical plan
will require detailed, specific information regarding the technical
capabilities of the proposed registry.  ICANN will extensively review and
analyze this section of the Registry Operator's Proposal. The content,
clarity, and professionalism of this section will be important factors in
ICANN's evaluation of applications. We strongly recommend that those who are
planning to apply secure professional assistance from engineers and/or other
technical consultants to aid in the formulation of the technical plan and
the preparation of the Technical Capabilities and Plan section of the
Registry Operator's Proposal.  The Technical Capabilities and Plan section
should consist of at least the following:
71. Detailed description of the registry operator's technical capabilities.
This should provide a detailed description of the registry operator's
technical capabilities, including information about key technical personnel
(qualifications and experience), size of technical workforce, and access to
systems development tools. It should also describe the registry operator's
significant past achievements. This description offers the registry operator
an opportunity to demonstrate the extent of its technical expertise in
activities relevant to the operation of the proposed registry.
72. Technical plan for the proposed registry operations. This should present
a comprehensive technical plan for the proposed registry operations. In
addition to providing basic information concerning the operator's proposed
technical solution (with appropriate diagrams), this section offers the
registry operator an opportunity to demonstrate that it has carefully
analyzed the technical requirements of registry operation. Factors that
should be addressed in the technical plan include:
General description of proposed facilities and systems. Address all
locations of systems. Provide diagrams of all of the systems operating at
each location. Address the specific types of systems being used, their
capacity, and their interoperability, general availability, and level of
security. Describe in detail buildings, hardware, software systems,
environmental equipment, Internet connectivity, etc.
73. Registry-registrar model and protocol. Please describe in detail.
Database capabilities. Database size, throughput, scalability, procedures
for object creation, editing, and deletion, change notifications, registrar
transfer procedures, grace period implementation, reporting capabilities,
etc.  Zone file generation. Procedures for changes, editing by registrars,
updates. Address frequency, security, process, interface, user
authentication, logging, data back-up.  Zone file distribution and
publication. Locations of nameservers, procedures for and means of
distributing zone files to them.  Billing and collection systems. Technical
characteristics, system security, accessibility.  Data escrow and backup.
Frequency and procedures for backup of data. Describe hardware and systems
used, data format, identity of escrow agents, procedures for retrieval of
data/rebuild of database, etc.
74. Publicly accessible look up/Whois service. Address software and
hardware, connection speed, search capabilities, coordination with other
Whois systems, etc.  System security. Technical and physical capabilities
and procedures to prevent system hacks, break-ins, data tampering, and other
disruptions to operations. Physical security.  Peak capacities. Technical
capability for handling a larger-than-projected demand for registration or
load. Effects on load on servers, databases, back-up systems, support
systems, escrow systems, maintenance, personnel.   System reliability.
Define, analyze, and quantify quality of service.  System outage prevention.
Procedures for problem detection, redundancy of
all systems, back up power supply, facility security, technical security,
availability of back up software, operating system, and hardware, system
monitoring, technical maintenance staff, server locations.
75. System recovery procedures. Procedures for restoring the system to
operation in the event of a system outage, both expected and unexpected.
Identify redundant/diverse systems for providing service in the event of an
outage and describe the process for recovery from various types of failures,
the training of technical staff who will perform these tasks, the
availability and backup of software and operating systems needed to restore
the system to operation, the availability of the hardware needed to restore
and run the system, backup electrical power systems, the projected time for
restoring the system, the procedures for testing the process of restoring
the system to operation in the event of an outage, the documentation kept on
system outages and on potential system problems that could result in
outages.
76. Technical and other support. Support for registrars and for Internet
users and registrants. Describe technical help systems, personnel
accessibility, web-based, telephone and other support, support services to
be offered, time availability of support, and language-availability of
support.
77. Subcontractors. If you intend to subcontract any the following:
78. all of the registry operation function;
79. any portion of the registry function accounting for 10% or more of
overall costs of the registry function; or
80. any portion of any of the following parts of the registry function
accounting for 25% or more of overall costs of the part: database operation,
zone file generation, zone file distribution and publication, billing and
collection, data escrow and backup, and Whois service please (a) identify
the subcontractor; (b) state the scope and terms of the subcontract; and (c)
attach a comprehensive technical proposal from the subcontractor that
describes its technical plans and capabilities in a manner similar to that
of the Technical Capabilities and Plan section of the Registry Operator's
Proposal. In addition, subcontractor proposals should include full
information on the subcontractor's technical, financial, and
management capabilities and resources.
81. Applications -- The application and database segment has a combination
of UNIX servers to support registry applications, and high-speed PC
workstations to act as billing servers. Using high-speed PC workstations to
support customer service operations, configured commercial workstations as
required to support the evolving customer service operations.
82. Online Testing and Evaluation Segment -- provides a test bed for
investigating registry issues before going online, as well as a technical
verification environment for potential registrars. The test bed has an RRP
gateway outside a firewall; all other activities are directed through
registry application and database servers with other equipment added as
needed. Initial capability is hosted on multi-processor UNIX servers. The
OT&E environment does not interact in any way with the live production
database system.
83. Power Supply -- The operations facility used in connection with.org
includes the data center, communications room and electrical room. The
electrical room houses the uninterrupted power supply ("UPS"), the battery
room and the generator to power the UPS in the event of electrical outage. A
fuel tank for the generator is available at the facility.
84. Technical support for users of the .org registry is provided primarily
through a help desk that refers problems to technicians who can resolve
them. Technical support is provided to registrars for software support,
registrar technical support and verification, the registrar OT&E
environment, and database support. The systems integration organization
provides problem-solving support to the registrars and performs technical
verification of the software interfaces between the registrars and Global
Registry Services. Emergency support services are available 24x7 to support
the number and geographic diversity of the registrars. The range of support
includes both initial implementations and on-call support if issues arise
that affect a registrar's service.
85. Standardization -- We recognize the importance of standardization in
certain aspects of any maturing industry. For this reason, we encourage
ICANN to ensure that the registry operators introduced by ICANN standardize
core practices and procedures based on the current successful experience in
.com, .net and .org.
86. Pricing -- We support the current policy to allow all registrars to set
their own prices for domain name registration services. This policy is the
cornerstone of the effort to foster market-driven competition for domain
name registration services. Registrars are free to bundle registrar services
with other products, enhancing the possible benefits to consumers and having
a positive effect on the ease of registering domain names on the average
consumer. The net effect is to encourage innovation which tends to attract a
greater number of participants onto the Internet.
87. Fashioning the legal relationship with ICANN -- principles governing
relationship with ICANN:
88. The need to maintain the Internet's stability
89. ICANN's first priority is to preserve the stability of the Internet,
including the domain-name system (DNS). Proposals should demonstrate
specific and well-thought-out plans, backed by ample, firmly committed
resources, to operate in a manner that preserves the Internet's continuing
stability. Security and reliability of the DNS are important aspects of
stability, and proposals should set forth comprehensive strategies to assure
both. ICANN will undertake a wide-ranging assessment of a proposal's
treatment of stability issues. Among the significant aspects of stability
ICANN will review are:
90. The prospects for the continued and unimpaired operation of the TLD in
the manner proposed by the registry operator or sponsor throughout the
period for which the delegation is agreed;
91. Provisions to minimize unscheduled outages of registry or registration
systems due to technical failures or malicious activity of others;
92. Provisions to ensure consistent compliance with technical requirements
in operation of the TLD;
93. Effects of the new TLD on the operation and performance of the DNS in
general and the root-server system in particular;
94. Measures to promote rapid correction of any technical difficulties that
occur (whether or not due to the TLD's operation), such as availability of
accurate, consistent, and helpful Whois information;
95. The protection of domain-name holders from the effects of registry or
registration-system failure, such as procedures for rapid restoration of
services from escrowed data in the event of a system outage or failure; and
96. Provisions for orderly and reliable assignment of domain names during
the initial period of the TLD's operation.
97. The extent to which selection of the proposal would lead to an effective
"proof of concept" including the diversity the proposal would bring to the
program, such as fully open top level domains, restricted and
chartered domains with limited scope, noncommercial domains, and personal
domains; and a variety of business models and geographic locations.
98. the current program is intended to serve as a "proof of concept" for
ways in which the DNS might evolve in the longer term.  Proposals should be
chosen so as to promote effective evaluation of :
99. the effectiveness of different procedures for launching a registry
100. different policies under which a TLD can be administered in the longer
term,
101. different operational models for the registry and registrar functions,
102. different business and economic models under which TLDs can be
operated;
103. the market demand for different types of TLDs and DNS services; and
104. different institutional structures for the formulation of registration
and operation policies within the TLD.
105. This factor will be best served by applications that clearly articulate
what concept or proposition the proposal would test, how the results of that
test should be evaluated, and how the results of the evaluation would assist
in the long-range management of the DNS.
106. The enhancement of competition for registration services at the
registry and registrar level.
107. The enhancement of competition for registration services -- As noted in
the White Paper, market mechanisms that support competition and consumer
choice should, where possible, drive the management of the DNS. One of
ICANN's core principles is the encouragement of competition at both the
registry and registrar levels. Though the market will be the ultimate
arbiter of competitive merit, it is appropriate to make a preliminary
evaluation of competitive merit for the "proof of concept."
108. A proposal's contributions to enhancement of competition can take
various forms, depending on the specifics of the proposal. The nature and
degree of competition involved may vary. Proposals will be evaluated to
determine whether they are responsive to the general goal of enhancing
competition for
registration services.  Some examples of competitive issues that may be
considered in evaluating
proposals are:
109. What prospects do the proposed TLD and registry have for effectively
competing with other TLDs and registries (either pre-existing or introduced
at the same time)? Are the proposed pricing and service levels likely to be
competitive with other TLDs and operators having significant market shares?
If effective marketing is necessary to make the TLD competitive, does the
proposal adequately provide for that marketing? If the proposal is for an
unrestricted TLD, are any features proposed to maximize the prospect that
the TLD will be attractive to consumers as an alternative to .com?
110. Is the proposal particularly attractive to a significant sub-market in
which it can compete effectively? Are distinctive services being proposed
that will meet the needs of those not being served adequately by existing
services?
111. Is there any significant competitive concern that the proposed TLD is
likely to lead to lock-in of domain-name holders, so that inter-TLD
competition is constrained? To the extent there is a concern about
constrained competition, what measures are proposed or available to ensure
competitive operation of the TLD (periodic rebidding of registry, etc.)?
112. What effect would the proposal have on registrar-level competition?
Does the proposal restrict the ability of accredited registrars to offer
registration services within the TLD on competitive terms? What mechanism is
proposed for selecting registrars?  Describe in detail the policies for
selection of, and competition among, registrars. Will domain-name holders
deal through registrars, directly with
the registry operator, or some combination of the two? What are the
respective roles, functions, and responsibilities for the registry operator
and registrars? If registrars are to be employed, how and by whom will they
be selected or accredited? If the number of registrars will be restricted,
what number of registrars will be selected? Have the qualifying registrars
already been selected? On what basis will selections among those seeking to
be registrars be made, and who will make them? If registrars are to be used,
what mechanisms will be used to ensure that TLD policies are implemented?
113. If accredited registrars are not permitted to offer registration
services within the TLD on a competitive basis, are there other, effective
mechanisms for providing competitive choices to domain-name holders seeking
to register within the TLD?
114. Would the proposal advance competitive frontiers by introducing an
innovative use of the DNS?
115. Would restrictions proposed for a restricted TLD impair (either in
principle or in implementation) competition among potential registrants?
116. The enhancement of the utility of the DNS.
117. The extent to which the proposal would meet previously unmet types of
needs.  The DNS should meet a diversity of needs. Close examination will be
given to whether submitted proposals exhibit a well-conceived plan, backed
by sufficient resources, to meet presently unmet needs of the Internet
community.

 Policy Development -- policies for the entity's operation of the .org
top-level domain

All registrants in new TLDs should be required to:

pre-pay all registration fees

provide accurate contact information and keep it current

fully complete electronic registration forms

certify that statements made in the registration application are true

require to provide for a structured semantic sub-domain structure that
enables ease of access to specific content areas. Without such an approach
any new domain will sustain the risks of exhaustion and also encourage a
high volume of protective registrations that has been quoted as limiting
further registrations in the .com domain.
118. ICANN should require the operators of all new and existing Top Level
Domains to verify that applications for domain names do not infringe the
rights of holders of intellectual property, trade marks or brand names of
existing entities, whether commercial, non-commercial or individual; any
applicant seeking to win Board approval must include in its application
proposals for mechanisms that provide protection for intellectual property
rights.
119. reject bulk registrations and pre-emptive registrations which seek to
create an opportunity for speculative resale of domain names;
120. provide, in advance, protective registrations for domain names that are
the intellectual property, trade marks or brand names of existing
businesses, at cost;
121. flag applications when there is a risk of homonyms arising which may
create confusion with other registrants' names.
122. A TLD with no enforced restrictions on who may apply for a registration
within the domain or on what uses may be made of those registrations. (Note
that RFC 1591 states that these domains are intended
for various uses. As a practical matter, however, anyone may register and
use names in these domains for any purpose.) A TLD having a structure with
second-level domains below which registrations are offered for registration
is considered an unrestricted TLD only if all of the domains in which
registrations are offered are themselves unrestricted.  Unrestricted TLDs
can operate either without a sponsoring organization (i.e. policies to be
established and modified only through the ICANN process) or with a
sponsoring organization (in which case policy-making responsibility is
allocated between ICANN and the sponsoring organization).
123. Continuity -- assuring the ability of present registrants to continue
their registrations
124. UDRP
125. The UDRP be continued as is, or improved

Given the success of the UDRP in existing open TLDs, there will be benefit
in expanding the UDRP. Registries in new chartered or restricted TLDs should
supplement their unilateral capacity to revoke a fraudulent registration by
adhering to an expanded UDRP, under which the registration or use of a
domain name in violation of the TLDs charter or other pertinent rules would
demonstrate bad faith. This would give an interested member of the consuming
public the ability to ensure that a bad faith actor will not be permitted to
use the name.
126. Additionally, members of the public need to be able to search for all
domain names registered to a particular registrant, at a particular postal
address, or involving a particular contact, without an arbitrary limit (e.g.
NSI search aborts at "50" hits and searches by postal address cannot be
conducted). This ability is important under the UDRP, for example, to
demonstrate a "pattern" of bad faith conduct.
127. Dispute Resolution. Describe the policies for domain name and other
dispute resolution. If you are proposing variations to the policies followed
in .com, .net, and .org, consider the following questions:
128. To what extent are you proposing to implement the  Uniform Dispute
Resolution Policy?
129. Please describe any additional, alternative, or supplemental dispute
resolution procedures you are proposing.
130. WHOIS -
131. All applications for new TLDs should provide for unfettered public
access, with robust searchability, to a current cross-registry database of
contact data, including:
132. second-level domain name and its status, including link to registrar
133. registrant's [and registrars] name and postal address
134. administrative/technical contacts' name, address, e-mail, telephone and
fax
135. original registration date, expiration date, update date
136. IP addresses, names of primary and secondary nameserver
137. Does the proposal make adequate provision for WHOIS service that
strikes an appropriate balance between providing information to the public
regarding domain-name registrations in a convenient manner and offering
mechanisms to preserve personal privacy (i.e. access to complete, accurate,
and up-to-date WHOIS data; centralized registry WHOIS; WHOIS w/o arbitrary
limits on the number of hits; multi-field WHOIS)?
138. It is essential that all applicants, as a condition of their
accreditation and as a material element in their continued accreditation,
agree to participate in the operation of a cross-registry WHOIS database,
which will provide searching capabilities and access to all information
concerning domain name registrations regardless of which TLD the domain name
is registered in or which registrar processed the domain name application.
Such agreement shall further require all applicants to keep the
cross-registry WHOIS database current and comprehensive.
139. Third Party Rights -- Care should be taken to ensure that the rights of
third parties are appropriately protected. Examples of matters to be
examined in this regard include:
140. Does the proposal have a well-thought-out plan for allocation of names
during the start-up phase of the TLD in a way that protects the legitimate
interests of significant stakeholders, including existing domain-name
holders, businesses with legally protected names, and others with which
conflict is likely?
141. Does the proposal provide for a reasonably accessible and efficient
mechanism for resolving domain-name disputes?
142. Has the proponent considered intellectual property interests or
otherwise designed protections for third-party interests?
143. Intellectual Property Provisions. Describe the policies for protection
of intellectual property.  Your response should address at least the
following questions, as appropriate to the TLD:
144. What measures will be taken to discourage registration of domain names
that infringe intellectual property rights?
145. If you are proposing pre-screening for potentially infringing
registrations, how will the pre-screening be performed?
146. What registration practices will be employed to minimize abusive
registrations?
147. What measures do you propose to comply with applicable trademark and
anti-cybersquatting legislation?
148. Are you proposing any special protections (other than during the
start-up period) for famous trademarks?
149. How will complete, up-to-date, reliable, and conveniently provided
Whois data be maintained, updated, and accessed concerning registrations in
the TLD?

Does the proposal make adequate provision for Whois service that strikes an
appropriate balance between providing information to the public regarding
domain-name registrations in a convenient manner and offering mechanisms to
preserve personal privacy?
150. Data Privacy, Escrow, and Whois. Describe the proposed policies on data
privacy, escrow and Whois service.
151. Billing and Collection. Describe variations in or additions to the
policies for billing and collection.
152. Services and Pricing. What registration services do you propose to
establish charges for and, for each such service, how much do you propose to
charge?
153. Other. Please describe any policies concerning topics not covered by
the above questions.
154. Does the proposal incorporate policies that are likely to discourage
abusive registration practices?

Due Process - allowing  the entity to set up its business operations
155. VeriSign contributes $5,000,000 endowment to fund future operating
costs of a non-profit entity
156. this endowment should be considered in developing policy for  future
operation of the .org TLD
157. Start up phase
158. The importance of appropriate protections of rights of others,
including intellectual property rights, in connection with the operation of
the TLD, especially during the start-up phases.
159. Enforcement: An application for a TLD should explain the mechanism for
charter enforcement where relevant and desired.
160. Must identify:
161. Details of when positive income is expected
162. the portion of "Other Direct Expenses" which are related to marketing
costs
163. Applicant's assumptions with respect to the existence of other general
purpose TLDs in determining the total number of registrations in your
application.
164. the timetable in which you will allow full access to ICANN accredited
registrars
165. If you intend to provide bulk Whois service, identify and provide a
summary of the party or parties who will provide that service
166. average and worst case transaction times for a post to confirmation of
acceptance.
167. the service level to which you are willing to contractually commit for
post to confirmation of acceptance.
168. projected level of Whois query traffic
169. the projected query traffic level to the Whois function to which you
are willing to contractually commit.
170. the timetable for the availability of the following services:
171. Assuming your primary site experiences a catastrophic failure, identify
and describe in detail the timetable required to restore:
172. partial SRS service; and full SRS service.
173. Identify whether you will provide a test-bed for registrars to validate
their  protocol software.
174. How do you propose to address the potential rush for registration at
the initial opening of the TLD? How many requested registrations do you
project will be received by the registry operator within the first day,
week, month, and quarter? What period do you believe should be considered
the TLD's "start-up period," during which special procedures should apply?
Do you propose to place limits on the number of registrations per
registrant? Per registrar? If so, how will these limits be implemented?
175. Will pricing mechanisms be used to dampen a rush for registration at
the initial opening of the TLD? If so, please describe these mechanisms in
detail.
176. Will you offer any "sunrise period" in which certain potential
registrants are offered the opportunity to register before registration is
open to the general public? If so, to whom will this opportunity be offered
(those with famous marks, registered trademarks, second-level domains in
other TLDs, pre-registrations of some sort, etc.)? How will you implement
this?
177. Describe in detail the criteria for registration in the TLD. Provide a
full explanation of the reasoning behind the specific policies chosen.
178. Describe the application process for potential registrants in the TLD.
179. Describe the enforcement procedures and mechanisms for ensuring
registrants meet the registration requirements.
180. Describe any appeal process from denial of registration.
181. Describe any procedure that permits third parties to seek cancellation
of a TLD registration for failure to comply with restrictions.
182. How do you propose that the results of the introduction should be
evaluated?
183. By what criteria should the success or lack of success of the TLD be
evaluated?
In what way would the results of the evaluation assist in the long-range
management of the DNS?



--
This message was passed to you via the ga-org@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-org" in the body of the message).
Archives at http://www.dnso.org/archives.html