In order to facilitate the triage of the temporary specification as outlined in the EPDP Team charter as the first deliverable, please work with your appointing organization team members to complete the following survey. Your input is expected to be received by Monday, 13 August 2018 19:00 UTC. The language below is verbatim from the Temporary Specification for gTLD Registration Data (see https://www.icann.org/resources/pages/gtld-registration-data-specs-en). 

Question Title

* 1. Your name

Question Title

* 2. EPDP Team Appointing Organization on whose behalf your filling out this survey

Question Title

* 3. Please consider Appendix D: Uniform Rapid Suspension: 

This Appendix contains supplemental requirements for the 17 October 2013 URS High Level Technical Requirements for Registries and Registrars and URS Rules effective 28 June 2013.

1. URS High Level Technical Requirements for Registry Operator and Registrar

1.1. Registry Operator Requirement: The Registry Operator (or appointed BERO) MUST provide the URS provider with the full Registration Data for each of the specified domain names, upon the URSprovider notifying the Registry Operator (or appointed BERO) of the existence of a complaint, or participate in another mechanism to provide the full Registration Data to the Provider as specified by ICANN. If the gTLD operates as a "thin" registry, the Registry Operator MUST provide the available Registration Data to the URS Provider.

1.2. Registrar Requirement: If the domain name(s) subject to the complaint reside on a "thin" registry, the Registrar MUST provide the full Registration Data to the URS Provider upon notification of a complaint.

2.     URS Rules
Complainant's complaint will not be deemed defective for failure to provide the name of the Respondent (Registered Name Holder) and all other relevant contact information required by Section 3 o the URS Rules if such contact information of the Respondent is not available in registration data publicly available in RDDS or not otherwise known to Complainant. In such an event, Complainant may file a "Doe" complaint and the Examiner shall provide the relevant contact details of the Registered Name Holder after being presented with a "Doe" complaint.

Having reviewed this section I support this section as is:

Question Title

* 4. Please consider Appendix E: Uniform Domain Name Dispute Resolution Policy

This Appendix contains supplemental requirements for the Rules for Uniform Domain Name Dispute Resolution Policy (the "Rules").

Uniform Domain Name Dispute Resolution Policy
1.1. Registrar Requirement: The Registrar MUST provide the UDRP provider with the full Registration Data for each of the specified domain names, upon the UDRP provider notifying the Registrar of the existence of a complaint, or participate in another mechanism to provide the full Registration Data to the Provider as specified by ICANN.

1.2. Complainant's complaint will not be deemed defective for failure to provide the name of the Respondent (Registered Name Holder) and all other relevant contact information required by Section 3 o the UDRP Rules if such contact information of the Respondent is not available in registration data publicly available in RDDS or not otherwise known to Complainant. In such an event, Complainant may file a "Doe" complaint and the Provider shall provide the relevant contact details of the Registered Name Holder after being presented with a "Doe" complaint.

Having reviewed this section I support this section as is:

Question Title

* 5. Please consider Appendix G: Supplemental Procedures to the Transfer Policy

This Appendix provides supplemental procedures for the Transfer Policy applicable to all ICANN-accredited Registrars.

1. Until such time when the RDAP service (or other secure methods for transferring data) is required by ICANN to be offered, if the Gaining Registrar is unable to gain access to then-current Registration Data for a domain name subject of a transfer, the related requirements in the Transfer Policy will be superseded by the below provisions:

1.1. The Gaining Registrar is not REQUIRED to obtain a Form of Authorization from the Transfer Contact.

1.2. The Registrant MUST independently re-enter Registration Data with the Gaining Registrar. In such instance, the Gaining Registrar is not REQUIRED to follow the Change of Registrant Process as provided in Section II.C. of the Transfer Policy.

Having reviewed this section I support this section as is:

Question Title

* 6. Please consider Appendix G: Supplemental Procedures to the Transfer Policy

2. As used in the Transfer Policy:

2.1. The term "Whois data" SHALL have the same meaning as "Registration Data".

2.2. The term "Whois details" SHALL have the same meaning as "Registration Data".

2.3. The term "Publicly accessible Whois" SHALL have the same meaning as "RDDS".

2.4. The term "Whois" SHALL have the same meaning as "RDDS".

3. Registrar and Registry Operator SHALL follow best practices in generating and updating the "AuthInfo" code to facilitate a secure transfer process.

4. Registry Operator MUST verify that the "AuthInfo" code provided by the Gaining Registrar is valid in order to accept an inter-registrar transfer request. 

Having reviewed this section I support this section as is:

Question Title

* 7. If there is any further input you want to provide on the sections referenced above that will help inform further deliberations, please use this comment box.

T