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

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

Feb. 21, 2023

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 21 February 2023 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/KIw-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 February 2023
by Julie Bisland Feb. 21, 2023

Feb. 21, 2023

**IMPORTANT REMINDER: There are only 2 more meetings taking place before ICANN76: 28 February (below) and 07 March. Please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> with your regrets if you cannot attend 07 March so we can determine there will be enough attendance to hold the meeting. ******************* Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 28 February 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/MIw-DQ * Time conversion link: https://tinyurl.com/24vu7zj7 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 #81 - 21 February 2023 at 16:00 UTC
by Julie Hedlund Feb. 21, 2023

Feb. 21, 2023

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Tuesday, 28 February 2023 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: Actions from Meeting on 14 February: 1. Re: Data from RADAR relating to TEAC -- Staff will check to see if there is any available data. 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. 3. 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. Notes: Transfer Policy Review - Meeting #81 Proposed Agenda 21 February 2023 1. Roll Call & SOI updates 2. Welcome and Chair Updates 1. Project Change Request, updated project plan, and charter revisions reflecting the new project plan were approved by Council on Thursday, 16 February. Minor revisions, not substantive. 2. Note that we shared ICANN org input on I.A.3.7.1 with the WG. Folks can socialize with their groups and think about it in the background. We will discuss when we return to Phase 1a topics. 3. Members should review the draft outreach letter on phase 2 topics to send to SO/AC/SG/Cs – WG members should share any questions/concerns to the mailing list by Monday, 27 February at the latest. As a reminder, we are not asking anyone to answer the questions at this time, we are just confirming that the letter is ok to send. 4. ICANN76: We have two sessions – first will be a working session on Saturday the 11th, probably on the TEAC; second session on Sunday the 12th will include perhaps more community input, such as on a possible fast undo. First Session is Saturday March 11 at 9:00 local time. Second Session is Sunday March 12 at 10:30 local time. 3. Continued Discussion of Transfer Emergency Action Contact (TEAC) We will be using the following working document to support discussion on TEAC: https://docs.google.com/document/d/1ejqMnKrN5Pnqyne6G4jHj-DPTfFLVidmeSDpyPM… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1ejqMnKrN5Pnq…>. As we move through deliberations on this topic, archived versions of the working document will be kept on the wiki here: https://community.icann.org/display/TPRPDP/Working+Documents Summary of working document: * Current applicable policy language -- I.A. 4.6 Transfer Emergency Action Contact * Survey Inputs from the Policy Status Report at: See https://www.surveymonkey.com/results/SM-Q2J8JZRQV/ * Question 18: Do you think the Transfer Emergency Action Contact (“TEAC”) is an effective way to handle urgent inter-registrar transfer issues between registrars, or does the TEAC process require changes?” See above working document for responses. * Additional Comments in Survey<https://www.surveymonkey.com/results/SM-Q2J8JZRQV/> Responses Related to TEAC/Transfer Reversal. See above working document for responses. * Question 5: The transfer policy has evolved over the last six years. In your opinion, have the policy modifications improved, worsened, or had no effect on the process for transferring domains between registrars and/or registrants? * Question 16: Should there be more standard reporting requirements across registrars as they relate to transfers? If so, what should these reporting requirements include? * Question 19: In general, what issues are your customers having, if any, as they relate to transfers? * Question 21: What do you think the ideal transfer process should look like from a policy and a technical perspective? Discussion on Charter Questions: f1) Is additional data needed to support evaluation of the effectiveness of the TEAC mechanism? If so, what data is needed? * Primary source is survey data from the PSR. Deliberations: * Working group members noted that because TEAC communications may occur through a variety of channels, it is difficult to collect comprehensive data sets on the use and effectiveness of the TEAC across the industry. * Survey responses and anecdotal information may point to pain points and opportunity areas. * Question for further consideration: Could there be requirements going forward that would result in better data to support the next review of TEAC? Discussion: * May not be the best question to start with. * Lack of data is often an issue. Data is what can be gleaned from the survey responses. Can we improve this to ensure there is ongoing data? * Being able to document/log is important -- would that emergency contact be tracked by ICANN, others? How can we track data on an ongoing basis. * Do we have any data from the RADAR days? Might be, but could be a problem because not all communications had to go via RADAR so could be incomplete. ACTION ITEM: Re: Data from RADAR relating to TEAC -- Staff will check to see if there is any available data. f2/f3) The time frame (4 hours) for registrars to respond to communications via the TEAC channel has been raised as a concern by the Transfer Policy Review Scoping Team and in survey responses. Some have expressed that registries must, in practice, have 24x7 coverage by staff members with the appropriate competency to meet this requirement and the language skills to respond to communications from around the world. Is there merit to concerns that the requirement disproportionately impacts certain registrars, namely: i. Registrars located in regions outside of the Americas and Europe, because of significant time zone differences? ii. Small and medium-sized registrars, which may not have a sufficiently large team to have 24x7 staff coverage with the necessary competency? iii. Registrars in countries where English is not the primary language, who may, in practice, need to have English-speaking TEAC contacts to respond to requests in English? To what extent should the 4-hour time frame be revisited in light of these concerns? Are there alternative means to address the underlying concerns other than adjusting the time frame? RrSG comment<https://mm.icann.org/pipermail/comments-irtp-status-14nov18/attachments/201…> on the issue (input to Policy Status Report): There is significant concern with the 4-hour response time requirement… Other input received via survey<https://www.surveymonkey.com/results/SM-Q2J8JZRQV/>: * Response required within 4 hours of the initial request is an unreasonable policy, we suggest to extend the response hour to 12-24 hours. * It needs to be changed on the 4 hours, it is too difficult. * TEAC requires 4 hours response time is unfair and unreasonable for non-English speaking registrars that are in different time zones to those in the US and Europe. Deliberations: * From one perspective, the 4-hour time frame is very rigid. If the TEAC doesn’t respond within the time frame, this is a reason for the transfer to be undone. * At the same time, some noted that this 4-hour requirement may be gamed by bad actors. * From one perspective, there may be an opportunity to be more flexible with the requirement. Perhaps there is another penalty that is not as consequential as a transfer undo. * It was suggested that the required timeframe be contingent on the urgency of the request. * Some working group members pointed out that it may not make sense to have a rigid requirement for initial (often non-substantive) response and no requirements around a timeframe for meaningful resolution (see also f4). Discussion: * Might depend on the reversal process. * Highly unlikely that we could agree on a quick undo process. * Even not a quick undo, but I feel like we need to understand the overall reversal process before we can set timeframes for responses in emergency cases. * Think this a question about which piece of the discussion comes first – consider what could improve the process now. ICANN76 session could be a gap analysis on the TEAC and what needs improvement/needs not being met and possible solutions. Also to get broader community input on fast undo. Might need to toggle between specific charter questions and the bigger picture. * Do we need multiple paths? Do we need an emergency contact and also a regular contact? * Focus on looking what’s there, does it need to change, does it leave a gap? * Multiple WG members agree that 24 hours seems better (then we have to consider if it's business or real time). * Sounds like 24 hours could be an improvement. WG members should consider. ACTION ITEM: 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. f4) Section I.A.4.6.2 of the Transfer Policy states that “Communications to a TEAC must be initiated in a timely manner, within a reasonable period of time following the alleged unauthorized loss of a domain.” The Transfer Policy Review Scoping Team noted that this timeframe should be more clearly defined. Is additional guidance needed to define a “reasonable period of time” after which registrars should be expected to use a standard dispute resolution process? Note: The WG may want to discuss two possible issues: 1. The timeframe for initial contact to the TEAC following the alleged unauthorized loss of a domain. 2. The timeframe for final resolution of an issue raised through the TEAC channel. Relevant RrSG comment<https://mm.icann.org/pipermail/comments-irtp-status-14nov18/attachments/201…> on the issue (input to Policy Status Report): * The TEAC is an effective way to make contact regarding an urgent transfer issue, but it does not go far enough, because it does not require that both registrars work together to investigate and reverse the disputed transfer if needed. The process should be revised to require the two registrars to come to a mutually acceptable resolution, potentially with the assistance of a neutral mediator. Relevant survey<https://www.surveymonkey.com/results/SM-Q2J8JZRQV/> input - Policy Status Report: * Yes, but registrars need to be required to respond to all inquiries and find resolution (whatever it may be) and not just an initial response within 4 hours. We would like to see TEAC be the start of a process requirement where both registrars work to come to a resolution. * . . . What is needed is a deadline by which a TEAC response must give a final answer on whether the transfer will be reversed, not merely a deadline on when they have to send a generic useless response. Deliberations: Regarding time frame for first contact with the TEAC: * From one perspective, if someone doesn’t notice for a long time that the domain has been transferred inappropriately, this may be an indication that the issue is not urgent and therefore the TEAC might not be the right channel for resolving the issue. This may point to a need to define a specific timeframe for first contact to the TEAC. * From another perspective, resolution may still be needed urgently even if the RNH does not realize that there is an issue right away. There should not be a cutoff period for using the TEAC. * Change “reasonable period of time following the alleged unauthorized loss of a domain” to reasonable timeframe from the time that the Rr finds out about the issue. Regarding time frame for resolution: * It was pointed out that some Registars respond quickly with a non-substantive response upon first contact but take a long time to resolve issues. There is no penalty for this currently. * Suggestion: The negative impact of the transfer defines how urgent the issue is and the appropriate timeframe for final resolution. Discussion: * Hard to say what is a negative impact. * Not clear what is a “reasonable” time. * If the transfer has taken place in the distant past (say 6 months) but brought through the TEAC – should be a restriction period, say a week. * Feels like the time to file a dispute should align with the lock period (30 days) though also I like an exception for if the RNH notices it some time later on (I think we saw that last week?). Right - is there a non-emergency path? what are the expectations there? Why don’t we define the process first and then see if we need emergency and not-emergency and when? * A transfer can happen and the DNS could remain the same – so might not be noticed. * How do we define urgency? Should there be a limit? * IRTP came up with reasonable by balancing the variables – number of customers, time frame, etc. For example, if it’s past 30 days do you have to provide a justification to be able to use the TEAC. Should “reasonable” be more precisely defined? * Using 30 days as a restriction seems reasonable, but someone could game the system by waiting until 31 days. Is there a way to have 30 days with an exception to go longer? * What about the time frame for resolution – should it be 7 days? Is there a different time frame for urgent/non-urgent? f5) According to section I.A.4.6.2 of the Transfer Policy, the TEAC may be designated as a telephone number, and therefore some TEAC communications may take place by phone. The Transfer Policy Review Scoping Team flagged this provision as a potential item for further consideration. Do telephone communications provide a sufficient “paper trail” for registrars who may later wish to request a transfer “undo” based on failure by a TEAC to respond? Such a request would require the registrar to provide evidence that a phone call was made and not answered, or a call back was not received within 4 hours. Noting this requirement, should the option to communicate by phone be eliminated? Is an authoritative “system of record” for TEAC communications warranted? If so, what are the requirements for such a system? Deliberations: * Some working group members pointed out that that phone may have seemed like an efficient channel when TEAC requirements were first put into place, but the technology environment has evolved and that there may be a better framework to pursue going forward that will allow for a quick response and provide a paper trail. * It was noted by one member that it would be better for ROs if the TEAC communication occurs via email, because there is a paper trail. Discussion: * Phone number is good, but email is better for documentation. * Is email at each registrar enough, but should it be tracked centrally? * When you centralize that might cause delays. * I think we should make req's for what is tracked, but not that it be centralized somehow - there's so much work that would add (personal data considerations!). * Keep the phone number but require documentation in email. f6/f7) The Transfer Policy Review Scoping Team indicated that there are several factors that make a Registry Operator’s obligation to “undo” a transfer under Section 6.4 of the Transfer Policy challenging: i. Registry Operators do not have access to the designated TEACs for each Registrar, making validation of an undo request nearly impossible. ii. There is no way for Registry Operators to independently verify that a Registrar did not respond within the required time frame or at all since Registry Operators are not a party to, or copied on, communications between the Registrar TEACs. iii. Transfer “undo” requests associated with the failure of a TEAC to respond are unilateral so there is no validation required prior to a Registry Operator taking action. This has, on occasion, led to a “he said”, “she said” scenario. iv. Follow on to f6 iii., if the policy were to be updated to allow for some level of validation by the Registry Operator prior to taking action, the requirement to “undo” a transfer within 5 calendar days of receiving an TEAC undo request leaves little to no time to attempt to validate the request prior to taking the action. To what extent are changes to the policy needed to address these concerns? Are there other pain points for Registry Operators that need to be considered in the review of the policy in this regard? Deliberations: i. TEAC data is stale in some cases and not usable by the RO. ICANN should pass TEAC update changes to the Registries when providing notifications of other primary/authoritative contacts. This will ensure RO will get updates, but won’t address the issue of a TEAC not being updated by the Rr. Discussion: * Maybe instead of the registry validating it, there is a set of circumstances that have to be met and then the ry will return the domain without further validation, responsibility to ensure it's correct lies with the pre-transfer registrar. * These are not consistently up-to-date. * Like a chain of indemnifications that all goes back to the pre-transfer Registered Name Holder - they indemnify the registrar who indemnifies the registry … * ICANN could publish the TEAC but doesn’t help if the registrar doesn’t keep it up-to-date. * Thinking about where is the ultimate responsibility? The RNH should know where the name should be. Maybe the verification is done by the registrar who indemnifies the registry. * The hard part is to determine which registrant – who has that decision? * We're not necessarily talking about two registrants, but indeed we could be -- In which case I do think the pre-change registrant has authority. * Maybe there are multiple paths. * What check boxes do we need to go through to make sure that the registry doesn’t have to make a decision. Other pain points/opportunities: * Not everyone knows about the TEAC channel and when to use it. Is more/different/better information needed about the purpose and function of the TEAC? * Should “emergency” be further defined and guidance provided about when the TEAC should be used (versus TDRP)? Function/purpose of the TEAC: * Working group members noted considered scenarios where the TEAC is used: * Domain names that have been transferred but the transfer should not have occurred. Typically, there is a time sensitive element in these cases. There may be different reasons, including hijack, error, etc. * Some cases involve malicious behavior, for example unauthorized access to the registrar account to steal the domain name, use of fake court orders, etc. * Some working group members noted that when a domain is high value/high profile and/or financial, service delivery, and/or safety issue for the RHN or customers/end users, it is more important to have a fast mechanism to resolve an issue. 4. AOB: Two more calls before ICANN76 --- 28 February and 07 March ACTION ITEM: 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.

1 0

ICANN76 GNSO Sessions - How to Get Organized / Remote Participation Details
by Julie Bisland Feb. 21, 2023

Feb. 21, 2023

Dear all, With ICANN76<https://meetings.icann.org/en/icann76> just around the corner, please take a moment to read the information below for a seamless and successful meeting. REGISTER NOW! DEADLINE TO REGISTER IS 08 MARCH 2023! * Sign into Your ICANN Account or create an account here [account.icann.org]<https://urldefense.com/v3/__https:/account.icann.org/login__;!!PtGJab4!5B3b…>. * Register by selecting the Meeting Registration tile. * Click on the Registration link. Before creating your schedule, please read this page carefully: https://meetings.icann.org/en/remote-participation. If participating on-site, please read the Health and Safety page<https://meetings.icann.org/en/76healthandsafety>. CREATE YOUR MEETING SCHEDULE * Access the schedule here [icann76.sched.com]<https://urldefense.com/v3/__https:/icann76.sched.com/__;!!PtGJab4!5B3bwFsFR…>. The schedule shows up with blank radial buttons to the left of each session. Hover over the radial button and click “ADD TO MY SCHEDULE” or just click to add the checkmark. * Once you’ve selected all sessions, click the My Schedule link in the lower left corner or hover over your profile and select My Schedule. * Click the Phone icon * In the bottom section, “Export Calendar”, click the link next to “My Schedule”. When the .ics is exported, add it to the appropriate calendar. * Please remember, for security purposes, participation links will be posted 24-hours prior to the session start times. There will be no calendar invitations sent, as the meeting schedule allows you to download all sessions of interest to you, to your individual calendars Review the Participation Tools and update Zoom * All sessions will use Zoom rooms. Access details are available 24hrs prior. * Visit the Participation Tools page<https://meetings.icann.org/en/remote-participation> for links to download the latest version of Zoom for access to the ICANN Meeting sessions. * Please see the ICANN Meeting Virtual Participation How-To Guide for more information on how to get the most out of the virtual meeting tools. Links to Bookmark ICANN76 Meeting Schedule [icann76.sched.com]<https://urldefense.com/v3/__https:/icann76.sched.com/__;!!PtGJab4!5B3bwFsFR…> GNSO ICANN76 Wiki Page<https://community.icann.org/x/RAKBDQ> GNSO Session agendas<https://community.icann.org/x/QgKBDQ> For all GNSO meeting-related queries (RP or others), please email us at: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> and we will be more than happy to assist! Kind regards, GNSO SO/AC Support team -- Julie Bisland Policy Operations Sr. Coordinator (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: 79613b691cb8a6c1 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

**AT THE TOP OF THE HOUR** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 21 February 2023
by Julie Bisland Feb. 21, 2023

Feb. 21, 2023

**AT THE TOP OF THE HOUR** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 21 February 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/KIw-DQ * Time conversion link: https://tinyurl.com/2b9x28mt [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2b9x28mt__;!!PtGJab4!6v54PZd…> 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

Reminder: Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 24 January 2023
by Nathalie Peregrine Feb. 20, 2023

Feb. 20, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 24 January 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/IYw-DQ * For other places see: https://tinyurl.com/4twuefvb [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/4twuefvb__;!!PtGJab4!9YDcLtW…> 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

GNSO Council approval of TPR Project Change Request
by Emily Barabas Feb. 20, 2023

Feb. 20, 2023

Dear working group members, As many of you are already aware, the GNSO Council approved the working group’s Project Change Request (PCR), project plan update, and associated charter adjustments during the 16 February Council meeting. If you have any questions, please feel free to bring them to tomorrow’s WG meeting. Kind regards, Caitlin, Julie, Berry, and Emily From: council <council-bounces(a)gnso.icann.org> on behalf of Terri Agnew via council <council(a)gnso.icann.org> Reply to: Terri Agnew <terri.agnew(a)icann.org> Date: Thursday, 16 February 2023 at 08:05 To: "council(a)gnso.icann.org" <council(a)gnso.icann.org> Cc: "gnso-secs(a)icann.org" <gnso-secs(a)icann.org> Subject: [council] GNSO Council resolutions 16 February 2023 Dear all, Please find below the resolutions from the GNSO Council meeting on Thursday, 16 February 2023, which will be posted shortly on the GNSO Council resolutions <https://urldefense.com/v3/__https:/gnso.icann.org/en/council/resolutions/20…> page. CONSENT AGENDA Nomination of a Member of the Fellowship Selection Committee Submitted by: Greg DiBiase Seconded by: John McElwaine Whereas, 1. On 11 November 2022, the ICANN Fellowship Program invited<https://community.icann.org/download/attachments/105383387/digest_2022_11No…> the GNSO to nominate one individual to serve as member of the Fellowship Selection Committee<https://www.icann.org/resources/pages/fellowship-selection-committee> for six consecutive ICANN meetings beginning with ICANN78. 2. On 9 December 2022, the GNSO launched [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/announcements/announce…> an Expression of Interest (EOI) process to solicit volunteers for the GNSO-nominated position. 3. The GNSO Council tasked the GNSO Standing Selection Committee (SSC) with reviewing applications and recommending one individual for the GNSO to nominate. 4. The SSC reviewed the applications received, taking into account the criteria outlined in the EOI announcement. 5. The SSC submitted its full consensus recommendation to the GNSO Council on 06 February 2023, by way of submission of the relevant motion. 6. The GNSO Council considered the recommendations of the SSC. Resolved, 1. The GNSO nominates Taiwo Peter Akinremi to serve as a Fellowship Selection Committee member for six consecutive ICANN meetings, beginning with ICANN78. 2. The GNSO Council instructs the GNSO Secretariat to communicate resolved #1 to staff supporting the ICANN Fellowship Program. 3. The GNSO Council instructs the GNSO Secretariat to inform the nominated candidate that he has been selected. 4. The GNSO Council requests the GNSO Secretariat to send a response to the applicants who were not nominated, thanking them for their interest and encouraging them to apply for future opportunities as they arise. Vote results [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> CONSENT AGENDA Adoption of the Revised Charter for the Budget and Operations Townhall Submitted by: Greg DiBiase Seconded by: John McElwaine Whereas, 1. In 2017 the GNSO Council expressed its desire to establish the GNSO Standing Committee on Budget and Operations (SCBO) to assist with the development of GNSO Council comments that relate to ICANN's Budgetary and Finance matters; 2. On 21 December 2017, the GNSO Council adopted the formation of the SCBO and its interim charter; 3. In FY18, the SCBO developed four public comments (IANA-PTI FY19 Budget, ICANN's Reserve Fund Target Level, ICANN's Draft FY19 Budget and Operating Plan, and ICANN Reserve Fund: Proposed Replenishment Strategy) on behalf of the GNSO Council that were later accepted and posted to ICANN's public forum; 4. On 24 October 2018, the GNSO Council voted to adopt the charter for the GNSO Standing Committee on Budget and Operations (SCBO) on a permanent basis; 5. On an annual basis, the SCBO developed and provided drafts public comment to the GNSO Council on the IANA-PTI Budget and ICANN’s Draft Budget and Operating Plan, which upon non-objection from the Council, were submitted to the relevant public comment proceeding; 6. Interest and engagement in the SCBO has waned and the substance of public comments has diminished; 7. The GNSO Council identified an opportunity to evolve the SCBO to better align with the needs of the Council as well as establish a consistent platform for the Stakeholder Groups and Constituencies to engage with the Finance and Planning team in a more streamlined and collaborative manner; and, 8. The GNSO Council leadership team coordinated with the GNSO Council and Stakeholder Group and Constituency leadership teams to ensure that they are supportive of the change to the SCBO. Resolved, 1. The GNSO Council adopts the revised Charter [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> for the Budget and Operations Townhall (formerly known as the SCBO). 2. The GNSO Council thanks the Council members and subject matter experts that have contributed to the SCBO throughout its lifespan. Vote results [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> 20230216-2 Motion - Approval of a Project Change Request (PCR) to Update the Project Plan of the Transfer Policy Review (TPR) Policy Development Process (PDP) Submitted by: Osvaldo Novoa Seconded by: Greg Dibiase Whereas, 1. On 18 February 2021, the GNSO Council voted [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/council/resolutions/20…> to initiate a PDP to review the Transfer Policy. 2. On 24 March 2021, the GNSO Council approved [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/council/resolutions/20…> the PDP working group’s charter, which anticipated a two-phase approach to completing the PDP’s work. 3. The working group began meeting in May 2021 and has made substantial progress, including publication of an Initial Report on Phase 1(a) topics, review of public comments on the Phase 1(a) Initial Report, and preliminary deliberations on Phase 1(b) topics. 4. In the course of considering the Phase 1 charter questions, the working group identified dependencies between charter topics that require the working group to make progress on certain Phase 2 topics (Transfer Emergency Action Contact (TEAC), reversal of a transfer, and Transfer Dispute Resolution Policy (TDRP)) before Phase 1 deliberations on inter-registrar and inter-registrant transfers can be completed. 5. The working group has determined that the best path forward is to consolidate its work into a single phase, which will allow the working group to consider all topics in the charter iteratively. This approach will result in delivery of a second Initial Report covering all topics in the charter and a single Final Report. 6. The working group anticipates that with this new approach, the PDP will conclude a year earlier than originally anticipated, because there will be fewer discrete deliverables and public comment periods. 7. The Working Group leadership team submitted a Project Change Request outlining the full rationale for updating the project plan. Resolved, 1. The GNSO Council approves this Project Change Request. 2. The GNSO Council instructs policy support staff to update the TPR project plan, charter, and other materials accordingly and post on the working group wiki. Vote results [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Thank you. Kind regards, Terri

1 0

Deadline 27 February: WG member review of draft outreach letter to SO/AC/SG/Cs on Phase 2 topics
by Emily Barabas Feb. 20, 2023

Feb. 20, 2023

Dear working group members, As discussed on the last call, staff had an action item to share a draft outreach letter to SO/AC/SG/Cs on Phase 2 topics. Please find the letter attached, along with a list of the Phase 2 charter questions and a few additional questions proposed by the leadership team regarding “fast undo.” Please review this document and share any questions or concerns no later than, Monday 27 February. As you will recall, early outreach is a standard process in the PDP. The working group asked community groups for early input on Phase 1 topics in June 2021<https://community.icann.org/display/TPRPDP/Community+Input>. With the Project Change Request and restructured work plan, we are now requesting input on Phase 2 topics to support the deliberations that are now beginning on these charter questions. The leadership team is aiming to send the outreach letters to SO/AC/SG/Cs on 28 February and seek input by 4 April. Thanks in advance for your review. Kind regards, Caitlin, Julie, Berry, and Emily Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names an Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Proposed agenda for meeting #81 on Tuesday 21 February 2023 at 16:00 UTC
by Emily Barabas Feb. 20, 2023

Feb. 20, 2023

Dear Working Group members, Please find below the proposed agenda for the next meeting scheduled to take place on Tuesday 21 February at 16:00 UTC. Kind regards, Caitlin, Berry, Julie, and Emily Transfer Policy Review - Meeting #81 Proposed Agenda 21 February 2023 1. Roll Call & SOI updates 2. Welcome and Chair Updates 3. Continued Discussion of Transfer Emergency Action Contact (TEAC) 4. AOB

1 1

ICANN org input on TPR Preliminary Recommendation 19, Transfer Policy Section I.A.3.7.1
by Emily Barabas Feb. 17, 2023

Feb. 17, 2023

Dear working group members, As you know, ICANN org Liaisons from Compliance and GDS continue to follow working group deliberations and coordinate org input where it may be helpful to support working deliberations. In reviewing recent revisions to the Preliminary Recommendations, org has provided some specific comments on Recommendation 19 - I.A.3.7.1. Please see below. The working group will have an opportunity to discuss this feedback when we return to Phase 1(a) topics in the future, but we are sharing it now so that members have an opportunity to digest the input and discuss with your groups, as appropriate. Kind regards, Caitlin, Julie, Berry, Emily The ICANN organization (org) has been following the conversations in the Transfer Policy Review working group regarding denial of transfers, and specifically regarding section I.A.3.7.1 of the Transfer Policy. ICANN org understands that currently, the working group is considering draft recommendation language that would recommend revising section I.A.3.7.1 of the Transfer Policy to state that a Registrar of Record MAY deny a transfer for the following reason: “Evidence of (a) fraud or (b) the domain presents an active DNS Security Threat as defined here: https://www.icann.org/dns-security-threat." ICANN org would like to provide some additional feedback on the latest version of this recommendation. In providing this feedback, we want to emphasize that this feedback is for the purposes of providing factual information concerning Contractual Compliance complaints in this area, and Compliance-related issues associated with the language under consideration by the team. As a reminder, the discussion of revising I.A.3.7.1 was in part prompted by observations ICANN org has garnered from the receipt of complaints related to and the enforcement of the Transfer Policy. Throughout the years, ICANN Contractual Compliance has received complaints involving transfer requests which were denied by the sponsoring registrars because such requests involved domain names that were identified as “abusive” by the registrar. The registrars conducted investigations and determined that the domain names were being used to perpetuate abusive and/or illegal activities. These registrars then suspended and locked the domain names for transfers as part of their abuse investigations and responses, and related mitigation efforts. However, under the current Transfer Policy, the suspension of an abusive domain name is not, by itself, a permitted ground for denying a transfer request. Further, many of these cases would also not fall within the scope of the language under consideration by the working group, because these cases were not limited to DNS Security Threats. Specific examples of these compliance cases included domain names allegedly used to perpetuate distribution of Child Sexual Abuse Material (CSAM), medication without prescription or imagery determined by the registrar to be violent and against its terms of service. ICANN org would like to clarify that the new language proposed by the working group would not provide a basis for denial in the scenarios above or similar that are not strictly related to DNS Security Threats. If the working group believes that the Transfer Policy should provide grounds for denial where the domain name has been found to perpetuate the activities cited above (or other harms beyond DNS Security Threats) the language of the draft recommendation would need to be broadened. For example: The Registrar or Registrar of Record may deny an inter-registrar transfer request only in the following specific instances: * 3.7.1 Evidence of Fraud. * 3.7.2 Evidence of the domain name being engaged in an activity expressly prohibited by the Registrar’s domain anti-abuse terms and policies. ICANN org notes that additional guardrails may be appropriate in the form of implementation guidance, for example: Implementation Guidance: A Registrar may use this denial reason only after determining, through its own investigation, that the domain name subject to the transfer request is used for an activity expressly prohibited by the Registrar’s anti-abuse terms and policies. In all instances, the Registrar must comply with the applicable requirements in this Transfer Policy and the Registrar Accreditation Agreement relating to providing Registered Name Holders with access to transfer processes information and the terms and conditions upon which the Registrar will prohibit the transfer of a domain name. In short, the Registered Name Holder must have access to information explaining that the activity is prohibited and that the consequences for engaging in it may include a transfer denial. ICANN org understands the working group’s concerns that broad provisions could potentially be used by a registrar to unfairly prevent a registrant from transferring the domain to a new registrar. ICANN org notes the following additional considerations that the working group may want to take into account: * Separating the existing subsection in this provision “evidence of fraud” and the new abuse-related denial reason may allow the production of a denial reason that is comprehensive enough to address the concerns of potential misuse with implementation guidance. It may also prevent the potential interpretation that there is some type of dependency between fraud and any other type of abuse which may be considered under this subsection. Under Section II.C.3.6 of the Transfer Policy, registrars can already modify registrant information without following the Change of Registrant process (hence, without obtaining registrant’s consent) when it is done “in response to an abuse complaint”. * For most generic top-level domains, registrars are expected to include in their registration agreements with the registrants the list of prohibited activities and the consequences for engaging in these activities. The Transfer Policy also requires the registrar to include in the registration agreement the terms and conditions upon which it prohibits a transfer (if the registrar decides to enact the “clientTransferprohibited” status). Therefore, the registrant must have access to information regarding the instances in which a registrar may deny a transfer request before deciding whether to use such a registrar or not. * The information provided to the registrant, coupled with a detailed explanation of the ground for denial can potentially help prevent a potential abuse of this section while still permitting registrars to deny transfers in certain scenarios which do not necessarily involve security threats. Should the working group choose to keep the recommendation focused on DNS security threats as it is currently drafted, ICANN org would like to raise concern that the suggested language references a webpage. As in all agreements and policies, linking to a webpage may create challenges in the future because webpages and the location of content may be modified or no longer be available over time. In addition, the referenced ICANN org webpage is not intended to define DNS Security Threats but rather explain ICANN org efforts in supporting the mitigation of DNS Security Threats. ICANN org suggests that if a link to a definition is included, the link points to a more stable resource. ICANN org can suggest possible resources on request. Regards, Isabelle and Holida 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/>

2 1