- GNSO-TPR - lists.icann.org

January and February 2022 calls | Transfer Policy Review PDP WG
by Terri Agnew Nov. 18, 2021

Nov. 18, 2021

**We are sending in advance to get dates on everyone’s calendar. Dear all, The calls for January and February 2022 for the Transfer Policy Review PDP WG are listed below and the .ics files are attached to this email. Please be sure to download them the your inbox calendars. The scheduled start time is 16:00 UTC for 90 minutes. * Tuesday, 04 January 2022 * Tuesday, 11 January 2022 * Tuesday, 18 January 2022 * Tuesday, 25 January 2022 * Tuesday, 01 February 2022 * Tuesday, 08 February 2022 * Tuesday, 15 February 2022 * Tuesday, 22 February 2022 Future meeting invitations will be sent out closer to the date of the meeting. Next meeting is scheduled on 23 November 2021. Thank you. With kind regards, Terri --- Terri Agnew Policy Operations Specialist (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: terri.agnew.icann 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

Transfer Policy Review PDP WG
by ICANN Policy Calendar Nov. 18, 2021

Nov. 18, 2021

Meeting: Transfer Policy Review PDP WG Date/Time: Recurring every Tuesday at 16:00 UTC for 90 minutes, 04 January 2022 through 22 February 2022 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/Z4HOCg Check your time zone: https://tinyurl.com/sb3srr8b 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

Transfer Policy Review PDP WG
by ICANN Policy Calendar Nov. 18, 2021

Nov. 18, 2021

Meeting: Transfer Policy Review PDP WG Date/Time: Recurring every Tuesday at 16:00 UTC for 90 minutes, 04 January 2022 through 22 February 2022 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/Z4HOCg Check your time zone: https://tinyurl.com/sb3srr8b 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

Proposed agenda for meeting #25 on Tuesday 23 November 2021 at 16:00 UTC
by Emily Barabas Nov. 18, 2021

Nov. 18, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 23 November 2021 at 16:00 UTC. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #25 Proposed Agenda Tuesday 23 November 2021 at 16:00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Losing FOA Candidate Recommendations (60 minutes) * Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14); Transfer Steps and Notifications<https://docs.google.com/spreadsheets/d/17ADMRTYxN5sA-e3WoEI96KxlH5YRALBsxgw…> 1. Rationale for Elimination of the Gaining FOA (15 minutes – time permitting) * Gaining FOA Working Document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…> (beginning on p. 16) 2. AOB (5 minutes) * Next call: Tuesday 30 November 2021 at 16:00 UTC

1 0

Proposal re: sending notification wording
by Owen Smigelski Nov. 17, 2021

Nov. 17, 2021

Hi team, During our call yesterday, we reviewed a few recommendations that included wording such as: The Working Group recommends that the Registrar of Record MUST send a notification [specify method of sending?] to the RNH (as listed in the Registration Data at the time of the TAC request) … [emphasis added] I suggest that we remove the bracketed wording, and follow the approach used for the ERRP. That consensus policy (at https://www.icann.org/resources/pages/errp-2013-02-28-en <https://www.icann.org/resources/pages/errp-2013-02-28-en>) states: 2.1.1 Prior to the expiration of any gTLD registration, registrars must notify the registered name holder of the expiration at least two times. One of these notices must be sent approximately one month prior to expiration and one must be sent approximately one week prior to expiration. [emphasis added] After the formal sections of the policy, there is a notes section, which includes this: Expiration Reminder Notices: The policy recommendations by the GNSO recognize that some flexibility is required in the timing of pre-expiration renewal notices. As such, if the notices required to be sent approximately one month and one week prior to expiration described in paragraph 2.1.1 are transmitted between 26-35 days and between 4-10 days prior to expiration, respectively, this would be considered compliant with the policy. [emphasis added] Using this approach, we can leave the wording as “send a notification” and then recommend that there is guidance in the notes, such as: Notification format: The policy recommendations by the GNSO recognize that notifications may be sent via email, SMS, or other secure messaging system. These examples are not intended to be limiting, and it is understood that additional methods of notification may be created that were not originally anticipated by the working group. Happy to discuss via email or during a future call. Regards, Owen

1 0

Re: [GNSO-TPR] Notes and action items - TPR WG Meeting #23 - 16 Nov 2021
by Emily Barabas Nov. 17, 2021

Nov. 17, 2021

Dear Working Group members, Following yesterday’s call, staff had an action item to review the deliberations about the proposed notification of TAC provision and specifically how this notification should fit alongside the provision of the TAC itself. In going back to the recordings, I can confirm that Sarah’s recollection is correct – members expressed support for the idea that if the TAC is being provided by email and the notification of TAC provision is being provided by email, these can be combined. If the TAC is provided by another method and it's not certain that it was directly sent to the RNH, then the RNH must be notified separately. Please see pages 29-33 of the transcript from 14 September here: https://gnso.icann.org/sites/default/files/policy/2021/transcript/transcrip…. Thanks for catching the error in the text, Sarah. We will go ahead and update the draft recommendations. Kind regards, Emily From: GNSO-TPR <gnso-tpr-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Tuesday, 16 November 2021 at 18:30 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: [GNSO-TPR] Notes and action items - TPR WG Meeting #23 - 16 Nov 2021 Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be on Tuesday, 23 November at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items 1. Losing FOA Candidate Recommendations – see: Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14) Candidate Recommendation #12: Staff will add a reference/footnote. Candidate Recommendation #13: 1) Staff to review the discussions to clarify the rationale for this recommendation to have two communications. 2) WG members to suggest wording for the method of sending and period of time (text in brackets). Candidate Recommendation #14: WG members to suggest wording re: the method of sending and period of time (text in brackets). Candidate Recommendation #15: 1) WG members to suggest wording re: the method of sending and period of time (text in brackets). 2) Staff to update the context to add text on when this makes sense to be used. Candidate Recommendation #16: WG members to suggest wording re: the method of sending and period of time (text in brackets). 2. Rationale for Elimination of the Gaining FOA: WG members to review the document at Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> (beginning on p. 16) and provide suggestions and comments if any. Transfer Policy Review Phase 1 - Meeting #23 Tuesday 16 November 2021 at 16:00 UTC 1. Roll Call & SOI Updates * No updates provided. 2. Welcome & Chair updates * Will return to the lock discussion in a few weeks. * Note that since we are being so efficient, we are looking to do a Project Change Request to pull forward the NACKing discussion scheduled for Phase 2 so we can get a complete view of the transfer policy during Phase 1a. That includes copying what we are doing now to review charter questions, develop recommendations, and incorporate into the Phase 1 report. We will inform the Council that those discussions may include the TEAC – how it may change or be enhanced with respect to the NACKing of transfers, but any recommendations for changes will not be part of Phase 1, but will stay in Phase 2. * Schedule NACKing after we get through with our discussions on bulk, etc. * The RrSG is holding a poll on locking. * At-Large CPWG also will hold a poll on locking. 3. Losing FOA Candidate Recommendations – see: Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14) Candidate Recommendation #12: The Working Group recommends eliminating from the Transfer Policy the requirement that the Registrar of Record send a Losing Form of Authorization. This requirement is detailed in sections [xxxx] of the Transfer Policy. * Wonder if there should be a footnote that there will still be a notification. * It would really help to include the explanation/context so that people not familiar will know that there will still be a notification. * Context: How this is structured – the candidate recommendations are preceded by a response to the charter questions, which does provide the context, including the rationale. These recommendations won’t be presented in isolation. * ACTION ITEM: Staff will add a reference/footnote. Candidate Recommendation #13: * What do we mean by “distinct” as in “If the Registrar of Record provides the TAC by email, the email containing the TAC and the message notifying the RNH of the TAC request must be two distinct communications.” Could be “two separate communications”. * Don’t see the value of sending two separate emails. Would rather see a combination of this in one email. * The important part is the notification to the registered name holder (RNH). There is also the concept of the 5-day window at the beginning. * Definitely agree we must ensure the RNH is notified; not sure it needs to be two separate messages. But we must have had some reason for it? * Would like to include the name of the person who requested it. * If we look at rows 4 and 5 in the charter, that is what we are doing here. The question we haven’t answered is do we have to specify who the TAC is provided to? If provided to the RNH then we don’t need separate methods. If to someone other than the RNH we’ll need two messages. The security element (secondary notification to RNH) is only needed if the TAC is provided in some method OTHER than by email to the RNH * It can only go to the RNH. It only makes sense to go there. * When we are talking about how we supply the TAC, there could be other means. We could send a notice that a TAC has been created and to look in your account,. * If we look at the early deliberations, some support was expressed for making this two distinct communications for security reasons. * Maybe we split this recommendation up: 1) notification to RNH that a TAC has been requested. 2) If the RNH is receiving the TAC via a communication then they know that the request happened (so no need for a separate communication). * Our goal is to ensure that the RNH is aware of the request. * We want to say if the TAC is being communicated to the RNH then we don’t need two communications, but if provided by a different mechanism then the RNH should receive a notification that the request has happened. * It might be helpful to zoom out to look at the table at: https://docs.google.com/spreadsheets/d/17ADMRTYxN5sA-e3WoEI96KxlH5YRALBsxgw… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/17ADMRTYx…>. * Also note that the recommendations are in order of mandatory ones first then optional, rather than in order of the process steps. * Registrar doesn’t know how the reseller is going to deliver the TAC. * Maybe it will be clearer if we break this recommendation into two parts. * Try to make the type of communication/notification as generic as possible. Suggest wording. * List doesn’t say specifically that the TAC has to be provided or how. * Don’t we have recommendations relating to the TAC? We have a set of recommendations that are specific to the TAC. Notifications of the provision of the TAC are related to the Losing FOA, so that is why the reference is here. We are likely to reorganized these when they are agreed to so all of the TAC recommendations are together. * Envision a scenario where someone logs into a portal and updates the RNH email address and requests a TAC – could be fraud in the account. So, if a RNH email is changed in a certain amount of time then a notification is sent to the previous RNH. * Think the above scenario will come up as part of the change of registrant process. Not sure that is a problem we need to solve for. * We cannot stop this type of fraud with an ICANN policy. * Concerned that we are relying on laws to provide security via some cumbersome and lengthy process, rather than looking at mechanisms that can enhance the security of the transfer. * This relates to Change of Registrant (COR) so we’ll delay that part of the discussion. * ACTION ITEMS: 1) Staff to review the discussions to clarify the rationale for this recommendation to have two communications. 2) WG members to suggest wording for method of sending and period of time (text in brackets). Candidate Recommendation #14: * On number 1 and the IANA ID – losing registrar always gets the IANA ID but not the name of the gaining registrar – if we want that then the registry will have to provide it. * Does it matter that the IANA ID is provided with the name of the gaining registrar? * Think adding IANA ID will overly complicate a communication intended for non-technical people. * Agree that regular users will find IANA ID confusing and unhelpful, but also agree that we can't currently automagically get the actual registrar name. * “Regular users” have a problem when there are resellers have initiated the transfers and the RNH sees the Registrar name (with/without IANA ID). * We do not have info about resellers at the gaining registrar. * Not sure that we need to set a requirement on that. * Language seems flexible enough to allow for minimal notification. * In most cases we see reporters do not know about registrars and file reports with compliance as changing reseller/service provider, but in fact it ends up with changing registrar. * ACTION ITEM: WG members to suggest wording re: the method of sending and period of time (text in brackets). Candidate Recommendation #15: * This is one of the optional notifications. * Add a number 4, the reason for the delay, if there is one? If it is due to a delayed TAC response this would be a good idea. * Do we need to add the rationale for why this is needed? Maybe clarifying when this makes sense to be used in the context. * ACTION ITEM: 1) WG members to suggest wording re: the method of sending and period of time (text in brackets). 2) Staff to update the context to add text on when this makes sense to be used. Candidate Recommendation #16: * This is the second optional notification – the pending notification. * If this is optional, do we have to specify the period of time? * ACTION ITEM: WG members to suggest wording re: the method of sending and period of time (text in brackets). 4. Rationale for Elimination of the Gaining FOA – see: Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> (beginning on p. 16) ACTION ITEM: WG members to review the Rationale for Elimination of the Gaining FOA – see: Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> (beginning on p. 16) and provide suggestions and comments if any. 5. AOB * Next call: Tuesday 23 November 2021 at 16:00 UTC

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 16 November 2021
by Julie Bisland Nov. 16, 2021

Nov. 16, 2021

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

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 23 November 2021 at 16:00 UTC
by Julie Bisland Nov. 16, 2021

Nov. 16, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 23 November 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/ewiHCg * Check your time zone: https://tinyurl.com/29892btv 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

Notes and action items - TPR WG Meeting #23 - 16 Nov 2021
by Julie Hedlund Nov. 16, 2021

Nov. 16, 2021

Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be on Tuesday, 23 November at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items 1. Losing FOA Candidate Recommendations – see: Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14) Candidate Recommendation #12: Staff will add a reference/footnote. Candidate Recommendation #13: 1) Staff to review the discussions to clarify the rationale for this recommendation to have two communications. 2) WG members to suggest wording for the method of sending and period of time (text in brackets). Candidate Recommendation #14: WG members to suggest wording re: the method of sending and period of time (text in brackets). Candidate Recommendation #15: 1) WG members to suggest wording re: the method of sending and period of time (text in brackets). 2) Staff to update the context to add text on when this makes sense to be used. Candidate Recommendation #16: WG members to suggest wording re: the method of sending and period of time (text in brackets). 2. Rationale for Elimination of the Gaining FOA: WG members to review the document at Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> (beginning on p. 16) and provide suggestions and comments if any. Transfer Policy Review Phase 1 - Meeting #23 Tuesday 16 November 2021 at 16:00 UTC 1. Roll Call & SOI Updates * No updates provided. 2. Welcome & Chair updates * Will return to the lock discussion in a few weeks. * Note that since we are being so efficient, we are looking to do a Project Change Request to pull forward the NACKing discussion scheduled for Phase 2 so we can get a complete view of the transfer policy during Phase 1a. That includes copying what we are doing now to review charter questions, develop recommendations, and incorporate into the Phase 1 report. We will inform the Council that those discussions may include the TEAC – how it may change or be enhanced with respect to the NACKing of transfers, but any recommendations for changes will not be part of Phase 1, but will stay in Phase 2. * Schedule NACKing after we get through with our discussions on bulk, etc. * The RrSG is holding a poll on locking. * At-Large CPWG also will hold a poll on locking. 3. Losing FOA Candidate Recommendations – see: Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14) Candidate Recommendation #12: The Working Group recommends eliminating from the Transfer Policy the requirement that the Registrar of Record send a Losing Form of Authorization. This requirement is detailed in sections [xxxx] of the Transfer Policy. * Wonder if there should be a footnote that there will still be a notification. * It would really help to include the explanation/context so that people not familiar will know that there will still be a notification. * Context: How this is structured – the candidate recommendations are preceded by a response to the charter questions, which does provide the context, including the rationale. These recommendations won’t be presented in isolation. * ACTION ITEM: Staff will add a reference/footnote. Candidate Recommendation #13: * What do we mean by “distinct” as in “If the Registrar of Record provides the TAC by email, the email containing the TAC and the message notifying the RNH of the TAC request must be two distinct communications.” Could be “two separate communications”. * Don’t see the value of sending two separate emails. Would rather see a combination of this in one email. * The important part is the notification to the registered name holder (RNH). There is also the concept of the 5-day window at the beginning. * Definitely agree we must ensure the RNH is notified; not sure it needs to be two separate messages. But we must have had some reason for it? * Would like to include the name of the person who requested it. * If we look at rows 4 and 5 in the charter, that is what we are doing here. The question we haven’t answered is do we have to specify who the TAC is provided to? If provided to the RNH then we don’t need separate methods. If to someone other than the RNH we’ll need two messages. The security element (secondary notification to RNH) is only needed if the TAC is provided in some method OTHER than by email to the RNH * It can only go to the RNH. It only makes sense to go there. * When we are talking about how we supply the TAC, there could be other means. We could send a notice that a TAC has been created and to look in your account,. * If we look at the early deliberations, some support was expressed for making this two distinct communications for security reasons. * Maybe we split this recommendation up: 1) notification to RNH that a TAC has been requested. 2) If the RNH is receiving the TAC via a communication then they know that the request happened (so no need for a separate communication). * Our goal is to ensure that the RNH is aware of the request. * We want to say if the TAC is being communicated to the RNH then we don’t need two communications, but if provided by a different mechanism then the RNH should receive a notification that the request has happened. * It might be helpful to zoom out to look at the table at: https://docs.google.com/spreadsheets/d/17ADMRTYxN5sA-e3WoEI96KxlH5YRALBsxgw…. * Also note that the recommendations are in order of mandatory ones first then optional, rather than in order of the process steps. * Registrar doesn’t know how the reseller is going to deliver the TAC. * Maybe it will be clearer if we break this recommendation into two parts. * Try to make the type of communication/notification as generic as possible. Suggest wording. * List doesn’t say specifically that the TAC has to be provided or how. * Don’t we have recommendations relating to the TAC? We have a set of recommendations that are specific to the TAC. Notifications of the provision of the TAC are related to the Losing FOA, so that is why the reference is here. We are likely to reorganized these when they are agreed to so all of the TAC recommendations are together. * Envision a scenario where someone logs into a portal and updates the RNH email address and requests a TAC – could be fraud in the account. So, if a RNH email is changed in a certain amount of time then a notification is sent to the previous RNH. * Think the above scenario will come up as part of the change of registrant process. Not sure that is a problem we need to solve for. * We cannot stop this type of fraud with an ICANN policy. * Concerned that we are relying on laws to provide security via some cumbersome and lengthy process, rather than looking at mechanisms that can enhance the security of the transfer. * This relates to Change of Registrant (COR) so we’ll delay that part of the discussion. * ACTION ITEMS: 1) Staff to review the discussions to clarify the rationale for this recommendation to have two communications. 2) WG members to suggest wording for method of sending and period of time (text in brackets). Candidate Recommendation #14: * On number 1 and the IANA ID – losing registrar always gets the IANA ID but not the name of the gaining registrar – if we want that then the registry will have to provide it. * Does it matter that the IANA ID is provided with the name of the gaining registrar? * Think adding IANA ID will overly complicate a communication intended for non-technical people. * Agree that regular users will find IANA ID confusing and unhelpful, but also agree that we can't currently automagically get the actual registrar name. * “Regular users” have a problem when there are resellers have initiated the transfers and the RNH sees the Registrar name (with/without IANA ID). * We do not have info about resellers at the gaining registrar. * Not sure that we need to set a requirement on that. * Language seems flexible enough to allow for minimal notification. * In most cases we see reporters do not know about registrars and file reports with compliance as changing reseller/service provider, but in fact it ends up with changing registrar. * ACTION ITEM: WG members to suggest wording re: the method of sending and period of time (text in brackets). Candidate Recommendation #15: * This is one of the optional notifications. * Add a number 4, the reason for the delay, if there is one? If it is due to a delayed TAC response this would be a good idea. * Do we need to add the rationale for why this is needed? Maybe clarifying when this makes sense to be used in the context. * ACTION ITEM: 1) WG members to suggest wording re: the method of sending and period of time (text in brackets). 2) Staff to update the context to add text on when this makes sense to be used. Candidate Recommendation #16: * This is the second optional notification – the pending notification. * If this is optional, do we have to specify the period of time? * ACTION ITEM: WG members to suggest wording re: the method of sending and period of time (text in brackets). 4. Rationale for Elimination of the Gaining FOA – see: Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> (beginning on p. 16) ACTION ITEM: WG members to review the Rationale for Elimination of the Gaining FOA – see: Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> (beginning on p. 16) and provide suggestions and comments if any. 5. AOB * Next call: Tuesday 23 November 2021 at 16:00 UTC

1 0

**10-minute reminder** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 16 November 2021 at 16:00 UTC
by Julie Bisland Nov. 16, 2021

Nov. 16, 2021

**10-minute reminder** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 16 November 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/eQiHCg * Check your time zone: https://tinyurl.com/3f849rjd [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3f849rjd__;!!PtGJab4!vnP3Jqy…> 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