Back

24 Shared Registration System (SRS) Performance

gTLDFull Legal NameE-mail suffixDetail
.appTop Level Domain Holdings Limitedgmail.comView
-HIGH-LEVEL SRS SYSTEM DESCRIPTION-
.APP will operate on Minds + Machines’ Espresso registry platform. Espresso’s design is proven to be secure, reliable and robust. The registry infrastructure is specifically configured to handle the high transaction volumes found in the TLD registry business. Espresso’s Shared Registry System (SRS) is an automated production environment dedicated to managing transactions to the registry database from multiple registrars.

The SRS system fully complies with Specification 10 of the registry agreement, including all Service Level Agreements (SLAs).

The EPP interface, Whois service and DNS service are all fully RFC compliant including all RFCs listed in Specification 6 and 10: DNS RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343 and 5966; EPP RFCs 5910, 5730, 5731, 5732, 5733, 5734, 3915 and 3735; DNSSEC RFCs 4033, 4034, 4035, 4509, 4641 and 5155; IDN RFCs 5890, 5891, 5892, 5893; IPv6: RFCs 4472 and 3912. The registry will use anycast DNS networks. Whois and DNS servers are continually updated. Past performance and reliability records, based on service to the .FM domain registry, of the registry’s technical functions enable us to confidently commit to ICANN’s SLAs.

In addition to the core registry services described in Question 23, the registry system provides a comprehensive billing and reporting solution, data escrow services and full Internationalized Domain Name (IDN) support for .APP. Services will be backed by a 24⁄7 help desk and network operations center provided by Minds + Machines.

The registry system uses a distributed architecture (as described in Question 32) that achieves the goals of scalability, reliability and extensibility. The registry system offers redundancy to function even if an entire server were to suffer catastrophic failure (see Question 39). The registry uses load balancers to mitigate hardware failure and assist in scalability. The registryʹs load balancing design allows hardware upgrades without customer impact.

Registry facilities and services will be operated in a minimum of two widely separated geographic locations, providing redundancy and fault tolerance. The primary registry facility is a live facility, meaning that it will be the normal full-time registry. The secondary registry facility is both a functional and standby facility, meaning that it will be activated for primary registry services if operational problems ever arise at the primary facility. The secondary facility is continuously synchronized with the primary. In case of a failover, the secondary site will be enabled to provide registry services such as reporting, daily zone file distribution and operational testing environment (OTE). A third site is used for database backup.

More information about facilities can be found in the answer to Question 34.

The registry system includes firewalls, routers, switches and virtual private network configurations. These are further detailed in the Security section of the application (Questions 30 and 31).

The registry operates multiple database servers to provide redundancy. The primary registry facility houses two database servers: one the main database and the other the secondary. The standby registry facility will house one database server which will be constantly synchronized with the primary registry. The database servers will be replicated but are not load balanced to ensure that there is one authoritative master database.

The SRS configuration and server allocation does not reflect the excessive multitude of servers presented by legacy registries in previous TLD application rounds. Hardware, software, database platforms and architecting have evolved significantly; it is no longer necessary to use dozens of servers to perform one registry function. Because we have access to state of the art systems, we have been able to architect the SRS so that our EPP servers are both business rule engines and protocol servers--less prone to errors and offering more efficient administration.

The Espresso platform is architected for ease of administration, which entails applications other than the registry transaction functions running on the same physical hardware. Currently, registering, updating, and deleting; any and all functions occur through the extensible provisioning protocol (EPP) servers. The software application contains all logic (business and policy) and applies them accordingly. Registrations, management of domains and management of accounts all occur through one application. Administrative changes and updating of business and policy rules are all EPP requests managed through the EPP servers. The registry configuration presented for .APP is greatly over-provisioned for the best-case projected number of registrations. Combined, the Espresso platform is comprises conceptually different pieces: the individual functions will be split into separate servers if the registry reaches a threshold of 25% capacity.

-REPRESENTATIVE NETWORK DIAGRAM-
Please see the attached “Q 24 SRS Overview” for a graphical representation of the SRS.

-NUMBER OF SERVERS-
The number of physical or virtual servers planned for the .APP registry SRS function (not including the DNS function, as fully detailed in the response to Question 35) are as follows:

At the primary location:
-2 Load balancers to listen and direct traffic to EPP servers: one primary, one standby;
-2 Database servers: one primary, one standby;
-2 Application servers to listen for EPP commands from registrars, query the database, and write to the database: one primary, one high availability spare;
-2 Hidden Master server instances for disseminating zone file information: one primary, one standby;
-1 System monitoring server for monitoring the health of servers, performing deep inspection and warning of denial of service and other malicious activities, plus external third party monitoring services;
-2 Whois Server instances to answer on Port 43 for RDDS queries: one primary, one standby
-2 Firewalls: one primary, one high availability spare;
-2 Routers⁄Switches: one primary, one high availability spare;
-2 VPN instances: one primary, one high availability spare;

In addition, a server is made available as an Operational and Testing Environment (OTE).

Technical resources required to run the SRS are adequate, on hand, committed and⁄or readily available.

-DESCRIPTION OF INTERCONNECTIVITY BETWEEN SERVERS-
Each registry instance is configured on a local area network. Servers are connected via redundant multi-homed 1 Gbps Ethernet. Connectivity between the primary and secondary registry facility (for replication) is over an encrypted VPN tunnel.

-FREQUENCY OF SYNCHRONIZATION BETWEEN SERVERS-
Local servers are synchronized constantly using encrypted asynchronous replication to update the database at the secondary facility.

-SYNCHRONIZATION SCHEME (E.G., HOT STANDBY, COLD STANDBY)-
The synchronization scheme is hot standby. The backup server is kept on and ready to failover should the primary database server fail. The secondary facility is also in hot standby. It runs idle, ready to failover should the primary facility be completely disabled. The monitoring system checks the health of the primary facility: if emergency thresholds are met, the system fails-over to the secondary facility.

-SYSTEM ENVIRONMENTS AVAILABLE-
Registrars are provided with an OTE to test connectivity and EPP schema, an automated production environment (both via EPP and web-based graphical user interface (GUI)) and a demonstration system for training.

-DOMAIN NAME PROVISIONING SERVICE TYPE-
The registry system is EPP with software code development specifically targeted to meet ICANN’s new gTLD requirements. A GUI for administrative use and for registrars that have yet to integrate via EPP is available and provides all functions available via the EPP interface.

-REGISTRAR TOOLKITS AVAILABLE-
Registrar tool kits (EPP schema made available to Registrars to shorten development time and ensure accurate communications) will be made available for download from the Registry Administration site, as is standard across most TLDs. Special EPP extensions are also made available for registrar implementation.

-WHOIS SERVICE-
The Whois service is RFC 3912 compliant. The registry administrator may determine what information is displayed through the Whois server depending on additional policies established for the TLD.

-WHOIS CHECK SERVICE-
The Whois check service is RFC 3912 compliant. It accepts and returns ASCII queries. In anticipation of rapid adoption of IDNs, we also have a unicode-enabled Whois service allowing for querying and display of non-Roman characters. The Whois service also meets ICANN’s new gTLD “thick registry” requirements (where the registry collects registrant data and must provide Whois, rather than only the registrar providing Whois) and IP ranges can be black- or white-listed for specified lookup limits.

-REGISTRY PORTAL WEB APPLICATION-
The web portal is intuitive, easy to use and every registry function is accessible. For example, the Whois service is easily configured via the GUI.

-REGISTRY DATABASE-
The Registry database is fully scalable and over-provisioned to meet the requirements of our highest projected registration volumes. The registry database has 60 times the transactional capability required by registries of 1.25 million domains. When greater transaction capabilities are required, the system will be reconfigured to split out separate functions onto multiple protocol servers.

-DNS SERVICE-
We have contracted with Packet Clearing House (PCH) for DNS services. PCH complies with the RFCs as listed in Specification 6 and 10. The DNS uses BIND and is configured to respond to queries over TCP, UDP and all IANA-recognized DNS resource record types. Access to DNS servers over IPv6 is possible through enabled dual-stack IPv4⁄IPv6 connectivity. PCH utilizes anycast technology, which enables zero downtime as traffic can be redirected to alternate locations if local servers are overloaded or unavailable. PCH has provided Minds + Machines, our outsourced Registry Service Provider, with SLAs guaranteeing 100% uptime, with a twenty-year history proving 100% reliability.

-REGISTRY SUPPORT-
Critical support is available 24⁄7 with on-call technicians responding immediately upon notification. Support staff may be reached via telephone, email, or SMS.

-DISASTER RECOVERY SERVICES (BUSINESS CONTINUITY)-
Registry continuity in compliance with Specification 6 is assured through high availability and highly redundant network operations and is detailed in Question 39. In case of a physical disaster, anycast DNS and hot swapping to off-site registry mirror ensures no interruption to services. Regular off-site backups and escrow deposits ensure integrity of data. Our registry continuity plan follows ICANN’s specifications and is tested regularly (as described in the answer to Question 39). In case of business failure, we also have in place mutual registry transition agreements with an alternate registry operator to ensure an uninterrupted, smooth transition of registry operations (as described in the answer to Question 40).

-SERVICE LEVEL AGREEMENT-
We will meet or exceed the SLAs required by ICANN and outlined in Specification 10 (Registry Performance Specifications) as evidenced by our current operational record of the .FM registry. Anycast DNS, high availability, redundancy and an off-site mirror ensure that SLAs will be met.

-WILDCARD PROHIBITION-
The registry will return a “Name Error” response for any domain names which are either not registered, do not have valid NS records or the status does not allow them to be published in the DNS, as prescribed in RFCs 1034 and 4592. Wildcarding will not be implemented in the registry.

-ICANN REPORTING-
The registry system outputs and submits all required reports to ICANN, including monthly the Per-Registrar Transaction Report and Registry Functions Activity Report as defined in Specification 3.

-IDNA2008 COMPLIANT-
The registry software is IDNA2008 compliant. It accepts xn--registrations into the database. The registry allows input of non-ASCII characters into “local language” registrant fields.

-IPV6 ENABLED-
The registry supports and resolves IPv6 records in the host fields.

-DNSSEC-
DNSSEC will be implemented and TLD zones will be signed in compliance with RFCs 4033, 4034, 4035, 4509 and 5155 and their successors. Key signature storage and processing methodologies have been developed and implemented at registry level.

-SETUP OF ESCROW SERVICES-
The registry operator will provide compressed, encrypted and signed secure data file transfers (SFTP) to the outsourced escrow agent on a daily and weekly basis and will validate every file within 24 hours. All requirements detailed in Specification 2 will be met.

-SETUP OF MANAGED DNS SERVICES-
Zone files will be disseminated through DNS via BIND. DNS system performance tests will show network availability, server and load capacity, query latency, reachability and transaction capability. DNSSEC support, including the full life cycle of KSK and ZSK keys will be proven. Since the DNS system is already operational and used by more than 19 different TLDs, setting up managed DNS services is a routine task for PCH staff.

-OBTAINING IANA DELEGATION-
All requirements for delegation will be satisfied, including adherence to relevant ICP-1 instructions.

-ON-GOING MANAGED DOMAIN NAME REGISTRY SERVICES-
Day-to-day operations of the TLD once it is set up involve several aspects of DNS: technical, administrative, support, financial and policy. From a technical perspective, all hardware and software on the system will be maintained and updated regularly. Monitoring of system stability and security occurs constantly. Escrow deposits will be made on a daily basis and ICANN reports will be submitted when required. Registrar relations will be managed, including OTE, EPP and Whois support. Specialized accounting and traffic reports will be produced and shared with relevant parties required for business operation and systems maintenance. Required configuration updates or changes will be made. Consensus or temporary policy changes enacted by ICANN will be incorporated into the system.

Question 31, is a summary of responses to Questions 32-44. All staff necessary for critical registry services and vital business operations only a registry service provider can provide are listed below and described in the attachment “Q 24 Staff.” In the response to each specific question that follows, allocation of resources for each function is noted and described.

-RESOURCING PLANS-
We are outsourcing registry service provision to Minds + Machines. This response lists the personnel in their registry operation. For complete descriptions of each position, please refer to attachment “Q 24 Staff.”
CEO
CFO
CMO
CTO
VP Policy
VP Client Services
VP Corporate Development
Director Legal Affairs
Compliance Administrator
Controller
Registrar Liaison
Registrar Cust Svc Admin 1
Registrar Cust Svc Admin 2
Registrar Cust Svc Tech 1
Registrar Cust Svc Tech 2
Network Ops Manager
Network Engineer 1
Network Engineer 2
Network Engineer 3
Espresso Application Developer
Espresso Application Developer 2
Espresso Application Developer 3
Database Developer
Database Developer 2
Information Security Officer
Database Administrator
Database Administrator 2
Marketing Manager
Public Relations Associate
IT Support Specialist
Executive Assistant
Office Manager
Network Architect
Ombudsperson

-DNS: PCH-
PCH’s technical advisory board sets strategic direction, provides expertise to make specific projects possible and drives them forward. Each member has built major Internet exchanges or backbone networks and together they provide a basis of operational experience that spans more than twenty years of Internet development around the world.

PCH Staff
All PCH staff members are listed in Question 35.

-NCC (Escrow)-
NCC’s resourcing information is described in detail in our answer to Question 38.

-Secondary NOC-
The Secondary NOC (hot standby) site is managed by Tucows. NOC staff that manage the Tucows facility in Brampton, CA also monitor and manage Minds + Machines’ secondary failover NOC. Our use of the term ʺNetwork Operations Center (NOC)ʺ indicates the co-location facility where the hardware is stored; i.e. the datacenter.


For complete information about Tucows’ staff and staffing procedures, please see attachment “Q 24 Staff.”
gTLDFull Legal NameE-mail suffixDetail
.spaTop Level Domain Holdings Limitedgmail.comView
.SPA will operate on Minds + Machines’ Espresso registry platform. Espresso’s design is proven to be secure, reliable and robust. The registry infrastructure is specifically configured to handle the high transaction volumes found in the TLD registry business. Espresso’s Shared Registry System (SRS) is an automated production environment dedicated to managing transactions to the registry database from multiple registrars.

The SRS system fully complies with Specification 10 of the registry agreement, including all Service Level Agreements (SLAs).

The EPP interface, Whois service and DNS service are all fully RFC compliant including all RFCs listed in Specification 6 and 10: DNS RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343 and 5966; EPP RFCs 5910, 5730, 5731, 5732, 5733, 5734, 3915 and 3735; DNSSEC RFCs 4033, 4034, 4035, 4509, 4641 and 5155; IDN RFCs 5890, 5891, 5892, 5893; IPv6: RFCs 4472 and 3912. The registry will use anycast DNS networks. Whois and DNS servers are continually updated. Past performance and reliability records, based on service to the .FM domain registry, of the registry’s technical functions enable us to confidently commit to ICANN’s SLAs.

In addition to the core registry services described in Question 23, the registry system provides a comprehensive billing and reporting solution, data escrow services and full Internationalized Domain Name (IDN) support for .SPA. Services will be backed by a 24⁄7 help desk and network operations center provided by Minds + Machines.

The registry system uses a distributed architecture (as described in Question 32) that achieves the goals of scalability, reliability and extensibility. The registry system offers redundancy to function even if an entire server were to suffer catastrophic failure (see Question 39). The registry uses load balancers to mitigate hardware failure and assist in scalability. The registryʹs load balancing design allows hardware upgrades without customer impact.

Registry facilities and services will be operated in a minimum of two widely separated geographic locations, providing redundancy and fault tolerance. The primary registry facility is a live facility, meaning that it will be the normal full-time registry. The secondary registry facility is both a functional and standby facility, meaning that it will be activated for primary registry services if operational problems ever arise at the primary facility. The secondary facility is continuously synchronized with the primary. In case of a failover, the secondary site will be enabled to provide registry services such as reporting, daily zone file distribution and operational testing environment (OTE). A third site is used for database backup.

More information about facilities can be found in the answer to Question 34.

The registry system includes firewalls, routers, switches and virtual private network configurations. These are further detailed in the Security section of the application (Questions 30 and 31).

The registry operates multiple database servers to provide redundancy. The primary registry facility houses two database servers: one the main database and the other the secondary. The standby registry facility will house one database server which will be constantly synchronized with the primary registry. The database servers will be replicated but are not load balanced to ensure that there is one authoritative master database.

The SRS configuration and server allocation does not reflect the excessive multitude of servers presented by legacy registries in previous TLD application rounds. Hardware, software, database platforms and architecting have evolved significantly; it is no longer necessary to use dozens of servers to perform one registry function. Because we have access to state of the art systems, we have been able to architect the SRS so that our EPP servers are both business rule engines and protocol servers--less prone to errors and offering more efficient administration.

The Espresso platform is architected for ease of administration, which entails applications other than the registry transaction functions running on the same physical hardware. Currently, registering, updating, and deleting; any and all functions occur through the extensible provisioning protocol (EPP) servers. The software application contains all logic (business and policy) and applies them accordingly. Registrations, management of domains and management of accounts all occur through one application. Administrative changes and updating of business and policy rules are all EPP requests managed through the EPP servers. The registry configuration presented for .SPA is greatly over-provisioned for the best-case projected number of registrations. Combined, the Espresso platform is comprises conceptually different pieces: the individual functions will be split into separate servers if the registry reaches a threshold of 25% capacity.

-REPRESENTATIVE NETWORK DIAGRAM-
Please see the attached “Q 24 SRS Overview” for a graphical representation of the SRS.

-NUMBER OF SERVERS-
The number of physical or virtual servers planned for the .SPA registry SRS function (not including the DNS function, as fully detailed in the response to Question 35) are as follows:

At the primary location:
-2 Load balancers to listen and direct traffic to EPP servers: one primary, one standby;
-2 Database servers: one primary, one standby;
-2 Application servers to listen for EPP commands from registrars, query the database, and write to the database: one primary, one high availability spare;
-2 Hidden Master server instances for disseminating zone file information: one primary, one standby;
-1 System monitoring server for monitoring the health of servers, performing deep inspection and warning of denial of service and other malicious activities, plus external third party monitoring services;
-2 Whois Server instances to answer on Port 43 for RDDS queries: one primary, one standby
-2 Firewalls: one primary, one high availability spare;
-2 Routers⁄Switches: one primary, one high availability spare;
-2 VPN instances: one primary, one high availability spare;

In addition, a server is made available as an Operational and Testing Environment (OTE).

Technical resources required to run the SRS are adequate, on hand, committed and⁄or readily available.

-DESCRIPTION OF INTERCONNECTIVITY BETWEEN SERVERS-
Each registry instance is configured on a local area network. Servers are connected via redundant multi-homed 1 Gbps Ethernet. Connectivity between the primary and secondary registry facility (for replication) is over an encrypted VPN tunnel.

-FREQUENCY OF SYNCHRONIZATION BETWEEN SERVERS-
Local servers are synchronized constantly using encrypted asynchronous replication to update the database at the secondary facility.

-SYNCHRONIZATION SCHEME (E.G., HOT STANDBY, COLD STANDBY)-
The synchronization scheme is hot standby. The backup server is kept on and ready to failover should the primary database server fail. The secondary facility is also in hot standby. It runs idle, ready to failover should the primary facility be completely disabled. The monitoring system checks the health of the primary facility: if emergency thresholds are met, the system fails-over to the secondary facility.

-SYSTEM ENVIRONMENTS AVAILABLE-
Registrars are provided with an OTE to test connectivity and EPP schema, an automated production environment (both via EPP and web-based graphical user interface (GUI)) and a demonstration system for training.

-DOMAIN NAME PROVISIONING SERVICE TYPE-
The registry system is EPP with software code development specifically targeted to meet ICANN’s new gTLD requirements. A GUI for administrative use and for registrars that have yet to integrate via EPP is available and provides all functions available via the EPP interface.

-REGISTRAR TOOLKITS AVAILABLE-
Registrar tool kits (EPP schema made available to Registrars to shorten development time and ensure accurate communications) will be made available for download from the Registry Administration site, as is standard across most TLDs. Special EPP extensions are also made available for registrar implementation.

-WHOIS SERVICE-
The Whois service is RFC 3912 compliant. The registry administrator may determine what information is displayed through the Whois server depending on additional policies established for the TLD.

-WHOIS CHECK SERVICE-
The Whois check service is RFC 3912 compliant. It accepts and returns ASCII queries. In anticipation of rapid adoption of IDNs, we also have a unicode-enabled Whois service allowing for querying and display of non-Roman characters. The Whois service also meets ICANN’s new gTLD “thick registry” requirements (where the registry collects registrant data and must provide Whois, rather than only the registrar providing Whois) and IP ranges can be black- or white-listed for specified lookup limits.

-REGISTRY PORTAL WEB APPLICATION-
The web portal is intuitive, easy to use and every registry function is accessible. For example, the Whois service is easily configured via the GUI.

-REGISTRY DATABASE-
The Registry database is fully scalable and over-provisioned to meet the requirements of our highest projected registration volumes. The registry database has 60 times the transactional capability required by registries of 1.25 million domains. When greater transaction capabilities are required, the system will be reconfigured to split out separate functions onto multiple protocol servers.

-DNS SERVICE-
We have contracted with Packet Clearing House (PCH) for DNS services. PCH complies with the RFCs as listed in Specification 6 and 10. The DNS uses BIND and is configured to respond to queries over TCP, UDP and all IANA-recognized DNS resource record types. Access to DNS servers over IPv6 is possible through enabled dual-stack IPv4⁄IPv6 connectivity. PCH utilizes anycast technology, which enables zero downtime as traffic can be redirected to alternate locations if local servers are overloaded or unavailable. PCH has provided Minds + Machines, our outsourced Registry Service Provider, with SLAs guaranteeing 100% uptime, with a twenty-year history proving 100% reliability.

-REGISTRY SUPPORT-
Critical support is available 24⁄7 with on-call technicians responding immediately upon notification. Support staff may be reached via telephone, email, or SMS.

-DISASTER RECOVERY SERVICES (BUSINESS CONTINUITY)-
Registry continuity in compliance with Specification 6 is assured through high availability and highly redundant network operations and is detailed in Question 39. In case of a physical disaster, anycast DNS and hot swapping to off-site registry mirror ensures no interruption to services. Regular off-site backups and escrow deposits ensure integrity of data. Our registry continuity plan follows ICANN’s specifications and is tested regularly (as described in the answer to Question 39). In case of business failure, we also have in place mutual registry transition agreements with an alternate registry operator to ensure an uninterrupted, smooth transition of registry operations (as described in the answer to Question 40).

-SERVICE LEVEL AGREEMENT-
We will meet or exceed the SLAs required by ICANN and outlined in Specification 10 (Registry Performance Specifications) as evidenced by our current operational record of the .FM registry. Anycast DNS, high availability, redundancy and an off-site mirror ensure that SLAs will be met.

-WILDCARD PROHIBITION-
The registry will return a “Name Error” response for any domain names which are either not registered, do not have valid NS records or the status does not allow them to be published in the DNS, as prescribed in RFCs 1034 and 4592. Wildcarding will not be implemented in the registry.

-ICANN REPORTING-
The registry system outputs and submits all required reports to ICANN, including monthly the Per-Registrar Transaction Report and Registry Functions Activity Report as defined in Specification 3.

-IDNA2008 COMPLIANT-
The registry software is IDNA2008 compliant. It accepts xn--registrations into the database. The registry allows input of non-ASCII characters into “local language” registrant fields.

-IPV6 ENABLED-
The registry supports and resolves IPv6 records in the host fields.

-DNSSEC-
DNSSEC will be implemented and TLD zones will be signed in compliance with RFCs 4033, 4034, 4035, 4509 and 5155 and their successors. Key signature storage and processing methodologies have been developed and implemented at registry level.

-SETUP OF ESCROW SERVICES-
The registry operator will provide compressed, encrypted and signed secure data file transfers (SFTP) to the outsourced escrow agent on a daily and weekly basis and will validate every file within 24 hours. All requirements detailed in Specification 2 will be met.

-SETUP OF MANAGED DNS SERVICES-
Zone files will be disseminated through DNS via BIND. DNS system performance tests will show network availability, server and load capacity, query latency, reachability and transaction capability. DNSSEC support, including the full life cycle of KSK and ZSK keys will be proven. Since the DNS system is already operational and used by more than 19 different TLDs, setting up managed DNS services is a routine task for PCH staff.

-OBTAINING IANA DELEGATION-
All requirements for delegation will be satisfied, including adherence to relevant ICP-1 instructions.

-ON-GOING MANAGED DOMAIN NAME REGISTRY SERVICES-
Day-to-day operations of the TLD once it is set up involve several aspects of DNS: technical, administrative, support, financial and policy. From a technical perspective, all hardware and software on the system will be maintained and updated regularly. Monitoring of system stability and security occurs constantly. Escrow deposits will be made on a daily basis and ICANN reports will be submitted when required. Registrar relations will be managed, including OTE, EPP and Whois support. Specialized accounting and traffic reports will be produced and shared with relevant parties required for business operation and systems maintenance. Required configuration updates or changes will be made. Consensus or temporary policy changes enacted by ICANN will be incorporated into the system.

Question 31, is a summary of responses to Questions 32-44. All staff necessary for critical registry services and vital business operations only a registry service provider can provide are listed below and described in the attachment “Q 24 Staff.” In the response to each specific question that follows, allocation of resources for each function is noted and described.

-RESOURCING PLANS-
We are outsourcing registry service provision to Minds + Machines. This response lists the personnel in their registry operation. For complete descriptions of each position, please refer to attachment “Q 24 Staff.”
CEO
CFO
CMO
CTO
VP Policy
VP Client Services
VP Corporate Development
Director Legal Affairs
Compliance Administrator
Controller
Registrar Liaison
Registrar Cust Svc Admin 1
Registrar Cust Svc Admin 2
Registrar Cust Svc Tech 1
Registrar Cust Svc Tech 2
Network Ops Manager
Network Engineer 1
Network Engineer 2
Network Engineer 3
Espresso Application Developer
Espresso Application Developer 2
Espresso Application Developer 3
Database Developer
Database Developer 2
Information Security Officer
Database Administrator
Database Administrator 2
Marketing Manager
Public Relations Associate
IT Support Specialist
Executive Assistant
Office Manager
Network Architect
Ombudsperson

-DNS: PCH-
PCH’s technical advisory board sets strategic direction, provides expertise to make specific projects possible and drives them forward. Each member has built major Internet exchanges or backbone networks and together they provide a basis of operational experience that spans more than twenty years of Internet development around the world.

PCH Staff
All PCH staff members are listed in Question 35.

-NCC (Escrow)-
NCC’s resourcing information is described in detail in our answer to Question 38.

-Secondary NOC-
Our use of the term ʺNetwork Operations Center (NOC)ʺ indicates the co-location facility where the hardware is stored; i.e. the datacenter. The Secondary NOC (hot standby) site is managed by Tucows. NOC staff that manage the Tucows facility in Brampton, CA also monitor and manage Minds + Machines’ secondary failover NOC.

For complete information about Tucows’ staff and staffing procedures, please see attachment “Q 24 Staff.”