Section 3 – Technical Capabilities and Plan
D.14 The third section of the Registry Operator's Proposal is a description of the registry operator's 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. The topics listed below are representative of the type of subjects that will be covered in the Technical Capabilities and Plan section of the Registry Operator's Proposal.
The following sections will attempt to cover all the questions and points raised in the D.14 section and D.15 subsections. We will cover the business rules of the .kids Registry system, the software components and finally the production system and the operations of the .kids Registry system.
DotKids, Inc. has selected SARAF Software Solutions RegyStar system as the basic engine for the .kids Registry system. SARAF will work with us to customize the RegyStar™ system to tailor the core engine to our specific requirements. The SARAF team will perform all customization development of the software and all future technical support and future enhancements. SARAF team brings a wealth of experience in the domain registration system arena. They have been involved with a number of Registrars along with the NSI Registry system. One of the SARAF team is the co-author of the existing RRP protocol.
For the .kids Registry operations, DotKids, Inc. has selected Comdisco Inc., to be the data center for hosting the production systems, operating of the production systems including the generation and distribution of the .kids zone files.
This section provides a high level description of the .kids Registry model, the functional specifications, and business rules. This .kids Registry is composed of a number of subsystems: the Registration subsystem, the Registrar and customer support subsystem, the zone generation subsystem, the Whois subsystem and finally the reporting and batch processes subsystem.
The Registration subsystem manages the domain registration in the .kids Registry TLD. Registrars connect to this subsystem to submit their domain registration requests by creating a TCP/IP over SSL session with the .kids Registry.
The .kids Registry is proposed to be a “fat” or “thick” Registry model. This implies that the .kids Registry database system will store the information of the SLD holder of the domain and the contacts (admin and technical) of the SLD holder along with the information of the Registrar who registered the domain (refer to the .kids Registry data dictionary – appendix VII j).
Registrars will be communicating with the .kids Registry by submitting domain registration related requests using the proposed domain registration XML (see Appendix VII b). Registrars first create a session with the .kids Registry using open standards TCP/IP connection over SSL. The TCP/IP SSL connection is a two-way handshake between the .kids Registry and the Registrars. Once a connection is successfully established, Registrars continue submitting requests to the .kids Registry until they end the connection session by issuing a quit request. Registrars can submit add, modify, delete, query, renew, transfer, and check commands. The add, modify, delete, and query commands apply to domain, nameserver, contact, and SLD holder entities. The check command applies to the domain and nameserver entities while the renew and transfer commands apply to the domain entity only.
Registrars may submit more than one request per one XML document. The requests are processed one at a time by the .kids Registry. The .kids Registry however, returns one XML response document to the Registrar with listing the outcome of the execution of the different commands.
The .kids Registry system will offer the following functionality:
1. Registration – allowing ICANN accredited Registrars to register domains in the .kids TLD. The domain registration is based on a prepayment model where Registrars are charged with the registration fee at the time the registration is executed. Registrars can also register nameservers in .kids TLD and in other TLDs.
2. Maintenance – allowing ICANN Accredited Registrars to maintain domains and nameservers already registered. Maintenance includes functionality such as domain/nameserver modification, deletion, querying of the domain/nameserver attributes. Registrars can also renew the registration of a domain. A Registrar can only submit these requests on domains that are registered by that Registrar. A Registrar cannot modify/renew/delete/query a domain that is registered by another Registrar.
3. Check availability – allowing Registrars to check for the availability of a domain or nameserver.
4. Transfer of domains – allowing Registrars to submit requests to transfer a domain from another Registrar. Domain transfers results in an automatic one year renewal of the domain requested for transfer. The .kids Registry will implement similar transfer process as the existing process of the NSI Registry.
5. Maintenance of SLD Holder contacts – allowing Registrars to register new contacts, query, modify and delete existing contacts. A Registrar can only modify and delete contacts that are created by the Registrar. Registrars can use contacts created by other Registrars.
6. Maintenance of SLD Holder – allowing Registrars to modify and query existing SLD holder information. A Registrar can only modify SLD Holder information created by the Registrar.
Registrars registering in the .kids Registry will have a web-based tool allowing them to perform the functionality mentioned in the Registration subsystem except for the add functionality.
Through the Registrar web based tool, Registrar will also have the capability to download daily transaction file and weekly data synchronization files. These files will contain Registrar data to allow Registrars to sync their database with that of the .kids Registry.
DotKids, Inc. will have its own in-house customer support team. The support team will be responsible for first and to a lesser degree second level support. Technical support (second and third level support) will be provided by the SARAF team. DotKids, Inc. will have a dedicated team of SARAF software developers committed to the .kids Registry.
Comdisco will provide support related to the .kids Registry operations, communication, and system support. We will include a profile of the Comdisco support team in the operations document to be submitted later, see above).
DotKids, Inc. will implement a problem reporting escalation process. We will be providing ICANN with the details of the SLA that will be proposed by the .kids Registry to the Registrars. This is still under finalization with the SARAF and Comdisco teams.
The DotKids, Inc. customer support will use a web based tool to track issues reported by the Registrars and to provide support to Registrars. The DotKids, Inc. support team will be able to perform all the functionality mentioned in the Registration subsystem except for the add functionality.
The .kids Registry will generate the zone file at least at the same frequency as the current NSI Registry, i.e. twice a day. The .kids Registry system will review the process of generating zone files on a more frequent basis, ideally culminating in a more dynamic zone generation process. DotKids, Inc. will provide more detailed information regarding the generation and distribution of the .kids zone files in the operations document.
The .kids Registry will provide Whois service to the Registrars and the public. Since the .kids Registry is based on the “fat” or “thick” model, the .kids Whois server will provide the following information:
SLD Holder name and address
SLD Holder contact information (admin and technical)
The .kids Registry will also be sensitive to privacy issue and is in the process of reviewing the added functionality of allowing Registrars to flag information as non-Whois publishable.
There will be some maintenance batch processes. Since the .kids Registry is basing some of its procedures on the existing NSI Registry model (such as transfers notification, domain deletion after a specific hold period, …); the .kids Registry will develop a number of batch processes to implement these procedures.
Since it is difficult to cover all the reporting requirements of the different Registrars, the .kids Registry proposes to solve the reporting requirement by providing each Registrar’s with their raw data on a weekly basis. Each Registrar will be given access to a secure FTP site where the Registrar will have the capability to download the raw data. The data can either be in a common format such as comma delimited format or an XML based format. The files will remain for a period of four weeks allowing the Registrars ample time to download their files.
The .kids Registry will also develop a subsystem that interfaces with the different accredited international rating organizations. DotKids, Inc. will work with the rating organizations to help in defining a common interface to notify the .kids Registry whenever a domain is newly rated, a rating has changed, or a rating is invalidated.
Logging and Auditing
The .kids Registry system will be logging all incoming request along with the result whether the request is successfully executed or not. .kids Registry will maintain archives of the log files for auditing purposes. Each logged message will have a timestamp indicating the date and time the request was received. There will be other information stored in each log message that will help the .kids Registry team in identifying the source and the entity that performed or submitted the request.
At the database level, .kids Registry will store a history of the changes that are made to entities stored in the database. The history information will allow the .kid Registry recreate the series of transactions that are performed on a specific entity.
D15.2.6 Billing and Collection - the .kids Registry system is based on a prepayment model. Registrars must have a positive balance with the Registry in order to perform domain registrations. It will be the Registrar responsibility to ensure that adequate funds are available for their domain registration needs. The availability of funds will be handled by the DotKids, Inc. accounting and legal departments. They will have the capability of adjusting a Registrar balance in the .kids database to allow for the Registrar to perform registrations. The Registry software will adjust a Registrar balance every time a domain registration is performed, or when a deletion, renewal or any other Registry transaction is performed that has a fee attached to it.
DotKids, Inc. is still working with Comdisco to finalize the requirements for the .kids Registry production systems. We have attached Comdisco proposal along with their SLA and a letter of intent from Comdisco.
As mentioned above, we will be using Comdisco for our production and operations of the .kids Registry.
Comdisco proposal (appendix VII h) covers our solution to the following subsections:
D15.2.9 System security – refer to Comdisco’s proposal.
D15.2.10 Peak capacity – we are also considering using Comdisco’s At-Time-Of-Peak (ATOP) Service that provides added server capacity during seasonal peak periods.
D15.2.11 System reliability – refer to Comdisco’s proposal for hardware and system software reliability. For the .kids Registry registration software, .kids will be using SARAF QA department to perform system functionality testing, load testing and performance testing.
D15.2.12 System outage prevention – refer to Comdisco proposal