[GNSO-TPR] Notes and action items - TPR WG Meeting #36 - 15 Feb 2022

Tue Feb 15 17:44:01 UTC 2022

Dear TPR WG Members,

Please find below the notes and action items from today’s call.

The next TPR WG meeting will be on Tuesday, 22 February 2022 at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

Action Items:

ACTION ITEM: Staff will update the work plan to include time for a couple of sessions on the claw-back procedure.  Staff to include a note that this issue will be revisited in the Additional Topics Working Document.

Transfer Policy Review Phase 1 - Meeting #36
Tuesday 15 February 2022 at 16:00 UTC

1. Roll Call & SOI updates (5 minutes)

2. Welcome & Chair updates (5 minutes)

  *   See #3 below re: Business Constituency comments.
3. Registrar-applied locks upon domain creation and domain transfer (15 minutes) -- Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1RGow_TYPSESvI9DFweF3T_g7vgufg6zCwEdSsUjBfqs/edit__;!!PtGJab4!sQkbkEXuWsv1j2i8mdAbJ0-FrsfcejL9juXDiE61fkUs6GVMlkmVGwlfycuE81PRbvz7SC32Hw$>

Post-Creation Locks:

  *   The Business Constituency had a brief discussion on locks and wanted to share some feedback from brand owners in the BC: Desire to keep the 60-day post-creation day lock; if too short could compel the brand owner to redo the UDRP.  From a brand perspective was that the 60-day lock for post creation could prevent having to redo UDRP enforcement.
  *   Some discussion that create doesn’t have the same issues as post transfer, but issue raised by the brand owners that a longer period allows more time for UDRP enforcement.
  *   If there is evidence of fraud the registrar can always lock again.
  *   It doesn’t prevent a brand owner from raising a UDRP, but it’s a practical issue if you have to redo it, which is a temporary obstacle.
  *   The flip side is input from WIPO – in some instances inter-registrar transfers are rejected when they are within the 60-day lock period.
Post-Transfer Locks:

  *   Note that there is no specific policy to mandate a post-transfer lock, but many registrar agreements include it.
  *   Suggested proposal of a 10-day post transfer lock – discussion:
     *   Think we need to first discuss the claw-back procedure -- do we need to tie the transfer reversal timeframe to the lock period?
     *   Think we can still discuss it now and note that it is dependent on the claw-back procedure/timing.
     *   Would it work for the domain to be locked for 10 days but you can dispute a transfer for 6 months? or does that not make sense?
     *   Note that we could put guidelines around a transfer claw back. Not sure we can come up with a mechanism that would solve all cases.
     *   We just need a period that is long enough for the old registrar to get contacted by the registrant and for them to investigate and contact the new registrar so they can investigate.
     *   10 days seems good and matches the timing of the post-creation lock, but we still have the issue of claw backs.  Should we look at wording here that allows us to tie those together at a later time?
     *   In the PCR we recognized how closely related locks are to denial of transfers – we can have those deliberations but not make any formal recommendations.  Need to think about some guardrails for now.
     *   Could talk about claw backs over a couple of sessions and come to a general understanding of what it looks like at a high level.
     *   Could come up with some ideas around what a successful claw-back procedure looks like.
ACTION ITEM: Staff will update the work plan to include time for a couple of sessions on the claw-back procedure.  Staff to include a note that this issue will be revisited in the Additional Topics Working Document.

4. Begin discussion on NACKing (60 minutes) -- Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3VxyAjVCrkyVqdttOPn2EaqBARRRnEPd0Q/edit__;!!PtGJab4!sQkbkEXuWsv1j2i8mdAbJ0-FrsfcejL9juXDiE61fkUs6GVMlkmVGwlfycuE81PRbvx3xnJXDg$>

NACK: A denial of a request for transfer by the Losing Registrar. (Note: this definition comes from paragraph 1.9 of the Transfer Dispute Resolution Policy<https://www.icann.org/resources/pages/tdrp-2016-06-01-en>.)

Two Charter Questions (pages 3 and 4):

h1) Are the current reasons for denying or NACK-ing a transfer sufficiently clear? Should additional reasons be considered? For instance, ICANN Contractual Compliance has observed difficulties from registrars tying transfer denials involving domain names suspended for abusive activities to the denial instances contemplated by the Transfer Policy; or should any reasons be removed?

In considering this question, the WG may wish to consider:

  *   Should any or all of the reasons that registrars MAY NACK a transfer be changed to MUST NACK to promote consistency and reduce potential registrant confusion?
Contractual Compliance has noted that many registrars and registrants remain confused by the terminology used in I.3.9.1, “Instances when the requested change of Registrar MAY NOT be denied include, but are not limited to: 3.9.1 Nonpayment for a pending or future registration period.” Does the Working Group have suggestions for clarifying this language, or does it believe it should remain as is?

h2) Should additional guidance around cases subject to a UDRP decision be provided to ensure consistent treatment by all registrars? If so, is this something that should be considered by the RPMs PDP Working Group’s review of the UDRP, or should it be conducted within a Transfer Policy PDP?

  *   See feedback from WIPO in the discussion document.
  *   This was part of a public comment proceeding that was open to everyone.  We didn’t seek target input from them or other providers.
  *   WIPO comments seem to be related to people not following the policy.
General Discussion:

  *   NACKing could still happen after a transfer if there is evidence of fraud.
  *   One of the questions we need to resolve is whether or not the lists and groupings are correct for when one MAY or MUST NACK.  Also, is the terminology correct?
  *   We should rename NACK.  “NACK” is “Not acknowledge”. I was always confused when I saw that working at ICANN Compliance. I think deny is more logical (and obvious to anyone to reads the term).
  *   The groupings seem correct but we could review the reasons within the group.
  *   Move the NACK timing to when the TAC is requested, not when it is provided.
  *   It is easier to NACK in the pre-TAC creation time.
  *   Of the groupings – the MUST and MAY NOT are more rigid, the MAYs are flexible.
Discussion re: The reasons the Registrar of Record MAY deny a transfer request:

  *   We should consider (1) should it be removed; (2) should it be moved to a different section.
  *   Seems that the reasons for MAY deny all belong on the list.  We can confirm what’s in the policy.
  *   Update the transfer contact so it is consistent with the EPDP Phase 1 recommendations.
  *   Under current recommendations 3.7.5 & .6 could become MUST.  Maybe 3.7.2 also should be a MUST, as well as 3.7.4.
  *   Question: Are we talking about denying the transfer, or denying the provision of the TAC?  Answer: We need to be clear on this. You never deny a transfer, but you deny a transfer request all the way up until the transfer occurs.  So do we say that these are the reasons to deny a transfer request?
  *   Two points: 1) this is the brainstorming phase of the discussion, but a poll could help with the review the of lists; 2) for consideration: what is the specific reason why any of these need to remain as a MAY?  We are trying to avoid MAYs in policy.
  *   Note that if it is not in the MAY section, you are not allowed to do it.
  *   Maybe they belong in "MAY" to indicate that the Rr has option to determine if that evidence is compelling enough to warrant denial or not.
  *   For the first 3 on the list it is important that the registrar has the opportunity to review and make a decision.  So they should remain in the MAY section.
Discussion re: the reasons the Registrar of Record MUST deny a transfer request:

  *   We should consider (1) should it be removed; (2) should it be moved to a different section.
  *   Update 3.8.5 with the new timeline if not 60 days.
  *   3.8.5: Phase 1a and 1b – this is likely going to be untouched until we have our deliberations in Phase 1b on change of registrant (COR).
  *   Could combine 3.8.1 and 3.8.4 (URS and UDRP proceedings).  Not sure if calling them out makes it clearer.  The difference could be that a pending UDRP could be officially commenced, but for 3.8.4 it could be an intent to commence a URS.  May need to clarify if combined especially where the information (informing the registrar) is coming from.  The nuance has nothing to do with whether a UDRP or URS is filed, so we could clarify, the relevancy is when the registrar is notified by the provider that there has been a UDRP has been filed. The case has to actually been filed by the provider and is ongoing.
  *   In the URS, the registry applies a lock that the registrar cannot undo.  Registries apply a lock when notified of an URS action.
  *   At that the time that section 3.8 was added to the policy, there was no mention of the registrar so that language was added (“Registrar informed of”).  Wanted to make sure that a registrar wasn’t being penalized for something they were unaware of.
  *   For 3.8.5: Couldn’t we just remove the 60 days?
  *   There will be an opportunity to adjust after the COR discussions for the Phase 1 Final Report.
  *   For 3.8.2: what is a competent jurisdiction?  It is one that the registrar is subject to.
  *   Seems that there is agreement that these reasons belong in this MUST deny list.
5. AOB (5 minutes)

     *   Next call: Tuesday 22 February 2022 at 16:00 UTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220215/f0be4d78/attachment-0001.html>