June 2022 - GNSO-TPR - lists.icann.org

Notes and action items - TPR WG Working Session ICANN74 - 13 June 2022 at 08:30 UTC
by Julie Hedlund June 13, 2022

June 13, 2022

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be Tuesday, 28 June at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: None. Notes: Transfer Policy Review Phase 1(a) – ICANN74 Working Session Proposed Agenda 13 June 2022 1. Welcome and opening remarks * Initial Report will be released in the next couple of weeks. * Now we turn to our next order of business, Phase 1(b) Work – Change of Registrant (COR) 2. High-level Overview of Phase 1(b) Work - Change of Registrant (COR) See the slides at: https://community.icann.org/x/HhR1Cw Overview of Transfer Policy: What is the transfer policy: ICANN consensus policy governing the procedure and requirements for registrants to transfer their domain names from one registrar to another. * Goal: Enhanced domain name portability * greater consumer and business choice * registrants may select the registrar that offers the best services and price for their needs * Formerly called the Inter-Registrar Transfer Policy (IRTP) * Went into effect on 12 November 2004 * GNSO reviewed the policy once before, shortly after implementation Issue Areas for the PDP and Status – A Phased Approach Phase 1(a): * Form of Authorization (including Rec. 27, Wave 1 FOA issues) * AuthInfo Codes * Denying (NACKing) Transfers Phase 1(b): * Change of Registrant (including Rec. 27, Wave 1 Change of Registrant issues) Phase 2: * Transfer Emergency Action Contact * Transfer Dispute Resolution Policy (including Rec. 27, Wave 1 TDRP issues) * Reversing transfers * ICANN-approved transfers Topics in Phase 1(b): Change of Registrant (CoR): What is Change of Registrant? Requirements that seek to prevent domain name hijacking by ensuring that certain changes to registrant information have been authorized. What is required? Registrars must obtain confirmation from the Prior Registrant and New Registrant before a material change is made to: Prior Registrant name, Prior Registrant organization, Prior Registrant email address, and/or Administrative Contact email address, if no Prior Registrant email address. CoR Issue Areas: What specific elements of the CoR Policy need review? * “60-day inter-registrar transfer lock” prevents transfer to another registrar for sixty (60) days following a CoR. Registrants have difficulty with the 60-day lock, especially that they are not able to remove the lock once it is applied. * Designated Agent: an individual or entity that the Prior Registrant or New Registrant authorizes to approve a CoR. * Appear to be different interpretations of role and authority. * Compliance enforcement is being deferred in relation to CoR as it applies to removal or addition of privacy/proxy services, pending further work to clarify implementation of relevant IRTP-C provisions. CoR Lock: Transfer Policy Status Report Data ICANN’s Global Support Center: Inquiries regarding transfers increased at a higher rate than inquiries overall, likely due to issues related to CoR lock. ICANN Aggregate Transfer-Related Monthly Registry Reporting: Large spike in transfers in 2016 just before implementation of IRTP-C, including CoR lock. Metrics from ICANN’s Contractual Compliance Department: Complaints about inter-registrar transfers have been decreasing, complaints related to CoR lock increased. Survey of Registrars and Registrants: Registrants are confused and frustrated when the CoR lock prevents them from completing a transfer. Some want to eliminate or change it. CoR: Focus of Charter Questions * Does the policy achieve its stated goals? Is it still relevant in the current domain ownership system? * Can requirements be simplified to make them less burdensome and confusing, especially regarding the 60-day lock? * To what extent should there be a process or options to remove the 60-day lock? * To what extent should the Change of Registrant policy, and the 60-day lock, apply to underlying registrant data when the registrant uses a privacy/proxy service? * Is the Designated Agent function operating as intended? If not, should it be retained and modified? Eliminated? Working Document for Charter Questions d1, d2, and d3: https://docs.google.com/document/d/1gu4sXGvyJeWJIfvaK_I7GKA6lAdfKFPQKaN4UMg…: Relevant Metrics from the Transfer Policy Status Report (summarized in the Final Issue Report): * In the period from 1 January 2015 - 23 May 2018, the number of Global Support Center inquiries received regarding transfers increased at a higher rate than the overall amount of inquiries received (which also increased). GSC posited that the increase in transfer-related inquiries is likely due to an increase in issues related to the Change of Registrant (COR) lock. * According to aggregate data on ICANN Monthly Registry Reports, there was a prominent spike in transfers toward the end of 2016. The Transfer Policy Status Report speculates that this spike may be explained by the then forthcoming implementation of the IRTP Part C, including the 60-day lock (see page 18). * The Transfer Policy Status Report notes with respect to tickets received by ICANN’s Contractual Compliance Department between 2012 and 2018, “The nature of transfer complaints changed in December 2016, when the IRTP-C and -D became effective. While inter-registrar transfer complaints have been trending downward, Contractual Compliance noticed an increase in complaints relating to the “Change of Registrant” (COR) lock that became effective in December 2016.” In addition, the Transfer Policy Status Report summarizes survey input with respect to Change of Registrant: * Respondents wanted to see fewer and/or less complicated steps for registrants to transfer their domain(s), and quicker transfer times. * Respondents express frustration when they encounter barriers to transferring their domain name(s) (e.g. the “Change of Registrant” lock). * Some respondents recommended eliminating or reducing the 60-day Change of Registrant transfer lock imposed on registrants who’ve changed their contact information. * Some registrar respondents indicated that their customers were often frustrated with certain aspects of the Policy, and did not seem to understand the underlying rationale for certain requirements (such as the Change of Registrant lock). 3. Discussion of Charter Questions<https://community.icann.org/display/TPRPDP/2.+WG+Charter?preview=/161808892…> d1, d2, and d3 Overview: * First charter question is the most important – is the policy doing what it set out to do; does it need to do those things? * Once we address that question the other charter questions get easier. Charter Questions d1, d2, and d3: d1) According to the Transfer Policy Review Scoping Team Report, the Change of Registrant policy “does not achieve the stated goals” and “is not relevant in the current & future domain ownership system.” To what extent is this the case and why? Are the stated goals still valid? If the Change of Registrant policy is not meeting the stated goals and those goals are still valid, how should the goals be achieved? Discussion: * Very different now than when the policy was created. * Security is much more of the emphasis now. * In 2015 there were no statistics and we still don’t have statistics. * Security technology will continue to evolve and the security situation has changed significantly since 2015; now we have GDPR, which takes away email as an attack vector. * Why doesn't the policy achieve the stated goal? I think the goal is changing the registrant, which is a valid goal? * Goals are to curtail hijacking and facilitate Change of Registrant. May not be meeting those goals today – hiding email may even facilitate hijacking. * We could change the Registrant without going through this double approval process. So maybe the goal was to prevent domain theft, and maybe we've seen that that's not necessary? * The original goal was to make domain names more secure, but have we done too little to protect domain names and are we requiring too much. * So can registrants transfer ownership and registrar at the same time now? With the 60 day lock, not really. The policy states that registrars must notify registrants that if they are changing data for a transfer, then they should do so after to avoid the COR lock. * Maybe the split in two independent processes "inter-Registrar-Transfer" and "Change-of-Registrar" cause a lot of the headache, because both processes had their own checks and locks, but are initiated concurrently. So the processes interfere and block each other. It's not a solution to weakening each of the processes separately. * Have statistics changed after the implementation of the Temp Spec; do we have statistics? There are some stats in the Issues Report, but that is a good question to ask. * I think most of these are less statistics and more anecdotal references we all experience from registrant complaints. * Useful to look at the current Change of Registrant policy: https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en. Get concrete about what we might be proposing. * think ICANN data did not really show a decrease or increase of unauthorized transfers after Temp Spec (at least that is my recollection when we did the scoping for this PDP). * I “feel" that we are now seeing less reports of hijacked domains than we did in the past, but that may also be due to our tendency to return such domains * It's a complex process! If someone is unsure and wants to learn more, we put out this help info when the policy was first live, might help parse things: https://opensrs.com/change-of-registrant-re-enablement/. * Would like to see us have the goal that the domain owner knows what is happening with their domain name and making it easier for the update to happen and making it easier to undo it. * Maybe the policy needs to stick around but be changed. * We thought a lot about security issues in Phase 1(a), so we don’t want to lose that emphasis in Phase 1(b). * As a baseline we could start with all the same security principles we established in Phase 1(a). In the intra-registrar case don’t see that the Transfer Policy can address hijacking. * Quick reversal is one part of the puzzle, but that only protects the registrant. It is only relevant if we have failed to prevent hijacking/theft. If we go in the direction of security we have to remember that this doesn’t protect all registrants. * Just a thought: generally speaking, in order to follow up the efficiency of new policies, it could make sense to see via statistical data the evolution before and after a new policy that addresses a problem like this PDP. * We must not forget the reseller business model and tune the CoR policy for this too. * I think the use of TAC in COR is an important consideration, important enough that you should start with that baseline (i.e., align with inter-registrar transfer) and think about why you shouldn't do it as opposed to why you should do it. * There is no quick undo. Let’s not base policy on this. * Have been some reversals among registrars working together. * I think a core difference in the case of intra-registrar hijacking, remedy is less complicated than in the event of inter-registrar. because the domain remains within the registrar, the registrar's control, ability and means to restore the domain name to the victim is much stronger. * Remedy may be easier but I wouldn't use that as a reason to do things differently than the way things are done for inter-registrar transfer. * As we move forward we might want to talk to the ICANN Rights and Responsibilities staff as to how this is working for registrant. * Statistics would be very helpful. * You could decide they are not different and thus COR should use a TAC and should involve a registry. On the other hand, maybe there is a distinction you want to make, and thus you use a TAC-like model, i.e., a COR TAC that is only and fully managed by the registrar. * Like the suggestion of going through all the security features for the Inter-registrar transfer -- and considering which can apply here also. * We should take into account that most transfers occur without incident. * Group seems to be deciding that the CoR policy should stay but should be changed. d2) Data gathered in the Transfer Policy Status Report indicates that some registrants find Change of Registrant requirements burdensome and confusing. If the policy is retained, are there methods to make the Change of Registrant policy simpler while still maintaining safeguards against unwanted transfers? * The policy is complex and hard to understand. * Could be interpreted in different ways – particularly re: details not listed in the policy. * Consistency in the implementation of CoR is something that would be beneficial. Registrar A may implement the opt-out of the 60 day lock, Registrar B may not. * I don't think the “security theater" is any worse than it is in the inter-registrar case. if any change to registration data is a "transfer", then use the transfer process. * One fundamental consistency we should probably adopt is to make this a 30-day lock, as with the inter-registrar locks. * On the other hand, if the actual physical owner is not changing but the "name" or "address" is changing, then don't use a transfer process. the question is can you identify those cases so you can make that simpler. * One model is to take on board everything we did in Phase 1(a), but then ask a number of questions – such as do you want to involve a registry? Or do you keep it local? I CoR a physical transfer, or not an ownership change in a physical sense? If the physical owner is going to change then you’d want to use a TAC-like system. * You could decide they are not different and thus COR should use a TAC and should involve a registry. On the other hand, maybe there is a distinction you want to make, and thus you use a TAC-like model, i.e., a COR TAC that is only and fully managed by the registrar. * Could make a list of security features from Phase 1(a) and see what fits and what doesn’t. Maybe also think about what updates are a material change or would trigger this process? * The distinction I'm making is whether material change to registration information is any way correlated to the physical entity that owns it. * As well as looking at CoR policy we need to look and see if the transfer policy actually can address change of registrants and if there are other issues other than security. * Re: material change, think about what is the anchor. Could be the email address. It could mean that nothing else is material. So the only thing that constitutes a transfer is moving between registrars. * On the other hand, if the actual physical owner is not changing but the "name" or "address" is changing, then don't use a transfer process. the question is can you identify those cases so you can make that simpler. * For COR, policy considers these are the contact data points that are impacted and considered material changes - * Prior Registrant name * Prior Registrant organization * Prior Registrant email address * Administrative Contact email address, if there is no Prior Registrant email address. * Anchor could be whatever you are using for contactability. * To Maxim's point, I like the idea of having that as an exception for the Rr to use in case of dispute, but I'm not sure it can be the standard. * Where can we put in flexibility? * What’s the definition of ownership? d3) The Transfer Policy Review Scoping Team Report suggests that there should be further consideration of establishing a standalone policy for Change of Registrant. According to the Scoping Team, the policy should take into account the use case where a Change of Registrar occurs simultaneously with a Change of Registrant. To what extent should this issue be considered further? What are the potential benefits, if any, to making this change? To what extent does the policy need to provide specific guidance on cases where both the registrar and registrant are changed? Are there particular scenarios that need to be reviewed to determine the applicability of COR? * Gaining Registrar allows a new customer to input the Registrant information when requesting an inbound inter-registrar transfer. The information entered by the customer does not match Registration Data available in the Whois display. * In the case of “thin” domain names, the Gaining Registrar obtains information from the Registry. If it is determined that the Change of Registrant policy should be retained and modified, the following specific areas may be appropriate for further review. Discussion: * Should the policy be split? * Like splitting but they are interrelated. * First bullet seems to describe the current process, while the last bullet point seems to be referencing thick TLDs. * Could table this for later or skip this question. * Making them separate policies would be the easier thing to do. * Think we're moving away from the thick/thin terms anyways, right? * If you take a look just below the charter question in the working document, there is a further clarification of why the charter question refers to "thin". * Look at what are the elements that are distinctive to document about this policy – if there aren’t any then do we need it? Or maybe defining “material change” will tell when you need to use an inter-registrar transfer process or not. * Seems that a Change of Registrant should be easier than a Change of Registrar. * Gaining Registrar doesn’t have a reliable source of data right now with GDPR. We have to rely on the transfer process being secure. 4. AOB

1 0

Please read: Welcome to ICANN74!
by Nathalie Peregrine June 12, 2022

June 12, 2022

Dear all! Welcome to ICANN74! Please read the below for smooth session running 😊 For members on-site please ensure to arrive ten mins early to enter the GNSO sessions and allow for the meeting to start on time. There will be name checks at the room entrance and this may take a little time. Sessions will kick off on time, and end on time. GNSO sessions will have a secondary room (Yangtze) with screens and standalone microphones. Members who have not managed to sign up to a specific GNSO session, will be able to follow from the secondary room. Coffee and snacks will be available in the foyer outside the GNSO Room (Amazon) . Looking forward to seeing you all on-site and remote! Thank you! Kind regards, Nathalie

1 0

A few issues
by farzaneh badii June 10, 2022

June 10, 2022

Dear all, I was wondering if we addressed the following issues at some point as I don't see them in the preliminary recommendations: 1. Sanctions: there have been instances of registrars or registries finding out that the domain name registrant is located or is providing services to ordinary residents of sanctioned countries. In some cases they have been able to transfer smoothly. But in others the notice to transfer was too short and it amounted to confiscation of a domain name. sometimes the registrars change jurisdiction and suddenly stop serving domain name registrants in sanctioned countries which is over compliance with the sanctions anyway. But they do that on regular basis. Up to this point ICANN has allowed this to happen since this is within the remit of internal governance of registries and registrars. Can we discuss this issue a little bit more? 2. Fees: I can't find anything in our recommendations about excessive transfer fees. Fee setting by ICANN creates complications but can we mention that non-malicious transfer should be free or transfer fee should be reasonably priced? Best regards, Farzaneh

3 5

Initial Report to be published on 20 June
by Emily Barabas June 8, 2022

June 8, 2022

Dear all, Seeing no additional comments on the draft questions for community input<https://docs.google.com/document/d/1-iMcSboPsoTCHYye_u0uVmaVgNiOP7FKYXkO3FW…>, these questions have been added to the Initial Report, leveraging the edits supported on yesterday’s call. Please find attached the final revision of the Initial Report in redline and clean versions. This is the version of the report that will be published for public comment on 20 June 2022. Kind regards, Caitlin, Julie, Berry, and Emily Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Pre-work and proposed agenda - Transfer Policy Review ICANN74 session - Monday 13 June 2022 at 8:30 UTC/10:30 CEST
by Emily Barabas June 8, 2022

June 8, 2022

Dear working group members, Please find below the proposed agenda for our ICANN74 working session<https://community.icann.org/display/TPRPDP/2022-06-13+ICANN74+Transfer+Poli…> scheduled to take place on Monday 13 June 2022 at 8:30 UTC/10:30 CEST (local time in the Hague). Prior to the call, please review pages 20-32 of the Final Issue Report<https://gnso.icann.org/sites/default/files/file/field-file-attach/final-iss…>, which provides context about Change of Registrant, summarizes applicable metrics, and serves as a basis for Monday’s discussion. Kind regards, Caitlin, Berry, Julie, and Emily Proposed Agenda Transfer Policy Review ICANN74 session 1. Welcome and opening remarks 2. High-level Overview of Phase 1(b) Work - Change of Registrant (COR) 3. Discussion of Charter Questions<https://community.icann.org/display/TPRPDP/2.+WG+Charter?preview=/161808892…> d1 & d2 4. AOB Charter Questions d1 & d2: d1) According to the Transfer Policy Review Scoping Team Report, the Change of Registrant policy “does not achieve the stated goals” and “is not relevant in the current & future domain ownership system.” To what extent is this the case and why? Are the stated goals still valid? If the Change of Registrant policy is not meeting the stated goals and those goals are still valid, how should the goals be achieved? d2) Data gathered in the Transfer Policy Status Report indicates that some registrants find Change of Registrant requirements burdensome and confusing. If the policy is retained, are there methods to make the Change of Registrant policy simpler while still maintaining safeguards against unwanted transfers? Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Notes and action items - TPR WG Meeting #50 - 07 June 2022 at 16:00 UTC
by Julie Hedlund June 7, 2022

June 7, 2022

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be during ICANN74 on Monday, 13 June at 8:30 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: 1. I.A.3.7.1: Re: "Evidence of fraud or violation of the Registrar’s domain use or anti-abuse policies." Not later than 24 hours from the 07 June WG meeting: WG members are requested to review the language. See: https://docs.google.com/document/d/1clAqB1wBeOf9ZC5RMMxKrrUTs3N2WyaVYTIyVy_… page 6<https://docs.google.com/document/d/1clAqB1wBeOf9ZC5RMMxKrrUTs3N2WyaVYTIyVy_…>. 2. Re: Charter Question b4): Standard TTL revised language: Not later than 24 hours from the 07 June WG meeting: WG members are requested to review the revised language. See: https://docs.google.com/document/d/1-iMcSboPsoTCHYye_u0uVmaVgNiOP7FKYXkO3FW…. 3. Staff to submit the final version of the Initial Report to the WG for reference with revisions as noted above. 4. ICANN74 Preparation – Change of Registrant topic: WG members are encouraged to review the relevant section of the Final Issue Report before the session so they are ready to discuss. See: https://gnso.icann.org/sites/default/files/file/field-file-attach/final-iss… 3.1.3. Change of Registrant (“CoR”) or Inter-Registrant Transfers, page 20. Notes: Transfer Policy Review Phase 1(a) - Meeting #50 Proposed Agenda 07 June 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * I.A.3.7.1 Transfer Denial Reason: * Remind WG members that as there wasn’t disagreement we are going with the language "Evidence of fraud or violation of the Registrar’s domain use or anti-abuse policies." * In the next/final version of the report, staff will provide a slightly adjusted rationale to correspond to the text update in the recommendation. * WG members are requested to review within 24 hours. See: https://docs.google.com/document/d/1clAqB1wBeOf9ZC5RMMxKrrUTs3N2WyaVYTIyVy_… page 6. * Email from Farzaneh Badii, NCSG regarding sanctions and transfer fees: * These topics are likely out of scope, they’ve been touched on previously by the WG without any proposed recommendations, and any comments can be submitted as public comment. * Comments from Jim Galvin, RySG: on the question for community input regarding enforcement of TTL: https://docs.google.com/document/d/1-iMcSboPsoTCHYye_u0uVmaVgNiOP7FKYXkO3FW… * Re: “It is a maximum because the TAC can only be used once.” Jim: This may need more explanation. May be okay to drop this sentence. Could leave as “maximum standard TTL”. * Remove the last suggested sentence. * WG members are requested to review within 24 hours. See: https://docs.google.com/document/d/1-iMcSboPsoTCHYye_u0uVmaVgNiOP7FKYXkO3FW… 3. Preview of Public Comment Form – see: https://docs.google.com/document/d/1ekTphFh2vXYzGkK2QNrIxlK_bjnvjwtz/edit * Goals of the Target Public Comment Forum/Survey Format: * Make sure comments are linked to specific text in the Initial Report. * Ensure that there is rationale for comments. Will be helpful look at the rationale and the thinking behind those positions. * Greatly improves efficiency and accuracy of public comment analysis. * Format: * Section 1: Name, affiliation, etc. * Each section is broken down by topic with page number references. * Section 2: Preliminary recommendations 1-4: Questions for each are the same for each: * Please choose your level of support for Preliminary Recommendation 1: [single select, optional] * Support Recommendation as written * Support Recommendation intent with wording change * Significant change required: changing intent and wording * Recommendation should be deleted * No opinion * Section 3: Preliminary Recommendations 5-13 on Transfer Authorizations Codes (TAC) * Section 4: Preliminary Recommendations 14-15 on EPDP Phase 1, Recommendation 27, Wave 1 Report Items * Section 5: Preliminary Recommendations 16-22 on Denying (NACKing) Transfers * Section 6: Other Comments and Submission * Two questions for community input – see: https://docs.google.com/document/d/1-iMcSboPsoTCHYye_u0uVmaVgNiOP7FKYXkO3FW… * Names are required to submit a public comment. Anyone can submit a comment (even if they are representing a group), but the person does have to create an account. * Target open for the public comment forum is 20 June and closing on 01 August. We are on track to meet this timetable. 4. AOB * Next session is at ICANN74: Monday 13 June at 8:30 UTC. * Format of the ICANN74 session: Intro to Change of Registrant as a topic, including first charter questions d1 and d2: * d1) According to the Transfer Policy Review Scoping Team Report, the Change of Registrant policy “does not achieve the stated goals” and “is not relevant in the current & future domain ownership system.” To what extent is this the case and why? Are the stated goals still valid? If the Change of Registrant policy is not meeting the stated goals and those goals are still valid, how should the goals be achieved? * d2) Data gathered in the Transfer Policy Status Report indicates that some registrants find Change of Registrant requirements burdensome and confusing. If the policy is retained, are there methods to make the Change of Registrant policy simpler while still maintaining safeguards against unwanted transfers? * WG members are encouraged to review the relevant section of the Final Issue Report before the session so they are ready to discuss. See: https://gnso.icann.org/sites/default/files/file/field-file-attach/final-iss… 3.1.3. Change of Registrant (“CoR”) or Inter-Registrant Transfers, page 20.

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 28 June 2022
by Julie Bisland June 7, 2022

June 7, 2022

As stated on the call, the next TPR Team meeting will be during ICANN74: Monday 13 June at 10:30 CEST (08:30 UTC). Please see the ICANN74 Schedule for join information. * ICANN74 wiki agenda page: https://community.icann.org/x/vhN1Cw * Please be sure your registration is up-to-date (in-person or virtual)! * Entrance to session rooms that are full will be limited to attendees who have signed up for the session. Anyone may join virtually. * Zoom participation links will be published 24 hours before the ICANN74 sessions start. For more information on how to participate, visit: https://74.schedule.icann.org/attend Find below the meeting details for the TPR call taking place after ICANN74. **************************************************************** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 28 June 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/cAD5Cw * Check your time zone: https://tinyurl.com/ymtx2xxu 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

Post Call | Transfer Policy Review PDP WG | Tuesday, 07 June 2022
by Julie Bisland June 7, 2022

June 7, 2022

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

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

June 7, 2022

**AT THE TOP OF THE HOUR** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 07 June 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/7BB1Cw * Check your time zone: https://tinyurl.com/y5mamr72 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/y5mamr72__;!!PtGJab4!8M3iLwT…> 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, 07 June 2022
by Julie Bisland June 6, 2022

June 6, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 07 June 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/7BB1Cw * Check your time zone: https://tinyurl.com/y5mamr72 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/y5mamr72__;!!PtGJab4!8M3iLwT…> 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