Policy Development Process to Review the Transfer Policy: Difference between revisions

← Older edit Newer edit →

VisualWikitext

@@ Line 31: / Line 31: @@
 ===Phase 1(a) Initial Report & Public Comment===
-The working group intends to publish its Phase 1(a) Initial Report in June 2022.<ref>[https://community.icann.org/pages/viewpage.action?pageId=176622934 PDP Transfer Policy Review Workspace - Action Items & Work Plan], last updated November 2021</ref>
+The working group intends to publish its Phase 1(a) Initial Report in June 2022.<ref>[https://community.icann.org/pages/viewpage.action?pageId=176622934 PDP Transfer Policy Review Workspace - Action Items & Work Plan], last updated November 2021</ref> Early drafts of the Initial Report contained a total of 22 recommendations in response to the charter questions:
+# Eliminate the requirement that the Gaining Registrar send a Gaining Form of Authorization;
+# Eliminate the requirement that the Losing Registrar send a Losing Form of Authorization;
+# Require the Registrar of Record to issue a Notification of Transfer Authorization Code (TAC) Provision to the Registered Name Holder within ten minutes of providing a TAC;
+# Require the Losing Registrar to send a Notification of Transfer Completion to the Registered Name Holder within 24 hours after the transfer is completed;
+# Replace "AuthInfo Code" and similar terms (Auth-Info Code, Auth-Code, transfer code) with "Transfer Authorization Code" (TAC) throughout the Transfer Policy;
+# Define "Transfer Authorization Code" as: "a token created by the Registrar of Record and provided upon request to the RNH or their designated representative. The TAC is required for a domain name to be transferred from one Registrar to another Registrar and when presented authorizes the transfer."
+# Task ICANN org with the creation of minimum requirements for and components of the TAC;
+# Require Registries to validate that a TAC meets the minimum requirements when it is stored in the Registry system;
+# Secure the TAC process by: only generating a TAC upon request, securely storing the TAC in the Registry system using a one-way hash, and provide information regarding the timing of expiration of the TAC;
+# Affirm the Temporary Specification's requirement that the Registry Operator verify that the TAC is valid prior to allowing an inter-registrar transfer;
+# Require that each TAC be a "one-time use" code;
+# Maintain the existing requirement that registrars must provide a TAC within "five calendar days" of a request, but recommend changing the time limit to 120 hours for clarity.
+# Set a default Time to Live (TTL) for a TAC at 14 days, and allow the Registrar of Record to set the TAC to null before the expiration date upon request from the Registered Name Holder or by agreement between the Registrar of Record and the Registered Name Holder;
+# Clarify what terms are equivalent between the Transfer Policy and the current [[Registrar Accreditation Agreement]] by specifying (for example) that "WHOIS Data" and "Registration Data" are referring to the same thing;
+# Remove any reference to "Administrative Contact" or "Transfer Contact" and replace those terms with "Registered Name Holder" unless specifically indicated;
+# Establish a mandatory 30-day moratorium on transfers from the initial registration date;
+# Establish a mandatory 30-day moratorium on new transfers from the date of completion of an inter-registrar transfer;
+# Separate section I.A.3.7 of the Transfer Policy into two distinct sections, one containing the requirement that the Registrar of Record present their reason for denial of a transfer request, and the other specifying the permitted reasons for denial;
+# Update and refine the language of the permitted reasons for denial of a transfer request;
+# Update and revise some of the reasons that the Registrar of Record '''may''' deny a transfer request under the Transfer Policy so that they become circumstances under which the Registrar of Record '''must''' deny the transfer request;
+# Update and refine the language of the Transfer Policy's existing list of circumstances under which the Registrar of Record must deny a transfer request; and
+# Update and revise the Transfer Policy so that situations in which a Registrar '''may not''' deny a transfer request are instead situations in which the Registrar of Record '''must not''' deny such a request.<ref name="1adraftIR">[https://community.icann.org/display/TPRPDP/Working+Documents?preview=/167543675/197263958/TPR%20Initial%20Report%20Draft%20-%2029%20April%202022.pdf Transfer Policy Review PDP - Draft Initial Report], as of April 20, 2022</ref>
 ==References==