- GNSO-TPR - lists.icann.org

Re: [GNSO-TPR] Proposed agenda for meeting #29 on Tuesday 21 December 2021 at 16:00 UTC
by Emily Barabas Dec. 16, 2021

Dec. 16, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 21 December 2021 at 16:00 UTC. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #29 Proposed Agenda 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 1. Second reading: TAC and FOA (45 minutes) * TAC Working Document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…> (beginning on p. 15) * Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14) * Gaining FOA Working Document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…> (beginning on p. 16) 2. 60-day post domain registration lock and post domain transfer lock (30 minutes) * See Parking Lot<https://docs.google.com/document/d/1e4hwyxKTx2JFROQ0qpqm_KREHIuZqIugRlzl_gY…> document for high-level notes from previous WG discussions on this topic 3. AOB (5 minutes) * Next call: Tuesday 4 January 2021 at 16:00 UTC

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 14 December 2021
by Julie Bisland Dec. 14, 2021

Dec. 14, 2021

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 14 December 2021 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/gQiHCg> (attendance included) and the GNSO Master calendar<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call as a Panelist, observers can join as an Attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-tpr/> and the main wiki page<https://community.icann.org/x/P4aUCQ>. Thank you. With kind regards, Julie

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 21 December 2021 at 16:00 UTC
by Julie Bisland Dec. 14, 2021

Dec. 14, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 21 December 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/gwiHCg * Check your time zone: https://tinyurl.com/26vjzu4h ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Notes and action items - TPR WG Meeting #28 - 14 Dec 2021
by Julie Hedlund Dec. 14, 2021

Dec. 14, 2021

Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be on Tuesday, 21 December at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> (beginning on p. 15) Page 16, charter question b1, rationale: Re: “A spike in complaints might have been an indication of security shortcomings that would need to be investigated further.” ACTION ITEM: Strike the sentence. It is covered earlier in the text. Recommendation 3, page 16: ACTION ITEM: WG members to comment on the revised language of recommendation 3. Recommendation 5, page 16: ACTION ITEMS: 1. Staff to split the concepts in the recommendation into two parts as per comments from WG members. 2. Replace “failed attempt” with “presentation of an invalid TAC” and “Registry must notifies the Registrar of Record of the presentation of an invalid TAC”. Charter Question b2: Recommendation 6, page 17: ACTION ITEM: Staff to split the recommendation into three parts. Recommendation 9: ACTION ITEM: Change the text to: “The Registry Operator MUST clear the TAC as part of completing the transfer request.” WG to review the revised text. Transfer Policy Review Phase 1 - Meeting #28 Tuesday 14 December 2021 at 16:00 UTC 1. Roll Call & SOI Updates * No updates provided. 2. Welcome & Chair updates (5 minutes) * Update from Sarah Wyld: Yesterday we participated in a panel at the NARALO monthly meeting and discussed the TPR PDP. Very useful discussion. * Update from Jim Galvin, RySG: Agree that the NARALO panel was helpful. Had a lot of really good discussion and asked some good questions about the transfer process. Confirmation that we are addressing issues that are interesting and important. * RySG Advice (Jim Galvin): Action to ask registries about providing the gaining registrar IANA ID to the registrar of record. People are generally supportive of the concept. Some technical issues came up that we will provide more details about. Keep in mind that the IANA ID is only present for accredited registrars and isn’t present everywhere. Have to be able to accommodate those registrars without an IANA ID. Also discussed which field to use and if there is an additional element then there needs to be a standard for it in the IETF, but that would be a relatively straightforward process. * Kristian Ormen: ccTLDs would probably all follow the policy even where the ID isn’t available. * Jim Galvin: Whatever solution we provide needs to be compatible. 3. Second reading: TAC and FOA (45 minutes) -- see: TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> (beginning on p. 15) Page 16, charter question b1, rationale: Re: “A spike in complaints might have been an indication of security shortcomings that would need to be investigated further.” * Comment from Theo Geurts: “I suggest striking this if we do not know what happened it does not add any value. For all, we know a script went haywire somewhere.” * Think this was put in here is because we were looking for any changes in that data. Maybe just a wording change is needed. * Even if it did indicate some kind of ICANN compliance issue they wouldn’t be able to say what to do. Should be taken out? ACTION ITEM: Strike the sentence. It is covered earlier in the text. Recommendation 2: * Comment from Theo Geurts: “Note to WG, some registries create the TAC now and not the registrar. Perhaps this should be more clear so all actors involved are aware that code changes are required.” * Recommendations shouldn’t be considered in isolation. Maybe the answer is in relation to preliminary recommendation 6. There is a variety of implementations that occur. The current state is that a TAC is created at registration and sits there until requested from the registered name holder. New recommendations state that the TAC is only created upon the request from the registered name holder. * Maybe this could be included as an implementation note to put this in the context of recommendation 6. Recommendation 3: * Reconfiguring the language of the recommendation to be specific about the standards to be referenced. Do we want to cover this now? ACTION ITEM: Keep this as an ongoing action item for WG members to comment. Recommendation 5: * Comment from Theo Geurts: “These notifications need to be subject to standard EPP poll messages.” * Need to define what is a failed attempt. Need to think about the lock in this context. “Failed attempt” may not be the right term. Could refer only to “presenting an invalid TAC”. * Would still need some wording for an invalid TAC with respect to the lock. * We haven’t firmed up the final details, but if a TAC is presented to the registrar of record to the registry then the registry should confirm that there are no registrar locks on the name. An nvalid TAC is whatever doesn’t match what is in the system. * Replace “failed attempt” with “presentation of an invalid TAC” and “Registry must notifies the Registrar of Record of the presentation of an invalid TAC”. * We need to tie the presentation of a TAC with the absence of locks. * What threat are we protecting against to allow these things to be uncoupled and expecting the user to do the right thing? It is more likely that we want simple principles. * We are only creating the TAC at transfer in the future based on the current recommendations. * Seems unnecessary to tie these together. In today’s policy is “registry must remove the locks or provide registrars with access”. Maybe we keep the same concept of “or”. * The gaining registrar can quite easily see that the name is locked. Don’t even take a transfer request if the domain is locked. * Looking at this recommendation, agree to change “failed attempts” to “presents an invalid TAC”. But do we need to be explicit about what is an “invalid TAC”? * If the TAC is correct and the domain is locked it isn’t an invalid TAC. * It only matters if the TAC is invalid to send a notice; if the TAC is correct and the domain is locked, the losing registrar doesn’t need to know. * Notification is required only if the TAC is invalid. Do we want to say what “invalid” means, or is that self-explanatory? The word “invalid” seems clear enough, although we could include an implementation note. * Re: 3-5 number: Most have precautions in place to monitory multiple TAC requests since registry resources aren’t unlimited. * Don’t think we are getting multiple brute-force attempts. * People are looking at the 3-5 number. What is reasonable from a security point of view? 10 is a common number as an absolute. 3 is a common number too. * How many attempts do you need to be successful for a brute-force attack? You would need to send a massive amount of requests, and you will be shut out. * Suggestion: Are we trying to pack too much into recommendation 5? There are plenty of reasons why an invalid TAC could be sent. Most likely the gaining registrar will be monitoring and attempting to correct the error. Is it worth trying to separating the issues? Staff could try to try to do recommendation 5a and 5b. ACTION ITEMS: 1. Staff to split the concepts in the recommendation into two parts as per comments from WG members. 2. Replace “failed attempt” with “presentation of an invalid TAC” and “Registry must notifies the Registrar of Record of the presentation of an invalid TAC”. Charter Question b2: Recommendation 6: * Re: “generate the TAC, set the TAC in the Registry platform, and provide the TAC to the RNH” -- Comment from Sarah Wyld: “added some words for clarity, otherwise it suggests that we generate, set, and provide the TAC ALL to the RNH (but actually only provide is to the RNH). * Staff suggestion is to split this into three parts: 1) registrar is the contracting party setting the TAC; 2) TAC is only generated upon request; 3) only after confirmed by the registry is a TTL set. * Re: “After confirmation that the TAC has been successfully set at the Registry, when the Registrar provides the TAC it should also provide information about when the TAC will expire.” Comment from Jothan: Should this happen chronologically only after it has successfully been set with the registry, in order to ensure it works in harmony with any minimum standard of the registry? * Staff is working on a diagram to work out the timing. ACTION ITEM: Staff to split the recommendation into three parts. Recommendation 7: * Is “disclosure” the right word in “The Working Group recommends that when the Registry receives the TAC, the Registry must securely store the TAC using a one-way hash that protects the TAC from disclosure.” Or is “unintended” or “unauthorized”. * Seems to be the right term. * Could provide a footnote to clarify that the disclosure only happens when the un-hashed code is used to validate the transfer. Recommendation 8: * Don’t seem to be any issues. * But if this is becoming part of the transfer policy we could add a sentence clarifying that the AuthInfo Code is being replaced by the TAC. ACTION ITEM: Staff to add a sentence clarifying that in the transfer policy the term “AuthInfo Code” is being replaced by “TAC”. Recommendation 9: * Re: “Once the Registry Operator has verified that the TAC provided by the Gaining Registrar is valid in order to accept an inter-registrar transfer request,” Comment from Sarah Wyld: “is this clear enough? should we add something to indicate that this happens after the transfer is completed?” And from Roger: “+1. Also, should we say "...the Registry should clear the TAC..." instead of "null" to allow flexibility?” * Depends on what we decide on the losing FOA. * What do we mean by “clear the TAC” instead of “null” – a way of saying that the field is empty (so null). * May need to put a pin in this one to make sure there is consistency with the losing FOA recommendations. * “clear the tac” is a better English phrase to describe what’s happening. “set to null” is overly prescriptive as it treads into a technical description. * Suggest not to be overly prescriptive on what needs to happen/sequence of steps at the back end at the registry. The policy can just say what you expect to have occurred. * Could we simply say “Once the transfer is complete, the Registry should clear the TAC”? Or is this too prescriptive? * We can say this if we get rid of the losing FOA. * Don’t have to be prescriptive of when the steps take place – so no need to say that the TAC has to be cleared as a particular step (say, when complete). * The registry could also clear the TAC as soon as they have verified it. * We want to say that once the TAC is used it can no longer be used again. ACTION ITEM: Change the text to: “The Registry Operator MUST clear the TAC as part of completing the transfer request.” WG to review the revised text. 4. AOB (5 minutes) * Next call: Tuesday 21 December 2021 at 16:00 UTC

1 0

**On in 15 minutes** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 14 December 2021 at 16:00 UTC
by Julie Bisland Dec. 14, 2021

Dec. 14, 2021

**On in 15 minutes** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 14 December 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/gQiHCg * Check your time zone: https://tinyurl.com/88hbd29v [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/88hbd29v__;!!PtGJab4!sOd3IJe…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and 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, 14 December 2021 at 16:00 UTC
by Julie Bisland Dec. 13, 2021

Dec. 13, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 14 December 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/gQiHCg * Check your time zone: https://tinyurl.com/88hbd29v [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/88hbd29v__;!!PtGJab4!sOd3IJe…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and 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 #28 on Tuesday 14 December 2021 at 16:00 UTC
by Emily Barabas Dec. 10, 2021

Dec. 10, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 14 December 2021 at 16:00 UTC. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #28 Proposed Agenda Tuesday 14 December 2021 at 16:00 UTC 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 1. Second reading: TAC and FOA (45 minutes) * TAC Working Document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…> (beginning on p. 15) * Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14) * Gaining FOA Working Document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…> (beginning on p. 16) 2. 60-day post domain registration lock and post domain transfer lock (30 minutes) * See Parking Lot<https://docs.google.com/document/d/1e4hwyxKTx2JFROQ0qpqm_KREHIuZqIugRlzl_gY…> document for high-level notes from previous WG discussions on this topic 3. AOB (5 minutes) * Next call: Tuesday 21 December 2021 at 16:00 UTC

1 0

Adding IANA ID/Registrar Name to Transfer Complete email
by Sarah Wyld Dec. 9, 2021

Dec. 9, 2021

Hi all, Re Adding the IANA ID or Registrar Name (or registry ID that maps to registrar name) to the Notification of Transfer Completion email, I’m still thinking about this and have a couple thoughts to share. 1 - Adding it in means development work for everyone (registry needs to include it in the epp message, registrar needs to receive it and pass it on to the registered name holder) and as such we need to make sure there’s a good reason. 2 - If there is benefit to the change then we should recommend it, but I’m not sure there is sufficient value to balance out the cost of work. Reasons to include: - Domain owner would be informed as to where their domain ended up - ... Are there more? I couldn’t think of any others Is informing the domain owner of the registrar name very important, and can it be accomplished in any other way? Presumably the domain owner initiated the transfer via the gaining registrar (or their reseller) and by this point they have already received the TAC or been informed that the TAC has been provided, so the fact of the transfer itself can’t be a surprise, and the identity of the gaining registrar should be known, as the transfer was initiated in their system. There’s some thoughts to be had around the user experience, what’s best for the domain owner. Should user experience concerns be addressed by the losing registrar which no longer provides service for the domain? Or should we expect that the gaining registrar will want to welcome their customer and provide relevant info, although we also decided there’s no policy obligations in that area? So, setting aside the question of ‘is this a lot of work?’ I think we can all agree that we need to have a good reason for any policy obligations we’re creating, and I don’t yet know what that reason is. Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld(a)tucows.com +1.416 535 0123 Ext. 1392

1 0

Adding IANA ID/Registrar Name to Transfer Complete email
by Sarah Wyld Dec. 9, 2021

Dec. 9, 2021

Hi all, Re Adding the IANA ID or Registrar Name (or registry ID that maps to registrar name) to the Notification of Transfer Completion email, I’m still thinking about this and have a couple thoughts to share. 1 - Adding it in means development work for everyone (registry needs to include it in the epp message, registrar needs to receive it and pass it on to the registered name holder) and as such we need to make sure there’s a good reason. 2 - If there is benefit to the change then we should recommend it, but I’m not sure there is sufficient value to balance out the cost of work. Reasons to include: - Domain owner would be informed as to where their domain ended up - ... Are there more? I couldn’t think of any others Is informing the domain owner of the registrar name very important, and can it be accomplished in any other way? Presumably the domain owner initiated the transfer via the gaining registrar (or their reseller) and by this point they have already received the TAC or been informed that the TAC has been provided, so the fact of the transfer itself can’t be a surprise, and the identity of the gaining registrar should be known, as the transfer was initiated in their system. There’s some thoughts to be had around the user experience, what’s best for the domain owner. Should user experience concerns be addressed by the losing registrar which no longer provides service for the domain? Or should we expect that the gaining registrar will want to welcome their customer and provide relevant info, although we also decided there’s no policy obligations in that area? So, setting aside the question of ‘is this a lot of work?’ I think we can all agree that we need to have a good reason for any policy obligations we’re creating, and I don’t yet know what that reason is. Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld(a)tucows.com +1.416 535 0123 Ext. 1392

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 14 December 2021 at 16:00 UTC
by Julie Bisland Dec. 7, 2021

Dec. 7, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 14 December 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/gQiHCg * Check your time zone: https://tinyurl.com/88hbd29v ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and 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