The Swiss Education & Research Network
|
The Swiss Education & Research Network
|
| Switch ORG Proposal: ICANN .org Proposal Form | back to index | ||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||
|
I. GENERAL INFORMATION ABOUT THE APPLICANT C1. The first
section of the .org Proposal (after the signed copy of this document)
covers general information about the applicant. Please key your responses
to the designators (C2, C3, C4, etc.) below. C2. The full legal name, principal address, telephone and fax numbers, and e-mail address of the applicant, and the URL of its principal world wide web site.
Refer to appendix A for detailed information. SWITCH was formally established in October 1987 as a foundation of the private sector by the Swiss government (Federal Department of Home Affairs) and eight university cantons for the purpose of creating and maintaining Switzerland's academic and research network. SWITCH is listed in the commercial register of Bern with its seat at Schweizerische Universitätskonferenz (see appendix AA, in paper form only), offices are located in Zürich at Limmatquai 138 and Neumühlequai 6. The network part of SWITCH supports the TCP/IP suite of protocols since 1989, at that time with a 2 Mbps dual-star backbone between Lausanne and Zürich. Since then the network - called SWITCHlan - has grown considerably and is now connecting all Swiss universities, Swiss Federal Institutes of Technology, Universities of Applied Sciences and many other institutions devoted to research and education, e.g.CERN, Paul Scherrer Institute and many libraries (some 40 sites). The current network topology is shown below.
SWITCH also participating in 6bone (a voluntary coordination
initiative of Research and Education Networks to promote and encourage
early production IPv6 network services to facilitate high quality, high
performance, and operationally robust IPv6 networks) and Mbone (an IP
multicast virtual network) initiatives and infrastructures.
The magazine SWITCHjournal is published twice per year to report on recent activities and provide background information (see appendix AE for journal 2/2001 in paper form). Domain registration for (CH) Switzerland: In 1999 introduction of technical and security improvements to the registration system: User-ID's and passwords, Oracle data base, new billing system. SWITCH is highly respected by the Swiss Internet community (according to public hearings held in August 2001) for technical and administrative competence and efficiency. SWITCH customer care center communicates in three official languages (German, French and Italian) and in English, Spanish, Portuguese and Yugoslavian. The Web pages have been in English seen as the major communication language from the beginning and are now also available in German, French and Italian. In 2001 the Swiss Federal Office of Communications decided to enhance its responsibility for the communication infrastructure in Switzerland. As a result, SWITCH performs registry services for CH now in its function as delegee of the Swiss Federal Office of Communications (since 1.4.2002). The benefits are clear competences, defined (local) re-delegation rules and a legally stable and elaborate system. ADR/UDRP: Due to well established summary proceedings conducted by local public courts, their short decision times and low cost it was felt unnecessary to introduce ADR's for domain name disputes under CH. Local trade mark lawyers have indicated that such a mandatory procedure would only increase the time required for challenges. SWITCH is currently evaluating an ADR process tailored to the need of the local community.
Domain registration for the Principality of Liechtenstein
(LI): Statistical data for Liechtenstein and LI:
Website: www.nic.li;
WHOIS: whois.nic.li
A section of the Customer Care Center for Domain Registration (CH and LI) As a non-profit organization located in Switzerland, SWITCH is able to provide a stable, secure and independent environment for the global ORG community. With the establishment of offices in America and Asia-Pacific, SWITCH will provide regional support in appropriate languages and focus its strategy on best services at lowest possible prices within a transparent, open and neutral environment.
C5. Dun & Bradstreet D-U-N-S Number (if any) of
the applicant. C6. The number of employees currently employed by
the applicant. C7. The applicant's total revenue (in US dollars)
in the last-ended fiscal year. C8. Full names and positions of (i) all directors, (ii) all officers, (iii) all relevant managers, and (iv) any persons or entities owning five percent or more of the applicant.
Committee of Council of Foundation: Management Board: Dr. Karl-Heinz Krebser, General Secretary Marco D'Alessandro C9. Provide the name, telephone and fax number, and e-mail address of person to contact for additional information regarding this application. If there are multiple people, please list all their names, telephone and fax numbers, and e-mail addresses and describe the areas as to which each should be contacted.
II. STATEMENT OF CAPABILITIES OF THE APPLICANT AND CONTRACTED SERVICE PROVIDERS
Throughout this document, operation of the .org registry,
including providing all associated Registry Services, as defined in subsection
1.16 of the model .org Registry Agreement, is referred to as the "Registry
Function". C12. State whether the applicant intends to perform
all aspects of the Registry Function, or whether the applicant intends
to outsource some or all aspects of the Registry Function to other entities
that will provide services or facilities under contract with the applicant.
If any portion(s) of the services or facilities will be provided by another
entity under contract, please describe which portion(s), state the time
period during which they will be provided under contract, and identify
what entity will be providing the services or facilities. C13. Identify by name each entity other than the applicant that will provide any of the following:
The identification of each entity should include: C13.1 The full legal name, principal address, telephone and fax numbers, and e-mail address of the entity, and the URL of its principal world wide web site.
Wampumpeag, LLC
Nominum, Inc. development efforts focus on improving the domain name system and management of dynamic host (DHCP). Our management includes the original author of the DNS protocol, Paul Mockapetris, and many of the authors/maintainers of the most widely distributed implementation of DNS protocols. Our hosted DNS platform, Global Name Service, operates on a non-BIND proprietary code base and serves country registries and enterprises who wish to deploy the latest in DNS security developments and network efficiency. Wampumpeag, LLC: Operating Systems and Networks Consulting and Software Development. IX Europe Telehouse: see Web site C13.4. Dun & Bradstreet D-U-N-S Number (if any) of the entity. Mount10: none C13.5. The number of employees currently employed
by the entity. Mount10: information will not be disclosed C13.6. The entity's total revenue (in US dollars)
in the last-ended fiscal year. Mount10: information will not be disclosed C14. For each entity identified in item C13, please
state the scope and terms of the contract under which the facilities or
services will be provided and attach documentary evidence that the entity
has committed to enter into that contract.
[ICANN's evaluation of your response to item C15 will
be a major factor in the selection of a successor .org operator. We recommend
that you give a detailed, specific response.] C15. Describe in detail the abilities of the applicant and the entities identified in item C13 to operate a TLD registry of significant scale in a manner that provides affordable services with a high degree of service responsiveness and reliability. Your response should give specifics, including significant past or present achievements and activities of the applicant and the entities identified in item C13 that demonstrate the described abilities. It should also include information about key technical personnel (qualifications and experience), size of technical workforce, and access to systems development tools. Mount10 Desaster Protection Competence Center is a renowned data storage and backup company Nominum: PLEASE SEE TECHNICAL OVERVIEW ATTACHED as appendix CA. Wampumpeag began work on a reference implementation of a multi-protocol registry backend, supporting the EPP (IETF), RRP (VGRS), and SRS (CORE) protocols, over TCP, BEEP, FTP, and SMTP, in January of 2002. IX Europe Telehouse maintains the Swiss TIX (see
appendix C). III. TECHNICAL PLAN (INCLUDING TRANSITION PLAN) C16. The third section of the .org Proposal is a description
of your technical plan. This section must include a comprehensive, professional-quality
technical plan that provides a full description of the proposed technical
solution for transitioning and operating all aspects of the Registry Function.
The topics listed below are representative of the type of subjects that
will be covered in the technical plan section of the .org Proposal. [ICANN will extensively review and analyze this section of the .org 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 plan section of the .org Proposal.] C17. Technical plan for performing the Registry Function.
This should present a comprehensive technical plan for performing the
Registry Function. In addition to providing basic information concerning
the proposed technical solution (with appropriate diagrams), this section
offers the applicant an opportunity to demonstrate that it has carefully
analyzed the technical requirements for performing the Registry Function.
Factors that should be addressed in the technical plan include: C17.1. 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 buildings, hardware, software systems, environmental equipment, Internet connectivity, etc. Refer to appendix B for detailed information. The excellent registry model relies on technical expertise gained from operating CH and LI top level domains since 1987, a financially stable and robust organization and the aim to deliver state-of-the-art performance to the ORG community. The application describes a synchronized dual registry system with identical components, one located in Zürich at the Swiss Federal Institute of Technology (ETHZ), the other at CERN in Geneva, both connected over redundant gigabit fiber optic lines with each other and to the Internet. Both systems additionally have local backup and a disaster recovery with copies of the data bases to be stored in a Swiss mountain. The systems are designed to handle exceptionally high loads and provide equal access for registrars using RRP and EPP protocols. The proposed design uses system similar to one already in use for CH and LI domain name registration but with many enhancements and improvements. It has been possible to specify and measure the parameters for the ORG TLD based on the system in use (its OT&E components) and this system will serve for further developments and measurements. Two identical and synchronized registry systems, located in two data centers with more than 250 km distance between will be used, one in Zürich at the Swiss Federal Institute of Technology (ETHZ, www.ethz.ch) and one in Geneva (Meyrin) at the European Organization for Nuclear Research (CERN, www.cern.ch). The following security requirements are met at each location:
Both data centers have protective and preventative measures and procedures in case of fire and water. The main machine rooms are equipped with a sensitive laser based detection system at ceiling level and a less sensitive system in the false floor plenums. An on-site fire brigade is alerted if smoke is detected by either system. CERN also have 24x7 on-site operator cover. In both locations there is no (or almost no) water piping in the machine rooms. Zürich and Meyrin (where CERN is located) are not in the lowest earthquake risk category, but risk is very low for both sites. Refer to paras. 7 f and g for protective measures to recover from such events.
Both sites are located near the core nodes of the SWITCH backbone in Geneva and Zürich. The underlying DWDM infrastructure allows for the installation of a dedicated gigabit Ethernet channel between both systems. SWITCH has peerings of up to 1 Gbit/s with global transit providers at the TIX and CIXP Internet exchange points in Zürich and at CERN, respectively (http://www.tix.ch/ and http://wwwcs.cern.ch/public/services/cixp/), and with many other co-location carriers at these peering nodes. SWITCH is also part of the community of European educational and research networks connected by the GEANT backbone at 2.5 Gbit/s, which ensures excellent connectivity to the North American educational and research network Internet2 and its peers. The connectivity of the data centers at the SWITCH backbone is fully redundant. Hardware Architecture Scalability or extensibility is another key issue. With the planned differentiation of the ORG name, an additional demand for ORG domain names has to be anticipated. Each component has been foreseen to be scalable. The Gateway, the RRP server and the WHOIS directory service can be scaled by using parallel computer park architectures (clustering). Before moving toward any parallel architecture, the registry will upgrade each single hardware component, allowing approximately a doubling of the specified load. The database is realized with ORACLE ™ software and is extendable using parallel computer parks (clusters) within the proposed concept. The hardware concept uses a gateway and a dedicated RRP server, allowing a smooth transition to EPP. Once the EPP draft recommendations become a proposed standard, the gateway can serve both RRP and EPP servers, which will run in parallel.
Hardware Specifications 2 web servers and 2 gateway servers Reporting and administration server 2 database servers and 2 RRP servers 2 Whois servers
The "unplanned disasters" referenced above result in the failure of the systems at both sites. Otherwise, operation will continue immediately from the second system. C17.2. Registry-registrar model and protocol. Please describe in detail, including a full (to the extent feasible) statement of the proposed RRP and EPP implementations. See also item C22 below.
C17.3. Database capabilities. Database size, throughput,
scalability, procedures for object creation, editing, and deletion, change
notifications, registrar transfer procedures, grace period implementation,
reporting capabilities, etc. Database capabilities Reporting capabilities Procedure for object modification Object creation The "add" command creates objects like domain names or hostnames. The accepted add request is immediately processed on the main database and the registrar is charged for the registered domain name. Object editing All modification commands change the object in the main database after the commands are accepted either by the registry or the registrar. The centralized authority database guarantees data integrity and data consistency. Transfer and other pending requests are served from a request queue, this queue ensures first-come-first-served principles. The 'Renew' command will be immediately processed and be charged to the registrar's account. If a registrar does not renew a domain name before expiration date, an auto-renew is initiated by the registry and the registrar is charged. The expiration date of the domain is extended for one year. The "transfer"command will insert a pending request in the request list. This request list ensures equal treatment of all registrars on a first-come-first-served basis. An e-mail is sent to the losing registrar. The losing registrar can approve or reject the transfer during the transfer pending period. After that period the registry automatically approves the transfer and sends a change notification to the losing registrar. The "delete" command will update the domain
status from registered to registry-hold. During this period the domain
name is no longer in the zone file. The registrar receives a delete notification.
After the delete commands there is a delete pending period. After this
period the domain name will be deleted from the registry database and
the domain name is available for new registration. Grace period The "add grace" period will be 5 days. During the period the following rules are applied (consistent with VeriSign practices): · delete: registrar can delete but is credited
for the registration amount During the renew/extend grace period, 5 days after the renew commands, the following rules are applied (consistent with VeriSign practices): · delete: registrar can delete, the sponsoring
registrar receives a credit of the renew/extend fee The "Auto-renew" grace period will be 45 days. During the auto-renew grace period, the following rules are applied (consistent with VeriSign practices): · delete: the registrar can delete, the registrar
receives a credit for the auto-renew fee The transfer pending period is set to 5 calendar days. During the transfer pending period, the following rules are applied (consistent with VeriSign practices): · Transfer request or renew requests are not
accepted by the registry During the delete pending period the following rules are applied (consistent with VeriSign practices): · Retraction: the registrar can retract the
delete process without costs, by contacting the registry Exceptions for the grace periods If an operation is performed, that falls into more
than one grace period, the actions appropriate for each grace period apply
(with some exceptions as noted below) Overlap Exceptions
C17.5. Zone file distribution and publication. Locations
of nameservers, procedures for and means of distributing zone files to
them. If you propose to employ the VeriSign global resolution and distribution
facilities described in subsection 5.1.5 of the current .org registry
agreement, please provide details of this aspect of your proposal. C17.6. Billing and collection systems. Technical characteristics, system security, accessibility. The default principle is: domain name registrations
can be made until the amount of money on the registrar's bank accounts
and the bank guarantees is reaching the value zero. Each registrar will
be notified if a certain registrar-specific threshold has been reached
(these thresholds can be set by the registrars). Synchronization of the registry system with a dedicated on-site accounting system is ensured by inserting the reporting database between. Reports are required if the number of "payable" transactions counted by the registry system and the amount of money on the registrar's accounts is not consistent or contested. The dedicated on-site accounting systems perform monthly clearings and bookkeeping tasks. Accounting arrangements with each registrar will be made, enabling registrars to use banks in their neighborhood. The reporting database and the dedicated on-site accounting system will provide accounting information for monthly and other reports. This information will be accessible at each registrar services office and registrars can download lists displaying payable and received transactions and access further accounting information from a special individually restricted Web site. C17.7. 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. Data escrow and backup An external data escrow agent receives daily updates of the entire data base and these files can be used as escrow data (see para. 8 below). The zone file is escrowed to a dedicated secondary name server (C) and the manager of this name server acts as escrow agent for the zone file. It should be remembered that ORG is operated on the thin registry model, where the registry has no data on registrants, just domain name, name servers, registrar name and certain time information. C17.8. Publicly accessible look up/Whois service. Address software and hardware, connection speed, search capabilities, coordination with other Whois systems, etc. General information Just to provide an estimate: the system used so far for CH and LI second level names is set up on one computer and can deal with up to 300 WHOIS requests per second. The search engine realized for CH and LI can deal with substrings and presents results within 6 seconds (see https://wwws.nic.ch/reg/domain/searchdomain.cfm). The availability of the registry WHOIS directory service (thin registry concept) will be 99.9%. The thin registry concept employed in the beginning can be changed to a thick registry model if the need arises (see appendix D, Community Concept, for methods to seek input from the ORG community). Coordination with other WHOIS directory services,
such as UWHOIS, is already established for CH and LI and will be extended
for ORG. SWITCH also closely follows developments using SRV records to
locate WHOIS servers, the referral RWHOIS service (RFC-2167) and the WHOIS++
index service. b WHOIS compliance C17.9. System security. Technical and physical capabilities
and procedures to prevent system hacks, break-ins, data tampering, and
other disruptions to operations. Physical security. System security
Physical security of each data center is discussed in section hardware (appendix B, para. 3 and in C.17.1 above), security for each registry service is outlined below. All computers providing WHOIS directory service have software firewalls. The SSL port will be used to separate WHOIS access and internal network. The computers hosting Web sites for registrar related issues will be accessed via HTTPS and login requires individual username and password for each registrar. These computers have restricted IP routing access. The SSL port and a software firewall will be used to distribute and update Web site information. The gateway servers have a restricted IP routing access and provide the SSL connections for the registrars. The RRP server processes only the RRP instruction set with additional improved commands desired from the registrars. All other computers are accessible only locally. The main database, carrying sensible data, can only
be accessed through RRP/EPP server commands. Security for such sensible
data is thus assured and recovery, fault prevention and backup strategies
are described in the corresponding sections below. C17.10. Peak capacities. Technical capability for handling a larger-than-projected demand for registration. Effects on load on servers, databases, back-up systems, support systems, escrow systems, maintenance, personnel. Peak capabilities for larger-than-projected demands The gateways provide SSL connectivity and forward requests to the RRP server. This simple architecture can deal with about 2'000 connections in parallel at any time. Increasing system memory will increase this maximum peak capacity, if required. The RRP server has a queue which is normally empty. This queue will begin to fill up during larger-than-projected peak demands and the time for processing a request will increase. If the number of demands remains high, the computers involved can be upgraded to deal with at least twice the projected demands. Should further demand be encountered, the new registry
will migrate to parallel computer architectures. The database can handle
10 times the current total of ORG domain names (2.7million). A critical
issue is the number of add or modification demands per second. With an
upgrade of the hardware, twice the projected load can be processed. If
demands increase still further, an Oracle cluster can be used for the
main and second databases. With larger-than-projected-demands, the only effect on backup will be increased times and larger files. In the data escrow and backup section (para. 7) an option to change backup systems to larger tape systems for storing more data is mentioned. An online backup system will be used for the databases and since the registration system is available during such tasks, there will be no adverse effects for registrars connected to the registry. The personnel count for registrar services (helpdesk) is calculated according to the number of anticipated trouble tickets, phone calls and e-mails per time and the estimated probability that such requests need to be escalated to back office personnel. Some estimates on average weekly customer-service volumes can be made from the document ".org Metrics Data Package" and this is used for a starting point. For further details see section technical and other supports (para. 11). C17.11. 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. a Registrar services Three registrar services offices, one in Zürich, one in the US, one covering the Asia Pacific region will provide customer care for registrars on a 24/7 basis. These three registrar services will monitor both ORG registries and the worldwide name server network for ORG domain names and serve as first level support for registrars. The headquarters will be located in Zürich, with approximately 12 to 15 FTE's: 8 to 10 for first level support and marketing, 4 to 5 for accounting. The office in Asia will initially be set up with 4 FTE's and the office in the US with 5 to 6 FTE's. Supported languages will be English, Spanish, French, Chinese, Japanese, Portuguese and German, with each office free to offer additional support. Registrars will be able to use financial institutes in their neighborhood. b Back-office services Back-office services will provide expert know-how for in-depth technical problem analysis and accounting issues for the ORG registry. The SWITCH network (NOC) group comprises of 7 persons and will work on all issues related to name servers and the network. The group of system administrators at SWITCH (8 persons) will maintain and upgrade the registration systems and SWITCH security experts (5 persons) will monitor the systems from a security point of view and take action in case of events. Personnel from the CH and LI front- and back-offices can be assigned to ORG on short notice in case of need of human resources (more than 40 persons) and the SWITCH Web design team will provide help setting up Web pages (3 persons). C17.12. Compliance with specifications. Describe the extent of proposed compliance with technical specifications, including compliance with at least the following RFCs: 954, 1034, 1035, 1101, 2181, 2182. The systems will be fully compliant with these RFC's
( see also appendix C) C17.13. System reliability. Define, analyze, and quantify
quality of service. System reliability (QoS) a) Lookup commands to be answered within 3 seconds Quality aspects specified in a), b), c) and d) above will be provided by the system, even for peak capabilities, unless demand is significantly above the projected demands described in para. 4 above. Quality aspects specified in e), f) and g) will be covered with a ticket system for registrar requests and system monitoring tools (see section d) below). C17.14. 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. System outage prevention Redundancy is implemented on an architectural structure
(by multiple systems). In addition to the architectural structure prevention,
each component has a backup for application and data recovery. The possibility
of power failure is covered by multiple UPS on both systems and other
means. All critical components are built with Sun ™ computers. In
the case of failure, an on-site service agreement with Sun will guarantee
to have a technician on the site within 4 hours during working hours.
Both locations have additional technical staff for maintaining or repairing
hardware failures. Data escrow and backup An external data escrow agent receives daily updates of the entire data base and these files can be used as escrow data (see para. 8 below). The zone file is escrowed to a dedicated secondary name server (C) and the manager of this name server acts as escrow agent for the zone file. It should be remembered that ORG is operated on the thin registry model, where the registry has no data on registrants, just domain name, name servers, registrar name and certain time information. Registry failure provisions Other failures of the registry due to physical vulnerabilities are highly unlikely. A failure due to insolvency of the foundation can be neglected due to the non-commercial character of the foundation, sound financial management, multiple sources of income and the public sector interests in the foundation: the Swiss government and eight Swiss cantons are the founders of SWITCH. C17.15. 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. System recovery procedures Recovery procedures are only needed in case of unavailability of both systems. In this case each system has recovery strategies, which have been fully tested on the CH/LI system in use. These strategies guarantee that only the last open transaction will be lost. The critical points for data loss are the centralized databases of each system. SWITCH has technical staff with more than 12 years Oracle ™ database experience. Knowledge of backup and recovery strategies has been carefully built up at SWITCH and the new registry will be able to benefit from that. An example of recovery strategies in the case of all local discs having lost their data: The online backup files are used to recreate the data at the time the backup was performed. The archived log files are then applied and Oracle ™ recovers the data for the period up to the time of the crash. Because the transaction log files are very important, multiple mirroring of these files is required, not only on local, but also on external discs. If both systems fall victim of a majeure force and no hardware can be reused, the following service agreements will be made and the following time statements for restoring the system can be issued:
Registry failure provisions Other failures of the registry due to physical vulnerabilities are highly unlikely. A failure due to insolvency of the foundation can be neglected due to the non-commercial character of the foundation, sound financial management, multiple sources of income and the public sector interests in the foundation: the Swiss government and eight Swiss cantons are the founders of SWITCH.
C18.1. Steps of the proposed transition, including
sequencing and scheduling. Time schedule of the transition with milestones:
C18.2. The duration and extent of any interruption
of any part of the Registry Function. The first number in the list below is the expected time the second is the maximum time for transition, if all transitions proceed as planned. · WHOIS service: 3 hours - up to 1 day Name server: immediately available C18.3. Contingency plans in the event any part of the proposed transition does not proceed as planned. It is anticipated that the data base transition will be a major difficulty. We therefore will commit to a trial run with sample data as soon as possible. Details need to be worked out with the current operator, VeriSign Inc., and we would appreciate their cooperation (see transition plan). It is possible that one or two of the name servers will not be available right after transition but we see no major obstacles in setting up primaries and intend to load the zone prior to the transition to the secondaries (inactive until ICANN/IANA activates the new zone). A trial run is also anticipated for the name server network, the ORG zone will be loaded two weeks before transition. Registry systems: there is already a system in place,
for CH and LI names, and this system simply will be extended and duplicated.
It could be that the new system will not be working at peak load and that
only one system will be available at transition. The measure is then to
have these problems solved within a few weeks. A complete failure of both
systems is not considered (one is working currently). C18.4. The effect of the transition on (a) .org registrants
and (b) Internet users seeking to resolve .org domain names. Effect on ORG registrants Effect on Internet users seeking to resolve ORG
domain names C18.5. The specifics of cooperation required from
VeriSign, Inc. See transition plan. C18.6. Any relevant experience of the applicant and the entities identified in item C13 in performing similar transitions. The ccTLD's CH and LI had a system change in December 1999. Zone file updates were interrupted for several days until the new registry system could provide Web based registration access. C18.7. Any proposed criteria for the evaluation of
the success of the transition. Criteria for a good transition · Start of trial run with data from VeriSign
in November 2002 at the latest. VeriSign have to provide valid registration
data. C19. Please describe in detail mechanisms that you propose to implement to ensure compliance with ICANN-developed policies and the requirements of the registry agreement. Mechanism to ensure compliance with ICANN developed
policies and requirements of the registry agreement If the registry agreement needs to be changed by either party (ICANN or SWITCH), SWITCH enter into negotiations with ICANN to resolve such issues. IV. PROVISIONS FOR EQUIVALENT ACCESS BY ACCREDITED REGISTRARS C20. The selected successor operator for the .org registry will be required to provide all ICANN-accredited registrars having registry-registrar agreements in effect with equivalent access to registry services through a shared registry system, under which those registrars will provide services (either directly or through resellers) to registrants. This section of the .org Proposal covers the applicant's proposed arrangements for interacting with registrars in a manner that provides equivalent access. Provision for equivalent access by accredited registrars The 24/7 hours helpdesks will be accessible also on a non-discriminating basis it will be ensured that all registrars receive help. The three proposed locations of the helpdesk (in Switzerland, Asia and America) will allow for close interaction of registrars with the registry. C21. Describe in detail your proposed methods of providing registry services on an equivalent basis to all accredited registrars having registry-registrar agreements in effect. Your description should include any measures intended to make registration, technical assistance, and other services available to ICANN-accredited registrars in different time zones and relevant languages. In addition, describe the Registry Code of Conduct and other commitments you propose to make to ensure that all such registrars receive equivalent access to registry services. In preparing your response to this item, you may wish to refer to Appendices H and I of the registry agreements ICANN has entered for unsponsored TLDs (e.g., .biz, .com, .info, .name, and .pro). Registry Code of Conduct Registrar services The distributed locations of registrar services allows for registrars to use financial institutes in their neighborhood. Back-office services Back-office services will provide expert know-how for in-depth technical problem analysis and accounting issues for the ORG registry. The SWITCH network (NOC) group comprises of 7 persons and will work on all issues related to name servers and the network. The group of system administrators at SWITCH (8 persons) will maintain ansd upgrade the registration systems and SWITCH security experts (5 persons) will monitor the systems from a security point of view and take action in case of events. Personnel from the CH and LI front- and back-offices can be assigned to ORG on short notice in case of need of human resources (more than 40 persons) and the SWITCH Web design team will provide help setting up Web pages (3 persons). C22. VeriSign, Inc., the current operator of the .org registry uses a registry-registrar protocol (RRP) documented in RFC 2832. At the time of the transition, the selected successor operator will be required to continue to support the RRP (unless a migration of registrars in .org to another protocol has already been completed by that time). In addition, the selected successor operator will be required to implement support for the IETF provreg working group's protocol specification for an Extensible Provisioning Protocol (EPP) no later than 135 days after it is adopted as a Proposed Standard [RFC 2026, section 4.1.1]. Provide a detailed description of your plan for supporting RRP at the time of transition, for supporting EPP within the required time frame, and for providing registrars with a smooth, low-cost migration path from RRP to EPP.
Details and Performance of the RRP implementation The RRP can be divided into informational commands and add/modification commands. The informational commands, such as "check", "describe", "status" and "quit" are processed directly on the RRP server using a lookup table, synchronized with the main Oracle ™ database. The add/modification commands, such as "session", "add", "del", "mod", "renew" and "transfer" will operate on the centralized database. Publically available data from ICANN and VeriSign Inc. show that informational commands (malformed and correct) account for in excess of 98% of the command stream, and data published by ICANN in August 2001 on "add storms" load are reflected by this approach to system design. This allows load distribution on a protocol layer. The response time for the informational commands will be less than the 3 seconds specified for peak loads. For the add/modification commands the response time will be less than the 5 seconds specified for peak loads. Up to 500 informational commands per second can be handled. This means up to 43 million requests per day. The planned maximum peak will be 1'000 requests per second. The system can handle up to 400 modification commands per second. This means up to 34 millions requests per day. The planned maximum peak will be 600 requests per second. For the purposes of understanding the scaling capabilities, the system could handle more than 10 renew requests per day for each of the existing ORG domain name list (approx 2.7m).
SWITCH is aware that RRP is used by many ccTLD registries and its registrars and that RRP is also important for the smooth continuing of operation of many ICANN accredited registrars. SWITCH will license its RRP server to ccTLD registries at no cost, either upon transitioning the ORG registry from RRP to EPP, or at an earlier point in time. Within the proposed registry system the parallel usage of both protocols is foreseen. The gateway server will forward the demands to the parallel operating EPP and RRP servers. An intermix of usage, for example polling from the EPP-protocol, after a transfer request through the RRP protocol has been established, will be assured. The protocol transition is therefore individual for each registrar. For the registrar an extra web-site with hints and a discussion forum for the transition toward EPP will be enabled. An EPP reference client will be posted on the registrar web-site for downloading. Further help on problems discussed in the forum will be provided. The transport layer for EPP is TCP, secured by SSL. C23 and C24. Intentionally omitted.
C25. Describe each Registry Service (as defined in subsection 1.16 of the model .org Registry Agreement) that you propose to provide for a fee. For an example of a description of this type, see <http://www.icann.org/tlds/agreements/name/registry-agmt-appc-1-03jul01.htm>. From http://www.icann.org/tlds/agreements/name/registry-agmt-appc-1-03jul01.htm parts A and B. C26. State the maximum price you propose for each Registry Service identified in item C25. Price cap is USD 5.00 in the start phase. A precise business case cannot be calculated due to uncertainties in the fees collected by ICANN (budget not yet approved). Price to be fixed in consultation with ORG community (see appendix D). C27. Describe each Registry Service (as defined in subsection 1.16 of the model .org Registry Agreement) that you propose to provide without charging a fee. All other transactions (modifications, deletions etc.) and registrar services (helpdesk). C28. Describe the technical performance (including
quality-of-service commitments) you propose to make. See <http://www.icann.org/tlds/agreements/name/registry-agmt-appd-29jun01.htm>
for an example. The successor operator will be expected to meet the Cross-Network
Nameserver Performance Requirements set forth in section 2.1 of the document
at the above URL. System reliability (QoS) j) Lookup commands to be answered within 3 seconds Quality aspects specified in a), b), c) and d) above will be provided by the system, even for peak capabilities, unless demand is significantly above the projected demands described in para. 4 above. Quality aspects specified in e), f) and g) will be covered with a ticket system for registrar requests and system monitoring tools (see section d) below). C29. Intentionally omitted. VI. ENHANCEMENT OF COMPETITION C30. One of ICANN's core principles is the encouragement of competition in the provision of registration services at both the registry and registrar levels. Promotion of that principle will be a criterion. As one illustration of this criterion, a major purpose of the reassignment of the .org registry is to diversify the provision of registry services by placing the .org registry under different operation than the .com and .net registries. Consideration will be given to the extent to which proposed arrangements are consistent with this purpose. As another illustration, applicants are encouraged to refrain from prohibiting non-affiliated providers of backend services from offering their services in connection with other applications. This section of the .org Proposal concerns the effect on competition of the selection of a successor registry operator. C31. Give your analysis of how selecting your application
would affect competition in the provision of registration services at
both the registry and registrar level. C32. State whether the applicant or any entity identified
in item C13 operates a DNS registry having more than 500,000 registered
names and, if so, provide details. None of them operates a registry with more than 500,000 registered names. C33. Describe in detail all affiliations, including
direct or indirect ownership and contractual arrangements (including letters
of intent) for the past, present, or future provision of registry services,
between (a) the applicant or any entity identified in item C13 and (b)
any operator of a DNS registry having more than 500,000 registered names.
VII. RESPONSIVENESS TO THE NONCOMMERCIAL INTERNET USER COMMUNITY C35. Describe in detail the mechanisms you propose for ensuring that the policies and practices followed in your operation of the .org registry are responsive to and supportive of the noncommercial Internet user community, and reflect as much of its diversity as possible. Your description should include any affiliation you propose with representative noncommercial organizations and details (including proposed bylaws or other chartering documents) regarding any governing or advisory groups that you propose. Responsiveness to the non-commercial Internet user
community The process of determining where surplus funds would be allocated would be very expensive and establishing the mechanism could divert much of any surplus available if disputes arose over the decisions. The difficulty of treating such a diverse non-commercial community in a fair and equal manner on the issue of 'good causes' has led SWITCH to propose an independent and neutral approach. This will focus on three major issues: 1. Smooth transition, stable and secure high-quality
service ORG registrants will be reassured that the registration fees will be used to operate the registry in a reliable and efficient manner at lowest cost and that an identity is being created for the non-commercial community. They will not need to worry that their fees are being diverted to possibly unacceptable causes nor to waste time lobbying or arguing where surplus funds are being directed. SWITCH believes that focusing on the provision of a gateway for the non-commercial community, as described under C38, will bring more value to registrants. Any surplus funds made by the operation of the ORG registry will benefit all ORG users by reducing the registration fees.
Evidence of support has proved difficult to obtain in a form that could be submitted at this time. SWITCH believes that it is important seek real input from the diverse areas of the ORG community rather that just obtaining simple endorsements from few ORG registrants. Many of the organisations contacted have also been contacted by other bidders and understandably prefer to remain neutral at this time. Other registrants do not feel that they are well informed enough to make such a decision. Rather than promising benefits to a few ORG registrants, and in keeping with neutral approach of SWITCH, a program has been initiated to informing a broad range .org registrants of the potential benefits and the request for input. The neutral approach to surplus funds and the proposal to build a Community Gateway is being set out and input sought from those who will benefit.
C38. Describe any measures you propose to make to differentiate the .org TLD from TLDs intended for commercial purposes. Your proposal should describe in detail any planned marketing practices designed to differentiate the .org TLD, promote and attract registrations from the global noncommercial community, and minimize defensive and duplicative registrations. Differentiation of ORG Top Level Domain name With the rise of the dotcom culture, there is even
more need to provide an alternative identity for those who wish to have
a non-commercial image which ORG can fulfill. To reach this goal, a credible, independent and neutral approach is required, which can embrace the diversity of the ORG world. While there is no intention to make restrictive registration
policies that exclude any group from registering with ORG, the registry
will be portrayed as the global home for all noncommercial activities. C39. Intentionally omitted. IX. THE VERISIGN ENDOWMENT C40. The current .org registry agreement between ICANN and VeriSign, Inc., states: 5.1.4 No later than 90 days prior to the Expiration
Date, [VeriSign] will pay to ICANN or ICANN's designee the sum of US $5
million, to be used by ICANN in it sole discretion to establish an endowment
to be used to fund future operating costs of the non-profit entity designated
by ICANN as successor operator of the .org registry. [VeriSign] agrees
that such funds, once paid to ICANN, will become the property of ICANN
and/or ICANN's designee, and that [VeriSign] will have no ownership or
other rights or interests in such funds or in the manner in which they
are used or disbursed. C41. Do you propose to seek to qualify to receive
any funds from this endowment? Yes. C41.1. If so, describe in detail how you propose to
use this endowment. Include the commitments you propose to make about
the uses to which the endowment would be put. Explain why those uses are
consistent with the smooth, stable transition and operation of the .org
TLD for the benefit of current and future .org registrants. It is proposed to qualify for USD 1'800'000.00. The
usages are a) building-up the Community infrastructure for registrars
and registrants C41.2. If you propose to seek to qualify to receive the endowment funds, explain why you believe that your proposed use is consistent with the terms of the endowment. "Registry Operator will have no ownership or other rights or interests in such funds or in the manner in which they are used or disbursed". The funds will be devoted to the ORG community. C42-49. Intentionally omitted. X. SUPPORTING DOCUMENTATION C50. The following documentation should be provided in support of your .org Proposal: C50.1. Organizational documents of applicant. A copy
of the organizational documents (articles of association, bylaws, enabling
legislation, etc.) of the applicant. See appendices AA, AB, AC, AD (hard copy), AE (hard copy) and AF. C50.2. Organizational documents of certain other entities. A copy of the organizational documents of each non-profit entity identified in item C13. Not included. C50.3. Business references. A list of significant
trade and credit references of the applicant and each entity identified
in item C13. The applicant is not a commercial entity and is there for not able to supply business references. References from public authorities (governmental) and from educational organizations can be supplied upon request. C50.4. Annual reports. A copy of the most recent annual
financial report (or similar document), if any, of the applicant and each
entity identified in item C13. See appendices AC and AD. C50.5. Evidence of commitment. Any documentation requested
by item C14. See C.14. C50.6. Evidence of community support. Any documentation
requested by item C36. See appendix, Registry Concept, for support from CORE
registrars. By signing this .org Proposal, the undersigned certifies (a) that he or she has authority to do so on behalf of the applicant and, (b) on his or her own behalf and on behalf of the applicant, that all information contained in this proposal, and all documents attached to this proposal, is true and accurate to the best of his/her/its knowledge and information. The undersigned and the applicant understand that any material misstatement or misrepresentation will reflect negatively on the application of which this proposal is a part and may cause cancellation of any delegation of a top-level domain based on that application.
Signature
|
top | ||||||||||||||||||||||||||||||||||||||||||
