- GNSO-TPR - lists.icann.org

Notes and action items - TPR Meeting #16 - 07 September 2021
by Julie Hedlund Sept. 7, 2021

Sept. 7, 2021

Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting on Tuesday, 07 September 2021 at 16:00 UTC. The next meeting will be Tuesday, 14 September at 16:00 UTC. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items ACTION ITEM: Homework: WG members should look at reasons for denial in the current policy and comment on whether or not we need to update those reason. Add lines or comments to the Transfer Steps and Notifications Chart: Transfer Steps and Notifications chart [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/17ADMRTYx…> ACTION ITEM: Leadership and staff to clean up the document based on comments and determine where steps can be combined. See the updated Work Plan and Action Items here: https://docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8u… Notes: Transfer Policy Review Phase 1 - Meeting #16 – Tuesday, 07 September at 16:00 UTC Proposed Agenda 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) * Updates from WG member: None. * There will be a PDP WG meeting at ICANN72. 3. Continued discussion of Losing FOA (45 minutes) – See: Losing FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wCUMe9ii6g05…> Transfer Steps and Notifications Chart: Transfer Steps and Notifications chart [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/17ADMRTYx…> * Sarah’s goal was to document the process step-by-step to see where steps could be eliminated or combined. 1. Request to prepare domain for transfer * May not be the registrant; or it might be the registrant. * This is where there might be a transfer request notification with the idea that there was a request so a notification goes to the registrant; some support for providing a 5-day window for the registrar to provide the TAC (leading into step 2). * Question: Could there be a communication at this point, outlining the process, and that it might take up to 5 days to issue the TAC. * Could request the TAC even if the domain name is still locked. Don’t make it dependent on whether it’s locked or unlocked. The lock could come off later. * Today the status of a domain name (locked or not) is not a part of the transfer policy – should we add it for the next round? Which one of the locks should be controlled by the policy? * This is all pre-transfer, before a transfer is in a pending state. * 5-day window might be at this step. 2. Prepare domain for transfer * “verify validity of request” – should be optional; could mean different things for different types of registrars. Even “verify request” should be optional. * All of these sub steps are being done by the losing registrar. 3. Fulfill request to prepare domain for transfer * This is the biggest action step. Does this need to be communicated to certain specific people? * The requester may not be the registrant. So, should it also be sent to the registrant? * Should reduce the number of notifications. Maybe a lot of the communications could be combined. Steps 1-5 should only be one email. For example, you don’t have to notify of a TAC request if you have already provided a TAC. * Method of communication should be left open. * The few steps here could all happen basically at the same time, via the automated control panel (as it does today). - Do we still want the 5 day window for Losing Rr to provide the TAC? - Do we need to dictate who the TAC is provided to? * Seems to be some agreement to keep the 5-day window. * In the reseller model we have to assume that the reseller is doing things on behalf of the registrant – so no need to also notify the reseller. This is redundant. So, no need to dictate to whom the TAC is provided. * Today we have a state of pending transfer – should we change that to when the TAC is provided? Is the pre-transfer notification step the new pending transfer? We think not. * Could say it’s being transfer (pending) when the registry is aware. * If we have immediate transfers do we eliminate the pending state? Think this requires more work to figure out. * If we change pending transfer status and make it policy, we’ll have to change all of the other states. Pending shouldn’t happen until the registry is informed. * Think we should skip the whole pending transfer state when the transfer is immediate. 4. Notify domain owner (pre-transfer) * Could be different parties doing the requests. * Avoid pending transfer until someone comes up with a good spot for that. * We are starting to combine the notifications. This is one notification. 5. Initiate transfer * This is when they submit it to the gaining registrar. * Anyone who has the TAC at this point can initiate the transfer. * Gaining FOA is likely to send a welcome message, but this is up to the registrar or reseller. * In combining notifications there still needs to be a way to stop the transfer. Once the requester receives the TAC, it should be able to invalidate the TAC so it can’t be used. This needs to be part of the notification – steps to take so the domain name can’t be transferred. * Transfer status is important. * But if the transfer happens immediately then there isn’t a transfer status. Maybe it will go from locked to unlocked, but that is up to the registrar. * The important thing is that the NACK has gone away in this new model. The window of time to invalidate the TAC is between the requester receives the TAC and when it is provided to the gaining registrar. * If there is an option in the notification for the registrar to stop or reverse the transfer, then that is a NACK option. * We should be able to prevent unauthorized transfer of the Domain BEFORE it would happen, proactively. As opposed to having to react to it having been transferred. * If a hacker wants to steal a domain name, they will be in full control of all communications. So, there is no way to stop it. You won’t see the notification email. Could suggest some policy language such as, “Registrars and resellers should provide multifactor authentication of transfers.” * Getting a notification at the request time allows for more time for mitigation, but may not matter if the hacker controls the communications. * There are some cases where the IT department has the ability to get the auth code and open a transfer but the legal department has the ACK/NACK control now. * Need to keep in mind that no matter what we do we can’t prevent all unauthorized transfer. * One of the problems we have today is that the gaining FOA can’t be provided. Need to be able to tell the community that the new policy is as secure as the old one. * Most TACs that are created are given out right away at the request, but still keep the 5-day timeframe as an option. Could say it should be provided at the earliest at the request and at the latest at the end of the 5-day window, to provide flexibility. * None of these policies will create a super-secure system, so make sure that whatever you have in the policy, you have a way to easily reverse the transfer. * Today, even fraudulent transfer follow the policy, so any new policy will create a map for how to get around it. 6. Request transfer at Registry * Transfer should be as immediate as possible. 7. Move domain to new Registrar * Question: Is adding a year to the registration term up for modification in this PDP? Do we want to consider that? * The one-year renewal at transfer stops the registrant from changing the registrar too frequently. * Keep the current settings – don’t automatically gain a year upon transfer of the domain name. * Just assume that we don’t change the one-year add-on period. * Goes to the next step: there was discussion early on about the TAC being reset on transfer – when the registry completes the transfer. 8. Post-transfer updates * Early on we talked about a one-time TAC. If you want to transfer again you need to create a new TAC. But who does that? Gaining registrar wouldn’t have the access. Needs to be done at the registry level. Maybe we can state this unless someone comes up with a better solution. * The registry should reset it when it has been used and/or when it’s TTL expires. * (With Co-Chair Techops hat on) There have been discussions here in this group and in Techops about clearing tac - but non-conclusive. * Registry Stakeholder Group should consider this and get back with comments. 9. Notify domain owner (post-transfer) * Questions: * Does (should) the gaining Registrar also have a policy obligation to send a notice at this stage? They will likely want to send one for business/marketing purposes, but are they required to do so? * Should the Losing Registrar be required to provide links/info about procedures to follow if Registrant feels the transfer was done in error? * Just a simple message that a domain has been transferred, with no requirements on language, should be enough. * There are several registrars that operate among themselves to quickly reverse transfers – should not mandate certain procedures. * Would like it to include the name and/or IANA ID of the new registrar. Think it should be required, but we shouldn’t specify the mechanism. 10. Fast-Undo Transfer * Need to keep notes of these discussions when we get to our transfer dispute topics later. Reasons for denial: * Need to show where transfers can fail and make sure we have those items covered. Such as for the Max renewal term (transfer would >10 y from today). * Hard coded requirements on the registry level should guide us for the creation of the TAC – such as for incorrect syntax. When the losing registrar goes to create the TAC they could potentially not get the TAC created at the registry. ACTION ITEM: Homework: WG members should look at reasons for denial in the current policy and comment on whether or not we need to update those reason. Add lines or comments to the Transfer Steps and Notifications Chart: Transfer Steps and Notifications chart [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/17ADMRTYx…> ACTION ITEM: Leadership and staff to clean up the document based on comments and determine where steps can be combined. 4. AOB (5 minutes) - Next meeting: 14 September 2021 @ 16.00 UTC

1 0

**15-MINUTE REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 07 September 2021 at 16:00 UTC
by Julie Bisland Sept. 7, 2021

Sept. 7, 2021

**15-MINUTE REMINDER** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 07 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/JAA_Cg * Check your time zone: https://tinyurl.com/3t7zjyn5 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3t7zjyn5__;!!PtGJab4!q6YgSDe…> 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 Panelists and Attendees or Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Reminder: Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 07 September 2021 at 16:00 UTC
by Nathalie Peregrine Sept. 6, 2021

Sept. 6, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 07 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/JAA_Cg * Check your time zone: https://tinyurl.com/3t7zjyn5 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3t7zjyn5__;!!PtGJab4!q0yOCeB…> 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 Panelists and Attendees or 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

2 2

Proposed agenda for meeting #16 on Tuesday 7 September 2021 at 16.00 UTC
by Emily Barabas Sept. 3, 2021

Sept. 3, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 7 September 2021 at 16.00 UTC. For agenda item 3, the focus will be on pages 3-5 of the Losing FOA working document<https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy…> as well as the Transfer Steps and Notifications chart<https://docs.google.com/spreadsheets/d/17ADMRTYxN5sA-e3WoEI96KxlH5YRALBsxgw…>. Please review these materials before the call. For agenda item 4, we will be using this new working document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…> to support discussions of the Gaining FOA charter questions. Please note that this working document is still a work in progress, and will be developed further as we get into the topic. Please feel free to share any questions on list. Kind regards, Emily, Julie, Caitlin, and Berry Transfer Policy Review Phase 1 - Meeting #16 Proposed Agenda Tuesday 7 September 2021 at 16.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Continued discussion of Losing FOA (45 minutes) * Losing FOA working document<https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy…> * Transfer Steps and Notifications chart<https://docs.google.com/spreadsheets/d/17ADMRTYxN5sA-e3WoEI96KxlH5YRALBsxgw…> 4. New Topic: Gaining FOA (30 minutes) * Gaining FOA working document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…> 5. AOB (5 minutes) - Next meeting: 14 September 2021 @ 16.00 UTC

2 1

TPR-P1 // 31 Aug 2021 Project Package
by Berry Cobb Sept. 2, 2021

Sept. 2, 2021

Dear WG, Please find a link below to project package for the TPR-P1 PDP (31 Aug 2021). 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 2. Page 02 – Project Sitrep – an extract from the Council’s Project List 3. Page 03 – Group roster 4. Page 04-06 – Work and activity metrics & Group attendance for plenary meetings 5. Page 07 – Project Plan, Gantt chart 6. Page 08-09 – Work plan & Action items for the period Key points: * The WG is proceeding according to plan against the charter topics/questions; nothing substantive to report for this period. Please let us know if you have questions. Thank you. B Berry Cobb Policy Development - Portfolio Manager Internet Corporation for Assigned Names and Numbers (ICANN) berry.cobb(a)icann.org

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 31 August 2021 at 16:00 UTC
by Julie Bisland Sept. 2, 2021

Sept. 2, 2021

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 31 August 2021 at 16:00 UTC can be found on the agenda wiki page<https://community.icann.org/x/dATpCQ> (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

2 2

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 07 September 2021 at 16:00 UTC
by Julie Bisland Aug. 31, 2021

Aug. 31, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 07 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/JAA_Cg * Check your time zone: https://tinyurl.com/3t7zjyn5 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 Panelists and Attendees or 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

2 2

Notes and action items - TPR Meeting #15- 31 August 2021
by Julie Hedlund Aug. 31, 2021

Aug. 31, 2021

Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting on Tuesday, 31 August 2021 at 16:00 UTC. The next meeting will be Tuesday, 07 September at 16:00 UTC. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items ACTION ITEM: Sarah Wyld volunteered to create a flow chart. Staff will create a Google doc template for this. Notes: Transfer Policy Review Phase 1 - Meeting #15 – Tuesday, 31 August at 16:00 UTC Proposed Agenda 1. Roll Call & SOI Updates (5 minutes) * Update to SOI – Steinar Grøtterød at: https://community.icann.org/display/gnsosoi/Steinar+Grøtterød+SOI 2. Welcome & Chair updates (5 minutes) * Updates from WG member: None. * Leadership and staff are working on draft candidate recommendations on the TAC. These will be circulated on list in the background, concurrent with the meetings. Plan is to keep the TAC discussion moving. 3. Continued discussion of Losing FOA (30 minutes) – See: Losing FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wCUMe9ii6g05…> Poll Results: Notification of TAC Request: (Q1) Should the losing registrar notify the registrant when the TAC is requested? -- 16 responses * Yes, This notification should be required in policy – 69% * It should be up to the registrar if and how they do this – 25% * No, I do not support this type of notification – 6% * Not sure/needs further discussion – 0% (Q2) What, if anything, should be required in this communication? – 16 responses * The notification should contain all of the elements listed in the Working Document – 56% * The notification should include only some of the elements listed in the Working Document – 31% * The notification should include a different set of elements, which have not yet been discussed – 0% * I do not support this type of notification – 6% * Not sure/needs further discussion – 6% Discussion: * Send way too many notifications in the first place. * Can live with option #2. But try to trigger multiple notifications to the registrant. Registrants become numb to over notification. * For Q#2 – for those who answered that “only some of the elements” should be included – what items should be included? * You might include only the IANA ID. * Useful information to the end user in the transfer process – it all depends on the wording you put into this; how you formulate the communication. You could compromise and still keep the same bullet points as in the working document. * Also wondering if perhaps the message should require logging in at the registrar to see messages, as opposed to getting the message in email. it’s a common practice today in various retail contexts so just a thought. * What if we make it an option for the registrar to send the notification and the reseller has to ask for it to be sent? * If you make it too hard to transfer then a reseller won’t want to bother to transfer and may stick with a bad registrar. * Don’t understand why the TAC should be sent in an email – security issue? Should not include the TAC. * One of the reason for the notification of the TAC request is that we don’t have the losing FOA. If you request the TAC it probably means that you intend to do a transfer. If we have the losing FOA it won’t be necessary. * Note that the notification goes out when the registrant makes the request – but will get notified if someone has hacked the account also. Note that reseller requests are outside of this scenario. There are cases where a reseller makes a request as part of the regular business, although the registrant will get a notice. Need to take into account other types of requests. Need to make the distinction between registrant requests for transfer and reseller requests for transfer. Important to document those other types of transfers. * There can always be the option of the registrar authorized transfer in scenarios of needing to do bulk transfer for a reseller. Notification of Pending Transfer: (Q1) Should the losing registrar notify the registrant when a transfer is pending? – 19/16 responses * Yes, This notification should be required in policy – First response: 74%/Second response: 56% * It should be up to the registrar if and how they do this – First response: 21%/Second response: 13% * No, I do not support this type of notification – First response: 5%/Second response: 31% * Not sure/needs further discussion – First response: 0%/Second response: 0% (Q2) What should be included in the notification of pending transfer? – 19 responses/16 responses * Include a link to deny transfer (status quo - Losing FOA) – First response: 26%/Second response: 13% * Include a link to deny the transfer and a link to approve the transfer – First response: 58%/Second response: 50% * Include no links (the message serves as a notification only) –First response: 11 %/Second response: 13% * I do not support any notification of pending transfer – First response: 0%/Second response: 25% * Not sure/needs further discussion – First response: 5%/Second response: 0% Discussion: * Question: Is the transfer already done when the notification is sent out? Answer: the transfer is not complete. The notification is providing the TAC – that the registrar has updated the registry with the TAC and the transfer can go through. * Maybe we should have an explanation for the different notifications. But noting that this is just a discussion of the various examples. * Confusing – not sure how this is different than the previous TAC notification – notification of TAC request, not pending transfer. This is kind of, but not quite, the current losing FOA – you aren’t going to NACK this, but just approve it. * Doesn’t make sense. The registrant or reseller will go to the registrar and ask for the TAC. Then the registrant will go to the new registrar with the TAC and the registrar will go to the registry with the TAC. This notification of pending transfer seems to be a new way to describe the losing FOA. This will only be implemented if we decide to keep the losing FOA. * One of the good things about the losing FOA today is that you can see where the name is going. * Seems that immediate transfer is something everyone wants. * This pending idea – there is no pending if there’s an immediate transfer. It is pending between when the registrar creates the TAC but before it is used. * You don’t know who the gaining registrar is in this notification because you only created the TAC. * If the transfer is immediate then it is never pending. * It sounds like we're all in agreement to get rid of this middle email; maybe we should consider if any required elements listed here should be stuck into the Notification of TAC email instead? * Doesn’t the loosing registrar who the transfer request is coming from (name of registrar)? * There is the window of when the registrant requests the TAC and when the registrant gets the TAC. * The losing registrar do know who will be the gaining registrar – because they know where the TAC request is coming from, correct? No, when the registrant requests the TAC the registrar of record doesn’t know where it will go. In an instant transfer, you wouldn’t know the gaining registrar until the transfer is complete. * This should be combined with the TAC request notification. Then we aren’t sending two emails at the same time. Just put more information in the TAC request notification. * If the notifications are combined, will the registrant be able to NACK or ACK? * if we combine this into the notification of TAC request, then this is sent before the transfer has been submitted to the new Registrar, so there is no ACK or NACK yet. * The “NACK” process at this point would be to cancel or overwrite the TAC since the transfer then would not be able go ahead, and that cancel TAC is part of the first email template, right? * If we decide to go with immediate transfers then this information would be in the notification that the transfer is complete. * In our previous discussions we agreed that immediate transfer was the outcome we were looking for. * If we go to immediate transfer then we should take out the pending transfer notification. * Members should be talking with their Stakeholder Groups during these discussions, and not waiting. * Question: If we combine this into one notification – TAC request and possibility to provide a NACK/ACK – how do we solve the issue that the registrant might be different from the account holder? Answer: Are there logical points in the flow where a notification should happen? Where in the logical flow does notification have to happen or could occur? * If the pending transfer starts if a registrar is allowed 5 days to produce the TAC and send to the registrant, and that causes an email notification, the registrant could present the TAC to the account holder. * The experience when transferring away should be so good that the customer would want to come back to the registrar. Notification of Transfer Completion: (Q1) Should the losing registrar notify the registrant when a transfer is complete? 12 responses * Yes, This notification should be required in policy -- 42% * It should be up to the registrar if and how they do this -- 42% * No, I do not support this type of notification -- 17% * Not sure/needs further discussion -- 0% (Q2) What, if anything, should be required in this communication? 12 responses * The notification should contain all of the elements listed in the Working Document -- 17% * The notification should include only some of the elements listed in the Working Document -- 58% * The notification should include a different set of elements, which have not yet been discussed -- 0% * I do not support this type of notification -- 25% * Not sure/needs further discussion -- 0% Discussion: * For those who don’t support submitting the notice, from a registrant point of view the losing registrar should be off the hook; this should be a gaining registrar notification. * The problem is that the gaining registrar does not know who the domain owner is at this point. * Concern with the gaining Registrar sending it is that the contact info on the domain can change when the transfer happens, so it might not go to the original pre-transfer domain owner. * We can allow the reseller to send it, as long as there' a record that it was sent, contains what it should, etc. ? * A registrar can relay it’s requirements to the reseller but the registrar would still be on the hook for compliance if the reseller did not do it. * Compomise could be to not make this mandatory. See Losing FOA Working Document: Losing FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wCUMe9ii6g05…> Start at page 3: * Fourth bullet and items below go through the thought process of the in between time. * At some point we need to discuss when the losing registrar can prevent a TAC being created and thus block the transfer. Agree that we need to discuss this, but we first need to agree on a more streamlined process. * Could there be a notification when a transfer is requested – whether the registrant or someone else? “Transfer being requested” is confusing – that could be preparing it for transfer, but not initiated in the gaining registrar’s system. There should be two notices to the registrant, with the first being a combination of the TAC request and the pending transfer: 1) notification of TAC request/pending with ACK/NACK/cancel TTL; 2) losing registrar send notification to pre-transfer contact saying “goodbye”. Make sure there is no confusion in how we describe these steps. * Due diligence should happen before the TAC is provided – so first notification is only that a TAC is requested; second is when the registrar approves it based on due diligence. * Need a chart with the different stages of the transfer process and when notifications are sent. But need to get to one chart, not multiple options. * There should be available options, which we have now because of the 5-day delay. * Maybe call it “pre-transfer notification” which includes notification of TAC request and pending transfer. * Don’t include different options in the policy, but just what has to be included. Have a standardized process for most cases. * Helpful if Sarah and Kristian can propose how this flow would look, with or without a diagram. * Hard to do due diligence, so should be up to the registrars. We don’t have to stipulate what happens during the up-to-5-day period. Leave it as an available option. * If we combine notifications 1 and 2, then we can’t do the ACK/NACK. ACTION ITEM: Sarah Wyld volunteered to create a flow chart. Staff will create a Google doc template for this. 4. New Topic: Gaining FOA (45 minutes) – See: Gaining FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> * Postpone discussion to next meeting. 5. AOB (5 minutes) * Next meeting: 7 September 2021 @ 16.00 UTC

1 0

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

Aug. 31, 2021

**Starts in 15 minutes** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 31 August 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/dATpCQ Check your time zone: https://tinyurl.com/yp6arh3p [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/yp6arh3p__;!!PtGJab4!sX4W4YG…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * 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. * Alternate replacement confirmations – In order to keep track of 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): Please 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

2 1

Updated SOI
by Steinar Grøtterød Aug. 31, 2021

Aug. 31, 2021

Dear TPR Team, This is to inform you that my SOI is updated: https://community.icann.org/display/gnsosoi/Steinar+Grøtterød+SOI Regards, Steinar Grøtterød

1 0