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

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

Proposed agenda for meeting #15 on Tuesday 31 August 2021 at 16.00 UTC
by Emily Barabas Aug. 30, 2021

Aug. 30, 2021

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

2 1

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

Aug. 30, 2021

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

1 0

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

Aug. 24, 2021

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

Aug. 24, 2021

Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting on Tuesday, 24 August 2021 at 16:00 UTC. The next meeting will be Tuesday, 31 August at 16:00 UTC. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items ACTION ITEM: Leadership and staff will lay out the three proposed notifications/communications concepts/proposals. WG members to review and comment in preparation for the meeting on 31 August. See the document at: Losing FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wCUMe9ii6g05…> Also see the project workplan [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1FunWaz3g…> for action items. Notes: Transfer Policy Review Phase 1 - Meeting #14 – Tuesday, 24 August at 16:00 UTC Proposed Agenda 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) -- NCSG is leaning to more security for the AuthInfo code; maybe to make it available to the registrant. We will discuss this further. 3. Continued discussion of Losing FOA (75 minutes) * Losing FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wCUMe9ii6g05…> Page 7: Potential alternatives: * Provide notice before the transfer happens [option: with link to deny transfer] [option: with links to deny transfer and approve transfer] [option: with no links, notification only] * Advantage: Prior notice could reduce the number of transfers you need to reverse relative to the scenario where notification happens after the transfer has taken place. * Provide notice after the transfer has occurred. Options related to the above alternatives: * Content of the message: * Mandatory template or * Mandatory elements to include in the message and optional template or * Mandatory elements to include in the message only (no template) * Delivery of the message: * Require specific delivery method (for example email) or * Allow the registrant to choose how the message is received Discussion: * Think that the majority of transfers that occur are valid so the majority of customers would be best served by a process that lets the transfer happen as quickly as possible, with the transfer first and notice afterward; If we provide the notice before the transfer then we are building in a delay. There also should be an easy process to reverse a transfer. * As to reversing unauthorizing transfers, we need to have that discussion as soon as possible. It could be that a transfer reversal could put other processes in limbo. * There are so many interdependent processes that we may need to dig into some before we make other decisions. * Have we determined definitively that we are doing to eliminate the 5-day period? If we opted to provide a notice before a transfer that gave the registrant the option to approve the transfer that could be a middle ground option. * Don’t think we’ve agreed to get rid of the 5-day delay – even if we keep it there should be a way to do it faster. * It is important that if we send any kind of losing FOA there should be an option to approve or deny, unless the transfer is automatic. * Right now if we acknowledge a transfer because of the 5-day delay it doesn’t immediately happen. * Improvement to consider: when the registrant receives and acknowledges the transfer it should immediately go through; no 5-day wait. * Goal is to speed up the process from the end-user perspective, without losing security. * Getting back into the TAC discussions as well as how to recover bad transfers. * Once the registrar has the TAC then the transfer can go. * There are two 5-day windows – provide the TAC and unlock; 5-day window for losing FOA. We are saying the losing FOA could drop the 5-day period if we can get an update to the notification that allows them to immediately do it. * So there would be a fast-transfer process. * Relates to where we are planning to put our security? Whatever choice you make is fine; just need to understand that choice. Summary: If the TAC is supposed to be the final authority then you apply a set of security principles to the TAC; then it naturally follows that a near-real time transfer is probably okay. Separately we do need a way to reverse, but does that have to be real-time or have a delay? You can still do a notification that a transfer occurred (after the transfer) to allow the registrant to reverse. So put all the work and protections on the TAC and allow an option to reverse the transfer. * Keep in mind the possibility of multiple people being in the middle of this. * If you look at the reversal process, if there is an error made or unauthorized transfer you need a way to reverse it as quickly as possible. * Multi-factor authentication is important, but don’t think we should stipulate what it is. * Proposal: The TAC is the most important feature in the transfer process. We need to assume that the registrant has a relationship with the account holder and reseller; we could consider to put in a notification when a TAC is created with a TTL. The actual registrant would get a notification when the TAC is created and also when the transfer is completed, as well as reverse procedures. So, a pre-notification (the TAC) and also a post-notification. * Just have two notifications, one when the TAC is created and one when the transfer is complete. The notifications should go directly to the registrant. * It is possible to put information about what entity granted the TAC so the registrant can have it. * Should there be mandatory language in the notifications? Do we also mandate multiple communication mechanisms? * There should be some requirement for language but shouldn’t be very specific; leave it up to the registrar. * It is reasonable to have specific parts to include but not the exact language; just that it should say certain things. Might be worthwhile to check with ICANN’s Compliance team as to whether they can enforce without having mandatory language. * It is important that it is in the contract language, but not necessarily in English. * Don’t want to be too specific because technology changes frequently. Allow multiple communication options. Page 2: Draft New Template(s) “Notification of Transfer Completion” Requirements (MUSTs) [summary from meeting on 17 August] * Sent by losing registrar to registrant they had on file when the domain was with them * Within TBD time of transfer (within 24 hours? Depends on timeframe for reversal process) * Includes domain name(s) and new registrar (may include IANA ID) * Explanation that the domain was transferred, with date/time of transfer * What to do if this is an invalid transfer (how to start the reversal process) * In language of registration agreement with registrant * Information about who and how the TAC was given (MAYs) * Registrar may consolidate, at their option, a group of domains being transferred into a single notice where the gaining registrar and the losing registrant email are consistent. Discussion: * Can we get rid of the notification by fax? * Getting the notice to the actual registrant (domain holder) may include several people in that path. * Ultimately the registrant is in charge; but if you look at the reseller model it is based on the fact that the registrant doesn’t want to be burdened by any of the technical aspects. If we talk about reseller there is a legal basis in contracts to unburden the registrant from the technical procedures, such as transfers. * This notification on pending transfer in the document is basically a FOA. At some point we need to decide if this should still be there, if it should be removed or as suggested at last meeting being made an optional feature. Timing Considerations: * The timing of the losing FOA might be dependent on the timing of the reversal. * Are there multiple post-transfer notifications? Do we allow registrars to send follow up notification in the registrant has responded? * Is there any reason to give a registrar more than 24-hours to send a notification of transfer completion. Seems logical that it should happen as soon as possible. The reversal would then be a separate process. * In some cases a domain name may be transfers a couple of times before there is a complaint/dispute process. Something to consider if we are thinking about a 60-day lock after transfer. * Leave the dispute process mechanism timeline separate from the notification timeline, but may need to consider dependencies. * We could say the notification of transfer complete should be sent without undue delay but no more than X business days after. “Notification of Pending Transfer” Requirements (MUSTs) * Sent by losing registrar to registrant they have on file at time of transfer request * Triggered by transfer (sent within 24 hours) * Includes domain name(s) and new registrar (may include IANA ID) * Explanation that the domain was requested to transfer, with date/time of transfer request * Include maximum information (as permitted) about requesting party available * What to do if this is an invalid transfer (how to NACK) * The date and time the transfer would take effect, if no action taken. * In language of registration agreement with registrant * Information about who and how the TAC was given [Note, absent a link to ACK or NACK, the notification of pending transfer is quite similar to Losing FOA] (MAYs) Registrar may consolidate, at their option, a group of domains being transferred into a single notice where the gaining registrar and the losing registrant email are consistent. Discussion: * On the pending transfer notification, similar to the losing FOA – so we are back as to whether we should have the losing FOA or not. * Is that a business model flexibility that we want to keep? Or is that a policy? * In the current process the registrant can opt out of the 6-day lock; if we want to keep the losing FOA as optional then the registrant should be able to opt into it. * Question: At what stage should the registrant consider to opt in for the losing FOA? Answer: When you request the TAC. * Question: So are we assuming the TAC is not created when the domain is created? Answer: It seems that we are proceeding on that assumption. Though we don’t have consensus on that. * Suggest that when you create a TAC that could also be a notification of pending transfer. The losing FOA should only be done if the registrant opts into it. * Question: Are we assuming that only the registrant has access to the TAC? Answer: Don’t think that is what we are saying. Assumed whoever has access to the account where the domain is managed has access to the TAC. * We are assuming that the notifications are going to the registrant. * ACK or NACK should only be if you opt into it. Shouldn’t delay the transfer. * It doesn’t make sense to ACK or NACK a transfer that is not in process; it is not in process until the TAC is sent to the gaining registrant. * No matter where the TAC goes, it can be used to transfer the domain. * Example: You receive an email with the TAC and ACK; and that email includes a NACK. * Above example is a bad idea; most registrants would be confused by this. * We already had in mind that a TAC should be cancel-able, right? One can invalidate the TAC? So it would make sense that in the same place where the TAC is provided to the RNH they also have instructions for / ability to invalidate that TAC. * TAC should not be distributed via email. But we aren’t deciding this detail. Registrar should make this decision. * Registrant should be able to have a path to invalidate a transfer. * We shouldn’t conflate invalidating the TAC with NACKing the transfer. * The email could tell the user to go back to their CP to invalidate their TAC. * Question: Should the notification of TAC created go in here or in the AuthInfo Code documents? Answer: Staff can insert it in both documents. ACTION ITEM: Leadership and staff will lay out the three proposed notifications/communications concepts/proposals. WG members to review and comment in preparation for the meeting on 31 August. 4. AOB (5 minutes) - Next meeting: 31 August 2021 @ 16.00 UTC

1 0

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

Aug. 24, 2021

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 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

1 0