2022-12-06 Transfer Policy Review PDP WG Call

We do wish to mention here that the "general objection to all transfer requests received by the Registrar, either temporarily or indefinitely." can be made even stronger by our proposal in section I (TIMELOCK ACCESS TO TAC GENERATOR, AKA "VACATION MODE" or "LOCKDOWN MODE") of our submission. 

Also, the "express objection to the transfer" will be ineffective if the Losing FOA is eliminated, and/or it's too late if the transfer has already completed before the registrant has the opportunity to learn of an unauthorized transfer. Thus, the Losing FOA must be retained (at least as an option!). 

For the time limits in I.A.3.7.5 and I.A.3.7.6, it makes more sense to us for the registry to enforce the times, rather than the registrar.

Potential next step: WG to consider the extent to which these comments were addressed in deliberations on previous comments.

Fraud is one example of an abusive activity that registrars must prohibit in their Registration Agreement with Registrants. Edit language to further empower registrars to deny transfers for abusive behaviour, while also ensuring that the registrar has evidence of the abusive behaviour.

Add new reason that registrars MUST deny a transfer (currently a MAY): “The Registrar of Record has credible evidence of fraud.”

Potential next step: WG to consider whether this comment introduces new information that should be further considered.

The RrSG notes that the notification of UDRP or URS procedure must come from the Provider and as such there may in some cases be a delay between the time of registration and the time of notification of the dispute. It is important that the timing of transfer denials be carefully considered to ensure that a registrant does not move between registrars in order to avoid the UDRP or URS and, should that occur, rollback of the transfer in these scenarios should be considered in the appropriate phase of this TPR WG.

Rec 21: #4

Potential next step: WG to discuss if any additional adjustments need to be made to the recommendations with respect to this issue in the Phase I recommendations. Rollbacks will be considered in Phase II.

Transfer Policy Fee: We have heard there are cases of high transfer fees in some registrars. This is especially very restrictive for noncommercial users. Therefore, as the policy recommendations mentions the ground nonpayment as one of the denial of transfer, we expect to see the issue of high fees in terms of domain name transfer be fully discussed and addressed by the working group and requiring unreasonable fees be discouraged.

A Registrar may not withhold a domain name transfer; however, we have seen some Registrars charge their customers significant fees for moving their domain names away. . .It is our view that Registrants should not be forced to pay "exit" fees when they are trying to move to a new Registrar that better suits their needs.  We have reviewed such a third-party agreement (between a Registrar and Registrant), and the terms regarding exit fees were ambiguous at best, but without a clear policy to deal with this issue, it created an opportunity for the Registrar in question to use transfer out fees as a tool to deter their clients from leaving. If the goal of the transfer policy is to provide for enhanced domain name portability, resulting in greater consumer and business choice, then these fees fly in the face of this fundamental principle and should not be allowed.

We believe if you discuss the reasons that MAY deny a transfer, sanctions should be discussed as a reason. Ordinary noncommercial registrants who are not on special designated national list are subject to discrimination and on several instances transfer of domain names are not allowed by the registrar, the registrars just confiscate it. The working group decided not to discuss this issue or even dismiss it. We invite the working group to at least highlight the issue and if it believes it’s out of scope, express it.

Rec 22: #5

Potential next step: If the WG continues to believe that these topics are out of scope, consider adding language in the Final Report in this regard providing additional rationale.

With regard to transfer restrictions, we reiterate our concerns regarding the proposed restrictions as set out above, and we will have more comments on change of registrant restrictions when the issue is addressed in Phase 1(b).

Rec 22: #7

Potential next step: WG to consider if this comment raises any new issues that need to be discussed.

I.A.3.9.1: Current Guidance implies that these reasons only apply during the Auto-Renew Grace Period but they are intended to always apply. Recommend removal of “during the Auto-Renew Grace Period, provided that any auto-renewal costs borne by the Registrar are reversible for future period” so that the Guidance says:

“Implementation Guidance: Registrars are prohibited from denying domain name transfer requests based on non- payment of fees for pending or future registration periods during the Auto-Renew Grace Period, provided that any auto-renewal costs borne by the Registrar are reversible for future period.”

Potential next step: The original intention of the Implementation Guidance was to provide guidance specifically addressing questions that have come up surrounding the Auto-Renew Grace Period. Potential revision: “Implementation Guidance regarding the Auto-Renew Grace Period: Registrars are prohibited from denying domain name transfer requests based on non- payment of fees for pending or future registration periods during the Auto-Renew Grace Period, provided that any auto-renewal costs borne by the Registrar are reversible for future period.”

in I.A.3.9.2, the default behaviour from a security point of view should be to deny a transfer, unless you have affirmative consent (i.e. if there's no "ACK", then the transfer should be denied, even if there's no "NACK").

Potential next step: This suggestion is being discussed and considered in the context of discussions regarding the Losing FOA.

"Silence" (i.e. no response) should be interpreted conservatively. So, in I.A.3.9.2, the default behaviour from a security point of view should be to deny a transfer, unless you have affirmative consent (i.e. if there's no "ACK", then the transfer should be denied, even if there's no "NACK"). That's how things once used to be, but then it got changed to where the transfer would automatically go through by default, if there was no response. This is the "UltraSecure" option mentioned above (section F. "THE BEST OF BOTH WORLDS" PROPOSAL TO RETAIN THE LOSING FOA ON AN OPT-IN BASIS BY REGISTRANTS) that registrants should be allowed to have the choice to opt-in to. 

Small point, but in I.A.3.9.5, we've never liked the term "reseller" (although it's a defined term in the RAA). Some in the public (and UDRP complainants in particular) might use the label to imply that a "reseller" must be registering domain names in order to resell them (rather than someone that simply has access to a registrar's advanced systems, to be able to access white-label platform for registration services, or a "pro" interface). That confusion over the meaning of "reseller" might negatively impact a registrant. So, it would be nice at some point to revisit the term "reseller", and perhaps replace it with "Value Added Integrator" or some other term that doesn't reference buying/selling domains themselves (as opposed to domain registration services). The "registration service provider" term is also fine.

Potential next step: See deliberations on Losing FOA (recommendation 2). WG to consider whether to revisit the term “reseller” (see I.A.3.9.5).

Potential next step: Consider whether “violation of registrar’s anti-abuse policies, or evidence of fraud” in the MAY category is an appropriate compromise. 

In brief, the alternatives presented in the comments:

In the MAY category:

• Evidence of fraud (status quo)
• Violation of the Registrar's domain use or anti-abuse policies or evidence of fraud. OR Evidence of fraud, or violation of the Registrar’s domain use or anti-abuse policies.                     
• Evidence of fraud, illegal activity, phishing, distribution of malware, or to comply with the law.

In the MUST category: 

• The Registrar has knowledge of credible evidence of the domain currently being used for malware, phishing, pharming, or command & control botnets.

Additional proposal: Move “Evidence of fraud” to the MUST category and include “violation of the Registrar’s domain use or anti-abuse policies” in the MAY category.