- GNSO-TPR - lists.icann.org

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

June 28, 2022

**AT THE TOP OF THE HOUR** 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 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/ymtx2xxu__;!!PtGJab4!84plh9u…> 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, 28 June 2022
by Julie Bisland June 27, 2022

June 27, 2022

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 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/ymtx2xxu__;!!PtGJab4!84plh9u…> 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 #51 on Tuesday 28 June at 16:00 UTC
by Emily Barabas June 24, 2022

June 24, 2022

Dear Working Group members, Please find below the proposed agenda for the next meeting scheduled to take place on Tuesday 28 June 2022 at 16:00 UTC. Kind regards, Julie, Berry, and Caitlin, and Emily Transfer Policy Review Phase 1(a) - Meeting #51 Proposed Agenda 28 June 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Call schedule for July and August 1. Review of Phase 1(b) charter topics and workplan 2. Continued discussion of charter questions d1-d3 3. AOB * Next session: Tuesday 5 July at 16:00 UTC

1 0

Updated-correction made in red / July/August 2022 calls | Transfer Policy Review PDP WG
by Julie Bisland June 21, 2022

June 21, 2022

**We are sending in advance to get dates on everyone’s calendar. Dear all, The calls for July & August 2022 for the Transfer Policy Review PDP WG are listed below. The calls take place at 16:00 UTC for 90 minutes. The attached .ics is a recurring order, please be sure to download it as “recurring” vs. a one-time event to ensure all the dates show up on your calendar. * Tuesday, 05 July 2022 * Tuesday, 12 July 2022 * Tuesday, 19 July 2022 * Tuesday, 26 July 2022 * Tuesday, 02 August 2022 * Tuesday, 09 August 2022 Future invitations will be sent out closer to the date of the call. You should have already received the meeting invite for the next call, 28 June. Thank you. With kind regards, Julie

1 0

Public comment period on Transfer Policy Review Phase 1(a) Initial Report now open
by Emily Barabas June 21, 2022

June 21, 2022

Dear working group members, The TPR Phase 1(a) Initial Report has been published for public comment: https://www.icann.org/en/public-comment/proceeding/initial-report-on-the-tr… Please share information about this public comment opportunity with your groups and any others who may be interested. The public comment period is scheduled to close on 2 August 2022. Kind regards, Caitlin, Berry, Julie, 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

July/August 2022 calls | Transfer Policy Review PDP WG
by Julie Bisland June 14, 2022

June 14, 2022

**We are sending in advance to get dates on everyone’s calendar. Dear all, The calls for June 2022 for the Transfer Policy Review PDP WG are listed below. The calls take place at 16:00 UTC for 90 minutes. The attached .ics is a recurring order, please be sure to download it as “recurring” vs. a one-time event to ensure all the dates show up on your calendar. * Tuesday, 05 July 2022 * Tuesday, 12 July 2022 * Tuesday, 19 July 2022 * Tuesday, 26 July 2022 * Tuesday, 02 August 2022 * Tuesday, 09 August 2022 Future invitations will be sent out closer to the date of the call. You should have already received the meeting invite for the next call, 28 June. Thank you. With kind regards, Julie

1 0

Transfer Policy Review PDP WG
by ICANN Policy Calendar June 14, 2022

June 14, 2022

Meeting: Transfer Policy Review PDP WG Date/Time: Every Tuesday at 16:00 UTC for 90 minutes, 05 July through 09 August 2022 Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Wiki agenda page for 05 July 2022: https://community.icann.org/x/3AIVD * Time conversion link: https://tinyurl.com/yckz6c6a ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form<https://docs.google.com/forms/d/e/1FAIpQLScXP3-H595xH4EFgaR3ydOr-1o9BLAVGUI…> to communicate who the alternate is replacing and for which period. This information will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Everyone when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and in parentheses, (your affiliation - alternate), after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. For Audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6

1 0

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