- GNSO-TPR - lists.icann.org

Post Call | Transfer Policy Review PDP WG | Tuesday, 01 March 2022
by Julie Bisland March 1, 2022

March 1, 2022

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 01 March 2022 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/JhAiCw> (attendance included) and the GNSO Master calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call as a Panelist, observers can join as an Attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-tpr/> and the main wiki page<https://community.icann.org/x/P4aUCQ>. Thank you. With kind regards, Julie

1 0

Notes and action items - TPR WG Meeting #38 - 01 Mar 2022
by Julie Hedlund March 1, 2022

March 1, 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, 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/1L2bZnhJUY3Vx…> 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/1L2bZnhJUY3Vx…> 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-concernin…<https://www.google.com/url?q=https://www.icann.org/en/announcements/details…> : “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

1 0

ICANN73 Virtual Community Forum | Guidelines for Speakers
by Devan Reed March 1, 2022

March 1, 2022

Dear all, As we are just a week away from the ICANN73 Virtual Community Forum, the ICANN Language Services Team has created a document to serve as a guideline for speakers. As a reminder, GNSO-supported ICANN meetings do not use interpretation services. However, the reminders and pointers included are useful for all. Thank you! Kind regards, Devan

1 0

**STARTING IN 15 MINUTES** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 01 March 2022 at 16:00 UTC
by Julie Bisland March 1, 2022

March 1, 2022

**STARTING IN 15 MINUTES** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 01 March 2022 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/JhAiCw * Check your time zone: https://tinyurl.com/bdzeuust [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/bdzeuust__;!!PtGJab4!uh4_mVt…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 01 March 2022 at 16:00 UTC
by Julie Bisland Feb. 28, 2022

Feb. 28, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 01 March 2022 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/JhAiCw * Check your time zone: https://tinyurl.com/bdzeuust [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/bdzeuust__;!!PtGJab4!uh4_mVt…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Proposed agenda for meeting #38 on Tuesday 1 March 2022 at 16:00 UTC
by Emily Barabas Feb. 24, 2022

Feb. 24, 2022

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 1 March 2022 at 16:00 UTC. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #38 Proposed Agenda 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 1. Continued deliberations on Denial of Transfers (60 minutes) * Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…> 2. Begin discussion on bulk use cases (15 minutes – time permitting) 3. AOB (5 minutes) * Next call: ICANN73 session on Tuesday 8 March 2022 at 14:30 UTC

1 0

Notes and action items - TPR WG Meeting #37 - 22 Feb 2022
by Julie Hedlund Feb. 22, 2022

Feb. 22, 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, 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/1L2bZnhJUY3Vx…> 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

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 22 February 2022
by Julie Bisland Feb. 22, 2022

Feb. 22, 2022

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 22 February 2022 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/d4HOCg> (attendance included) and the GNSO Master calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call as a Panelist, observers can join as an Attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-tpr/> and the main wiki page<https://community.icann.org/x/P4aUCQ>. Thank you. With kind regards, Julie

2 1

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 01 March 2022 at 16:00 UTC
by Julie Bisland Feb. 22, 2022

Feb. 22, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 01 March 2022 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/JhAiCw * Check your time zone: https://tinyurl.com/bdzeuust ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

**On in 2 minutes** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 22 February 2022 at 16:00 UTC
by Julie Bisland Feb. 22, 2022

Feb. 22, 2022

**On in 2 minutes** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 22 February 2022 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/d4HOCg * Check your time zone: https://tinyurl.com/5evk4n39 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/5evk4n39__;!!PtGJab4!rwra4UA…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0