March 2023 - GNSO-TPR - lists.icann.org

Proposed Agendas - TPR Sessions - ICANN76
by Emily Barabas March 7, 2023

March 7, 2023

Dear all, As a reminder, the working group will have two working sessions at ICANN76: Session 1<https://community.icann.org/display/TPRPDP/2023-03-11+ICANN76+Transfer+Poli…>: Saturday 11 March from 9:00 – 10:00 EST Agenda 1. Introduction to the PDP and current topics under discussion 2. Discussion of Charter Questions<https://docs.google.com/document/d/1i6tLO_qbSa-ace0BnKaAn7voP1UA1RjYlrRo2Zn…> related to the Transfer Dispute Resolution Policy (TDRP) 3. Closing Session 2<https://community.icann.org/display/TPRPDP/2023-03-12+ICANN76+Transfer+Poli…>: Sunday 12 March 2023 from 10:30 – 12:00 EST Agenda 1. Introduction 2. Gap Analysis - Reversal of Inter-Registrar Transfers 3. Closing We look forward to your participation! Kind regards, Caitlin, Julie, Berry, and Emily Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 07 March 2023
by Julie Bisland March 7, 2023

March 7, 2023

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 07 March 2023 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/M4w-DQ> (attendance included) and the GNSO Master calendar<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * 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

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 28 March 2023
by Julie Bisland March 7, 2023

March 7, 2023

The TPR WG will meet during ICANN76 Cancún: Saturday, 11 March 2023 at 09:00-10:00 local time (14:00 UTC) in room Gran Cancún 2 (GNSO)-session link<https://icann76.sched.com/event/1J2Ko/gnso-transfer-policy-review-pdp-worki…> Sunday, 12 March 2023 at 10:30-12:00 local time (15:30 UTC) in room Gran Cancún 2 (GNSO)-session link<https://icann76.sched.com/event/1J2Kr/gnso-transfer-policy-review-pdp-worki…> **Zoom participation links will be published (see session link) 24 hours before the session starts Reminder: you must be registered for ICANN76 Below are the details for the next scheduled meeting after ICANN76: ************************************************************* Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 28 March 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/6oLKDQ * Time conversion link: https://tinyurl.com/2p95cn6r ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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

Notes and action items - TPR WG Meeting #83 - 07 March 2023 at 16:00 UTC
by Julie Hedlund March 7, 2023

March 7, 2023

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meetings will be at ICANN76 with remote access: Session 1: Saturday, 11 March at 09:00-10:00 Cancun (UTC-5) 14:00 UTC Session 2: Sunday, 12 March at 10:30-12:00 Cancun (UTC-5) 15:30 UTC Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: Re: TDRP -- Staff to research whether there are materials describing the goals of the TDRP. Notes: Transfer Policy Review - Meeting #83 Proposed Agenda 07 March 2023 1. Roll Call & SOI updates - Carolyn Mitchell, new Alternate from the RySG. 2. Welcome and Chair Updates * Reminder that we have two sessions coming up in Cancun. The first will be on Sat 11 March from 9:00-10:00 local time. The focus will be on continuing to work through our TDRP charter questions. The second session will be on Sun 12 March from 10:30-12:00 and will be focused on the "gap analysis" of any unmet needs not covered by the current TDRP and TEAC. Folks are encouraged to think ahead about what they think is missing, to ensure we have a productive conversation. * Next, the request for early input on group 2 topics went out to SO/AC/SC/Cs last Tuesday. Input is requested by 4 April. WG members are encouraged to flag this in their internal group meetings during ICANN76. * Work Plan: No open action items at the moment. Today we will talk about the TDRP and in the first session at ICANN76 on the Saturday. Once we've done the gap analysis discussion, we may want to revisit the sequence of discussion of TDRP and TEAC charter questions based on any unmet needs identified by the group. But for now, this is the sequence of topics as planned. We will be adjusting the work plan as it develops. Plan to wrap up the charter questions by early June. * TPR is also on the agenda in the Sunday March 12 afternoon TechOps Session 1 at 13:15. * Owen Smigelski: During the RySG/RrSG meeting at ICANN76 we will be talking about TPR. 3. Introduction to Transfer Dispute Resolution Policy Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1i6tLO_qbSa-a…> and discussion Overview of the Working Document: * Main inputs are the survey inputs from the Policy Status Report. See https://www.surveymonkey.com/results/SM-Q2J8JZRQV/. Responses are from 2018. * Excerpts in the Working Document as they relate to the TDRP. * Cases: ADNDRC: https://www.adndrc.org/decisions/tdrp, FORUM: https://www.adrforum.com/domain-dispute/search-decisions * Just a few charter questions on whether the TDRP is doing its job and whether it is effective. * ICANN Compliance has no other data – there were some cases that stated that they were related to the TDRP, but when investigated it was found that they were not related. * WG members should review: * Section 3.1 of the Transfer Dispute Resolution Policy<https://www.icann.org/resources/pages/tdrp-2016-06-01-en> specifies information that must be included with the complaint. * Section 3.2.1 of the Transfer Dispute Resolution Policy<https://www.icann.org/resources/pages/tdrp-2016-06-01-en> specifies information that must be included in the response by the respondent. * Charter questions relating to data retention and data protection policy: * g4) Are requirements for the processing of registration data, as specified in the TDRP, compliant with data protection law? * g5) Are requirements for the processing of registration data, as specified in the TDRP, appropriate based on principles of privacy by design and data processing minimization? * Note: Justification for retention relating to GDRP, depends on what is needed for the Transfer Policy. These questions should not be looked at in isolation, but they hinge on what is in the draft data retention policy and the 15-month data retention. * WG members should review Sections 3.1.2 and 3.1.4 of the Transfer Dispute Resolution Policy for additional context on this question. See: https://community.icann.org/display/RDPIRT/RegDataPolicy+Implementation+Res… * Question: Is it documented as to what the goals of the TDRP are? So we can gauge the effectiveness? Answer: Not sure the goals are laid out, but the purpose is to resolve a dispute. Question relates to the gap analysis the WG will be discussing at ICANN76. * Question: Can a RNH initiate a TDRP without a registrar? Answer: It technically has to come from the losing registrar (which could be initiated by a RNH) – it is one of the questions the WG will be considering. * This is a question that the IRTP D group previously reviewed - should domain name holders have direct access to the TDRP. https://gnso.icann.org/sites/default/files/filefield_46639/irtp-d-final-25s… (The WG did not recommend to open the TDRP up to registrants during this review.) * Staff: Not clear that opening up the TDRP to RNHs or accreditation are in the scope of this PDP; WG should focus on the charter questions. * Questions: Isn’t the charter question G3 an opportunity to look at opening the TDRP to the RNH? Answer: Not specifically. If we see the TDRP is insufficient it is for the WG to identify it or not. Another group could take this up. ACTION ITEM: Re: TDRP -- Staff to research whether there are materials describing the goals of the TDRP. Poll: Q1: As it currently stands, do you believe the TDRP is an effective dispute resolution mechanism? 1. Yes – 8% 2. No – 67% 3. Not sure/no answer – 25% Discussion/Results: * Majority think it’s not working in its current form. * What’s the argument saying this is effective? * No one uses it – is that to say it’s not effective? Q2: Is the current statute of limitations for the TDRP appropriate? In other words, is 12 months from the date of the alleged improper transfer an acceptable deadline to file a TDRP complaint? 1. Yes, it is appropriate. – 27% 2. No, it should be shorter. – 55% 3. No, it should be longer. – 18% Discussion/Results: * Question: Are we assuming that the TDRP is the only part of the timeline? Answer: TEAC is a part of the transfer dispute process – so the 12 months is for an overall process. We can come back to this as part of the gap analysis. * If shorter we’ll need to think about why and how long. * For longer – concern was the legal requirement of discoverability, which could require more time. * Don’t think it can be longer because the domain name might have expired. * If the domain name is expired then the procedure couldn’t be used. * Time period depends on what problem we are trying to solve. Can’t know until we know the problem. * Could look at the date of the last transfer for transfers that happened in the last two years. Look also at the lock-in periods. * The IRTP Part D Working Group’s Recommendation 5 resulted in the extension of the statute of limitations to initiate a TDRP from 6 months to 12 months. In its deliberations, the Working Group noted that many registrants do not regularly check the status of their domain names, and therefore 6 months may not be long enough to notice a disputable transfer and notify the registrar, who in turn would need to initiate a dispute. The Working Group considered registrars’ obligation under the Whois Data Reminder Policy (WDRP) to contact registrants annually, and noted that an extension to 12 months may be desirable in this regard. According to the Working Group’s Final Report, the extension could “mitigate multi-hop transfer problems by providing the losing registrant additional ‘reaction time’ to inquire with their registrar after they did not receive their annual reminder to update their contact information.” In addition, the Working Group did not believe that that extension unduly burdened legitimate transfers. * Would need to think about whether it should be shorter or longer and WG would have to agree on a change from status quo and why. Q3: What do you believe is the main factor that results in the low number of TDRP filings? 1. Cost of filing a TDRP complaint (loser pays model) – 0% 2. Registrars work out the issue amongst themselves and do not resort to filing a TDRP – 30% 3. Length of time between filing and panel decision – 0% 4. Not sure/no answer – 10% 5. Other – 60% Discussion/Results: * Some WG members selected “other” as an all of the above. Q4: Currently, only registrars have standing to file a TDRP claim. Is this appropriate, or should registrants also have the ability to file a TDRP claim? 1. It should remain as is - only registrars may file – 60% 2. Registrants should also have the ability to file a claim. – 20% 3. Not sure/no answer – 20% 4. Other – 0% Discussion/Results: * If there was a separate service, it should be available to registrants, but there isn’t so TDRP should just be for registrars. A service for registrants would have to be completely different. * We have too make sure that a RNH has an easy way to solve a dispute. * In order to file a TDRP you have to have access to a lot of internal registrar documentation. Also, opening up to non-registrars could allow it to be gamed by bad acters. * A dispute mechanism for registrants could be designed to mitigate gaming. * In the current TDRP, a registrant could file a complaint through their (losing) registrar. That might not be the same as the registrant having its own path. But could we require the registrant to go through a TDRP before going another way. Q5: Are the current reporting requirements appropriate to enable future review of the TDRP? 1. Yes – 20% 2. No – 20% 3. Not sure/no answer – 60% 4. Other – 0% Discussion/Results: * Would any changes create more reporting compliance requirements? Yes, they could. * Currently, the only data publicly available is the summary of cases themselves published on the providers’ websites. * WG should consider if we should be requesting more data. For next meeting: Q6: Are requirements for the processing of registration data, as specified in the TDRP, compliant with data protection law? 1. Yes 2. No 3. Not sure/no answer Q7: Based on the WG’s discussion to date, do you believe additional mechanisms (other than TEAC or TDRP) may be necessary to resolve improper transfers? 1. Yes 2. No 3. Not sure/no answer 4. AOB

1 0

**1 minute!** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 07 March 2023
by Julie Bisland March 7, 2023

March 7, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 07 March 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/M4w-DQ * Time conversion link: https://tinyurl.com/3kkyck24 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3kkyck24__;!!PtGJab4!7iWyrTb…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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

**AT THE TOP OF THE HOUR** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 07 March 2023
by Julie Bisland March 7, 2023

March 7, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 07 March 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/M4w-DQ * Time conversion link: https://tinyurl.com/3kkyck24 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3kkyck24__;!!PtGJab4!7iWyrTb…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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

Re: [GNSO-TPR] TPR-P1 // 28 February 2023 Project Package
by Berry Cobb March 7, 2023

March 7, 2023

Dear WG, Please find a link below to project package for the TPR-P1 PDP (28 February 2023). This package is a snap-shot at the close of each month and developed by the leadership team to report on the working group’s activities and status of the project. It is also distributed to the GNSO Council to keep them informed as managers of the PDP. The package is deposited on the wiki so that we can track access statistics. Link: https://community.icann.org/x/MQDQCQ 1. Page 01 – Summary Dashboard, Project SitRep, and Activity Metrics 2. Page 02 – Meeting metrics, Roster, & Group Attendance 3. Page 03,04 – Project Plan, Gantt chart 4. Page 05 – Workplan Key points: * The package for Feb 2023 is now updated post-approval of the project change request by the GNSO Council at its Feb 2023 meeting. Please let staff know if you have questions. Thank you. B Berry Cobb Policy Development – Senior Program Manager Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 424 443 8960 Phone: +1 202 570 7240 Fax: +1 202 789 0104 Twitter: @berrycobb www.icann.org<https://www.icann.org/>

1 0

Notes and action items - TPR WG Meeting #82 - 28 February 2023 at 16:00 UTC
by Julie Hedlund March 6, 2023

March 6, 2023

Dear TPR WG members, Please find below the notes and action items from yesterday’s meeting. The next meeting will be on Tuesday, 07 March 2023 at 16:00 UTC. Please contact the GNSO Secretariat at gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> ASAP if you cannot attend. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: Actions from Meeting on 21 February (ongoing): 1. Re: 07 March meeting -- If WG members cannot attend the 07 March meeting please let the Secretariat staff know at gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> so we can decide if we have enough attendance to hold the meeting. 2. Re: The time frame (4 hours) for registrars to respond to communications via the TEAC channel – WG members should consider a provisional recommendation to change the time frame to 24 hours. Notes: Transfer Policy Review - Meeting #82 Proposed Agenda 28 February 2023 1. Roll Call & SOI updates 2. Welcome and Chair Updates * We have one more meeting planned before ICANN76, next week on Tuesday, 07 March. If there are a lot of apologies we may cancel, but right now it’s on the schedule. * We have two meetings at ICANN76 on Saturday and Sunday. * We did not receive any input on the questions for early input on the Phase 2 topics so those have been sent out to the SOs and ACs. * On the work plan, we have been keeping it up to date. At the beginning of each meeting we’re going to quickly touch on where we are in the work plan and the items highlighted in green at the top – the outstanding action items: * In particular, please let us know if you can’t attend the next meeting. * WG members also should think about the proposal mentioned last week about possibly changing the 4-hour response window for the transfer emergency action contact to 24 hours. * Also to note that we will be talking about the TEAK for approximately the next 6 meetings, which will put us to the end of April or mid-April. 3. Presentation of ICANN Compliance Metrics – TEAC and TDRP (https://mm.icann.org/pipermail/gnso-tpr/2023-February/000797.html) Holida Yanik, ICANN Compliance: To address the request for metrics from Contractual Compliance: * That was needed during the review of Phase 2 topics relating to TEAC, TDRP, and ICANN-approved bulk transfers. Compliance has prepared the metrics for transfer complaints that we received. * So I want to make a small disclaimer: Contractual Compliance migrated its operations to the Naming Services Portal at the end of August 2020 and the smart forms used after this migration started capturing additional reporting criteria like reporter type. For example, if it's law enforcement, agency or registrar, and subject matter categories for the complaints received and processed. * So, for example, these are whether the complaint specifically refers to non-response to transfer emergency action, TEAC contact, request, and that no complaint type had cases with this complaint category provided in red, and here that means that no other complaints like whether it's renewal, abuse, or anything else. * We’ve reported with this TEAC category selected, so the subject matter category is initially selected by the complainant. * When the complaint is filed with Compliance, and when necessary Compliance amends it; * When the selected category does not properly reflect the issue that the complainant is reporting about; * So additionally invalid complaints like complaints that refer to ccTLD domain names, or to parties over whom ICANN does not have any contractual authority, are closed without initiating a case with the registrar. * So from 01 September 2020 to 31 December 2022 compliance received altogether 162 complaints for which complainant selected the TEAC category. * However, only 5 cases were validated and confirmed to refer to TEAC obligations that are described in the transfer policy, and finally addressed with the relevant registrar. * So, as a further aside, in these TEAC complaints the reported issue was non-response to requests to TEAC contact within the 4-hour time period. * And in all these addressed cases we saw that reported registrants were located in different time zones and all cases have been closed after the reported registrars took corrective actions like allocating special staff that would monitor TEAC contact emails for 24 hours and 7 days a week, and be able to investigate and address urgent transfer matters. * And another interesting point to mention is that in the past Compliance also received feedback from reported gaining registrars concerning the language in which the complaining registrar sent their requests to TEAC. * So the policy states that the goal of the TEAC is to quickly establish a real-time conversation between registrars in a language that both parties can understand in an emergency. * So, but for the receiving registrar, it may take more than 4 hours to translate, understand the matter, and respond if the request was not provided in a language that they understand. * So, I will move to TDRP related complaints. * Compliance received 141 cases where complaint and selected categories, indicating transfer, dispute resolution, policy matters. For example, into registrar transfers or change of registrant requests denied due to ongoing TDRPs. However, no valid case was initiated with the registrar referring to TDRP-related obligations. * Finally, with regard to the request for metrics for compliance metrics relating to ICANN-approved bulk transfers, I would like to clarify that ICANN Contractual Compliance does not track complaints that relate to ICANN-approved bulk transfers, but transfers may occur as a result of complaints received by ICANN Contractual Compliance when such complaints result in termination of the registrar's accreditation and after a bulk transfer has taken place. Compliance sometimes receives complaints alleging unauthorized transfer, because the registrant was not aware of the back transfer, and was either confused by the change, or did not agree to the new registrar as renewal fees or any other term. And in these cases compliance provides the relevant education to the reporter and closes the case because the gaining registrar did not violate any obligations. Discussion: * Question: TDRP I always understood it is a mechanism to dispute transfers. If there was a transfer out that wasn't authorized. So how are the UDRP and the URS tied into the TDRP process? * Answer (Holida, ICANN Compliance): That's a good question. So with within the transfer complaint category we receive complaints from the registrants that can complain about the transfer requests that were denied by their registrar due to UDRP, URS, or TDRP proceedings. However, we have a separate UDRP complaint, type, category, in which the UDRP complainants complain to Compliance regarding non-implementation of the UDRP decision or the domain name was not locked upon the provision of verification and lock requests by the provider. Those are different complaint, type, categories, and the main difference is who is complaining. Is it the current registrant, or the UDRP, or URS, or TDRP complainant? So this is why, in the transfer category. We have bundled all these UDRP, URS, and TDRP proceedings for the complaining registrants to complain about the he registrar of record that is denying COR transfer due to these pending proceedings. * Question re: the TEAC non-response: How many registrars were non-responsive to the TEAC request out of those numbers? Also do we know from the non-responses if the registrar then remediated the issue with ICANN Compliance? * Answer: (Holida, ICANN Compliance): So these 5 validated complaints that we received and addressed since September 2020 does not mean that they were 5 different registrations. They were multiple complaints and validated, and addressed with the same registrar and at the same time we had some cases that the reporting registrar had issue with the same gaining registrar not responding about multiple domain names, and the TEAC request was sent to at the same time but separately. And so the number of complaints does not mean that they were this number of non-compliant registrations. And as for the reason the receiving registrars brought us this as a reason for non-response, for quite different, most of them for small registrars. Maybe they were a couple of persons working as a registrar, and they were not able to monitor the emails or monitor the TEAC contact for 24 hours, and after the case was addressed to them, they said that we took corrective action, and we assigned an additional personnel or hired additional staff specifically for this purposes that would be monitoring the TEAC emails for 24 hours. However, we closed all those cases with the relevant resource code that the registrar took corrective action. However, after these cases were addressed with them, we didn't have any reoccurring instances, or any repeated complaints about those registrants. And at this stage, where we see the evidence of the responses and the copies of communication. There is nothing to do for compliance other than closing. * Re: low numbers there are probably several reasons but the biggest one is that most of the time registrars work together to resolve the issues and a TDRP doesn’t get filed. * Maybe we should look at the fees associated with the TDRP and whether they are too high. 4. Continued Discussion of Transfer Emergency Action Contact (TEAC) (working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1ejqMnKrN5Pnq…>) Poll: What is an appropriate deadline for initial response by the TEAC? 1. 4 hours (status quo) 2. 24 hours 3. Other 4. Not sure/no answer Discussion: * I don't feel that I yet have enough information to make a choice here like are we deciding that the TEAC is the only point of contact that will exist to all, do all transfer problems go through this point of contract? Or is there like some kind of tiered system with low-level problems and big-level problems? Because maybe only some transfer issues need a 4-hour response period. * That's kind of the point of the polls, I think, is to try to tease those out. Maybe 4 hours is still appropriate for some level. If there's a tier or a or we think about it. Is there a priority, or is there an urgency to some of them that may dictate? You know a a different set of policy requirements than others * We did get a lot of discussion last week. The thought was that 4 hours was pretty extreme. But it sounds like there should be multiple timeframes there that you're looking at -- if it's a direct customer impact, you know that's bigger -- so maybe there's multiple tiers that we can look at. * There’s a whole level of things that are going on before it even gets to the TEAC. Results: * This is what we heard last week. It's still an unknown thing. But there, there is a thought that that the 4 hours is too restrictive, especially on the outcome of not responding within 4 hours to transfer automatically. You can revert back it doesn't have to, but can revert back. We've got a pretty big granularity here -- 4 to 24 hours -- is there something in between that makes sense? Maybe it’s 12 hours or maybe 24 hours does make sense. Should there be a cutoff timeframe for initial contact to the TEAC following the alleged unauthorized loss of a domain? 1. Yes 2. No 3. No, but add guidance 4. Not sure/no answer Discussion: - Our second question -- should there be a cut off timeline timeframe for the initial contact to the TEAC following the alleged, unauthorized loss of domain? So this this question came up last week as well. - So are we expecting that the TEAC is the only point of contact to raise a dispute with the transfer, or is the TEAC for emergency disputes and other transfer disputes go elsewhere because I feel like that's going to change the answer. - Understanding is that the TEAC is for emergency processes only. Results: * A cut off seems logical, and last week there was discussion around whether the cut off is the same as the transfer prohibited window of 30 days. If it’s after 30 days maybe the TEAC shouldn’t be used. * Question: If there is a cut-off point, what does that mean with respect to policy or operations? * Answer: if there was a transfer on day 35 you wouldn’t be required to respond within that 4 or 24-hour time period. You would follow other processes in place. * Suggest that there could be a standard type of problem – regular and emergency. We can define what is an emergency and who is allowed to say that a certain situation is an emergency, then we could say the registrar could downgrade it to non-emergency under specific circumstances. So maybe with this cut-off time frame they're allowed the domain owners to say, “this is an emergency” even though it's been 40 days since the transfer happened, and normally we should submit within 30. * That question is definitely worth pursuing. Should there be a required timeframe for resolution of an issue raised through the TEAC? 1. Yes 2. No 3. No, but add guidance 4. Not sure/no answer Discussion: * Okay, should there be a required timeframe for resolution of an issue raised through TEAC. Should there be a timeframe for a TEAC or for any dispute? Or one or the other? Results: * Maybe that falls into the unsure ideas. So that's something we can continue to work through. * You can have a scenario. There is no resolution, or whatever reason there is and then it becomes a dispute. So you have another piece of the policy that addresses the dispute part. * Maybe not a lot of different processes but a stronger timeline to get those processes completed. * So if somebody contacts the emergency contact and says, there's a problem. And the decision is okay you're going to work with our transfer dispute team, that's not a resolution, that's passing the problem on to the next team that needs to address it. But if, instead, the emergency contact determines that they cannot resolve the issue and says you're going to need to contact this third party arbitration body that will review the transfer and its side, that's a resolution because you're moving to a completely different process outside of the TEAC and outside of the standard process. * It sounds like we're saying, yes, if it's urgent, then there is a different timeline -- an escalated timeline. Should the WG make recommendations about the TEAC method of contact? 1. No, status quo works 2. Initial contact must be by email, additional channels optional 3. All substantive communications must be by email 4. All substantive communications must be via centralized system 5. Other 6. Not sure/no answer Discussion: - Do we specifically say a TEAC emergency contact has to be a phone number? Can it be anything as long as that mechanism is responding within whatever timeline we're giving it 4 houra or 24 hours? Should those be documented somewhere? And how is that documented? - If it was a centralized system and you were responsible for being notified, you could theoretically select send me a text or send me an email. You could even have the thing phone you. But operationally and being effective, a centralized system would carry a ton of benefits, including the benefit of the documentation. - There was back in the day a centralized system for something like that, just because email is imperfect. - It's a real-time communication is what it says in in the current policy. Results: - What we're seeing the in the discussion we've had is that it kind of leans toward the bottom of this discussion about not sure. - If you're talking about a central system that TAC update becomes less of an issue. The update, you know, when the TAC is updated, sharing that out is less of an important thing if it's a centralized system that's already handling everything. - When we are discussing such a system there will be some hurdles in convincing certain registers in moving that direction, and spend all that money. - The status quo received the smallest number of responses, and so I think that we need to look at some kind of change to this language or functionality. Are any changes needed to enable Rys to validate transfer undo requests when a TEAC allegedly fails to respond in 4 hours? 1. Yes 2. No 3. Other 4. Not sure/no answer Discussion: * There any changes needed to enable registries to validate transfer undo requests when it allegedly fails to respond in 4 hours. * So I think that that's where this question comes up is if that 4 hours is gone and the registrar is claiming they didn't respond, how does the registry consume that information and make sure that it's correct? * I think there's a couple of possible ways to go here. So if the registry is required to validate that the dispute is correct, or that the transfer should be reversed, they need to know not only that the dispute was raised, but also that there was no response within the 4-hour timeframe, and proving that something has not happened is, I think, difficult, unless that whole process of raising and responding to the issue happens through a centralized system. * So the only way we can properly expect a registry to validate that it is a dispute that's been raised and not responded to would be, if it's going through a central system that I don't think we should build. * And then, on the other hand, the other option would be that the registry doesn't have a way to validate it. And so then it's not fair to expect them to do so. So maybe a path to consider would be that if a dispute is sent to the registry, as this was a TEAC it was not responded within the timeframe. You got to reverse it. Maybe the registry is just required to reverse the transfer, and they don't get to make a decision. But then also they're not liable for it. They don't get in trouble if it turns out to have been the wrong decision. * So maybe we have to think about who's responsible and who's liable, and who has access to the information before we can come up with this, and then ultimately also, I would like to hear if the registries have a preference. * It was this very interesting scenario where a registrar in theory could wait weeks before raising at a communication with our registrar, and then if they don't respond within those 4 hours, then the transfer can be 100% reversed. There's no discretion to a registry there to kind of make that determination. There's no ability for other facts or scenarios to be interpreted in there, whether it's reasonable to do or reversal in that, so I think there needs to be a little bit more flexibility for a registry and others to determine whether or not it's a warranted in every scenario. * So if the registries are in a position where there are fewer decisions that is preferable, because right now the registry is in a spot where it's having to make a decision and making that decision typically on very sketchy or suspect information. * So in theory, a registrar who receives a TAC request and responds at 3 h 59 min and says, okay, we're on this and then takes 3 months to resolve the transfer. They're compliant, but a registrar who responds at 4 h 1 min and says, okay, we we're okay. We'll reverse the transfer. That's technically non-compliant and so I think there's a there's a big discrepancy between those two because I think one of them is a much more desirable outcome. The responsive registrar that's dealing with a reversing the transfer although they missed an arbitrary deadline. Versus the other registrar who's just not collaborative, and draws everything out over a period of months. Results: * Seems like there's strong support for changes. The majority see some changes necessary. Should Rrs be required to track and report on TEAC communications to enable future review of the mechanism? 1. Yes 2. No 3. Other 4. Not sure/no answer Discussion: * Should registrar be required to track and report on TEAC communications to enable future review of mechanism. * So this isn't just documented, this is a concept of trying to create metrics, so that it can be reviewed in an ongoing way. * And again, you know we're talking about the transfer specifically here. But should there be metrics for the dispute process in in total? Results: - So good support on requiring something to be tracked, and so this is the point of this question. - We'll get that clarity as we work through that, and then see what's being tracked, and if it is useful or not. 5. AOB

1 1

Proposed agenda for meeting #83 on Tuesday 7 March 2023 at 16:00 UTC
by Emily Barabas March 6, 2023

March 6, 2023

Dear Working Group members, Please find below the proposed agenda for the next meeting scheduled to take place on Tuesday 7 March at 16:00 UTC. As noted in the agenda below, we will be shifting gears tomorrow to lay some groundwork on the Transfer Dispute Resolution Policy charter questions. This will help support the “gap analysis” that the WG will conduct during ICANN76. WG members are kindly asked to review Transfer Dispute Resolution Policy Working Document<https://docs.google.com/document/d/1i6tLO_qbSa-ace0BnKaAn7voP1UA1RjYlrRo2Zn…> before tomorrow’s meeting. Kind regards, Caitlin, Berry, Julie, and Emily Transfer Policy Review - Meeting #83 Proposed Agenda 7 March 2023 1. Roll Call & SOI updates 2. Welcome and Chair Updates 3. Introduction to Transfer Dispute Resolution Policy Working Document<https://docs.google.com/document/d/1i6tLO_qbSa-ace0BnKaAn7voP1UA1RjYlrRo2Zn…> and discussion 4. AOB

1 0

REMINDER | Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 07 March 2023
by Devan Reed March 6, 2023

March 6, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 07 March 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/M4w-DQ * Time conversion link: https://tinyurl.com/3kkyck24 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3kkyck24__;!!PtGJab4!7iWyrTb…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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