- GNSO-TPR - lists.icann.org

**15-MINUTE REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 12 December 2023
by Julie Bisland Dec. 12, 2023

Dec. 12, 2023

**15-MINUTE REMINDER** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 12 December 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/R4BFE * Time conversion link: https://tinyurl.com/wv6crbh3 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/wv6crbh3__;!!PtGJab4!5JedU1K…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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 December 2023
by Julie Bisland Dec. 11, 2023

Dec. 11, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 12 December 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/R4BFE * Time conversion link: https://tinyurl.com/wv6crbh3 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/wv6crbh3__;!!PtGJab4!5JedU1K…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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 and Proposed Agenda - Meeting #111 Tuesday, 12 December 2023 at 1600 UTC
by Christian Wheeler Dec. 8, 2023

Dec. 8, 2023

Dear TPR WG members, Please find below the proposed agenda for our next call, taking place on Tuesday, 12 December 2023 at 16:00 UTC. As a reminder, if you have any additional questions for Holida Yanik and the Contractual Compliance team regarding the transfer complaint metrics they shared last week, please respond by end of day today (Friday, 8 Dec). Sarah has already begun a draft message, which she shared to the list. Thank you and we look forward to seeing you all virtually. Kind regards, Christian, Caitlin, Berry, and Julie ---------- Transfer Policy Review - Meeting #111 Proposed Agenda 12 December 2023 1. Welcome and Chair updates 2. Discussion of additional Security Measures a. Improper CORs b. COR + Registrar transfers c. Poll questions 3. AOB

1 0

Proposed Agenda - Meeting #110 Tuesday, 05 December 2023 at 1600 UTC
by Christian Wheeler Dec. 6, 2023

Dec. 6, 2023

Dear TPR WG members, Please find below the proposed agenda for our next call, taking place on Tuesday, 05 December 2023 at 16:00 UTC. We will be joined by Holida Yanik of ICANN Contractual Compliance, who will kindly be providing an overview of Compliance’s Transfer complaint metrics (attached for your reference). We highly recommend that you review this data prior to the call and come prepared with any questions. Thank you and we look forward to seeing you all virtually. Kind regards, Christian, Caitlin, Berry, and Julie ---------- Transfer Policy Review - Meeting #110 Proposed Agenda 05 December 2023 1. Welcome and Chair updates 2. Transfer complaint metrics with ICANN Contractual Compliance 3. Recap of revised COR Process 4. Discussion of additional security measures 5. AOB

2 2

Notes and action items: TPR WG on 05 Dec at 1600 UTC
by Julie Hedlund Dec. 5, 2023

Dec. 5, 2023

Dear TPR WG members, Please find below the brief notes and action items from today’s meeting. The next meeting will be on Tuesday, 12 December at 1600 UTC. Kind regards, Christian, Caitlin, Berry and Julie ACTION ITEMS/HOMEWORK: Re: Transfer complaint metrics -- Sarah Wyld to send an email with the WG’s request for more specific data. [COMPLETE] Transfer Policy Review - Meeting #110 Proposed Agenda 05 December 2023 1. Welcome and Chair updates * Only two meetings left for the year then the holiday break. * Zack Muscovitch, BC update: * Position for the record: “Change of Registrant Lock -- The default rule should be a transfer lock following a change of registrant. However, a registrar should be required in a transparent manner, to enable a registrant, upon request to opt-out of the transfer lock or to reduce the transfer lock, rather then leave it to each registrar to decide whether they will generally permit opt-outs. Nevertheless, each registrar should retain discretion as to whether to permit a transfer even if the registrant has ostensibly opted out, for security reasons. A transfer lock should not prevent registrants and businesses from effecting bona fide transfers when necessary or desirable. There should be a fact-based rationale for the determination of the length of the default transfer lock, whether it is 60 or 30 days, for example.” * Explained to them is that there had been some preliminary discussions on removing transfer locks, and entirely as one of the options under discussion. Part of that suggestion could be that there was only notification to the registrar and to the losing registrar rather than an ability to stop the transfer, and some of the preliminary feedback I received from the BC on that question was that the BC would be prepared to accept the removal of change of registrant locks altogether, but as a quid pro quo of that the BC would want to see that there was more than a mere notification and an ability of the registrant to stop the impending transfer. This is preliminary, there's no decision or formal policy changes being made. But just to give you a sense of what the BC is thinking at this early stage. Discussion: * Owen -- Question: You mentioned a quid pro quo. I was just wondering if you could clarify that. So they'd be okay with removing the lock if the registrant could get out of such a change of registrar. * Zach: As far as the working groups is concerned, on the 30-day change of registrar lock, that provided a significant amount of protection for registrants in terms of getting back that domain name. And so in in that context it was somewhat persuasive to some in the BC. I think that removing the change of registrant lock could be acceptable, give given that additional protection was in place. Some believe that it would only be fair if there's if there's going to be no change of registrar lock to enable a registrant to have more than a mere notification with uncertain recourse after receiving the notification, but to actually stop the transfer between registrants. * Rich: I just wanted to further clarify something with Zack. You mentioned that your group is talking about the notice to undo a transfer during a CoR. A transfer isn't taking place. That notice is just letting them know a registering change has happened. If a transfer is happening, they're already getting notified via the FOA during the 5-day period. * Zach: My understanding was that the preliminary discussion this working group was having was that one of the possibilities under consideration was that upon a change of registrant being initiated, the registrant would be notified right away that the * change of registrant had been initiated but at that point it would be too late to stop it in any event. So if the registrant got the notification that would be too late in most cases, and then the registrant would be left to deal with the registrar to try to reverse it. And so * the BC's perspective at this preliminary stage they wanted something more than a mere notification and rather an ability to * stop that transfer. * Rich: I think there's a little bit of debate here on whether or not for the change of registrant there's a notification that sent. There's also verifications of the new details that are happening on the RDS side. So that's another process already happening. So they're probably getting another notification of the change from that as well to confirm it. Then after such a change during the CoR as it stands right now, but we're discussing removing it. Then a request for the auth code needs to be made, at which point those verifications kick in, and the 5 day to reverse the transfer which is already in place and already part of the process. I'm just wondering if a further lock is necessary, or whether we can continue with just removing the lock from the change of registrant. * Theo: So when you're discussing the current change of registrant process you need to keep in mind what we replace it with, and compare those two and not go back to the old transfer system, because that's going to make your discussion more complex when moving forward on this. * Zach: Just to add a little bit more background and context for the discussion with the BC. It was noted that there's going to be what's perceived as additional security provided by the new TAC process. And so essentially, the argument goes that if your email or your registrar account was penetrated that's a whole other story. And so we presume that in order to have a TAC that it's rightfully obtained, that would by extension the argument would go, so that's yet another reason for removing the ability of the registrant to stop the transfer at that point, because the registrants already authorize that change by obtaining the TAC. And so I understand that argument, and I believe I conveyed that to the BC. I think that the counter argument goes that yes, that's all true. But when it comes to something more than a notification and ability to stop it, it is belt and suspenders. But that is an appropriate precaution for moving something as important as a name, and secondarily, that the process of providing an ability to stop a transfer isn't so much more onerous than providing a notification. So for that incremental additional effort it provides significantly more comfort for the registrant in having that ability to stop it if something had somehow gone wrong with the TAC. * Roger: I think that we're talking about a fairly good use case here that does happen. And we're talking about a change of registrar, followed by an actual transfer from one registrar to another. We had the discussions back in in Group 1A that there is that 5-day window that the registrars have to provide the AUTH code, or to deny the transfer for whatever reasons. That the registrars need to do their due diligence and make sure. And during that 5 days, that was a look back: what was the registrar prior to this, and did someone make a big change? Or did they just make an acceptable change? My email wasn't working, now I have new one, and that's been confirmed and verified. As people have mentioned that has to occur anyway. We're talking about one scenario where change of registrant leads to a transfer and path does seem to be very secure. The registrar still had to do that due diligence upfront before providing that TAC. 2. Transfer complaint metrics with ICANN Contractual Compliance – see attached file Discussion: * Questions: 1) There are sections to differentiate – ticketing system was retired and moved to NSP; reflects data from two systems but can reflect the same detailed category after August 2020 is NSP. 2) No complaints of unauthorized transfers for hijacking? We have data up to October 2023. Grouped together from different complaint types. * Question: Like to understand how many complaints were there of unauthorized transfers – thinking about what is the most useful context? * Compliance: This data only shows complaints already addressed by the registrar. Compliance can work with their team based on the WG’s needs. * Question: Wonder if their could be related to ERRP/EBDP (renewal complaints as a subset) that is unauthorized change of registrant. * This is just the raw data – can we get to the real reason and get rid of the noise to refine the numbers (Sarah Wyld volunteered to start the discussion). * Compliance: We have a category of complaint relating to renewals. ACTION ITEM: Re: Transfer complaint metrics -- Sarah Wyld to send an email with the WG’s request for more specific data. [COMPLETE] 3. Recap of revised COR Process – see attached slides Discussion, Slide 4: * When it comes to confirming that the name is eligible have no way of knowing if the compliance requirement is met. * No timeframe requirement for steps 1 and 2 – interesting. On step 2, bullet point only the new registrant needs to be told that they need to enter into an agreement. * Questions: 1) is this a distillation of discussions – not agreement or proposals? Would like to see a discussion of formal proposals. Yes, that’s correct. We will get to the point where we can discuss recommendations. 2) In theory immediately or contemporaneously with step #2 the process in step #3 could be completed? Yes, but we should discuss if their should be time delays. Also may depend on the type of change. * Will depend on the business model. * If #1 has no timeframe, my question about CoR Appeal in #4 may be moot as the legitimacy of a CoR may be stronger with a good process in #1 which might remove a need for Appeal of CoR in #4. Discussion, Slide 5: * Think this is already being addressed with upcoming security laws. Also for #4 other, could identify existing registry locks as options. * Balance need to reclaim the name with how our systems work. Much more available if stays within the same registrar – much harder if in a different registrar. * With a notification is there a path the registrant can take? * The WG will have settle on an option or a combination. * Question: Is there a dispute mechanism in the current policy? Answer: Only option #1. Discussion, Slide 7: * This is where the true issues would come up. * This is an operational minefield. Looks good on paper but problems in execution – avoid all options. * Question: Are we talking about change of control? Answer: Don’t think we’ve narrowed that down. * For legitimate reasons, this does occur all the time. Needs to be safeguards to catch when it’s not legitimate. * Guardrails can be in place, but don’t have to be at the policy level. * There SHOULD be some guard rails -- removal of guard rails should not be our statement. Unless we define something here, it will be implemented in diverse ways that will be confusing to registrants where there is variance from Registrar-to-Registrar in how they implement this. Should be some appeals mechanism. * Opt out can only be before you make a change because of the lock. The CoR needs more resolution. Remember it’s part of a bigger approach. * These items are very much open. Come back with ideas.

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 05 December 2023
by Julie Bisland Dec. 5, 2023

Dec. 5, 2023

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 05 December 2023 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/RYBFE> (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 recording (including audio, visual, rough transcript, and chat.) * Transcript * Agenda and Notes/Action Items 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, 12 December 2023
by Julie Bisland Dec. 5, 2023

Dec. 5, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 12 December 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/R4BFE * Time conversion link: https://tinyurl.com/wv6crbh3 ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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, 05 December 2023
by Julie Bisland Dec. 5, 2023

Dec. 5, 2023

**AT THE TOP OF THE HOUR** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 05 December 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/RYBFE * Time conversion link: https://tinyurl.com/bdh8rb4w [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/bdh8rb4w__;!!PtGJab4!5xVUzmu…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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

2 1

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 05 December 2023
by Julie Bisland Dec. 4, 2023

Dec. 4, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 05 December 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/RYBFE * Time conversion link: https://tinyurl.com/bdh8rb4w [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/bdh8rb4w__;!!PtGJab4!5xVUzmu…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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 on 28 Nov at 1600 UTC
by Julie Hedlund Nov. 28, 2023

Nov. 28, 2023

Dear TPR WG members, Please find below the brief notes and action items from today’s meeting. The next meeting will be on Tuesday, 05 December at 1600 UTC. Kind regards, Christian, Caitlin, Berry and Julie ACTION ITEMS/HOMEWORK: WG members should review the CoR process in the attached slides, starting at slide 2, and consider the changes that the WG is suggesting in red to see how the process looks with the changes and if it’s a good solution. Transfer Policy Review - Meeting #109 Proposed Agenda 28 November 2023 1. Welcome and Chair updates * Four meetings remaining this year. * Steinar’s ALAC, report on the CPWG poll/update on CoR: * Lively discussion. * More than 40% were not sure about removing CoR from Transfer Policy so continuing to educate. Discussion: * Question: When we're talking about removing the change of registrant from the Transfer Policy, are we talking about removing it from the Transfer Policy and putting it somewhere else? Are we talking about removing the restrictions on change of registrant? Answer: I don't think we've gotten far enough in our discussions to go down either one of those paths. I think both of those paths are valid. And I think that you know, if it's removed out of policy, that's it's assumed and maybe even language put back in that the registrars are responsible for that. But again, I'm not sure that we're far enough down the path to say either way. * If we remove it from the inter-transfer policy, does it have to be a new PDP? That could be the alternative. This is an operational issue that can be handled directly by the registrar. * The Transfer Policy was technically an Inter-Registrar Transfer Policy. At the time it seemed like a an appropriate decision to drop the Inter-Registrar Transfer Policy and call it a Transfer Policy that really has two sections—inter-registrar transfers and CoR. In reality it's really two separate policies embedded on the same policy page. Because when you read through the definitions and the process for a CoR, it has zero connective tissue to anything of the traditional Inter-Registrar Transfer Policy. There have been discussions about whether CoR can somehow be embedded into the Inter-Registrar Transfer Policy, and maybe it can, maybe it can't. Maybe it needs to be something standalone. What is somewhat new to us is twofold: One is, there is connective tissue back to the whois accuracy policy, and some of those changes that occur there also align or coincide with what is being labeled as a material change in the CoR policy. So we need to look out for that and also thank you to Theo for mentioning the emphasis being provided on the organization field from the draft version of the Registration Data Policy. This group may want to pay a little bit of attention to that. The second block is we need to constantly remind ourselves of the draft preliminary recommendations that the group has come up with the Inter-Registrar Transfer Policy and the entire foundation has shifted because we're introducing the TAC meaning that there are several steps that are going to occur before the TAC is actually revealed to the registered name holder. There is a difference of when CoR, assuming that it were to remain in its current state, could be invoked before the actual Inter-Registrar Transfer Policy. Put another way, if the registered name holder makes a material changed as defined in CoR today and doesn't have the intent of doing an inter-registrar transfer these material changes are still invoked, whether that includes notifications or locks, or whatever the group ultimately comes up with. I'm starting to wonder if it's even possible to salvage components of the CoR that would be embedded just in the Transfer Policy by itself when they're, in fact, kind of distinct components. And again, we do have some sort of connective tissue back to the whois accuracy specification as well as the organization name field that now has bigger emphasis. * One of the original concerns for registrants was navigating what is, even to a lawyer, very complex and intricate, intricate document to this transfer policy that combines those two spheres is Barry mentioned. And so there was this interest in discussing, considering whether there should be a standalone portion just dealing with the change of registered provisions that a registered can more easily comprehend and navigate. But I think that, based upon my understanding of this group's discussions, particularly in the last call there seem to be some suggestions of getting rid of the restrictions on change, of registering altogether, and it seems to me that if that that suggestion were to have considerable support in the working group. Then that could impact the group's decision about whether there's an a need to have it as a standalone policy, or whether there's just nothing to say, because there's no restrictions, or maybe just has to do with the notice provisions. And so I think that rather than discuss the removal of the transfer locks in the sense of transferring it to a new standalone document. It might make sense to discuss the merits or lack of merit of changing or changing and or removing the transfer restrictions first. * Sounds like group is leaning towards removing most of the CoR from the Transfer Policy and making it standalone or replacing it with notification requirements. * Maybe the overarching security model has changed with the TAC: Transfers are based on the usage/exchange of the TAC and contactability. So whatever happens inside a registrar is up to the registrar – intra-registrar transfers. Inter-registrar transfers are about the TAC and contactability. * Seems we are moving to removing locks and only requiring notifications. * This is about the appropriate level of restriction to protect a domain name in an inter-registrar transfer. The interdependencies to maintain the integrity of the registration. * There is a point where the inter-registrar transfer isn’t invoked until the TAC is requested – WG could consider extra protections up to that point. * Think we could create a separate policy if that is a result of answering the charter questions. * One of the ALAC arguments re: preventing domain name hijacking – we don’t have any evidence that the policy does this. Want to have the update of registrant data as smooth and secure as possible. * Doesn’t do anything to create a new policy. Doesn’t have to be so complicated. * It is more or less a definitional issue. * Think a lot of this discussion relates to agenda item #2. 2. COR Process and Discussion – see attached slides. Discussion: * Question: Should we still use the phrase “security threats”? Answer: We should track any updates with terminology. * Thoughts on change of control/ownership change? That implies more than change of registrant. * Locks make sense with inter-registrar transfer, but not sure it makes sense for change of registrant contact info. * Are we still okay to eliminate the confirmation? * Question: If we go to notifications only, and we rely on the lock that applies for a change of registrar, there's going to be 30 days where the name can't move, and that provides the window of opportunity for the registrant upon notification to do something about it. What can the registrant do about it? The registrant can't invoke the transfer dispute resolution policy. Some registers may be happy to look into it for them, but there's no procedure in place. The UDRP can't be used unless in cases of domain theft, unless the complaint happens, have a trademark in other circumstances. So my question really is, is that the notification seems like an elegant solution but what can a register and do upon notification if it's a bad transfer? Answer: That notification should probably include something on if you disagree contacts -- there has to be that next step. * The issue is, do we put language around that that registrars notification has to include whatever we're going to call it, you know, at least a path for the registrar to at least ask, and is that as simple as the notification has to include Register our contact information, whatever it is. * If we, as a working group, proposed this, we would get all kinds of negative feedback on it. Just giving a phone number, an email address or a link to a complaints form really isn't going to do much for registrants that are left to their own devices. But if you go into notification there really needs to be another piece added to the puzzle to provide some kind of direct remedy. That that's an actual enforce standard for registrars. * We're not talking about a transfer. It's just a notification like the data set which you supplied back then, during your registration, has changed and it's up to the registrants, the current domain name owner to confirm this was an update. * It's one of those standard things that to me occurs across online environments today pretty regularly. It's definitely a model that we can take a look at. * So what I'm hearing now is consideration of a dispute process for a registrant contact info updates, and we barely even have one for inter register transfers; the fast undo suggestion didn't go anywhere. So as we discussed I'm not certain that the Transfer Policy is the right place for this requirement, especially since there are related obligations in the RAA, like the Whois accuracy program, has validation and verification. That's the same data set being reviewed. So if we're just keeping the CoR and like lightening it up to be a notification process, maybe even with no lock process, that would be great. We're chartered to do it. Let's make a useful change. * If I am a registrant and my domain name was changed and email and I was notified of that and it was unauthorized why is there no option to dispute it since it is essentially a transfer? * I don't think it's wrong to say that if there's a problem with your service, then you contact your service provider. * But what we have learned now is that this mechanism doesn't actually prevent domain name theft. What it does is it puts a burden on registrants, and that's why we are revisiting this. * We do have a slide that talks about what needs to be in the notification, so we will get to more in depth discussion on that. * I think one of the issues we're having today is this group is so efficient. We're talking about the things that we wanted to talk about. We're just talking about them in advance. * And I think one of the issues here to kind of pull out is this two notifications? Is that still a valid notification process, or should there just be one notification? Where a request is probably followed directly by the completion. Or both a request when the change of registrar is being requested, and then when it's actually completed in the system. So think about that. HOMEWORK: WG members should review the CoR process in the attached slides, starting at slide 2, and consider the changes that the WG is suggesting in red to see how the process looks with the changes and if it’s a good solution. 3. AOB – None.

1 0