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, 01 March 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: Denial of Transfers (NACKing): ACTION ITEMS: 1. Staff to add as a suggestion to the MAY list that a registrar MAY deny a transfer if that transfer violates its registration agreement or terms of service. 2. WG members to review suggested revisions provided by Sarah Wyld. 3. WG members to add language to 3.7.4 to update it and make it clearer. Bulk Transfers: ACTION ITEM: WG members to review the charter questions and consider whether they need to be modified or added to, particularly, b5 which is about bulk use of Auth Info Codes, and whether the other two charter questions that relate to ICANN approved transfers need to be addressed in Phase 1A. Transfer Policy Review Phase 1 - Meeting #37 Tuesday 22 February 2022 at 16:00 UTC 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) * Delaying discussion on the question on the second charter question on NACKing after we’ve talked with WIPO and FORUM about their comments. * This week is the Pre-ICANN73 prep week and Roger is participating in the policy update webinar for the Council later today. * ICANN73 meeting is scheduled for Tuesday, 08 March at 14:30 UTC (10:30 local time). * We will skip the regular weekly meeting the week after ICANN73 on Tuesday, 15 March. 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? ICANN Org Compliance Input on Denial of Transfers: * In general when Compliance investigates transfer complaint we ask detail on how the transfer policy has been followed in specific cases. * Registrars often unlock and let registrants transfer, and this might be affected by local laws, such as requests from governments to lock a domain name. * Registrars may set their own domain name abuse policies, which could go beyond transfer policy, as long as these don’t contravene the registrar agreement or local laws. * Compliance has to determine how the registrar has followed the transfer policy and/or the RAA. Would like to make this determination as straightforward as possible under current policy or recommendations for changes to current policy. * Most of the complaints get closed because the registrar demonstrates compliance. Discussion: * It may be that there is a violation of the RAA, but not necessarily domain name abuse. * If we detect abuse then there is an investigation and then the registrar notifies the registrant accordingly and this would be well documented. Not sure why a registrant would then complain to ICANN. * Under current transfer policy when a registrar denies a transfer under 3.7 under the policy they have to provide a reason to the registrant. * Let’s not make this about abuse but general violation of agreement. the registrar has to communicate the reason clearly. * Do we add to the list that a transfer MUST or MAY be denied if it violates the registration agreement? Seems that it would fit in the MAY list. MAY deny transfer when it violates their registration agreement. * Think about reasons that are not illegal but are a violation of the registration agreement. Illegal or legal issues would likely be in the registration agreement. * Per Compliance re: reasons for denial 3.9.1 Nonpayment for a pending or future registration period – unclear language is causing confusion where registrars are asking for clarification regarding scenarios of transfers during a renewal period where registrants have not paid renewal fees. What Compliance is doing is notifying registrars that registrars cannot deny a transfer if nonpayment is for a past registration period. Helpful to have more clarifying language in the policy on this point since the current language only applies to pending or future nonpayment: “3.8.1 and 3.9.1 Nonpayment for a pending or future registration period.” (Emphasis added.) * What's expected by the typical registrant: They want to transfer a domain without looking on upcoming renewals. Especially if there are only a few days difference. * Per Compliance: any date after the expiry period during that transfer period the transfer cannot be denied. * There is a lot of confusion on the timing and registrars apply the timing differently. Is there a definition for when a transfer is started? * Under the new recommendations it’s when the Gaining registrar provides the TAC to the registry, nearly simultaneously. Up until that time it is just a request to transfer. ACTION ITEM: Staff to add as a suggestion to the MAY list that a registrar MAY deny a transfer if that transfer violates its registration agreement or terms of service. Poll to aid in discussion: 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 3.7.1 Evidence of fraud. * Leave as MAY and keep language as-is -- 50% * Leave as MAY but make edits – 29% * Change to MUST – 14% * Other/don’t know – 7% Discussion: * Majority to leave as MAY but with some edits such as to incorporate the registrar agreement. * If you change to MUST how do we handle the issue of the registrar agreement. * Seems that if there is evidence of fraud it is a requirement to stop the transfer – so change it to MUST. * Illegal activity is jurisdiction specific – edit the language accordingly. * Maybe fraud needs to be defined. Maybe: "evidence of fraud, illegal activity, or breach of the Registration Agreement" Or “abusive activities”? * Is the transfer itself evidence of fraud, or something else. * Clarify 3.7: Separate the reasons why, so start this sentence as a separate bullet point: “The Registrar of Record MAY deny a transfer request only in the following specific instances: (emphasis added)” ACTION ITEM: WG members to review suggested revisions provided by Sarah Wyld. 3.7.2 Reasonable dispute over the identity of the Registered Name Holder or Administrative Contact. * Leave as MAY and keep language as-is – 23% * Leave as MAY but make edits – 69% * Change to MUST – 8% * Other/don’t know – 0% Discussion: * Majority suggest to leave as a MAY but update the language concerning the Administrative Contact. * Change it to say who is authorized to make a transfer for the RNH. This would be a big change. Should the identity idea disappear? Is it too broad? Think about how it could be abused. * Would we still be able to deny if there is a dispute over identity if we make it too broad? * If the request to transfer is not from the RNH then it would be invalid. * Could keep it and add another more broad-based reason. 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. . . * Leave as MAY and keep language as-is – 20% * Leave as MAY but make edits – 73% * Change to MUST – 7% * Other/don’t know – 0% Discussion: * “Registrar Hold” is ambiguous. Opportunity to clarify. * Agreement to keep it in MAY but need clarification on the time period, particularly concerning future nonpayment. Allowing some flexibility for business models but updated for clarity. * Reason to change to MUST, when there is nonpayment the registrar should be putting a lock on. Changing it to MUST gives the registrar a bit more authority. * If renewed and not paid they should be forced to pay before transferring. * WG members should add comments to the list. 3.7.4 Express objection to the transfer by the authorized Transfer Contact. . . * Leave as MAY and keep language as-is – 11% * Leave as MAY but make edits – 33% * Change to MUST – 44% * Other/don’t know – 11% Discussion: * This can be updated for clarity. * Maybe ask ICANN Compliance to provide data as to when this happened, if ever. From Compliance – has happened under instances of privacy proxy; another case is when the Admin contact wants to transfer but the Transfer contact doesn’t. May not be applicable anymore. Update with current language to cover privacy proxy instances. * If it’s a direct objection seems like it should go into the MUST list. * Seems like leaning toward MUST. * Need to update the language. * Maybe the account owner requests the transfer but the RNH doesn’t want it – cover that? * WG members to add language to update it and make it clearer. ACTION ITEM: WG members to add language to 3.7.4 to update it and make it clearer. 3.7.5 The transfer was requested within 60 days of the creation date as shown in the registry Whois record for the domain name. * Leave as MAY and keep language as-is – 0% * Leave as MAY but make edits – 54% * Change to MUST –23% * Other/don’t know – 23% Discussion: * It depends on whether we change the timing: if we change it to 10 days then it probably shouldn’t be a MUST. * If a MUST then the registrar couldn’t transfer even if the registrant was willing, but might not matter if it’s a shorter lock period. * But complicated transfer issues couldn’t be done in 10 days – so probably should be MUST. * Some were recorded as MAY but changed to MUST. 4. Begin discussion on bulk use cases (15 minutes – time permitting) ACTION ITEM: WG members to review the charter questions and consider whether they need to be modified or added to, particularly, b5 which is about bulk use of Auth Info Codes, and whether the other two charter questions that relate to ICANN approved transfers need to be addressed in Phase 1A. 5. AOB (5 minutes) * Next call: Tuesday 1 March 2022 at 16:00 UTC