- GNSO-TPR - lists.icann.org

Notes and action items - TPR WG Meeting #54 - 19 July 2022 at 16:00 UTC
by Julie Hedlund July 19, 2022

July 19, 2022

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be Tuesday, 26 July at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: WG members to consider the best way to frame the discussion of the CoR policy and review the Cor Foundation Brainstorm document at: https://docs.google.com/document/d/1Fjkdk6VSWHw-ZjRfHHL0vGeWw9NKcf7IsT8eT8T…. Notes: Transfer Policy Review Phase 1(b) - Meeting #54 Proposed Agenda 19 July 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Phase 1A created several new mechanisms that apply to the CoR concepts as well in a positive way. WG should take note of those things, such as the 5-day window to provide the TAC. * While it is Phase 2, everyone can assume we will create a more robust dispute mechanism not just for change of registrar, but could also be for CoR. * As a reminder, PC closes 2 August. 4 submissions thus far. https://www.icann.org/en/public-comment/proceeding/initial-report-on-the-tr…. We have three meetings before we take a break and then staff write up the public comment summary. * Re: Mike Rodenbaugh sent an email last week Tuesday about the 60-day lock being optional and since it’s optional why do we need recommendations – any comments? * From Mike: “I want to get clear on the effect of this proposed change. This 60-day lock is optional now. We are talking about removing that optional lock from the IRTP, and it seems we are getting to consensus to remove it. I suppose that removing it from the Policy is not the same as prohibiting registrars from imposing such a lock anyway via their TOS. So, are we also talking about prohibiting registrars from imposing any such lock upon Change of Registrant? Otherwise, I guess I do not see the point of removing it from the Policy. Maybe I am just missing something here...” * Discussion: * If you can opt out of it, what reason would there be to have a 30-day lock as a default? * Makes sense to remove it entirely. Registrars could still choose to do that and registrants could pick registrars accordingly. * Not a comment to Mike's email, but CoR was something that guarded against parties that had made a malicious registration from rotating the registrant of record frequently as a means of evasion - but this was more of a thing when more of the whois information was public. * +1 Jothan, and with a 30 day lock on transfers, it would remain at that registrar. * Good thing to think about, whether it even belongs or not. * Does the lock even need to exist for the CoR? * Locks from Phase 1a – transfer can’t occur 30 days from registration or transfer. It is a delay, not a lock per se. If you have a case where a name has changed to another registrant a lock would prevent moves to another registrar, but not a registrant within a registrar. We may need to diagram the different scenarios. * We don’t have any numbers so it’s not clear how much a problem are domain name hijacks. * Still a large impact (hijacks) even if there aren’t many of them. * The current Registrar of Record on a given domain name is the party with the highest ability to resolve matters related to that domain name. Change of Registrant, as long as the name remains at the most recent gaining registrar, does not introduce additional challenge to transfer related matters. * If we remove the locks it can be gamed and it is a little bit more risky. * The majority of CoRs are legitimate, but there can be a big impact from a few illegitimate changes. * We already have some security mechanisms, particularly from Phase 1a. * How to evaluate the impact from illegitimate CoRs: even if it is an intra-registrar transfer the rules should be the same – have the same locks. * GDPR (and subsequent Privacy Regulation) - and the affectation on the amount of redaction it caused to RDAP/WHOIS - have lowered the impact of Change of Registrant (CoR) related matters, because the majority of the information has become redacted or otherwise is not displayed publicly. * When providing a service to the registrant, you want some type of lock to mitigate hijacking. If you are going to have a lock in both cases, maybe 30 days is too long, or maybe not. It’s about providing a good service and keeping things the same. * I don’t think I agree that the transfers are similar enough to require the same locks for both...I like consistency (lock periods should be uniform) but I think updating owner data is different enough from changing Rrs that they're not the same thing. * It is not just about Registrar Hopping and domain theft, but preventing fraud on the Internet. If a registrant is doing something bad, the registrar knows that. If the registrar prevents fraud, the domain should not be able to move for a period of time to prevent the fraudster / phisher / bad guy continuing the fraud they are committing. * What is the criteria for a material change that today triggers a CoR lock? * 1.1 "Change of Registrant" means a Material Change to any of the following: 1.1.1 Prior Registrant name, 1.1.2 Prior Registrant organization, 1.1.3 Prior Registrant email address, 1.1.4 Administrative Contact email address, if there is no Prior Registrant email address. 3. Risk-based approach: What problems are we trying to solve with CoR? Here is the document we will use for today's discussion: Cor Foundation Brainstorm -- https://docs.google.com/document/d/1Fjkdk6VSWHw-ZjRfHHL0vGeWw9NKcf7IsT8eT8T… * This is an open-ended table. We can rank these and see if they help us get to the same spot. * Context: One of the things we are hoping to do is to take a step back from the current policy, think about the problems we are trying to solve and the risks. If a registrant name is changed, for example, is that something we need to worry about. We also don’t need to come up with solutions at this point. Discussion: * There is a big difference between changing the information about a registrant (name, etc.) then if there is a move to a different account (intra-registrar transfer). Not sure we need to care about changes to an account. * Account is difficult as that might not be in scope. Only if there is a true change of ownership. * If there is going to be a change that causes a lock a user should be warned before they commit to that. * Propose that we limit what we do to transfers. Some changes in a registrant’s account aren’t a transfer. * Change of ownership is valid to discuss. * See the definitions at: https://docs.google.com/document/d/1gu4sXGvyJeWJIfvaK_I7GKA6lAdfKFPQKaN4UMg…. * What we are trying to do is to determine the problems, not the solutions. * Also, registrars are responsible for keeping their accounts accurate, while registrants have rights to make changes. * At the end of the day the WG has to have consensus recommendations to change any of the CoR policy. * For example, does the change of a name warrant restrictions on subsequent changes or change of registrar? * Another example, if the WG agrees that a material change should no longer include a registrant name change then we need to thoroughly document the reason for the change. * 60-day lock is the action based on what is considered a “material change.” The WG could decide that something isn’t a “material change” but keep the subsequent action (lock), or decide to scrap both what are material changes as well as the actions – once we go through the various scenarios. * Maybe we decide something else is better than a lock. * If we look at today’s environment it doesn’t seem that there is much policy to prevent an illegitimate transaction. And the AuthInfo Code has been there since the name was created. But with the Phase 1A recommendations the TAC will not be sitting there, but not provisioned until requested. * Any transaction from column 1 with no other follow-on action would not invoke the TAC. But others would invoke the inter-registrar transfer policy. * The policy today originated through a discussion of change of control. * There has to be a way for registrants to dispute a change, beyond an intra-registrant policy. * No matter the original intent the policy has not worked well. * Should look at why an action was put in place and whether it is still needed. * We need to come up with a way to get to a rationale—either to keep the policy or to change it. * Example: If there is an illegitimate name change that stays within the registrar is that a problem particularly if easily corrected? * Could say that we don’t need to look at the definition or trigger, but maybe the possible action (notification, lock, dispute mechanism). * However the contact is made between the registrar and registrant, what is important is when that contact changes. * Can we create a baseline? * Don’t think the trigger is the update to the communication, but the owner. We will at least have to update the list of changes to remove the Administrative Contact. ACTION ITEM: WG members to consider the best way to frame the discussion of the CoR policy and review the Cor Foundation Brainstorm document at: https://docs.google.com/document/d/1Fjkdk6VSWHw-ZjRfHHL0vGeWw9NKcf7IsT8eT8T…. 4. AOB

1 0

15 MINUTES ** REMINDER - Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 19 July 2022
by Devan Reed July 19, 2022

July 19, 2022

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

1 0

Proposed agenda for meeting #54 on Tuesday 19 July at 16:00 UTC
by Emily Barabas July 18, 2022

July 18, 2022

Dear Working Group members, Please find below the proposed agenda for the next meeting scheduled to take place on Tuesday 19 July 2022 at 16:00 UTC. Kind regards, Julie, Berry, Caitlin, and Emily Transfer Policy Review Phase 1(b) - Meeting #54 Proposed Agenda 12 July 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates 3. Risk-based approach: What problems are we trying to solve with CoR? 4. AOB * Next session: Tuesday 26 July at 16:00 UTC

1 0

REMINDER - Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 19 July 2022
by Julie Bisland July 18, 2022

July 18, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 19 July 2022 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <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 <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/4QIVD * Check your time zone: https://tinyurl.com/4wctscze [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/4wctscze__;!!PtGJab4!7iOYsaP…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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 #53 - 12 July 2022 at 16:00 UTC
by Julie Hedlund July 12, 2022

July 12, 2022

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be Tuesday, 19 July at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: 1. WG members to go back to their representative groups to determine if there are any issues that need to be brought forward to the WG, but particularly the question of whether the 60-day lock for CoR should be removed, and replacing affirmation confirmation requirements with notification. See Key Elements of CoR (table on page 8) at: https://docs.google.com/document/d/1gu4sXGvyJeWJIfvaK_I7GKA6lAdfKFPQKaN4UMg…. 1. WG members to review the 60-day lock Working Document at https://docs.google.com/document/d/1SFMDrDazU7iM-1_mvf05ZMQ-ZS2GVJ1mtIXZNcI… and provide comments/suggestions to the charter questions beginning on page 3. Notes: Transfer Policy Review Phase 1(b) - Meeting #53 Proposed Agenda 12 July 2022 1. Roll Call & SOI updates * Jim Galvin – His employer Donuts has rebranded to Identity Digital. Otherwise everything is the same. See: https://community.icann.org/display/gnsosoi/James+M+Galvin+SOI. 2. Welcome and Chair Updates * Public comment period for the Phase 1(a) Initial Report closes on 02 August. Please get your comment in. * Steiner Grotterod, At-Large: Some comments on why we set 14 days for the duration of the TAC Time to Live (TTL)? * For security purposes, but don’t recall if we talked about other timeframes. * 14 days was originally suggested by TechOps and the WG thought it seemed like a reasonable number, but staff will check. Also time to complete locks or other issues before transfer. The CPH Tech Ops Group concluded “in regard to the TTL the group suggested a validity of no more than 14 days, presented as the total number of hours until TTL expiration. There was no resolution for a minimum TTL requirement, because registrars with different business models may have different requirements for how quickly a domain name gets unlocked and transferred. More work on any of these topics is needed.” * General discussion was that in those cases where things needed to be resolved sufficient time was needed. * That would be considered a maximum. The TAC being active opens the name up for a transfer window, which makes it exposed, so we want to allow shorter than 14 days. * See the deliberations on TTL on pages 8 and 9 here: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0… 3. WG Analysis of Key Elements of CoR (continued from previous meeting) – see: working document at: https://docs.google.com/document/d/1gu4sXGvyJeWJIfvaK_I7GKA6lAdfKFPQKaN4UMg… (table on page 8) Impose a 60-day inter-registrar transfer lock, unless the Registered Name Holder had previously opted out (Section II.C.2). WG Notes: * The fact that the policy says there is a 60-day lock, how that is done isn’t something we have to determine here. Maybe we consider to make it shorter, eliminate it, or allow it to be unlocked. * Some favor removing the lock. Registrars could have their own policies in place. If we keep it, it should be changed to 30 days and make it standard so everyone does it, and/or a way to opt out of it – maybe the registrar makes an arrangement with the registrant. * Think everyone agrees that 60 days is too long. II.C.2 The Registrar must impose a 60-day inter-registrar transfer lock [footnote 4<https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en#foot4>] following a Change of Registrant, provided, however, that the Registrar may allow the Registered Name Holder to opt out of the 60-day inter-registrar transfer lock prior to any Change of Registrant request. Footnote 4<https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en#note4>: The Registrar may, but is not required to, impose restrictions on the removal of the lock described in Section II.C.2. For example, the Registrar will only remove the lock after five business days have passed, the lock removal must be authorized via the Prior Registrant's affirmative response to email, etc. Notes: Inter-Registrar Transfer Lock following a Change of Registrant: Registrars are not required to apply a specific EPP status code for the 60-day inter-registrar transfer lock described in section II.C.2; however, if a registrar chooses to apply the clientTransferProhibited EPP status code, it must also lock the name in a way that prohibits the Registered Name Holder from removing the lock per section I.A.5.1. * See staff document on 60-day lock: https://docs.google.com/document/d/1SFMDrDazU7iM-1_mvf05ZMQ-ZS2GVJ1mtIXZNcI… * Policy Status Report and Issue Report have the most detail. WG Notes: * If it were changed to 30 days some WG members suggested that that would not be a significant improvement. Current policy seems to invite some confusion because some registrars don’t offer and opt out – the policy isn’t consistent. Also the timing of the opt out is inconsistent. * The policy isn’t very consumer-registrant friendly. * Faced with a definitional challenge: the definition of Change of Registrant is difficult to nail down. Unclear if the policy distinguishes between change of registrant data and change from one party to another. The lock isn’t needed in the first instance. Maybe try to organize the language. * For historical reference, the IRTP-C WG mentioned an opt out, but left it open for registrars to determine to offer an opt out of the 60-day lock. Specifically, “If a registrar chooses to offer an option for registrants to opt out, the process to remove this restriction must use a generally accepted method of authentication.” This, of course, does not prevent this WG from establishing consistent opt out requirements, but we thought it would be helpful to provide some context as to why there is currently an inconsistency. (Quotation is from p. 27 of the IRTP-C Final Report: https://gnso.icann.org/sites/default/files/filefield_34607/irtp-c-final-rep…) * Helpful if for the name component everyone sets the rules at the beginning. * May be helpful to look at the IRTP-C use cases (see discussion below). ACTION ITEM: WG members to go back to their representative groups to determine if there are any issues that need to be brought forward to the WG, but particularly the question of whether the 60-day lock for CoR should be removed, and replacing affirmation confirmation requirements with notification. See Key Elements of CoR (table on page 8) at: https://docs.google.com/document/d/1gu4sXGvyJeWJIfvaK_I7GKA6lAdfKFPQKaN4UMg…. 4. Review applicability of use cases/case studies from IRTP-C – see: Annex G of the Final Report on pages 72 – 77, at: https://gnso.icann.org/sites/default/files/filefield_34607/irtp-c-final-rep…<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/filef…> Case 1: Change Registrar: This falls under current IRTP policy. Mike wants to move his domain from one registrar to another. No other parties involved. Because the Registrant hasn’t changed, Registrant info must remain the same and the “waive lock” option is not needed or presented Case 2: Change Registrar: Mary (a business owner) wants to buy a domain from Mike for use in her business. She and Mike are using the same registrar. Because she plans to use the name for a long (me, and wants to protect it from hijacking, she leaves the lock in place. Case 3: Waive the Registrar Hopping Safeguard: Susan (a domain investor) wants waive the lock in anticipation of a future transaction Case 4: Change Registrant AND Registrar: Ann (an individual) wants to buy a domain from Mike for use for her blog. She and Mike are NOT using the same registrar. Because she plans to use the name for a long time, and wants to protect it from hijacking, she leaves the lock in place. Case 5: Change Registrant and Registrar and Waive Safeguard: Susan (a domain investor) wants to buy a domain asset from Mike. She and Mike are NOT using the same registrar. Because she wants the ﬂexibility to sell the name, and has sophisticated antihijacking of her own, she waives the lock. Case 6: Minor Change to Registrant Information: Nathalie (a recently married blogger) wants to update her Registrant information to her married name. Because she has no plans to transfer her domain and wants to protect from hijacking, she declines the opportunity to waive the lock when it’s presented by her registrar. Note: technically this is identical to Use Case 2. Case 7: Minor change to Registrant information, waiving the post<change lock: Nele (an unhappy registrar customer) wants to make a minor change to her registrant information. She is willing to waive the safeguard in order to have the option to quickly transfer to a new registrar. Discussion: * Some cases don’t apply anymore because of GDPR. * All comes back to what is a material change. Should there be different policies for changing registrant information and changing registrant. * How do you delineate each one of the scenarios. * If change of registrant happens at the same registrar then there’s less of a security issue. If outside the same registrar we have a 30-day lock anyway. * How does a registrant air a grievance – should be able to initiate a transfer dispute. * Once the transfer goes to another registrar there will be a lock put on it and because it is more difficult to undo. * There are so many updates to a domain names on a day-to-day basis, these restrictions don’t make it easier for people to update their data. * Relying on older anecdotal evidence on which to base a policy – there should be a basis to infringe on the right of a registrant to change ownership. Is this something that we should make registrars track? * Can probably re-use these use cases to document our thought processes. Some don’t seem to fit though. * See page 12 of the charter for proposed metrics: https://gnso.icann.org/sites/default/files/file/field-file-attach/draft-cha… -- could put this into the policy recommendations. 60-day lock policy questions: d4) Survey responses and data provided by ICANN’s Global Support Center indicate that registrants do not understand the 60-day lock and express frustration when it prevents them from completing an inter-registrar transfer. Does the 60-day lock meet the objective of reducing the incidence of domain hijacking? What data is available to help answer this question? Is the 60-day lock the most appropriate and efficient mechanism for reducing the incidence of hijacking? If not, what alternative mechanisms might be used to meet the same goals? Are there technical solutions, such as those using the control panel or two-factor authentication, or other alternatives that should be explored? d5) Survey responses and data provided by ICANN’s Global Support Center and Contractual Compliance Department indicate that registrants have expressed significant frustration with their inability to remove the 60-day lock. If the 60-day lock is retained, to what extent should there be a process or options to remove the 60-day lock? d6) Due to requirements under privacy law, certain previously public fields, such as registrant name and email may be redacted by the registrar. Is there data to support the idea that the lack of public access to this information has reduced the risk of hijacking and has therefore obviated the need for the 60-day lock when underlying registrant information is changed? d7) In its survey response, the Registrar Stakeholder Group indicated that the 60-day lock hinders corporate acquisitions, consolidations, and divestitures of large lists of domains to new legal entities. To what extent should this concern be taken into consideration in reviewing the60-day lock? d8) If the policy is retained, are there areas of the existing policy that require clarification? For example, based on complaints received by ICANN Contractual Compliance, the following areas of the policy may be appropriate to review and clarify: [see examples] Discussion: * As noted in our charter, are there any reporting/tracking requirements that the WG wants to recommend? Does the benefit of having the data outweigh the cost? * We are saying there’s no specific data at this time to show that there is a problem. What we have is anecdotal. * Seems like the lock still provides security, but not clear that it’s needed. * Our job is to go through the charter questions, answer them, and make any recommendations. * Is a lock (of any duration) still important? * Important that you are taking these issues back to the SGs/Cs and see if there are any issues that need to be brought forward, particularly on removing the lock and replacing affirmative confirmation with notification. Encourage anyone who wants a lock of any duration to provide a rationale. * Plan is for the WG to go into the 60-day working doc to make comments into each of these charter questions to get discussions going. See 60-day lock working doc at https://docs.google.com/document/d/1SFMDrDazU7iM-1_mvf05ZMQ-ZS2GVJ1mtIXZNcI…. * Pull the use case scenarios into our discussion doc. ACTION ITEM: WG members to review the 60-day lock Working Document at https://docs.google.com/document/d/1SFMDrDazU7iM-1_mvf05ZMQ-ZS2GVJ1mtIXZNcI… and provide comments/suggestions to the charter questions beginning on page 3. 5. AOB -- Next session: Tuesday 19 July at 16:00 UTC

2 1

Post Call | Transfer Policy Review PDP WG | Tuesday, 12 July 2022
by Julie Bisland July 12, 2022

July 12, 2022

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 12 July 2022 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/3wIVD> (attendance included) and the GNSO Master calendar <https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> . These include: * Attendance * 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, 19 July 2022
by Julie Bisland July 12, 2022

July 12, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 19 July 2022 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <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 <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/4QIVD * Check your time zone: https://tinyurl.com/4wctscze ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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

**AT THE TOP OF THE HOUR** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 12 July 2022
by Julie Bisland July 12, 2022

July 12, 2022

**AT THE TOP OF THE HOUR** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 12 July 2022 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <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 <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/3wIVD * Check your time zone: https://tinyurl.com/2sjukenb [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2sjukenb__;!!PtGJab4!5ugj-Ez…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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

REMINDER - Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 12 July 2022
by Julie Bisland July 11, 2022

July 11, 2022

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

1 0

Proposed agenda for meeting #53 on Tuesday 12 July at 16:00 UTC
by Emily Barabas July 7, 2022

July 7, 2022

Dear Working Group members, Please find below the proposed agenda for the next meeting scheduled to take place on Tuesday 12 July 2022 at 16:00 UTC. Under agenda item 4, the working group will consider whether it is useful to adapt the use cases/case studies presented in the IRTP-C Final Report in its analysis of proposals to update CoR. Prior to Tuesday’s call, please review Annex G of the Final Report on pages 72-77: https://gnso.icann.org/sites/default/files/filefield_34607/irtp-c-final-rep…. Kind regards, Julie, Berry, Caitlin, and Emily Transfer Policy Review Phase 1(b) - Meeting #53 Proposed Agenda 12 July 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates 3. WG Analysis of Key Elements of CoR (continued from previous meeting) 4. Review applicability of use cases/case studies from IRTP-C 5. AOB * Next session: Tuesday 19 July at 16:00 UTC

1 0