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, 08 March 2022 at ICANN73 at 10:30 local San Juan time/14:30 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: Continued deliberations on Denial of Transfers (NACKing) (60 minutes) -- see: Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vxy...> WG members to review the comments in the document, beginning on page 1, and are encouraged to add comments and suggestions. 3.7.3: ACTION ITEM: Staff to research to see if there is background as to why this sentence is included: “In all such cases, however, the domain name must be put into "Registrar Hold" status by the Registrar of Record prior to the denial of transfer.” ---- Transfer Policy Review Phase 1 - Meeting #38 Tuesday 01 March 2022 at 16:00 UTC 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) * The Business Constituency will have a dedicated call in about three weeks to discuss transfer locks and will report back. * Met yesterday (Monday, 28 February) with WIPO and FORUM for clarity on charter question two. Agreed that a lot of the issues apply to RPMs PDP Phase 2, but there could be a couple of points to discuss with this group to decide either to address or refer them. 3. Continued deliberations on Denial of Transfers (NACKing) (60 minutes) -- see: Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vxy...> Charter Question: 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? Discussion of Comments (beginning on page 1): 3.7.1 Evidence of fraud. * This wording is tricky – not sure about the definition of “fraud”. * Thought we discussed the violation of registration agreements rather than fraud. * Could be changed to “fraud, abuse, or violation of the registration agreement”. * From ICANN Compliance: ICANN doesn’t have a list of activities that could be defined as fraud, but when the registrar provides us with the reasons, usually these cases include activities by non-registrants, or violations of registrars’ terms of use. * This has been used for years and appears to function okay, but maybe it could be more clear. 3.7.2 Reasonable dispute over the identity of the Registered Name Holder or Administrative Contact. * Reasonable concern over the validity of the transfer request. * Reasonable concern that the transfer was not requested by the registered name holder. * Reasonable concern over the identity of the Registered Name Holder, that the transfer was not requested by the RNH, or that the transfer request is otherwise not valid. That last catch-all is fairly broad and might encompass too much. * Might want to rephrase it and not use the word “identity”. * Focus on ownership, rather than identity. 3.7.3 No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired. In all such cases, however, the domain name must be put into "Registrar Hold" status by the Registrar of Record prior to the denial of transfer. * From ICANN Compliance: WG should consider providing guidance on the expiration date, or for previous or current registration period – which date is it? * What typically happens is when the domain expires at the registry the name will be auto-renewed at the registry on the day of expiration, which will advance the registration date by a year, but the registrar will not update their dates – so these dates will be out of sync. The registrar won’t update the dates until they receive payment from the RNH. * How can we account for the above in the wording here. * There is a mix of registry and registrar registration dates, so we have to make sure for the end users to identify which date it is. * Maybe the expiration date should say “registrar” since that is what the registrar is using. So, change to “past its “registrar expiration date”. * Question from Sarah Wyld: “What is “Registrar Hold”? Answer: That could mean “ClientHold”status, but perhaps this is wording from the contract? Registrar Hold is something that is a disruption of DNS performed at a registrar which does not have an EPP Status. * Would it be more specific to use “EPP Status” such as “ClientTransferProhibited”? * We need to use a term that everyone will understand in the same way, which would then be “ClientHold” and make sure it’s consistent. * There is a challenge in that Client-Hold is something that is used in combatting abuse often. * Domain Status: clientHold https://icann.org/epp#clientHold; Client-Hold does not lock a name from transferring, though, all it does is remove a domain name from having its nameservers listed. * so one would, in order to effect 3.7.3 as worded, put both Client-Hold and clientTransferProhibited. * Not sure we need this last sentence – not sure it helps. Maybe remove it? If so we may have to be more specific on what we mean. * After the domain has expired, the period of renewal can be done otherwise the redemption period also affects the transfer. * This was put here so that the customer knows they have a situation they need to correct, because they otherwise they won’t know. * Suspect this disruption of DNS is present to respect obligations in a separate document. The goal was to get the registrant's attention that the name was expiring - so the DNS disruption would ensure awareness. Maybe expired registration recovery policy (ERRP)? * Consider removing if research can’t determine the purpose behind this sentence. ACTION ITEM: Staff to research to see if there is background as to why this sentence is included: “In all such cases, however, the domain name must be put into "Registrar Hold" status by the Registrar of Record prior to the denial of transfer.” 3.7.4: Move to a “MUST” and update “Transfer Contact”. 3.7.5: Move to a “MUST” potentially. Poll to aid in discussion (continued from meeting #37): NOTE: Some of the provisions below are only displayed in part due to character limits in the polling tool. In such cases, the text ends with “. . .” Reasons that the Registrar of Record MAY deny a transfer request, Cont. 3.7.6 A domain name is within 60 days (or a lesser period to be determined) after being transferred. . . * Leave as MAY and keep language as-is – 7% * Leave as MAY but make edits – 20% * Change to MUST – 60% * Other/don’t know – 13% Discussion: * Dependent on future discussion on transfer disputes. * 3.7.5 and 3.7.6 are VERY interdependent upon what sorts of restoration/clawback outcomes our group will discuss. MUST vs MAY and what these timeframes are will be intertwined with the REVERSAL options. X number of subsequent transfers might be considered. Rr A to Rr B, Rr B to Rr C within a particular timeframe to complicate REVERSAL. Reasons that the Registrar of Record MUST deny a transfer request 3.8.1 A pending UDRP proceeding that the Registrar has been informed of. * Leave as MUST and keep language as-is – 71% * Leave as a MUST but make edits –14% * Change to MAY – 7% * Other/don’t know – 7% Discussion: * Possibility to combine with 3.8.4. * Providers noted that some registrars take a complaint as valid when received and lock but without provider acknowledgement/notification. Could be helpful to have more precise language, perhaps referencing the UDRP rules. * There also is a situation where someone emails a registrant that they intend to file a UDRP – but is that formal notification? * There are points before determination of a valid complaint that the registrar may lock. Call out the UDRP rules that the provider has to notify everyone of a complaint. * We don't contemplate quantity of Inter-Registrar transfers within a timeframe and probably should consider introducing a maximum quantity of transfers within a particular timeframe. This would best be at the registry vs being a registrar obligation, and it would be, like 3.7.5 and 3.7.6, interdependent upon REVERSAL. * Need to come up with language of when the proceeding really starts, such as tying it to the UDRP rule of the provider giving notification to the registrar, etc. 3.8.2 Court order by a court of competent jurisdiction. * Leave as MUST and keep language as-is – 82% * Leave as a MUST but make edits – 18% * Change to MAY – 0% * Other/don’t know – 0% Discussion: * Agreement to leave as a MUST but perhaps with edits. * Requiring the court order to be domesticated to a relevant jurisdiction seems reasonable. 3.8.3 Pending dispute related to a previous transfer pursuant to the Transfer Dispute Resolution Policy. * Leave as MUST and keep language as-is – 85% * Leave as a MUST but make edits – 8% * Change to MAY – 0% * Other/don’t know – 8% Discussion: * Agreement to leave as a MUST but perhaps with edits. * One person wants to discuss further. * Question: Is the transfer not possible because of a pending proceeding under the TDRP? Answer: Yes, the wording is broader, but that was the intent. * Question: Will we change the TDRP in a way that affects this? Should we make a note to come back to this? Answer: If we make any changes to disputes we should revisit. * WG should think about suggesting changes to language to make it more clear. * Should we clarity what is meant by “previous transfer”? Should we remove "related to a previous transfer pursuant to"? 3.8.4 URS proceeding or URS suspension that the Registrar has been informed of. * Leave as MUST and keep language as-is – 64% * Leave as a MUST but make edits – 36% * Change to MAY – 0% * Other/don’t know – 0% Discussion: * Agreement to leave as a MUST but with edits. * Combine with 3.8.1. * Keeping UDRP and URS in different sections make sense to me since the proceedings are different. * Change to “URS proceeding or suspension”. * Or change to “URS proceeding that the Registrar has been notified of by the Provider in accordance with the URS Rules” (or something like that). * Keep URS and UDRP separate but use parallel/consistent language. * Or use more general terminology: “A rights protection mechanism proceeding that the Registrar has been notified of by the Provider”? * Update so we know the specific point in time when the registrar is informed and where that notice comes from (see wording above). [NOTE: There is no poll question for 3.8.5 since we agreed to revisit and update this following Phase 1b discussion on COR.] Reasons that the Registrar of Record MAY NOT deny a transfer request 3.9.1 Nonpayment for a pending or future registration period. * Leave as MAY NOT and keep language as-is – 46% * Leave as a MAY NOT but make edits – 54% * Remove from list – 0% * Other/don’t know – 0% Discussion: * Agreement to leave as a MUST but with edits. * From ICANN Compliance: Recommend adding clarification regarding transfer requests made during Auto Grace Renewal Period. As a starting point, please see the Registrar Advisory provided at: https://www.icann.org/en/announcements/details/registrar-advisory-concerning-the-inter-registrar-transfer-policy-3-4-2008-en<https://www.google.com/url?q=https://www.icann.org/en/announcements/details/registrar-advisory-concerning-the-inter-registrar-transfer-policy-3-4-2008-en&sa=D&source=docs&ust=1646154662406753&usg=AOvVaw3zbbseVs_sDLBJr54SD7I7> : “In those cases where a registrant has paid all past registration fees, but has not paid for renewal, and the domain name is in the Auto-Renew Grace Period, registrars are prohibited from denying a transfer request, as a registration in the Auto-Renew Grace Period is either a "pending or future" registration, during which time the Transfer Policy prohibits denial of transfers on the basis of non-payment.” * Perhaps a 'provided, that any autorenewal costs borne by the registrar are reversable for future period' on 3.9.1 refinement. 3.9.2 No response from the Registered Name Holder or Administrative Contact. * Leave as MAY NOT and keep language as-is – 25% * Leave as a MAY NOT but make edits – 50% * Remove from list – 8% * Other/don’t know – 17% Discussion: * General agreement to leave as MAY NOT, but some would like to discuss, and one would like to get rid of it. * WG should consider whether there is a reason for this or whether it helps. * From ICANN Compliance: Might be related to the Gaining FOA, which required an affirmative response from the RNH. * Is non-response a valid reason for denial? * This seems obsolete. Since we are changing the Gaining and Losing FOA maybe this should go away. NOTE: Take up the remainder of the poll responses and review comments at the PDP WG meeting at ICANN73. 4. AOB (5 minutes) * Next call: 08 March 2022 at ICANN73 at 10:30 local San Juan time/14:30 UTC