September 2021 - GNSO-TPR - lists.icann.org

Transfer Policy Review PDP WG
by ICANN Policy Calendar Sept. 30, 2021

Sept. 30, 2021

Meeting: Transfer Policy Review PDP WG Date/Time: Recurring every Tuesday at 16:00 UTC for 90 minutes, 09 November 2021 through 21 December 2021 Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# 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> Wiki Agenda meeting pages 2021: https://community.icann.org/x/QYaUCQ Check your time zone: https://tinyurl.com/4bmm2fpp ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form<https://docs.google.com/forms/d/e/1FAIpQLScXP3-H595xH4EFgaR3ydOr-1o9BLAVGUI…> to communicate who the alternate is replacing and for which period. This information will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Panelists and Attendees, or Everyone when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and in parentheses, (your affiliation - alternate), after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. For 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

1 0

ICANN72 GNSO Sessions - How to Get Organized / Remote Participation Details
by Julie Bisland Sept. 29, 2021

Sept. 29, 2021

Dear all, ICANN72 is right around the corner! This email provides some information to help you prepare and organize. Please note: You will need to register for ICANN72 to access the meeting schedule. Mandatory Registration for ICANN72 * Sign into your ICANN Account, or create an account here<https://account.icann.org/login>. * Register for ICANN72 by selecting Meeting Registration and click on the ICANN72 Registration link. Click here<https://gnso.icann.org/sites/default/files/policy/2021/presentation/instruc…> for detailed instructions. Note: the schedule will be published on 04 October 2021. Access the ICANN72 Schedule * ICANN72 schedule: https://72.schedule.icann.org/ For security purposes, participation links will be posted 24-hours prior to the session start times. * ICANN72 GNSO Sessions have been grouped on the ICANN72 GNSO wiki page<https://community.icann.org/x/CAFmCg>. Create your own schedule: * The ICANN Meeting website allows you to download all GNSO-related meetings to your inbox calendar in one go. For detailed instructions on how to create your personalized ICANN72 schedule and import your schedule to your calendar, click here<https://gnso.icann.org/sites/default/files/policy/2021/presentation/instruc…>. Review the Participation Tools and update Zoom * All sessions will use Zoom rooms. Access details are available 24hrs prior on the ICANN72 Meeting Schedule<https://72.schedule.icann.org/>. * Visit the Participation Tools page<https://72.schedule.icann.org/participation-tools> for links to download the latest version of Zoom for access to the ICANN72 sessions. * Please see the ICANN Meeting Virtual Participation How-To Guide<https://72.schedule.icann.org/attend#:~:text=virtual%20participation%20how-…> for more information on how to get the most out of the virtual meeting tools. Links to Bookmark ICANN72 Meeting Schedule<https://72.schedule.icann.org/> GNSO ICANN72 Wiki Page<https://community.icann.org/x/CAFmCg> GNSO Session agendas<https://community.icann.org/x/iIH8CQ> For all GNSO meeting-related queries (RP or others), please email us at: gnso-secs(a)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

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 05 October 2021 at 16:00 UTC
by Julie Bisland Sept. 28, 2021

Sept. 28, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 05 October 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<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 [icann.zoom.us]<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/LAA_Cg * Check your time zone: https://tinyurl.com/xj8cpk8d ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 28 September 2021
by Julie Bisland Sept. 28, 2021

Sept. 28, 2021

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

1 0

Notes and action items - TPR Meeting #19 - 28 September 2021
by Julie Hedlund Sept. 28, 2021

Sept. 28, 2021

Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting on Tuesday, 28 September 2021 at 16:00 UTC. The next meeting will be Tuesday, 05 October at 16:00 UTC. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items: Homework for the WG by Monday, 04 October: WG members should provide descriptions of the purposes of the gaining FOA and of the functions that the WG recommends to replace those purposes. See the updated Work Plan and Action Items here: https://docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8u… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1FunWaz3g…> Notes: Transfer Policy Review Phase 1 - Meeting #19 – Tuesday, 28 September at 16:00 UTC Proposed Agenda 1. Roll Call & SOI Updates (5 minutes) * See updated SOI from Farzaneh Badiei at: https://community.icann.org/display/gnsosoi/Farzaneh+Badiei+SOI. 2. Welcome & Chair updates (5 minutes) * Comments from WG members: None. 3. New Topic: Gaining FOA (75 minutes) – See: Gaining FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> Charter Questions: a4) If the Working Group determines the Gaining FOA is no longer needed, does the AuthInfo Code provide sufficient security? The Transfer Policy does not currently require specific security requirements around the AuthInfo Code. Should there be additional security requirements added to AuthInfo Codes, e.g., required syntax (length, characters), two-factor authentication, issuing restrictions, etc.? Discussion: * Think we have answered this. We have had discussions around additional security relating to AuthInfo Codes. * Question: Where are all the working documents? Answer: On the wiki at: https://community.icann.org/display/TPRPDP/Working+Documents. * Note that there are some candidate recommendations on AuthInfo Codes at: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0… (page 16). a5) If the Working Group determines the Gaining FOA is no longer needed, does the transmission of the AuthInfo Code provide a sufficient “paper trail” for auditing and compliance purposes? Discussion: * Everyone recognized that the gaining FOA provided another piece of the audit trail. Do we need to make sure that is embedded elsewhere? It is not just what we’ve done for the TAC, but also the notification of the transfer being complete provides an audit trail. * From ICANN Compliance: Requiring AuthInfo Code and Losing FOA be provided to the registrant. * We have ways to track the request history without Gaining FOA. Summary: * We aren’t getting rid of the losing or gaining FOA, but instead replacing their functionalities. Important to ensure that we are addressing the reason why the gaining FOA was being used. * Question: Rather than thinking about getting rid of the gaining FOA, but should we be taking the features and requirements served by the gaining FOA and say that you have to keep certain records. Do we want to make sure that we say that there is a paper trail, you are required to keep it, and this is the information it has to have. * The key is to extract the purposes of the gaining FOA and either provide those in another mechanism, or a rationale for why we don’t think we need to serve that purpose anymore. Poll Questions and Responses: (Q1) Did the Gaining FOA serve a security function? - 15 responses * Yes, and new requirements should exist to replace the Gaining FOA’s security function -- 33% * Yes, but this function is no longer necessary -- 40% * No, it did not serve this function -- 27% * Not sure/Needs further discussion -- 0% Discussion: * Just a mechanism to transfer a domain name; was not originally a security function. * It’s primary purpose was not as a security feature, just to facilitate a transfer. It could be a security feature, but it wouldn’t be a strong one. But, the added set might provide a small amount of security. * Think the gaining FOA requirements predated AuthInfo Codes. * Not everyone sees it as a security feature, or as a strong one. * Back in the day, we weren’t thinking in terms of security so these weren’t well documented. * The difficult question is whether or not the gaining FOA is a security mechanism. * Seems that there is general agreement that it does add something, if not security. (Q2) Did the Gaining FOA serve a notification function? - 16 responses * Yes, and new requirements should exist to replace the Gaining FOA’s notification function -- 63% * Yes, but this function is no longer necessary -- 38% * No, it did not serve this function -- 0% * Not sure/Needs further discussion -- 0% Discussion: * Don’t think we need a policy requirement because the losing registrar will have that requirement. The gaining registrar may wish to do it for other reasons. * The gaining FOA from the gaining registrar’s perspective did serve a purpose, but it doesn’t need to be a policy requirement. * Losing registrar will have policy obligation to notify, they don't both need to; Gaining registrar may have marketing desire or data protection obligation to notify, but not due to the transfer itself. (Q3) Did the Gaining FOA serve a “paper trail” function? - 18 responses * Yes, and new requirements should exist to replace the Gaining FOA’s “paper trail” function -- 44% * Yes, but this function is no longer necessary -- 50% * No, it did not serve this function -- 0% * Not sure/Needs further discussion -- 6% Discussion: * We need to know whether the function isn’t necessary or has been replaced and with what. * If 44% said yes, there is still a “paper trail” function, what would that look like? What are the barriers to accomplishing that? * The key here is that the majority people agreed that it provided a “paper trail” but disagreed on whether it was still needed. (Q4) Did the Gaining FOA serve another function not listed in previous questions? - 16 Responses * Yes -- 0% * No -- 94% * Not sure/Needs further discussion -- 6% Discussion: * Majority agreement that there are no other functions provided by the gaining FOA. * Sending emails for notification could be used by bad actors for phishing. When we do have mandatory emails requiring action by the registrant that can result in opportunities for abuse, so think about that if we are keeping notification requirements. * Perhaps in the policy we shouldn’t specify the mechanism for the transfer notification. * Answered “no” because we are talking about the gaining FOA as is (current policy). * Could take lessons from other industries on security principles, such as the financial industry. Such as the principle to not have embedded actions (such as clicking links). Notification itself can’t be directly actionable. * Keep in mind the timing of these types of notification – what is interesting is that the gaining FOA pre-GDPR was the first notification the registered name holder would receive, to agree to transferring the domain. Secondarily there was an option to reject that transfer as unauthorized. * If the gaining FOA is no longer a requirement, that changes the timing and who is notifying whom – which is connected to whether the gaining FOA played a part in a security mechanism. (Q5) Which statement do you support with respect to Gaining FOA? - 16 responses * The requirements should be removed from policy with no replacement -- 44% * Improved FOA security and new notifications are sufficient to replace it -- 50% * The WG needs to explore other possible measures to replace it -- 6% * Not sure/Needs further discussion -- 0% Discussion: * If we aren’t going to replace this function, we’ll need to provide a rationale. * Looks like we have a fairly even split. * Is this a solution in search of a problem? Seems like things are in good shape at the moment. * One distinction to make with respect to actionable notifications when thinking about the desire for 1-click actions, are you starting something or stopping something? there’s a case to be made to have a one-click to stop something but require logging in to the portal (being careful about phishing attacks, i.e., use two-factor authentication) to confirm or start something. it’s a subtle distinction that requires careful analysis but could be helpful. * Keep in mind with the redacted WHOIS it is not possible to send a gaining FOA at this moment. * Think we've got all the functionality moved to other places in the process. * If we thought the gaining FOA did something that we can't do any other way, we could explore how to keep it, but don't think that is the case, and then if we get into how to keep it, we need to consider lawful bases for processing the data, which may be nonexistent. * In the first answer we talk about “requirements” but think this question is just about the gaining FOA as a document in itself – think we want to keep all the things that this document stood for. The FOA itself needs to go away, but the requirements it stood for will replace it. * We want the security and notification, but they don't have to happen via the gaining FOA. * Can’t enforce what we were sending in the way we were sending it. * Find ways to keep what those notifications represented. * Think we will get information from the new registrar in another way. * Because of GDPR there needs to be some kind of contract between the losing and gaining registrars in order to transfer data. Is there a legal way to share data? So far no one could come up with a good way of doing that. * Don’t see how we can keep what the gaining FOA stood for because of GDPR. The data is not accessible. * “what it stood for” is the security requirements and paper trail that were provided by it. * Question: Is there a stakeholder insisting on keeping the gaining FOA? Answer: Not that we are aware of. * Seem to be recommending that we eliminate the gaining FOA, but then we need to identify its purposes and how they are being met with other mechanisms. * Need to ask the question of whether the TAC notifications address the purposes of the gaining FOA (the TAC presentation notification). * Potential scenario: A registrant goes to their incumbent registrar to ask for a TAC, registrant brings it to the gaining registrar, but realizes they lost it and can go back to the losing registrar message and asks again. If they don’t realize they lost it, but get a notification of transfer, they have the option to claw that back. If the accounts are compromised then we can’t do anything about that. * Don’t see how the gaining FOA improves security. * Majority of transfers happen without issues, but we are trying to solve for those who don’t. * Everyone seems to agree that the gaining registrars notifications would be very limited. * The gaining registrar may have business reasons to send out notifications, but the losing registrar won’t. Seems we agree that if the gaining registrar sends a notification it should not be mandatory, but optional. * All the security requirements go on the front end of the transfer, with the option at least to claw it back. * RNH should be notified when the transfer completes, but don't think that MUST come from the new Registrar. * Summary: Think we agree that the gaining FOA cannot exist in its current form in future, but it does provide certain functionalities that have been replaced. We need to say what those functionalities are and how they have been replaced (such as the presentation of the TAC). ACTION ITEM: Homework for the WG by Monday, 04 October: WG members should provide descriptions of the purposes of the gaining FOA and of the functions that the WG recommends to replace those purposes. 4. AOB (5 minutes) - Next meeting: 5 October 2021 @ 16.00 UTC

1 0

**Starts in 15 minutes** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 28 September 2021 at 16:00 UTC
by Julie Bisland Sept. 28, 2021

Sept. 28, 2021

**Starts in 15 minutes** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 28 September 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<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 [icann.zoom.us]<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/KgA_Cg * Check your time zone: https://tinyurl.com/57hhxay [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/57hhxay__;!!PtGJab4!v77HETNB…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Proposed agenda for meeting #19 on Tuesday 28 September 2021 at 16.00 UTC
by Emily Barabas Sept. 27, 2021

Sept. 27, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 28 September 2021 at 16.00 UTC. In addition, as discussed on the last call, draft responses to charter questions and “candidate” recommendations on AuthInfo Codes are now ready for your review and input. Please review the text beginning on page 16 and add comments/suggestions directly into the document: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #19 Proposed Agenda Tuesday 28 September 2021 at 16.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. New Topic: Gaining FOA (75 minutes) * Gaining FOA working document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…> 4. AOB (5 minutes) - Next meeting: 5 October 2021 @ 16.00 UTC

2 1

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 28 September 2021 at 16:00 UTC
by Julie Bisland Sept. 27, 2021

Sept. 27, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 28 September 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<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 [icann.zoom.us]<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/KgA_Cg * Check your time zone: https://tinyurl.com/57hhxay [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/57hhxay__;!!PtGJab4!v77HETNB…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Transfer Policy Review PDP WG
by ICANN Policy Calendar Sept. 21, 2021

Sept. 21, 2021

Meeting: Transfer Policy Review PDP WG Date/Time: Recurring every Tuesday at 16:00 UTC for 90 minutes, 07 September 2021 through 19 October 2021 Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# 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> Wiki Agenda meeting page for 07 September: https://community.icann.org/x/JAA_Cg (see left side for other meeting dates) Check your time zone: https://tinyurl.com/3t7zjyn5 ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form<https://docs.google.com/forms/d/e/1FAIpQLScXP3-H595xH4EFgaR3ydOr-1o9BLAVGUI…> to communicate who the alternate is replacing and for which period. This information will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Panelists and Attendees, or Everyone when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and in parentheses, (your affiliation - alternate), after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. For 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

1 0

Notes and action items - TPR Meeting #18 - 21 September 2021
by Julie Hedlund Sept. 21, 2021

Sept. 21, 2021

Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting on Tuesday, 21 September 2021 at 16:00 UTC. The next meeting will be Tuesday, 28 September at 16:00 UTC. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items: See the updated Work Plan and Action Items here: https://docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8u… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1FunWaz3g…> Notes: Transfer Policy Review Phase 1 - Meeting #18 – Tuesday, 21 September at 16:00 UTC Proposed Agenda 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) * WG member updates: none. * Leadership and staff are working on some draft candidate recommendations on AuthInfo codes/charter questions; we’ll be sending the document to WG members to review, probably this week. 3. Wrap up of discussion of Losing FOA (15 minutes) – see Losing FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wCUMe9ii6g05…> and Transfer Steps and Notifications chart [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/17ADMRTYx…> * Seems like we got to a very good spot last week. Got through all of the charter questions and perhaps ended up with having an early optional notification of TAC request, a required notification of TAC provision, and required notification of TAC completion. 4. New Topic: Gaining FOA (60 minutes) – see Gaining FOA Working Document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…> Highlights: * Identical in format to the Losing FOA document. * Language shows how the Gaining FOA has to be transmitted, to whom, when the Gaining FOA will expire and requirements for retention, actual of Gaining FOA in English, relevant language from Temporary Specification – registrar not currently required to send the Gaining FOA (until this is settled in this policy WG. * Charter questions: * Tables provide previous feedback. * Relevant feedback from survey respondents (2018). * WG may want to consider the highlighted questions: * Concerns from registrars with wholesale elimination of Gaining FOA due to lack of a paper trail. * Re: Temp Spec – “Until such time when the RDAP service (or other secure methods for transferring data) is required by ICANN to be offered…” is there another portal that could be used to transfer data? * How we typically work is that nothing changes without consensus. So we should look at what the reasons are for it not staying/being eliminated. Discussion: * Wondering how valuable are the previous comments (as in the table). Don’t need to rethink some very old stuff. * IRTP-D did deliberate this many years ago and the landscape has change. * There are registrars that think this is important for evidentiary purposes. If Gaining FOA is eliminated, how to mitigate these concerns. * Could say that we have added the TAC notification as a replacement of the gaining FOA. The board removed compliance enforcement because it’s not possible to follow today. * What are the reasons to get rid of it/replace it? * Is the Gaining FOA still needed? We haven’t been providing it for the last few years. * If you make it a requirement then you will have to find a way to do it under GDPR. Charter Questions: a1) Is the requirement of the Gaining FOA still needed? What evidence did the Working Group rely upon in making the determination that the Gaining FOA is or is not necessary to protect registrants? Green Bullet Point Responses (YES column): * First bullet: * The requirement to have a paper trail is a good one, but doesn’t have to happen with the Gaining FOA. We could find another way. * Does the gaining FOA add any security for the registrant that is not afforded adequately elsewhere in the process. For the “other stuff” I agree with Sarah, let’s see if we can retain it somewhere else in the process. * Second bullet: Does the Gaining FOA provide a tool for the registries? WG members from Registries can check. * Third bullet: maybe the Losing FOA notifications address this concern (“It is very important that the FOA confirmation letter is sent to the original registrant, which may affect the security of the domain name.”) * Fourth bullet: * Can see that it is handy to have, such as in China, but wonder if what is stated here is still accurate. * We can’t decide what personal data could be public, or is there a way to make this happen behind the scenes? * Can’t see any way how the gaining registrar should be able to get the current registrant e-mail. * This bullet isn't telling us any new factors we need to include. So far all we have is that we should have some sort of paper trail to rely on in disputes, which we're already doing with the TAC and other notification process. * The gist so far from these comments is that we need some way of logging a transfer took place. * We have the TAC and the notifications that have already been discussed. * We don’t have any ideas on how to share the personal data (current Registrant information including the losing registrar's name, the Registrant Name & Organization, the Registrant Email Address, Phone etc, so the gaining registrar still can send the FOA Email to the Registrant for authorization.) * Sounds like the WG would be in favor of transferring the data if it was possible under GDPR. Nice to have but not realistic anymore. * Fifth bullet: * This is the record-keeping piece again. * This one and the next one are just to protect against bad transfers/disputes. * Sixth bullet (re: mitigate unauthorized transfer): * Think we have moved this to the actual TAC itself. That the TAC is only valid during transfer. * ICANN Compliance: We have seen reporters file complaints about not receiving AuthInfo codes because they needed it in order to transfer resellers. Not sure if the AuthInfo code was actually needed to transfer resellers or if Reporter just didn’t understand the difference between switching resellers and switching registrars. Most cases get closed after educating reporters and finding that requests are not for inter-registrar transfer. * Seventh bullet (must have approval from registrant): * We have them notified, if not approval. * The notification of the TAC goes to the registrant and enables them to stop the transfer. * From understanding of GDPR the transfer of the domain does require extraordinary measures to protect the data subject and a lawful basis can be determined to transfer the data. The WG could consider asking for legal advice – would be a budget request to the GNSO Council. * We will need consensus to undo this and the WG should think about whether there is a better solution to deliver the benefits. * Keeping it alive is impossible. Why process the data if it’s not required? * Data minimization = use the least amount of data possible to do the job. We know we can do transfers securely without having the losing registrar send RNH data to the gaining registrar, so minimization tells us not to. * Or we could look at lawful bases and see if they apply. Performance of the contract doesn’t work, because the contract is not between losing and gaining registrars. Consent also is hard to convey to a third party with certainty that it’s valid. Legitimate interest means the need to process data must outweigh the privacy rights, and since we know we can do transfers without it, that doesn’t apply. * Eight bullet (re: hijack): Back to the issue of providing a paper trail. Solved by record-keeping. * Ninth bullet (mandatory email notices): We are solving this. * Tenth bullet: Goes back to the TAC (confirming a transfer). * Eleventh bullet: Goes to having the proper documentation in place to confirm the transfer. * Disagree that it's always better to have more records. We should have the right records and we should employ the 'data minimization' principle discussed earlier. * Twelfth bullet: Dealt with this. Replaced with Losing FOA notification and TAC. * Thirteenth bullet (last re: evidence for court cases/disputes): * Wonder how this is dealt with now without Gaining FOA? * Disputes plug into this. Red Bullet Point Responses (NO column): We have already been raising these points. Will be important to look at for rationale. A2) If the Working Group determines the Gaining FOA should still be a requirement, are any updates (apart from the text, which will likely need to be updated due to the gTLD Registration Data Policy) needed for the process? For example, should additional security requirements be added to the Gaining FOA (two-factor authentication)? * The last sentence – we took the Losing FOA a little broader to answer the question about additional security requirements. * Think we've established that there should be new/different security requirements, and that is separate from the FOA, so we should move on. Green Bullet Point Responses (YES column); * First bullet (re: verification, not just notification): Seems we have addressed this. * Second bullet (re: sharing registrant’s email through registry): * Doesn’t change the legal issues. * Via registry is better than entirely public, but I think we've already established that we don't need it. a3) The language from the Temporary Specification provides, “[u]ntil such time when the RDAP service (or other secure methods for transferring data) is required by ICANN to be offered, if the Gaining Registrar is unable to gain access to then-current Registration Data for a domain name subject of a transfer, the related requirements in the Transfer Policy will be superseded by the below provisions...”. What secure methods (if any) currently exist to allow for the secure transmission of then-current Registration Data for a domain name subject to an inter-registrar transfer request? * Don’t think we need to answer this question because we’ve decided that we don’t need the data – no purpose for it. * If there is a reason for this to happen, we’d need to come up with a mechanism. We haven’t needed it for 3 years. * Gets back to the question – is it necessary to transfer the data? We have shown that we don’t need to process vast amounts of data for a transfer. * Seems that we’ve already had this discussion. 5. AOB (5 minutes) * Next meeting: 28 September 2021 @ 16.00 UTC * Start with Chart Question 4.

1 0