- GNSO-TPR - lists.icann.org

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

Aug. 17, 2021

Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting on Tuesday, 17 August 2021 at 16:00 UTC. The next meeting will be Tuesday, 24 August at 16:00 UTC. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items ACTION ITEM: In preparation for the next meeting on 24 August WG members to provide suggested language for changes to the current losing FOA policy in the working document along with those provided on page 3 at: https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy…. Notes: Transfer Policy Review Phase 1 - Meeting #13 – Tuesday, 17 August at 16:00 UTC Proposed Agenda 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes 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…> At-Large Consolidated Policy Working Group (CPWG) comments – Steinar Grotterod on Outcomes of CPWG discussions: (Link to the Losing FOA working document: https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy… ) * Held discussions and polls. * Outcome is that CPWG agreed to keep the losing FOA as mandatory. * What the CPWG is: Policy members from the At-Large community. Report every week to the ALAC and bring questions back to the CPWG. Helps to avoid making personal decisions on behalf of At-Large. Discussion: * Great that ALAC is having these discussions and we hope that the other groups are doing the same thing. * Question: Why is the losing FOA important to preserve as a mandate for At-Large? Answer: It helps protect the registrant. When the losing FOA is sent, if the registrant hasn’t initiated the transfer when the registrant gets the losing FOA notification it can stop the transfer. So it provides added security. * Agree that the losing registrar should be required to notify the domain owner about the transfer. But I don't think the losing FOA should be required for approval/denial. * Question re: losing FOA being generated by the incumbent registrar. Need to document a distinction: If the TAC is provided to the registrant and the TAC is the authorization is allowed to take place. Then for the FOA to be an extra layer of security then it needs to go somewhere other than to the entity (registrant for example) who got the TAC. Otherwise it is not an additional layer of security. * We should use the losing FOA to notify the registrant. But not to approve/deny the transfer (that's the TAC). * TAC will be given to account holder. Loosing FOA will be sent to registrant e-mail. If we keep that practice sometimes it will be different entities and sometimes it will be the same entity. * Question: If the losing FOA is maintained, what if it is just a notification but doesn’t slow down the transfer? Answer: That is good, but not if we have to wait 5 days. * The losing registrar should send it as a notification of a transfer and build in a transfer reversal process. Require it but not the 5-day delay. * Depends on how much security you need. Depends on how big is the security problem. * At-Large CPWG will not necessarily vote against improvement of the losing FOA, just that there should be a message to the registrant and the losing FOA is one way to do that. * In thinking this through, there are some circumstances of a frictionless transfer – where the registrant has opted into a fast transfer. So in those circumstances it is an opt out of the usual notifications. If there were a deliberate process for the registrant to opt out of notifications what would the At-Large think about that.? * Maybe don’t call it a FOA, but just a notification. Is important for the losing registrar to send it. Retain the FOA if we are changing it to a notification. * We should rename it and change it to just a notification. * In the At-Large CPWG we are in favor for there to be a way for the registrant to be able to stop the transfer. * There has to be some reverse process, and boundaries around it to make sure people are not abusing it. * For rewriting the losing FOA, we should make required elements, but not actual required form/content. The current version is unwieldy. * In building a reversal process need to determine what to do if a renewal is involved. * Right now the compliance for the mandate is very strict. Should be guidelines. * WG members should put suggested language in the working document. Draft Straw Poll Questions - Losing FOA: 1. Does the Losing FOA serve a security function? -- 20 Responses * Yes, and it is important that the Losing FOA continues to serve this function --20 % * Yes, but this function can be served through other measures -- 55% * No, it does not serve this function --15 % * Not sure/Needs further discussion -- 10% Discussion: * Several ccTLDs do not have this form of authorization. We haven’t looked at their experiences. Not sure if this provides security. * At lot of the large ccTLD operators do not use the FOA. * This seems to be a weak form of security. Better if the registrar has a control panel with two-factor authentication. * Hard to compare ccTLDs and gTLDs. There are some differences. * There are several options. There is a notice before the transfer happens, there is a notice after a transfer might occur. There is a version of the losing FOA that includes a link or means to decline the transfer. Then a version of that to approve the transfer. Took the question to refer to the latter of the two options. We should be explicit about what we are agreeing. * Note that the transfer isn’t one thing, it has multiple factors in it. * The FOA was meant to ack or nack a transfer, it was not a security feature and as a security feature it is rather weak 2. Does the Losing FOA serve a notification function? -- 21 Responses * Yes, and it is important that the Losing FOA continues to serve this function --62 % * Yes, but this function can be served through other measures -- 38% * No, it does not serve this function -- 0% * Not sure/Needs further discussion -- 0% Discussion: * Maybe the language in the RAA needs to be changed. * Seems like everyone agrees. 3. Does the Losing FOA serve a “paper trail” function? -- 20 Responses * Yes, and it is important that the Losing FOA continues to serve this function -- 35% * Yes, but this function can be served through other measures -- 45% * No, it does not serve this function -- 15% * Not sure/Needs further discussion -- 5% Discussion: * Not sure it provides a paper trail. A positive or negative response is not necessary for the transfer to occur. * Yes, need to keep records. So not exactly full email, but copy of template and log about sending the FOA * Shouldn’t be too restrictive as to the type of communication. Should allow registrars to implement as they see fit. * Registrant should be able to choose their notification method. * In terms of record keeping don’t see how it is useful to show that the registrant acknowledged a transfer on day X. * The new notification email should not require action on the registrant's part (it's just a notification). * When we say “record keeping” what level are we talking about? * When we are talking about the losing FOA there are options in the marketplace where a registrant deliberately opts into a pre-authorization of a transfer. There could be legitimate reasons to not have these types of transfer notifications. Should allow frictionless transfers without requiring notification. * ICANN Org (Compliance): FOAs currently are only a notification and the losing the FOA only goes to the account holder. The registrant does not have the option to deny a transfer. The FOA is only a notification. * 4. Does the Losing FOA serve another function not listed in previous questions? -- 21 Responses * Yes -- 5% * No -- 67% * Not sure/Needs further discussion -- 29% Discussion: * Have had experiences in the last year where we’ve needed someone to forward the FOA email. There are some legitimate scenarios where the FOA helps to ensure that a transfer is done reliably. * Seems to be general agreement that the FOA is not needed in other circumstances. 5. Should the Losing FOA continue to be required? -- 23 Responses * It should be required as-is -- 4% * It should be required but updated/changed -- 57% * It should be eliminated as a requirement, but other measures are needed to serve certain functions -- 30% * It should be eliminated as a requirement with no additional measures to replace it -- 4% * Not sure/Needs further discussion -- 4% Discussion: * Think we are leaning to yes, but it needs to be updated and modified. 6. If you no longer support the Losing FOA as a requirement, would you support it as an optional resource for the Losing Registrar, i.e., “Losing Registrar MAY confirm the intent of the Registered Name Holder…”? -- 19 Responses * Yes -- 47% * No -- 26% * Not sure/Needs further discussion -- 26% Discussion: * Really interesting idea. Could see a situation where a registrar wants to have additional security. Should be allowed with some parameters/boundaries, so it doesn’t become prohibitive. * If we make the losing FOA possible we should add the requirement that it should be as easy to acknowledge or deny a transfer. Summary: * Agree that it needs to be updated. * Needs flexibility to grow. * If we see losing FOA as optional, then the TAC will be mandatory. * We could provide required points and an optional template (which covers those required points). * We should split these up: The registrar transfer notification is required, and the losing FOA is optional. * Need a few people to write down thoughts on changes to the losing FOA – such as name change, options versus mandatory, etc. Bring these suggestion to the next call for discussion. * Add to what Sarah has provided in page 3 of the document at: https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy… * Question: Can the losing FOA be used for bulk transfers? * Seems like instead of it being an FOA, it could be a notification as when you change your email. * Seems like each domain name should have its own unique transfer notification – but we could leave it up to registrars to design the system to allow bulk transfers. * Think bulk transfer is permitted now, we can leave it as it is now. ACTION ITEM: In preparation for the next meeting on 24 August WG members to provide suggested language for changes to the current losing FOA policy in the working document along with those provided on page 3 at: https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy…. 5. AOB (5 minutes) - Next meeting: 24 August 2021 @ 16.00 UTC

1 0

**15-minute reminder** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 17 August 2021 at 16:00 UTC
by Julie Bisland Aug. 17, 2021

Aug. 17, 2021

**15 minute reminder** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 17 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/awTpCQ Check your time zone: https://tinyurl.com/ap4cszp3 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/ap4cszp3__;!!PtGJab4!qYMwtRo…> 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

Comments due tomorrow...
by Mike Rodenbaugh Aug. 17, 2021

Aug. 17, 2021

Hi all, I did not want to waste valuable call time on this issue today. I should have spoken up earlier about the unreasonable timeframe to require constituency comments be drafted in July. Anyway now I do need to note that the IPC written comments will not be ready by tomorrow. We have struggled to coordinate during the July holiday season (for many). But we are fully in motion now. We are still taking input and drafting responses, and hope to have a constituency position at least as to the Phase 1 questions in the next 2 or 3 weeks. Best, Mike [image: Logo] Mike Rodenbaugh address: 548 Market Street, Box 55819 San Francisco, CA 94104 email: mike(a)rodenbaugh.com phone: +1 (415) 738-8087

4 3

ALAC input to the Losing FOA discussion
by Steinar Grøtterød Aug. 17, 2021

Aug. 17, 2021

Dear Transfer Policy Review PDP members, The ALAC / At-Large members of the Transfer Policy Review PDP WG have continuously informed the Consolidated Policy Working Group (CPWG) of the work being done by the PDP working group. On the charter questions connected to the Losing Form of Authorization (FOA), the ALAC view is: * ALAC recommend that the Losing Form of Authorization should still be mandatory in the reviewed transfer policy. The CPWG has also discussed the option to make the Losing FOA optional. The majority of the CPWG members did not favor this alternative. Regards, Steinar Grøtterød At-Large member of the Transfer Policy Review PDP WG

2 2

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

Aug. 16, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 17 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/awTpCQ Check your time zone: https://tinyurl.com/ap4cszp3 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/ap4cszp3__;!!PtGJab4!qYMwtRo…> 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

Proposed agenda for meeting #13 on Tuesday 17 August 2021 at 16.00 UTC
by Emily Barabas Aug. 12, 2021

Aug. 12, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 17 August 2021 at 16.00 UTC. If you have not yet done so, please review the working document for the topic Losing FOA and come to the meeting prepared to discuss the charter questions: https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy… Please feel free to share any questions on list. Kind regards, Emily, Julie, Caitlin, and Berry Transfer Policy Review Phase 1 - Meeting #13 Proposed Agenda Tuesday 17 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 (75 minutes) * Losing FOA working document<https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy…> 5. AOB (5 minutes) - Next meeting: 17 August 2021 @ 16.00 UTC

1 0

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

Aug. 10, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 17 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/awTpCQ Check your time zone: https://tinyurl.com/ap4cszp3 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, 10 August 2021 at 16:00 UTC
by Julie Bisland Aug. 10, 2021

Aug. 10, 2021

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

Aug. 10, 2021

Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting on Tuesday, 10 August 2021 at 16:00 UTC. The next meeting will be Tuesday, 17 August at 16:00 UTC. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items ACTION ITEM: WG members to review/comment on the Losing FOA Working Document<https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy…> in preparation for the meeting on Tuesday, 17 August. 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 #12 – Tuesday, 03 August at 16:00 UTC Proposed Agenda 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) * Staff sent out the updated Project Plan last week. Let us know if you have any questions or comments on it. * Calendar invites have been sent for meetings through October 2021. 3. Continued discussion of AuthInfo Codes (15 minutes): Focus relevant SO/AC/SG/C written input: See -- AuthInfo Codes working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> and Early Input<https://community.icann.org/display/TPRPDP/Community+Input>: * One piece to comment on is that there is a new standard out raised by a security organization on using dictionary words. That you could use three different dictionary words in a string and it would be just as secure. See: Link on password strength (related to Auth-Info) I mentioned in call https://www.ncsc.gov.uk/blog-post/the-logic-behind-three-random-words. * Didn’t see anything new that the WG hasn’t already discussed. * Mark this AuthInfo discussion as complete for now. 4. Discussion of Losing FOA (60 minutes): See – Losing FOA Working Document<https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy…>: Charter Questions: a7) Is the Losing FOA still required? If yes, are any updates necessary? Note: In answering this question, the Staff Support Team has included feedback from the Registrar/Registrant Survey that was issued as part of the Transfer Policy Policy Status Report. Additionally, the Support Staff Team has included a non-exhaustive list of sub-questions for the WG to consider. Early Written Input received from the BC on this charter question: Although apparently not necessary from a practical perspective, the Losing FOA may have some utility as a means of evidencing a transfer. Discussion: * Seems to be working without the losing FOA since GDPR. .NL we don’t use FOAs at all. * If it’s not broken, just leave it as it is and let the registrars make that decision. * Delays transfer for up to 5 days, so nice that it could be optional – particularly if we could do it faster. Would like to leave it optional if the registrar thinks it’s necessary for its registrant. * Reminder that there is a gaining FOA that a gaining registrar used to send to confirm their desire to transfer; the losing FOA was a form of acknowledgement of intent to transfer. The current transfer mechanism identifies those two steps. * The losing FOA is required today but a change we make could be to make it optional. * The thing to avoid here if we eliminated it or made it option if there was no form of awareness to stop a legitimate transfer. Should eliminate that there is some notice and means to decline in order to avoid having a registrant’s name transferred away under non-normal circumstances. * A fourth option: we could think about how to make it better – to require that it is as easy to accept the transfer as to deny it. * Think about the losing FOA to acknowledge that there is an intent to transfer. Think about the purpose of the losing FOA: you can meet the needs with the AuthInfo code, for example. Question is: what are we looking to achieve here? The purpose of the losing FOA. * Where the FOA is the second factor of protection, the losing FOA email in many cases serves as a means for the registrant to know the transfer occurred (or may occur) vs a silently vanishing name. * If you drill down you will find registrars using it for right and wrong reasons, so that argues for making it optional. For example, could be easier to explain for Dutch registrants as it would be similar to what we are doing now. * If the losing FOA is eliminated, then make sure that the registrars could have 5 days to determine if this is a fraudulent request or not. * Also, if the losing FOA is eliminated would like some way to get the domain name back if the registrar notifies that it is transferred erroneously. --- Additional questions for consideration (from the working document): * Should the five-day grace period remain or should the timeframe be reconsidered? * Is the current text of the Losing FOA sufficient or does it require updating? * Similar to the Gaining FOA, should the Losing FOA require express authorization/confirmation of the transfer? * Some registrar survey respondents have noted that the Losing FOA provides a useful paper trail - is this important to retain, or is there an alternative way to achieve this? * Is there another security mechanism that should be included with the Losing FOA in the event the registrant’s email address is hacked? ---- * The 5 days in the current process – how long do you go before finding out that the name has been transferred if the losing FOA goes away? * ICANN Org Compliance: The investigation of the transfer complaint – the main burden for evidence is on the losing registrar at that FOA (since the gaining FOA is not being used). * We do have a discussion later around the dispute mechanism/process. * More questions: What problem are we trying to solve? What has failed when it is necessary for a transfer to be recalled? Is it that the transfer itself was bad? Or did the transfer process work as it was supposed to but there is an external reason to recall the transfer? That factors into how easy or hard the transfer has to be or what the recovery process will be. * Don’t think there is a failure in the transfer process, but is an external failure. * When a domain hasn’t been properly transferred, it’s because an account was compromised, but not a failure of the transfer process, so we may not find a solution in the transfer policy. * There is no process that is so secure that it can never be bypassed. * To take that a step further, if the registrant has lost control of their email, as well as their registrar account, does the Losing FOA help at all? * We do need a process for recovery, so in that way there should be a way to internalize it. The question is whether the transfer process has to protect against email compromise or registrant account compromise. * There are numerous cases where we can’t protect everyone – so maybe the transfer process isn’t the place to find a solution. * Going back to the original question – this seems to be a second factor of protection, so we need to decide whether it is the best/right second factor of protection. * +1 on better recourse for 'clawback' under bad-act situations, however, there is also a need to have some finality to legitimate transfers. There are ways that bad-folk could abuse the clawback process (ex bad outcome scenario: 1] legitimate domain sale to third party, 2] money exchanges, 3] name transfers, 4] clawback + keep money). * It sounds like it’s a necessary thing, if not exactly what we have today. Maybe that doesn’t mean that the transfer process gets more secure, but maybe we change the dispute procedure. * How often is a “clawback” required? Does this require additional security measures, or would the dispute procedures solve that? * Security and the need for secure is a holistic type of problem. We want transfers to be secure, but that doesn’t mean that the transfer process has to solve every problem. If a registrant’s account at a registrar there is nothing we can do about that, unless you have other types of security controls, such as second factor authentication. * Even if the transfer process works the way it should be, there still could be other security failures. * The SSAC’s input references SAC007, SAC040, SAC044, and SAC074. You can find these four reports here: https://www.icann.org/groups/ssac/documents. * The registrar account: the account holder with the registrar may not be the registrant – it could be an entity doing something on behalf of the registrant. In this context: if there is an authorization to allow a registration to transfer, it might be coming from a third party, or from the registrant, but either way the registrant has to be notified quickly and reliably. * Looking through the additional questions it looks like we have hit on most of these. * Need to continue to discuss whether the policy should be changed to make the losing FOA and whether that might make compliance harder/slower. People are still looking at keeping a 5-day window, but not necessarily as part of the losing FOA, but perhaps part of the TAC. * Or, are there any requirements we would make in additional to the current ones? * In terms of gauging people’s reactions on whether the losing FOA should be optional: seems that we could put the emphasis on an improved dispute mechanism that addresses thefts. * Could look at the transfer dispute mechanism to see if we can improve that process. * Note that the TDRP (transfer dispute mechanism process) was hardly used. In general, the procedure itself is between the gaining and losing registrars. Only used when the registrant has exhausted all other options to recover the domain. We’ll take a closer look at it in phase 2. The WG can look at it in phase 1 and suggest some pointers for phase 2. * In terms of changing the existing requirement of the losing FOA: The losing and gaining FOA are requirements. There is a moratorium on the gaining FOA, but the losing FOA is a requirement so it will take consensus to change it. * The paper trail is an important factors – helpful for the registrars to give examples of logging of transfers that could be used for investigating fraudulent transfers. * Today it’s the losing registrar’s responsibility to prove everything. Is that responsibility in the correct spot, or should the gaining registrar have any responsibility? a8) Does the CPH Proposed Tech Ops Process represent a logical starting point for the future working group or policy body to start with? If so, does it provide sufficient security for registered name holders? If not, what updates should be considered? Note: As a starting point, the CPH Tech Ops Group “agreed that the requirement to notify the Registrant about a transfer request should be mandatory. As general business practices of Registrars and individual transfer scenarios vary, the group concluded that such notification does not have to be an email, but rather may incorporate other means of more modern communication.” Early Written Input received from the BC on this charter question: Good starting point. * What are you trying to achieve by notifying the registrant? If you get the AuthInfo Code that is a form of notification. What does this notification add to the process? * It is possible to obtain the AuthInfo Code other than with an email request, so the notification is another way for the registrant to be aware. The objective is to ensure that a domain doesn’t just silently vanish. * Note that Tech Ops concluded that the notification doesn’t have to be in an email. * Notification to registrant by gaining registrar (if different than the gaining registrant) was severely complicated by the GDPR _stuff_. * The question asked “does it provide sufficient security for registered name holders”. Nothing wrong with the additional level of notification, but from a risk management point of view, what are we really getting here? The losing registrar has to send it and if the losing registrar is behaving badly what is the point of having this requirement, or in cases where the registrar’s account is compromised. * Notification can be affected differently by thick or thin registries. Our suggestions/recommendations should be agnostic (not assuming) one or another. * What are we trying to solve here? The notification brings little to the table. a9) Are there additional inter-registrar transfer process proposals that should be considered in lieu of or in addition to the CPH TechOps Proposal? For example, should affirmative consent to the Losing FOA be considered as a measure of additional protection? Early Written Input received from the BC on this charter question: Transfer locks should be removable by the registrant. * As mentioned, where thin registry is in place, the registrant (and contact info) are known to registry… at thick registries but not at thin. * On the BC comment – the opportunity to opt out should be made more clear to registrants, registries, etc. * It is the registrant who had to remove a transfer lock, not the registry. * Question: Do we need to specify what is a transfer lock? Answer: We need to be specific. Which transfer lock we are mentioning. 5. AOB (5 minutes) * Next meeting: 17 August 2021 @ 16.00 UTC

1 0

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

Aug. 10, 2021

**15-MINUTE REMINDER** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 10 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/ZQTpCQ Check your time zone: https://tinyurl.com/dyfedvzj [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/dyfedvzj__;!!PtGJab4!vlNAh_j…> 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