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.
High level description of the .kids Registry functional specification
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.
Registration 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.
Registrar and Customer Support Subsystem
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.
Zone Generation Subsystem
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.
Whois Subsystem
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:
Domain name
Registrar
Registrar Whois
SLD Holder name and address
SLD Holder contact information (admin and technical)
Nameservers
Update date
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.
Reporting and Batch Processes Subsystem
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.
Rating subsystem
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.
Miscellaneous sections
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.7
Data backup and escrow – Comdisco will be performing daily incremental backups
of the system along with full backups of the database.
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