Application For Assignment Form - Material Subcontracting ... · Application For Assignment Form -...

ICANN | Insert title here (75 character maximum) Please use ICANN covers | [Publish Date] | 1

Application For Assignment Form - "Material Subcontracting Arrangement"This form is used for a Registry Operator to request a change to a Material Subcontractor.

Version 1.12 July 2017

I C A N N | APPLICATION FOR ASSIGNMENT FORM – MATERIAL SUBCONTRACTOR | JULY 2017 | 2

Table of Contents

I. INTRODUCTION: ............................................................................................................................................................... 3 A. PURPOSE .................................................................................................................................................................................................. 3 B. CONSIDERATIONS ................................................................................................................................................................................... 3 C. STEPS ........................................................................................................................................................................................................ 3

II. APPLICATION FOR ASSIGNMENT FORM .................................................................................................................. 5A. REGISTRY AGREEMENT INFORMATION .............................................................................................................................................. 5 B. ASSIGNMENT INFORMATION ................................................................................................................................................................ 5 C. ADDITIONAL INFORMATION ................................................................................................................................................................. 7

III. TECHNICAL QUESTIONS .......................................................................................................................................... 9

IV. ATTESTATION OF FULL AND TRUTHFUL DISCLOSURE .............................................................................. 21

APPENDIX 1 ......................................................................................................................................................................... 29 REGISTRY TRANSITION PLAN TECHNICAL REQUIREMENTS ............................................................................................................. 29

APPENDIX 2 ......................................................................................................................................................................... 35 REGISTRY CONTACT INFORMATION ...................................................................................................................................................... 35

Contents


I. INTRODUCTION: A. Purpose This Application for Assignment Form (AAF) should be used when a Registry Operator intends to change a “Material Subcontracting Arrangement”, defined as an “Assignment” in Section 7.5 of the Registry Agreement. A “Material Subcontracting Arrangement” (MSA) may include a change to the Registry Service Provider (RSP).

For detailed information on the MSA process, we recommend requesters review the Material Subcontracting Arrangement information available at https://www.icann.org/resources/material-subcontracting-arrangement.

B. Considerations No changes to the Registry Agreement are allowed as part of the Assignment process. If a change in services is contemplated, an RSEP and/or Registry Agreement amendment may need to be executed prior to requesting a Material Subcontractor Arrangement change. For more information regarding the RSEP, please visit: https://www.icann.org/resources/pages/rsep-‐2014-‐02-‐19-‐en.

The Assignment process has quiet periods. If a TLD is undergoing PDT or is in “Transition to IANA” status, ICANN may withhold consent and request for the “Assignment” to be resubmitted after those processes are completed.

For MSA type assignments, the services delivered by the proposed new Registry Service Provider (RSP) must be identical to the services delivered by the current provider. Any change or addition to services may require a Registry Services Evaluation Policy (“RSEP”) request.

If the proposed Registry Service Provider is not currently a New gTLD Registry Service provider, requesters will also need to provide responses to the questions listed in Section III in this form.

After a review of the submission, ICANN will provide an estimate of fees prior to the start of any evaluations for which Registry Operator will be invoiced.

To request direct assistance, you may log into the GDD Portal (https://gddportal.icann.org) or send an email to [email protected].

C. Steps

1. PREPARATION/INFORMAL INQUIRY

While not required, we strongly encourage you to submit an informal MSA inquiry to ICANN early on so additional questions and potential issues may be discussed prior to formal MSA submission. To adequately

https://www.icann.org/resources/material-subcontracting-arrangement

https://www.icann.org/resources/material-subcontracting-arrangement


prepare for your formal “Assignment” submission to ICANN and the related processes, you will need to assemble the appropriate documentation to support your request. This will include, but is not limited to, a cover letter summarizing your request, this completed AAF and all supporting documentation such as your transition plan between the providers, and changes in registry contacts.

2. FORMAL SUBMISSION

The submission of this document may impact other open processes (e.g., RSEP requests, Pre-Delegation Testing (PDT), Two character release requests). If you have requests open, please login to the GDD Portal and open a case to inquire about potential impact. The “Assignment” request must be submitted in accordance to Section 7.9 of the Registry Agreement. The physical submission of this form must be accompanied with all supporting documentation to answer each section.


II. APPLICATION FOR ASSIGNMENT FORMA. Registry Agreement Information

TLD (A-‐label if IDN):

Registry Operator for the TLD:

Effective Date of Registry Agreement:

Current Status of the TLD:

Approved Pre-‐Delegation Testing date:

PDT completion date:

Delegation/IANA token issue date:

Delegation date:

Number of Registrations (if applicable):

B. Assignment Information Please explain the nature of the proposed Subcontracting change, the current Subcontractor

Type of Change: � Registry Service Provider

� Other (explain) ___________________________________________________


Name of Current Subcontractor:

Address:

Phone:

Contact:

Email Address:

Service(s) Provided:

Name of Proposed Subcontractor:

Address:

Phone:

Contact:

Email Address:

Service(s) Provided:

List (no more than 5) New gTLDs Currently Operated by Proposed Subcontractor:

PROPOSED DATE OF AGREEMENT WITH PROPOSED SUBCONTRACTOR: _____________________


C. Additional Information

TECHNICAL REVIEW

Please list at least one New gTLD that is operating on the same technical infrastructure run by the Proposed Subcontractor.

If the Proposed Subcontractor does not currently operate any New gTLDs, you must also complete the questions in Section III.

Registry Operator confirms that their New gTLD will be operated by the Proposed Subcontractor in the same environment as the New gTLD mentioned above. Initial: ___________

TRANSITION PLAN

If the TLD has been delegated, you must provide a detailed transition plan between the current subcontractor and the proposed successor. This plan must be approved by ICANN prior to starting Registry System Testing. An outline of the transition plan is attached as Appendix 1.

REGISTRY SYSTEM TESTING

If the TLD has previously completed Pre-Delegation Testing (PDT), registry system tests similar to PDT must be completed in the new environment prior to submitting this form. Please provide the date when testing was completed in the proposed Subcontractor environment. ___________

CONTACT UPDATES

Provide any changes in contact information including for all contact types listed in Appendix 2 attached to this form.

EVALUATION FEES

Please acknowledge that if there are any fees associated with evaluation of this “Assignment” request, they must be paid before the request can be approved. Initial: ___________

SUPPORTING DOCUMENTS

Submit this document along with the following supporting documents:

¨ A cover letter on company letterhead describing the current and proposed Subcontractors, estimated timing and any other details along with a signature.

¨ Answers to questions in Section III (if applicable)


¨ If the TLD has been delegated, provide a transition plan as outlined in Appendix 1. This plan should include the detailed steps that will be taken to transition services between service providers.

¨ Updated contact information as required by Appendix 2.

CONSULTATION CALL

Due to the complexity of the process, we highly recommend a consultation call. To schedule a consultation call, contact your Engagement Manager or open a case in the GDD Portal: https://gddportal.icann.org.

COURIER/SHIPMENT INFORMATION

Per section 7.9 of the Registry Agreement, if sent via courier, please include the courier information of the formal Assignment request:

Courier Name:

Tracking Number:

Date Sent:


III. TECHNICAL QUESTIONSIf the proposed provider is not currently operating one or more New gTLD registries, provide attachment(s) including responses to each of the questions below. If the Material Subcontracting Arrangement request will not affect the response to a question or set of questions listed below, please indicate so in the response.

1. SHARED REGISTRATION SYSTEM (SRS) PERFORMANCE: DESCRIBE

The plan for operation of a robust and reliable SRS. SRS is a critical registry function forenabling multiple registrars to provide domain name registration services in the TLD. SRS must include the EPP interface to the registry, as well as any other interfaces intended to be provided, if they are critical to the functioning of the registry. Please refer to the requirements in Specification 6 (section 1.2) and Specification 10 (SLA Matrix) attached to the Registry Agreement; and

Resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect ofthe criteria (number and description of personnel roles allocated to this area).

A complete answer should include, but is not limited to:

A high-level SRS system description;

Representative network diagram(s);

Number of servers;

Description of interconnectivity with other registry systems;

Frequency of synchronization between servers; and

Synchronization scheme (e.g., hot standby, cold standby).

2. EXTENSIBLE PROVISIONING PROTOCOL (EPP): PROVIDE A DETAILED DESCRIPTION OFTHE INTERFACE WITH REGISTRARS, INCLUDING HOW THE REGISTRY OPERATOR WILL COMPLY WITH EPP IN RFCS 3735 (IF APPLICABLE), AND 5730-5734.

If intending to provide proprietary EPP extensions, provide documentation consistent with RFC 3735, including the EPP templates and schemas that will be used. Describe resourcing plans (number and description of personnel roles allocated to this area).

A complete answer is expected to be no more than 5 pages. If there are proprietary EPP extensions, a complete answer is also expected to be no more than 5 pages per EPP extension.

3. WHOIS: DESCRIBE


How the Registry Operator will comply with Whois specifications for data objects, bulk access,and lookups as defined in Specifications 4 and 10 to the Registry Agreement;

How the Registry Operator Whois service will comply with RFC 3912; and


A complete answer should include, but is not limited to:

A high-level Whois system description;

Relevant network diagram(s);

IT and infrastructure resources (e.g., servers, switches, routers and other components);

Description of interconnectivity with other registry systems; and

Frequency of synchronization between servers.

Answers may also include:

Provision for Searchable Whois capabilities; and

A description of potential forms of abuse of this feature, how these risks will be mitigated, and thebasis for these descriptions.

A complete answer is expected to be no more than 5 pages.

4. REGISTRATION LIFE CYCLE:Provide a detailed description of the proposed registration lifecycle for domain names in the proposed gTLD. The description must:

Explain the various registration states as well as the criteria and procedures that are used tochange state;

Describe the typical registration lifecycle of create/update/delete and all intervening steps suchas pending, locked, expired, and transferred that may apply;

Clearly explain any time elements that are involved - for instance details of add-grace orredemption grace periods, or notice periods for renewals or transfers; and

Describe resourcing plans for this aspect of the criteria (number and description of personnelroles allocated to this area).

The description of the registration lifecycle should be supplemented by the inclusion of a state diagram, which captures definitions, explanations of trigger points, and transitions from state to state.

If applicable, provide definitions for aspects of the registration lifecycle that are not covered by standard EPP RFCs.



5. ABUSE PREVENTION AND MITIGATION:Registry Operator should describe the proposed policies and procedures to minimize abusive registrations and other activities that have a negative impact on Internet users. A complete answer should include, but is not limited to:

An implementation plan to establish and publish on its website a single abuse point of contactresponsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning all names registered in the TLD through all registrars of record, including those involving a reseller;

Policies for handling complaints regarding abuse;

Proposed measures for removal of orphan glue records for names removed from the zone whenprovided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6); and


Answers must include measures to promote Whois accuracy as well as measures from one other area as described below.

Measures to promote Whois accuracy (can be undertaken by the registry directly or by registrarsvia requirements in the Registry-Registrar Agreement (RRA)) may include, but are not limited to:

Authentication of registrant information as complete and accurate at time of registration.Measures to accomplish this could include performing background checks, verifying all contact information of principals mentioned in registration data, reviewing proof of establishment documentation, and other means.

Regular monitoring of registration data for accuracy and completeness, employing authenticationmethods, and establishing policies and procedures to address domain names with inaccurate or incomplete Whois data; and

If relying on registrars to enforce measures, establishing policies and procedures to ensurecompliance, which may include audits, financial incentives, penalties, or other means. Note that the requirements of the RAA will continue to apply to all ICANN-accredited registrars.

A description of policies and procedures that define malicious or abusive behavior, capturemetrics, and establish Service Level Requirements for resolution, including service levels for responding to law enforcement requests. This may include rapid takedown or suspension systems and sharing information regarding malicious or abusive behavior with industry partners;

Adequate controls to ensure proper access to domain functions (can be undertaken by theregistry directly or by registrars via requirements in the Registry-Registrar Agreement (RRA)) may include, but are not limited to:

Requiring multi-factor authentication (i.e., strong passwords, tokens, one-time passwords) fromregistrants to process update, transfers, and deletion requests;

Requiring multiple, unique points of contact to request and/or approve update, transfer, anddeletion requests; and


Requiring the notification of multiple, unique points of contact when a domain has been updated,transferred, or deleted.


6. RIGHTS PROTECTION MECHANISMS:Registry Operator must describe how their registry will comply with policies and practices that minimize abusive registrations and other activities that affect the legal rights of others, such as the Uniform Domain Name Dispute Resolution Policy (UDRP), Uniform Rapid Suspension (URS) system, and Trademark Claims and Sunrise services at startup. A complete answer should include:

A description of how the Registry Operator will implement safeguards against allowingunqualified registrations (e.g., registrations made in violation of the registry’s eligibility restrictions or policies), and reduce opportunities for behaviors such as phishing or pharming. At a minimum, the Registry Operator must offer a Sunrise period and a Trademark Claims service during the required time periods, and implement decisions rendered under the URS on an ongoing basis; and

A description of resourcing plans for the initial implementation of, and ongoing maintenance for,this aspect of the criteria (number and description of personnel roles allocated to this area).

Answers must also include additional measures specific to rights protection, such as abusive use policies, takedown procedures, registrant pre-verification, or authentication procedures, or other covenants.


7. (A) SECURITY POLICY:Provide a summary of the security policy for the proposed registry, including but not limited to:

Indication of any independent assessment reports demonstrating security capabilities, andprovisions for periodic independent assessment reports to test security capabilities;

Description of any augmented security levels or capabilities commensurate with the nature of theapplied for gTLD string, including the identification of any existing international or industry relevant security standards the Registry Operator commits to following (reference site must be provided);

List of commitments made to registrants concerning security levels.

Answers must also include:

Evidence of an independent assessment report demonstrating effective security controls (e.g.,ISO 27001).

A summary of the above should be no more than 20 pages. Note that the complete security policy for the registry is required to be submitted in accordance with 8(b).

(b) Security Policy: Provide the complete security policy and procedures for the proposed registry, including but not limited to:

System (data, server, application/services) and network access control, ensuring systems aremaintained in a secure fashion, including details of how they are monitored, logged and backed up;


Resources to secure integrity of updates between registry systems and nameservers, andbetween nameservers, if any;

Independent assessment reports demonstrating security capabilities (submitted as attachments),if any;

Provisioning and other measures that mitigate risks posed by denial of service attacks;

Computer and network incident response policies, plans, and processes;

Plans to minimize the risk of unauthorized access to its systems or tampering with registry data;

Intrusion detection mechanisms, a threat analysis for the proposed registry, the defenses that willbe deployed against those threats, and provision for periodic threat analysis updates;

Details for auditing capability on all network access;

Physical security approach;

Identification of department or group responsible for the registry’s security organization;

Background checks conducted on security personnel;

Description of the main security threats to the registry operation that have been identified; and


8. TECHNICAL OVERVIEW OF PROPOSED REGISTRY:Provide a technical overview of the proposed registry.

The technical plan must be adequately resourced, with appropriate expertise and allocation of costs. The Registry Operator will provide financial descriptions of resources in the next section and those resources must be reasonably related to these technical requirements. The overview should include information on the estimated scale of the registry’s technical operation, for example, estimates for the number of registration transactions and DNS queries per month should be provided for the first two years of operation.

In addition, the overview should account for geographic dispersion of incoming network traffic such as DNS, Whois, and registrar transactions.

If the registry serves a highly localized registrant base, then traffic might be expected to come mainly from one area. This high-level summary should not repeat answers to questions below. Answers should include a visual diagram(s) to highlight dataflows, to provide context for the overall technical infrastructure. Detailed diagrams for subsequent questions should be able to map back to this high-level diagram(s). The visual diagram(s) can be supplemented with documentation, or a narrative, to explain how all of the Technical & Operational components conform.


9. ARCHITECTURE:Provide documentation for the system and network architecture that will support registry operations for


the proposed scale of the registry. System and network architecture documentation must clearly demonstrate the Registry Operator’s ability to operate, manage, and monitor registry systems. Documentation should include multiple diagrams or other components including but not limited to:

Detailed network diagram(s) showing the full interplay of registry elements, including but notlimited to SRS, DNS, Whois, data escrow, and registry database functions;

▪ Network and associated systems necessary to support registry operations,including:

▪ Anticipated TCP / IP addressing scheme,

▪ Hardware (i.e., servers, routers, networking components, virtual machines andkey characteristics (CPU and RAM, Disk space, internal network connectivity, andmake and model)),

▪ Operating system and versions, and

▪ Software and applications (with version information) necessary to support registryoperations, management, and monitoring

General overview of capacity planning, including bandwidth allocation plans;

List of providers / carriers; and


Answers must also include evidence of a network architecture design that greatly reduces the risk profile of the proposed registry by providing a level of scalability and adaptability (e.g., protection against DDoS attacks) that far exceeds the minimum configuration necessary for the expected volume.


10. DATABASE CAPABILITIES:Provide details of database capabilities including but not limited to:

Database software;

Storage capacity (both in raw terms [e.g., MB, GB] and in number of registrations/registrationtransactions);

Maximum transaction throughput (in total and by type of transaction);

Scalability;

Procedures for object creation, editing, and deletion, and user and credential management;

High availability;

Change management procedures;

Reporting capabilities; and



A registry database data model can be included to provide additional clarity to this response.

Note: Database capabilities described should be in reference to registry services and not necessarily related support functions such as Personnel or Accounting, unless such services are inherently intertwined with the delivery of registry services.

Answers must also include evidence of database capabilities that greatly reduce the risk profile of the proposed registry by providing a level of scalability and adaptability that far exceeds the minimum configuration necessary for the expected volume.


11. GEOGRAPHIC DIVERSITY:Provide a description of plans for geographic diversity of:

a. Name servers, andb. Operations centers.

Answers should include, but are not limited to:

The intended physical locations of systems, primary and back-up operations centers (includingsecurity attributes), and other infrastructure;

Any registry plans to use Anycast or other topological and geographical diversity measures, inwhich case, the configuration of the relevant service must be included;

Resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect ofthe

Criteria (number and description of personnel roles allocated to this area).

Answers must also include evidence of a geographic diversity plan that greatly reduces the risk profile of the proposed registry by ensuring the continuance of all vital business functions (as identified in the Registry Operator’s continuity plan in Question 17) in the event of a natural or other disaster) at the principal place of business or point of presence.

12. DNS SERVICE:Describe the configuration and operation of nameservers, including how the Registry Operator will comply with relevant RFCs.

All name servers used for the new gTLD must be operated in compliance with the DNS protocol specifications defined in the relevant RFCs, including but not limited to: 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, and 4472.


Provide details of the intended DNS Service including, but not limited to: A description of theDNS services to be provided, such as query rates to be supported at initial operation, and reserve capacity of the system. Describe how your nameserver update methods will change at various scales. Describe how DNS performance will change at various scales.

RFCs that will be followed – describe how services are compliant with RFCs and if these arededicated or shared with any other functions (capacity/performance) or DNS zones.

The resources used to implement the services - describe complete server hardware andsoftware, including network bandwidth and addressing plans for servers. Also include resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect of the criteria (number and description of personnel roles allocated to this area).

Demonstrate how the system will function - describe how the proposed infrastructure will be ableto deliver the performance described in Specification 10 (section 2) attached to the Registry Agreement.

Examples of evidence include:

Server configuration standard (i.e., planned configuration).

Network addressing and bandwidth for query load and update propagation.

Headroom to meet surges.


13. IPV6 REACHABILITY:Provide a description of plans for providing IPv6 transport including, but not limited to:

How the registry will support IPv6 access to Whois, Web-based Whois and any otherRegistration Data Publication Service as described in Specification 6 (section 1.5) to the Registry Agreement.

How the registry will comply with the requirement in Specification 6 for having at least twonameservers reachable over IPv6.

List all services that will be provided over IPv6, and describe the IPv6 connectivity and providerdiversity that will be used.



14. DATA BACKUP POLICIES & PROCEDURES:Provide:

Details of frequency and procedures for backup of data,

Hardware, and systems used for backup,

Data format,


Data backup features,

Backup testing procedures,

Procedures for retrieval of data/rebuild of database,

Storage controls and procedures, and



15. DATA ESCROW:Describe:

How the Registry Operator will comply with the data escrow requirements documented in theRegistry Data Escrow Specification (Specification 2 of the Registry Agreement); and



16. REGISTRY CONTINUITY:Describe how the Registry Operator will comply with registry continuity obligations as described in Specification 6 (section 3) to the registry agreement. This includes conducting registry operations using diverse, redundant servers to ensure continued operation of critical functions in the case of technical failure.

Describe resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect of the criteria (number and description of personnel roles allocated to this area).

The response should include, but is not limited to, the following elements of the business continuity plan:

Identification of risks and threats to compliance with registry continuity obligations;

Identification and definitions of vital business functions (which may include registry servicesbeyond the five critical registry functions) versus other registry functions and supporting operations and

Technology;

Definitions of Recovery Point Objectives and Recovery Time Objective; and

Description of testing plans to promote compliance with relevant obligations.


A highly detailed plan that provides for leading practice levels of availability; and

Evidence of concrete steps such as a contract with a backup provider (in addition to anycurrently designated service operator) or a maintained hot site.



17. REGISTRY TRANSITION:Provide a Service Migration plan (as described in the Registry Transition Processes) that could be followed in the event that it becomes necessary to permanently transition the proposed gTLD to a new operator. The plan must take into account, and be consistent with the vital business functions identified in the previous question.

Elements of the plan may include, but are not limited to:

Preparatory steps needed for the transition of critical registry functions;

Monitoring during registry transition and efforts to minimize any interruption to critical registryfunctions during this time; and

Contingency plans in the event that any part of the registry transition is unable to move forwardaccording to the plan.


18. FAILOVER TESTING:Provide:

A description of the failover testing plan, including mandatory annual testing of the plan.Examples may include a description of plans to test failover of data centers or operations to alternate sites, from a hot to a cold facility, registry data escrow testing, or other mechanisms. The plan must take into account and be consistent with the vital business functions identified in Question 17; and


The failover testing plan should include, but is not limited to, the following elements:

Types of testing (e.g., walkthroughs, takedown of sites) and the frequency of testing;

How results are captured, what is done with the results, and with whom results are shared;

How test plans are updated (e.g., what triggers an update, change management processes formaking updates);

Length of time to restore critical registry functions;

Length of time to restore all operations, inclusive of critical registry functions; and

Length of time to migrate from one site to another.


19. MONITORING AND FAULT ESCALATION PROCESSES:Provide:


A description of the proposed (or actual) arrangements for monitoring critical registry systems(including SRS, database systems, DNS servers, Whois service, network connectivity, routers and firewalls). This description should explain how these systems are monitored and the mechanisms that will be used for fault escalation and reporting, and should provide details of the proposed support arrangements for these registry systems.



Meeting the fault tolerance/monitoring guidelines described

Evidence of commitment to provide a 24x7 fault response team.


20. DNSSEC:Provide:

The registry’s DNSSEC policy statement (DPS), which should include the policies andprocedures the proposed registry will follow, for example, for signing the zone file, for verifying and accepting DS records from child domains, and for generating, exchanging, and storing keying material;

Describe how the DNSSEC implementation will comply with relevant RFCs, including but notlimited to: RFCs 4033, 4034, 4035, 5910, 4509, 4641, and 5155 (the latter will only be required if Hashed Authenticated Denial of Existence will be offered); and


A complete answer is expected to be no more than 5 pages. Note, the DPS is required to be submitted as part of the application.

21. THIS QUESTION IS OPTIONAL BUT MUST BE ANSWERED IF THE REGISTRY CURRENTLYOFFERS IDNs. IDNs:

State whether the proposed registry will support the registration of IDN labels in the TLD, and ifso, how. For example, explain which characters will be supported, and provide the associated IDN Tables with variant characters identified, along with a corresponding registration policy. This includes public interfaces to the databases such as Whois and EPP.

Describe how the IDN implementation will comply with RFCs 5809-5893 as well as the ICANNIDN Guidelines at: http://www.icann.org/en/topics/idn/implementation-guidelines.htm.

Describe resourcing plans for the initial implementation of, and ongoing maintenance for, thisaspect of the criteria (number and description of personnel roles allocated to this area).

A complete answer is expected to be no more than 10 pages plus attachments.

http://www.icann.org/en/topics/idn/imple


IV. ATTESTATION OF FULL ANDTRUTHFUL DISCLOSURE The undersigned hereby represents and warrants that he/she is a duly authorized person (officer, owneror director) with the requisite power and authority to bind the Registry Operator and request a Material Subcontracting Arrangement change. The undersigned attests that the information contained herein, and all supporting documents submitted herewith, are true and accurate to the best of the undersigned’s knowledge. The undersigned gives ICANN permission to contact third parties, investigate, request and obtain additional information and documentation, and otherwise verify the information contained herein. The undersigned waives liability on the part of ICANN for its actions in verifying the information provided in this application. The undersigned further waives liability on the part of any third parties who provide truthful, material, relevant information about the undersigned as requested by ICANN.

_________________________________________ Signature

_________________________________________ Name (please print)

_________________________________________ Title

_________________________________________ Date

Answer all questions and attach supporting documents to a signed copy of this form. Please send directly or by courier to ICANN at:

12025 E. Waterfront Drive, Suite 300

Los Angeles, CA 90094-‐2536

USA

[email protected]

Phone: +1 310 301 5800

Fax: +1 310 823 8649


Appendix 1 Guidelines for Transition Plan

(APPLICABLE ONLY TO DELEGATED TLDS WITH OR WITHOUT REGISTRATIONS)

A Registry Operator should use the following guidelines when developing a plan to transition services from the current Registry Service Provider (RSP) to a proposed RSP. Note that the “current RSP” refers to the RSP from which the services are being transitioned. The “proposed RSP” refers to the RSP to which the services are being transitioned.

n General

o The transition plan must:

o Contain detailed steps to be executed.

o Describe which Registry Service Provider will execute each step of the transition plan.

o Include blocking steps that must be completed before continuing with the plan.

o Confidential information (e.g. TSIG keys) may be communicated between the current andproposed RSPs. If communicating confidential information, describe the security mechanisms fornon-repudiation and privacy.

n IANA

o The transition plan must include when and whom will execute the updates to the IANA informationas applicable:

§ Sponsoring Organization

§ Contacts

§ Name Servers

§ DS Records

o The transition plan should consider that IANA updates are not immediate, and may be ablocking step(s).

o If the Registry Operator is removing all name servers and adding a new set to the root, IANA mayrequire the Registry Operator to justify the change.

o The transition plan shall comply with the IANA Technical requirements for authoritative nameservers available at https://www.iana.org/help/nameserver-requirements. The followingrequirements may be waived after providing justification to IANA:


§ Network diversity§ Consistency between authoritative name servers - Serial number

§ Matching DNSKEY

n Rollback

p Provide contingency steps in the event that any part of the registry transition is unable to move forward according to the plan.

n Monitoring

p Describe the processes and systems that will be used to monitor the different services during the registry transition process.

n Exceptions

o Provide a list of potential exceptions and their treatment.o Identify exceptions that may generate a rollback and exceptions that could be handled after the

transition.o Communications with the Registrars regarding the potential exceptions should be described in the

transition plan. For example, the exception of an IDN not being imported from the losing Registry,because the winning Registry does not support the code points will generate a rollback.

n Decommissioning of services by the current Registry Service Provider

p The transition plan must contemplate the decommissioning of services by the current RSP. The proposed RSP must obtain confirmation from the now current RSP that the services have been decommissioned and shut down.

n Data Escrow

p The transition plan must describe how the current RSP will transition its data escrow deposits to the proposed Registry.

p Previous data escrow deposits shall be transferred to the proposed Data Escrow Agent, if applicable. If the Data Escrow Agent of the current and proposed RSP is the same, the plan should specify that the Data Escrow Agent will transfer the deposits from one account to the other.

p Include in your plan that the proposed RSP and its Data Escrow Agent will send data escrow reports and notifications to ICANN immediately after the transition.

n Monthly reporting

p If for a given month, there are transactions in both the current and proposed RSPs, describe how the proposed RSP will incorporate the partial information of the monthly report.

p Describe any steps to be taken for the values of the fields in the report based on the transition process. For example, no new registrations will be possible 6 days before the transition in order to clear AGP of all domain names.


n ONBIR (ZFA, CZDS, BRDA and URS information)

o As part of the transition process, the winning Registry Service Provider must provide new ONBIRinformation to ICANN in order to continue meeting the requirements for ZFA, CZDS BRDA andURS.

o The winning Registry Service Provider must agree with ICANN on the timing for applying the newONBIR information.

n Registry Services under Exhibit A

p If Registry Services offered by the current RSP will be phased out, provide a phase out plan that minimizes the impact to Registrants. Note: An RSEP request is required to remove Registry Services from the Exhibit A. The RSEP request, if approved, may lead to a Registry Agreement amendment, which may require a Public Comment Period.

p Identify in the transition plan the Registry Services that will be offered by the proposed RSP.

p Describe the transition plan for Registry Services in the Exhibit A of the current RSP.

n Internationalized Domain Names

p Identify differences between the IDN languages/scripts supported by the current and proposed RSPs. Note: An RSEP request is required to update the IDN provision in the RA of the proposed Registry, in case that the supported IDN languages/scripts is different between the current and proposed RSPs.

p Identify differences between handling of variants by the RSPs and the code points supported for the same IDN language/scripts. For example, you might write, “The IDN table for Spanish language in the proposed RSP does not support the LATIN SMALL LETTER A WITH ACUTE (i.e. á, U+00E1) code point, which is supported by the losing Registry Service Provider.”

§ If different code points are supported in the IDN languages/scripts or different IDNlanguages/scripts will be supported, provide a mapping algorithm. For example: IDNs underGerman Language in the losing Registry will be mapped to Latin Script in the winning Registry.

§ Provide an initial evaluation of domain names that may not be imported as a result of amismatch of IDN support between the two registries.

§ Identify the IDN languages/scripts that are currently supported by the Registry Service Providerfor all gTLDs managed by the Registry Service Provider.

§ If active IDN variant Domain Names exists in the losing Registry Service Provider, explain thetreatment of IDN variants in the winning Registry Service Provider. For example, the IDNvariants domain names in the losing Registry Service Provider will be activated in the winningRegistry Service Provider.

n Searchable Whois

o If the Searchable Whois service is offered by the losing Registry and will be offered by the winningRegistry, describe the mechanism to migrate the users of such service, in case that theauthentication is required.

n DNS Service


o Describe how the DNS and DNSSEC services will be transitioned from the losing Registry to thewinning Registry.

o Consider that the monthly SLR for the DNS service is 0 minutes of downtime.o The DNSSEC chain of trust must not be broken at any time. Registry Service Providers should follow

the best practices described in RFC 6781.o If the losing or gaining Registry will transfer the zone file on a continuous basis for a period of time,

describe the secure mechanisms (e.g. TSIG) that will be used for zone transferring.o If the algorithms used by the Registry Service Providers are different, provide information about the

considerations in the transition plan.o If the TLD will be transitioned from NSEC to NSEC3 or vice versa, provide information about the

considerations in the transition plan.o Provide a timeline diagram with the transition and updates of DNSSEC Keys, Name servers, updates

to the root zone and TTLs. Include in the timeline diagram the originator (i.e. Winning or losingRegistry) of the zone file used.

o The timeline shall include:o Name server set, and DS RRs at the root in each step.o Name server set and keyset at the winning and losing registries' name servers.o Please include the hostname and IP addresses of the name servers.

o Describe the mechanism to ensure that the last zone file generated by the losing Registry ServiceProvider is consistent with the first zone file generated by the winning Registry Service Provider.

n RDDS

o Describe how the RDDS service will be transitioned from the losing Registry to the winningRegistry.

o Consider that the monthly SLR for the DNS service is 864 minutes of downtime.o Describe the mechanism to ensure a transition of the RDDS service without violating your SLR.

For example: the service will be running on the winning and losing Registry Service Providerwhile the whois.nic.<tld> entry expires from the caches. The TTL of whois.nic.<tld> will bedecreased before the transition.

o Describe the mechanism to ensure that the RDDS database is consistent between the twoRegistries while the service is being transitioned.

n SRS

p Describe how the SRS service will be transitioned from the current RSP to the proposed RSP.

o Database import:

§ Describe the process that will be used to verify the data to be imported.

§ Describe the process used to verify that the RDDS database and zone files appear to beconsistent between the current and proposed RSPs.

p ROIDs (Repository Object Identifier):

p Explain if the ROID of the different objects will remain the same. If ROIDs will be changed, the proposed RSP shall communicate the changes to the Registrars.


p Explain the steps to be taken in case that duplicate ROIDs for the same type of objects are found.

p Registrars shall be informed of any changes to the ROIDs of the objects.

p IDs:

p Explain if the identifiers of the different objects will remain the same. Note that EPP supports IDs and ROIDs for the same object type. If IDs will be changed, the proposed RSP shall communicate the changes to the Registrars.

p Explain what will occur if duplicate identifiers for the same type of objects are found.

p Stipulate that Registrars shall be informed of any changes to the IDs of the objects.

p Contacts:

p Describe steps taken in the case of mismatch in the support of contact transfers between the RSPs.

p Describe steps taken in the case of mismatch in the support of contact disclose functionality between the RSPs.

p Describe the steps to be taken if the linked contact objects are not found in the copy of the database from the current RSP.

p Domains:

o Describe steps taken in the case of a mismatch in the supported grace periods between thecurrent and proposed RSPs.

§ Describe the treatment for a mismatch in the duration of the different grace periodsbetween the losing and gaining Registry Service Providers.

§ Describe any changes to the statuses of the domain names as part of the transition. Forexample: the gaining Registry Service Provider will remove server* statuses.

§ Describe the treatment if domain names cannot be imported based on business rules of thegaining Registry Service Provider.

p Hosts:

§ Describe the treatment for mismatch in the support of host transfers between the RegistryService Providers.

§ Describe the treatment in the case that a transition from managing hosts as objects to hosts asattributes or vice versa. Note: Registrars should be notified if there is change in the mechanismto manage hosts.

§ Describe special handling of imported hosts that may become glue records based on thedifferent namespaces managed by the Registry Service Provider.

§ Describe the treatment if any linked host objects are not found in the copy of the databasefrom the losing Registry Service Provider.

§ Describe the treatment if you find duplicate hosts objects in the copy of the database from thelosing Registry Service Provider.


p DNSSEC:

§ Describe the treatment in case that the DNSSEC information required by the winning RegistryService Provider has not been captured by the losing Registry Service Provider. For example, thelosing Registry Service Provider uses the DS interface and the winning Registry Service Providerrequires the KeyData interface.

p EPP:

§ Describe the mechanism used to ensure a transition of the EPP service without violating your SLR.§ Describe the treatment in case of mismatch between the EPP extensions supported by the losing

and winning Registry Service Provider. Registrars should be informed about the differences in theEPP extensions.

§ Describe the treatment for the authInfo information. For example: a new randomly authInfo willbe generated

p Registrars:

§ Describe the treatment in case that sponsoring Registrars for domain names to be imported arenot accredited by the winning Registry Service Provider.

§ Describe the treatment in case of mismatch of information about the Registrars between thewinning and losing Registry Service Providers.

p URS

o Describe the treatment for domain names in URS Lock/Suspension.

n TMCH

p Describe the steps to be taken for domain name applications that have not been resolved before the transition.


Appendix 2 Registry Contact Information

Provide any changes to the Registry's operational and emergency contact information. Unless specified as “optional,” all fields must be filled out. For more information, please refer to the New gTLD Welcome Kit at the “Onboarding” section.

Registry Primary Contact

First Name

Last Name

Position/Title (optional) Telephone (+##.###-‐###-‐###) Mobile (+##.###-‐###-‐###)

Fax

Email

Street Address

City

State/Province/District

Postal Code

Two-‐Letter Country Code

Registry Secondary Contact

First Name

Last Name

Position/Title (optional) Telephone (+##.###-‐###-‐###) Mobile (+##.###-‐###-‐###) (optional)

Fax (optional)

Email

Street Address

City


State/Province/District (optional)

Postal Code


Registry Service Provider Primary Contact

First Name

Last Name


Fax

Email

Street Address

City


Postal Code


Registry Service Provider Secondary Contact

First Name (optional)

Last Name (optional)

Position/Title (optional) Telephone (+##.###-‐###-‐###)

(optional)

Mobile (+##.###-‐###-‐###) (optional)

Fax (optional)

Email (optional)

Street Address (optional)

City (optional)


Postal Code (optional)

Two-‐Letter Country Code (optional)


Data Escrow Agent Primary Contact

First Name

Last Name


Fax (optional)

Email

Street Address

City


Postal Code


Data Escrow Agent Secondary Contact



Position/Title (optional) Telephone (+##.###-‐###-‐###)

(optional)

Mobile (+##.###-‐###-‐###) (optional)

Fax (optional)

Email (optional)


City (optional)





Technical Contact

First Name

Last Name


Fax (optional)

Email

Street Address

City


Postal Code


Legal (Notice) Contact

First Name

Last Name


Fax

Email

Street Address

City


Postal Code



Media / Communications Contact



Position/Title (optional)

Telephone (+##.###-‐###-‐###)

(optional)

Mobile (+##.###-‐###-‐###) (optional)

Fax (optional)

Email (optional)


City (optional)




Billing/Financial Primary Contact

First Name

Last Name


Fax

Email

Street Address

City


Postal Code



Billing/Financial Secondary Contact




Telephone (+##.###-‐###-‐###)

(optional)

Mobile (+##.###-‐###-‐###) (optional)

Fax (optional)

Email (optional)


City (optional)




24x7 Emergency Contact -‐ Escalation 1

First Name (Actual Person’s first name/last name)

Last Name (Actual Person’s first name/last name)


Telephone (+##.###-‐###-‐###) Mobile (+##.###-‐###-‐###)

Fax

Email

Street Address

City


Postal Code




First Name (Different from 24x7 Emergency Contact-‐Escalation 1)

Last Name



Fax (optional)

Email


City (optional)





First Name (Different from 24x7 Emergency Contact-‐Escalation 1 & 2)

Last Name



Fax (optional)

Email


City (optional)





CZDS Primary Contact

First Name

Last Name


Telephone (+##.###-‐###-‐###) Mobile (+##.###-‐###-‐###) (optional)

Fax (optional)

Email


City (optional)




CZDS Secondary Contact




Telephone (+##.###-‐###-‐###)

(optional)

Mobile (+##.###-‐###-‐###) (optional)

Fax (optional)

Email (optional)


City (optional)





TMDB Contact

First Name

Last Name


Telephone (+##.###-‐###-‐###)

(optional)

Mobile (+##.###-‐###-‐###)

Fax (optional)

Email


City (optional)




Abuse Contact

First Name

Last Name



Fax

Email

Street Address

City


Postal Code



Compliance Contact

First Name (Actual Person’s first name/last name)

Last Name (Actual Person’s first name/last name)



Fax

Email

Street Address

City


Postal Code


URS -‐ Registry Operator

First Name

Last Name



Fax

Email

Street Address

City


Postal Code



URS -‐ Backend Technical Service Provider




Telephone (+##.###-‐###-‐###)

(optional)

Mobile (+##.###-‐###-‐###) (optional)

Fax (optional)

Email (optional)


City (optional)




¨

Application For Assignment Form - Material Subcontracting ... · Application For Assignment Form -...

Documents

Transcript of Application For Assignment Form - Material Subcontracting ... · Application For Assignment Form -...