gTLD	Full Legal Name	E-mail suffix	Detail
.VIG	VIENNA INSURANCE GROUP AG Wiener Versicherung Gruppe	sedari.com	View

Answers for this question (#24) are provided directly from Afilias, the back-end provider of registry services for this TLD.

THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉”
CHARACTERS), WHICH ICANN INFORMS US (CASE ID 11027) CANNOT BE PROPERLY
RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE, THE FULL ANSWER TO
THIS QUESTION IS ATTACHED AS A PDF FILE, ACCORDING TO SPECIFIC
GUIDANCE FROM ICANN UNDER CASE ID 11027.

Afilias operates a state-of-the-art EPP-based Shared Registration System (SRS) that is secure, stable and reliable. The SRS is a critical component of registry operations that must balance the business requirements for the registry and its customers, such as numerous domain acquisition and management functions. The SRS meets or exceeds all ICANN requirements given that Afilias:
• Operates a secure, stable and reliable SRS which updates in real-time and in full compliance with Specification 6 of the new gTLD Registry Agreement;
• Is committed to continuously enhancing our SRS to meet existing and future needs;
• Currently exceeds contractual requirements and will perform in compliance with Specification 10 of the new gTLD Registry Agreement;
• Provides SRS functionality and staff, financial, and other resources to more than adequately meet the technical needs of this TLD, and;
• Manages the SRS with a team of experienced technical professionals who can seamlessly integrate this TLD into the Afilias registry platform and support the TLD in a secure, stable and reliable manner.
Description of operation of the SRS, including diagrams
Afilias’ SRS provides the same advanced functionality as that used in the .INFO and .ORG registries, as well as the fourteen other TLDs currently supported by Afilias. The Afilias registry system is standards-compliant and utilizes proven technology, ensuring global familiarity for registrars, and it is protected by our massively provisioned infrastructure that mitigates the risk of disaster.
EPP functionality is described fully in our response to question #25; please consider those answers incorporated here by reference. An abbreviated list of Afilias SRS functionality includes: • Domain registration: Afilias provides registration of names in the TLD, in both ASCII and IDN forms, to accredited registrars via EPP and a web-based administration tool.
• Domain renewal: Afilias provides services that allow registrars the ability to renew domains under sponsorship at any time. Further, the registry performs the automated renewal of all domain names at the expiration of their term, and allows registrars to rescind automatic renewals within a specified number of days after the transaction for a full refund.
• Transfer: Afilias provides efficient and automated procedures to facilitate the transfer of sponsorship of a domain name between accredited registrars. Further, the registry enables bulk transfers of domains under the provisions of the Registry-Registrar Agreement.
• RGP and restoring deleted domain registrations: Afilias provides support for the Redemption Grace Period (RGP) as needed, enabling the restoration of deleted registrations.
• Other grace periods and conformance with ICANN guidelines: Afilias provides support for other grace periods that are evolving as standard practice inside the ICANN community. In addition, the Afilias registry system supports the evolving ICANN guidelines on IDNs.
Afilias also supports the basic check, delete, and modify commands.
As required for all new gTLDs, Afilias provides “thick” registry system functionality. In this model, all key contact details for each domain are stored in the registry. This allows better access to domain data and provides uniformity in storing the information.
Afilias’ SRS complies today and will continue to comply with global best practices including relevant RFCs, ICANN requirements, and this TLD’s respective domain policies. With over a decade of experience, Afilias has fully documented and tested policies and procedures, and our highly skilled team members are active participants of the major relevant technology and standards organizations, so ICANN can be assured that SRS performance and compliance are met. Full details regarding the SRS system and network architecture are provided in responses to questions #31 and #32; please consider those answers incorporated here by reference.
SRS servers and software
All applications and databases for this TLD will run in a virtual environment currently hosted by a cluster of servers equipped with the latest Intel Westmere multi-core processors. (It is possible that by the time this application is evaluated and systems deployed, Westmere processors may no longer be the “latest”; the Afilias policy is to use the most advanced, stable technology available at the time of deployment.) The data for the registry will be stored on storage arrays of solid state drives shared over a fast storage area network. The virtual environment allows the infrastructure to easily scale both vertically and horizontally to cater to changing demand. It also facilitates effective utilization of system resources, thus reducing energy consumption and carbon footprint.
The network firewalls, routers and switches support all applications and servers. Hardware traffic shapers are used to enforce an equitable access policy for connections coming from registrars. The registry system accommodates both IPv4 and IPv6 addresses. Hardware load balancers accelerate TLS⁄SSL handshaking and distribute load among a pool of application servers.
Each of the servers and network devices are equipped with redundant, hot-swappable components and multiple connections to ancillary systems. Additionally, 24x7 support agreements with a four-hour response time at all our data centers guarantee replacement of failed parts in the shortest time possible.
Examples of current system and network devices used are:
• Servers: Cisco UCS B230 blade servers
• SAN storage arrays: IBM Storwize V7000 with Solid State Drives • SAN switches: Brocade 5100
• Firewalls: Cisco ASA 5585-X
• Load balancers: F5 Big-IP 6900
• Traffic shapers: Procera PacketLogic PL8720
• Routers: Juniper MX40 3D
• Network switches: Cisco Nexus 7010, Nexus 5548, Nexus 2232
These system components are upgraded and updated as required, and have usage and performance thresholds which trigger upgrade review points. In each data center, there is a minimum of two of each network component, a minimum of 25 servers, and a minimum of two storage arrays.
Technical components of the SRS include the following items, continually checked and upgraded as needed: SRS, WHOIS, web admin tool, DNS, DNS distributor, reporting, invoicing tools, and deferred revenue system (as needed).
All hardware is massively provisioned to ensure stability under all forecast volumes from launch through “normal” operations of average daily and peak capacities. Each and every system application, server, storage and network device is continuously monitored by the Afilias Network Operations Center for performance and availability. The data gathered is used by dynamic predictive analysis tools in real-time to raise alerts for unusual resource demands. Should any volumes exceed established thresholds, a capacity planning review is instituted which will address the need for additions well in advance of their actual need.


SRS diagram and interconnectivity description
As with all core registry services, the SRS is run from a global cluster of registry system data centers, located in geographic centers with high Internet bandwidth, power, redundancy and availability. All of the registry systems will be run in a 〈n+1〉 setup, with a primary data center and a secondary data center. For detailed site information, please see our responses to questions #32 and #35. Registrars access the SRS in real-time using EPP.
A sample of the Afilias SRS technical and operational capabilities (displayed in Figure 24-a) include:
• Geographically diverse redundant registry systems;
• Load balancing implemented for all registry services (e.g. EPP, WHOIS, web admin) ensuring equal experience for all customers and easy horizontal scalability;
• Disaster Recovery Point objective for the registry is within one minute of the loss of the primary system;
• Detailed and tested contingency plan, in case of primary site failure, and;
• Daily reports, with secure access for confidentiality protection.
As evidenced in Figure 24-a, the SRS contains several components of the registry system. The interconnectivity ensures near-real-time distribution of the data throughout the registry infrastructure, timely backups, and up-to-date billing information.
The WHOIS servers are directly connected to the registry database and provide real-time responses to queries using the most up-to-date information present in the registry.
Committed DNS-related EPP objects in the database are made available to the DNS Distributor via a dedicated set of connections. The DNS Distributor extracts committed DNS-related EPP objects in real time and immediately inserts them into the zone for dissemination.
The Afilias system is architected such that read-only database connections are executed on database replicas and connections to the database master (where write-access is executed) are carefully protected to ensure high availability.
This interconnectivity is monitored, as is the entire registry system, according to the plans detailed in our response to question #42.
Synchronization scheme
Registry databases are synchronized both within the same data center and in the backup data center using a database application called Slony. For further details, please see the responses to questions #33 and #37. Slony replication of transactions from the publisher (master) database to its subscribers (replicas) works continuously to ensure the publisher and its subscribers remain synchronized. When the publisher database completes a transaction the Slony replication system ensures that each replica also processes the transaction. When there are no transactions to process, Slony “sleeps” until a transaction arrives or for one minute, whichever comes first. Slony “wakes up” each minute to confirm with the publisher that there has not been a transaction and thus ensures subscribers are synchronized and the replication time lag is minimized. The typical replication time lag between the publisher and subscribers depends on the topology of the replication cluster, specifically the location of the subscribers relative to the publisher. Subscribers located in the same data center as the publisher are typically updated within a couple of seconds, and subscribers located in a secondary data center are typically updated in less than ten seconds. This ensures real-time or near-real-time synchronization between all databases, and in the case where the secondary data center needs to be activated, it can be done with minimal disruption to registrars.

SRS SLA performance compliance
Afilias has a ten-year record of delivering on the demanding ICANN SLAs, and will continue to provide secure, stable and reliable service in compliance with SLA requirements as specified in the new gTLD Registry Agreement, Specification 10, as presented in Figure 24-b.
The Afilias SRS currently handles over 200 million EPP transactions per month for just .INFO and .ORG. Overall, the Afilias SRS manages over 700 million EPP transactions per month for all TLDs under management.
Given this robust functionality, and more than a decade of experience supporting a thick TLD registry with a strong performance history, Afilias, on behalf of Applicant, will meet or exceed the performance metrics in Specification 10 of the new gTLD Registry Agreement. The Afilias services and infrastructure are designed to scale both vertically and horizontally without any downtime to provide consistent performance as this TLD grows. The Afilias architecture is also massively provisioned to meet seasonal demands and marketing campaigns. Afilias’ experience also gives high confidence in the ability to scale and grow registry operations for this TLD in a secure, stable and reliable manner.
SRS resourcing plans
Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.
Over 100 Afilias team members contribute to the management of the SRS code and network that will support this TLD. The SRS team is composed of Software Engineers, Quality Assurance Analysts, Application Administrators, System Administrators, Storage Administrators, Network Administrators, Database Administrators, and Security Analysts located at three geographically separate Afilias facilities. The systems and services set up and administered by these team members are monitored 24x7 by skilled analysts at two NOCs located in Toronto, Ontario (Canada) and Horsham, Pennsylvania (USA). In addition to these team members, Afilias also utilizes trained project management staff to maintain various calendars, work breakdown schedules, utilization and resource schedules and other tools to support the technical and management staff. It is this team who will both deploy this TLD on the Afilias infrastructure, and maintain it. Together, the Afilias team has managed 11 registry transitions and six new TLD launches, which illustrate its ability to securely and reliably deliver regularly scheduled updates as well as a secure, stable and reliable SRS service for this TLD.

gTLD	Full Legal Name	E-mail suffix	Detail
.wilmar	Wilmar International Limited	wilmar.com.sg	View

THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉”
CHARACTERS, or < and >), WHICH ICANN INFORMS US (CASE ID 11027)
CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE,
THE ANSWER BELOW AS DISPLAYED IN TAS MAY NOT RENDER THE FULL RESPONSE
AS INTENDED. THEREFORE, THE FULL ANSWER TO THIS QUESTION IS ALSO
ATTACHED AS A PDF FILE, ACCORDING TO SPECIFIC GUIDANCE FROM ICANN
UNDER CASE ID 11027.


Answers for this question (#24) are provided directly from the Service Provider, the back-end provider of registry services for this TLD.

As referred to above, in the Applicant’s response to Question 23, As agreed between the Applicant and The Service Provider, all technical back-end operations with respect to the .WILMAR gTLD will be outsourced to The Service Provider, an experienced and proven registry operator with over ten years of experience managing a world-class registry platform. The Applicant will, however, remain responsible for the provision of these services vis-à-vis ICANN, as referred to in the Registry Operator Agreement.
The Applicant has partnered with The Service Provider, an experienced TLD registry operator, who will provide for the necessary support in deploying a fully ICANN-compliant Shared Registration System (SRS). The Applicant is confident that the plan in place for the operation of a robust and reliable SRS as currently provided by The Service Provider will satisfy the criterion established by ICANN.

The Service Provider built its SRS as an EPP based platform and has been operating it reliably and at scale since 2001. The software currently provides registry services to inter alia .INFO and .ORG TLDs. The Service Provider’ state of the art registry has a proven track record of being secure, stable, and robust. It manages more than 20 million domain names, and has over 375 registrars connected today.

The following describes a detailed plan for a robust and reliable SRS that meets all ICANN requirements, including compliance with Specifications 6 and 10 to the Registry Operator Agreement published by ICANN.
The answers for this question (#24) are provided in cooperation with The Service Provider


The .WILMAR TLD will operate in a state-of-the-art EPP-based Shared Registration System (SRS) that is secure, stable and reliable. The SRS is a critical component of registry operations that must balance the business requirements for the registry and its customers, such as numerous domain acquisition and management functions. The SRS that will be used for the .WILMAR TLD meets or exceeds all ICANN requirements given that The Service Provider:
− operates a secure, stable and reliable SRS which updates in real-time and in full compliance with Specification 6 of the new gTLD Registry Agreement;
− is committed to continuously enhancing the SRS that will be used for the operation of the applied-for TLD to meet existing and future needs;
− currently exceeds contractual requirements and will perform in compliance with Specification 10 of the new gTLD Registry Agreement;
− provides SRS functionality and staff, financial, and other resources to more than adequately meet the technical needs of this TLD, and;
− manages the SRS with a team of experienced technical professionals who can seamlessly integrate the applied-for TLD into the The Service Provider registry platform and support the applied-for TLD in a secure, stable and reliable manner.



Description of operation of the SRS, including diagrams
The SRS that will be used for the .WILMAR TLD will provide the same advanced functionality as that used in the .INFO and .ORG registries, as well as the fourteen other TLDs currently supported by The Service Provider. The registry system that will be used for the .WILMAR TLD, is standards-compliant and utilizes proven technology, ensuring global familiarity for registrars, and it is protected by massively provisioned infrastructure that mitigates the risk of disaster. Specifically, The Service Provider has engineered its registry applications as stateless systems, managed with load balancers. This permits dynamic scaling at the application layer for all registry functions. The Service Provider’ applications exercise 5-6% sustained load on the current application servers, with bursted loads of up to 12-13%. The servers are operated with a minimum bursted capacity of 50% over sustained loads. In the event of unexpected load increase, this available overhead permits The Service Provider to promote additional resources into production without expected degradation of service.

EPP functionality is described in detail in the Applicant’s response to Question #25; please consider those answers incorporated here by reference. An abbreviated list of the SRS functionality that will be supported by the Applicant, through The Service Provider, includes:
− Domain registration: the Applicant will provide registration of names in the TLD, in both ASCII and IDN forms, to accredited registrars via EPP and a web-based administration tool.
− Domain renewal: the Applicant will provide services that allow registrars the ability to renew domains under sponsorship at any time. Further, the registry shall be able to perform the automated renewal of all domain names at the expiration of their term, and will allow registrars to rescind automatic renewals within a specified number of days after the transaction for a full refund.
− Transfer: the Applicant will provide efficient and automated procedures to facilitate the transfer of sponsorship of a domain name between accredited registrars. Further, the registry shall enable bulk transfers of domains under the provisions of the Registry-Registrar Agreement.
− RGP and restoring deleted domain registrations: the Applicant, through its Back-End Operator, shall provide support for the Redemption Grace Period (RGP) to the extent needed, enabling the restoration of deleted registrations.
− Other grace periods and conformance with ICANN guidelines: the Applicant, through its Back-End Operator shall be able to provide support for other grace periods that are evolving as standard practice inside the ICANN community. In addition, the registry system that the Applicant will use, shall support the evolving ICANN guidelines on IDNs.

The Applicant, through its Back-End Operator shall also support the basic check, delete, and modify commands.


As required for all new gTLDs, the system provides “thick” registry system functionality. In this model, all key contact details for each domain are stored in the registry. This allows better access to domain data and provides uniformity in storing the information.
The SRS complies today and will continue to comply with global best practices including relevant RFCs, ICANN requirements, and this gTLD’s respective domain policies. With over a decade of experience, the Service Provider has fully documented and tested policies and procedures, and our highly skilled team members are active participants of the major relevant technology and standards organizations, so ICANN can be assured that SRS performance and compliance are met. Full details regarding the SRS system and network architecture are provided in responses to questions #31 and #32; please consider those answers incorporated here by reference.


SRS servers and software
All applications and databases for the applied-for TLD will run in a virtual environment currently hosted by a cluster of servers equipped with the latest Intel Westmere multi-core processors. (Although it is possible that by the time this application has passed the evaluation and systems deployed, Westmere processors may no longer be the “latest”, the Applicant’s Back-End Operator’s policy is to use the most advanced, stable technology available at the time of deployment.) The data for the registry will be stored on storage arrays of solid state drives shared over a fast storage area network. The virtual environment will allow the infrastructure to easily scale both vertically and horizontally to cater to changing demand. It will also facilitate effective utilization of system resources, thus reducing energy consumption and carbon footprint.

The latest network firewalls, routers and switches will support all applications and servers. Hardware traffic shapers will be used to enforce an equitable access policy for connections coming from registrars. The registry system that will be used for the applied-for gTLD accommodates both IPv4 and IPv6 addresses. Hardware load balancers will accelerate TLS⁄SSL handshaking and distribute load among a pool of application servers.

Each of the servers and network devices that will be used for the gTLD are equipped with redundant, hot-swappable components and multiple connections to ancillary systems. Additionally, 24x7 support agreements with a four-hour response time at all the Back-End Operator’s data centers guarantee the replacement of failed parts in the shortest time possible.

Examples of current system and network devices used by the Applicant’s Back-End Operator are:
− Servers: Cisco UCS B230 blade servers
− SAN storage arrays: IBM Storwize V7000 with Solid State Drives
− SAN switches: Brocade 5100
− Firewalls: Cisco ASA 5585-X
− Load balancers: F5 Big-IP 6900
− Traffic shapers: Procera PacketLogic PL8720
− Routers: Juniper MX40 3D
− Network switches: Cisco Nexus 7010, Nexus 5548, Nexus 2232


These system components are upgraded and updated as required, and have usage and performance thresholds which trigger upgrade review points. In each data center of the Applicant’s Back-End Operator, there is a minimum of two of each network component, a minimum of 25 servers, and a minimum of two storage arrays.

Technical components of the SRS that will be used for the applied-for gTLD already include the following items, continually checked and upgraded as needed: WHOIS, web admin tool, DNS, DNS distributor, reporting, invoicing tools, and deferred revenue system (as needed).

All hardware that will be used for the applied-for gTLD is massively provisioned to ensure stability under all forecast volumes from launch through “normal” operations of average daily and peak capacities. Each and every system application, server, storage and network device to be used for the applied-for gTLD will be continuously monitored by the The Service Provider Network Operations Center for performance and availability. The data gathered will be used by dynamic predictive analysis tools in real-time to raise alerts for unusual resource demands. Should any volumes exceed established thresholds, a capacity planning review shall be instituted to address the need for additions well in advance of their actual need.



SRS diagram and interconnectivity description
As with all core registry services, the SRS that will be used for the applied-for gTLD, shall be run from a global cluster of registry system data centers, located in geographic centers with high Internet bandwidth, power, redundancy and availability. All of the registry systems will be run in a 〈n+1〉 setup, with a primary data center and a secondary data center. For detailed site information, please see the Applicant’s responses to questions #32 and #35.

Registrars will be able to access the SRS that will be used for the applied-for gTLD in real-time using EPP.

A schematic overview of the Applicant’s Back-End Operator’s registry infrastructure that will be used for the applied for gTLD is provided in Annex A – Figure 24-a.

A sample of the technical and operational capabilities (displayed in Annex A – Figure 24-a) of the SRS that will be used include:
− Geographically diverse redundant registry systems;
− Load balancing implemented for all registry services (e.g. EPP, WHOIS, web admin) ensuring equal experience for all customers and easy horizontal scalability;
− Disaster Recovery Point objective for the registry (This is within one minute of the loss of the primary system);
− Detailed and tested contingency plan, in case of primary site failure, and;
− Daily reports, with secure access for confidentiality protection.

As evidenced in Annex A – Figure 24-a, the SRS that will be used for the applied-for gTLD contains several components of the registry system. The interconnectivity ensures near-real-time distribution of the data throughout the registry infrastructure, timely backups, and up-to-date billing information.

The WHOIS servers that will be used for the applied-for gTLD shall be directly connected to the registry database and provide real-time responses to queries using the most up-to-date information present in the registry.

Committed DNS-related EPP objects in the database will be made available to the DNS Distributor via a dedicated set of connections. The DNS Distributor will extract committed DNS-related EPP objects in real time and immediately inserts them into the zone for dissemination.

The system as proposed by the Applicant, through its Back-End Operator is architected such that read-only database connections are executed on database replicas and connections to the database master (where write-access is executed) are carefully protected to ensure high availability.

This interconnectivity will be monitored, as will be the entire registry system, according to the plans detailed in the Applicant’s response to Question #42.



Synchronization scheme
Registry databases are synchronized both within the same data center, and in the backup data center using a database application called Slony. For further details, please see the responses to questions #33 and #37; please consider those answers incorporated here by reference. Slony replication of transactions from the publisher (master) database to its subscribers (replicas) will work continuously to ensure the publisher and its subscribers remain synchronized. When the publisher database completes a transaction, the Slony replication system will ensure that each replica also processes the transaction. When there are no transactions to process, Slony will “sleep” until a transaction arrives or for one minute, whichever comes first. If there is no transaction within one minute, Slony will “wake up” each minute to confirm with the publisher that there has not been a transaction and thus will ensure that subscribers are synchronized and that the replication time lag is minimized. The typical replication time lag between the publisher and subscribers will depend on the topology of the replication cluster, specifically the location of the subscribers relative to the publisher. Subscribers located in the same data center as the publisher are typically updated within a couple of seconds, and subscribers located in a secondary data center are typically updated in less than ten seconds. This ensures real-time or near-real-time synchronization between all databases, and in the case where the secondary data center needs to be activated, it can be done with minimal disruption to registrars.



SRS SLA performance compliance
The Applicant’s Back-End Operator has a ten-year record of delivering on all ICANN SLAs, and will continue to provide secure, stable and reliable service in compliance with SLA requirements as specified in the new gTLD Registry Agreement, Specification 10, as presented in Annex A – Figure 24-b.

The The Service Provider SRS currently handles over 200 million EPP transactions per month for just .INFO and .ORG. Overall, the The Service Provider SRS manages over 700 million EPP transactions per month for all TLDs under management.

Given this robust functionality and the Applicant’s Back-End Registry Operator having more than a decade of experience supporting a thick TLD registry with a strong performance history, the Applicant will meet or exceed the performance metrics in Specification 10 of the new gTLD Registry Agreement. The The Service Provider services and infrastructure are designed to scale both vertically and horizontally without any downtime to provide consistent performance as this TLD grows. The The Service Provider architecture is also massively provisioned to meet seasonal demands and marketing campaigns. The Service Provider’ experience also gives high confidence in the ability to scale and grow registry operations for this TLD in a secure, stable and reliable manner.



SRS resourcing plans
Since its founding, The Service Provider is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the The Service Provider registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. The Service Provider operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the The Service Provider project management methodology allows efficient and effective use of our staff in a focused way.

Over 100 The Service Provider team members contribute to the management of the SRS code and network that will support this TLD. The SRS team is composed of Software Engineers, Quality Assurance Analysts, Application Administrators, System Administrators, Storage Administrators, Network Administrators, Database Administrators, and Security Analysts located at three geographically separate The Service Provider facilities. The systems and services set up and administered by these team members are monitored 24x7 by skilled analysts at two NOCs located in Toronto, Ontario (Canada) and Horsham, Pennsylvania (USA). In addition to these team members, The Service Provider also utilizes trained project management staff to maintain various calendars, work breakdown schedules, utilization and resource schedules and other tools to support the technical and management staff. It is this team who will both deploy the .WILMAR TLD on the The Service Provider infrastructure, and maintain it. Together, the The Service Provider team has managed 11 registry transitions and six new TLD launches, which illustrate its ability to securely and reliably deliver regularly scheduled updates as well as a secure, stable and reliable SRS service for the .WILMAR TLD.