November 2021 - GNSO-TPR - lists.icann.org

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 23 November 2021 at 16:00 UTC
by Julie Bisland Nov. 16, 2021

Nov. 16, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 23 November 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/ewiHCg * Check your time zone: https://tinyurl.com/29892btv 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 #23 - 16 Nov 2021
by Julie Hedlund Nov. 16, 2021

Nov. 16, 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, 23 November at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items 1. Losing FOA Candidate Recommendations – see: Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14) Candidate Recommendation #12: Staff will add a reference/footnote. Candidate Recommendation #13: 1) Staff to review the discussions to clarify the rationale for this recommendation to have two communications. 2) WG members to suggest wording for the method of sending and period of time (text in brackets). Candidate Recommendation #14: WG members to suggest wording re: the method of sending and period of time (text in brackets). Candidate Recommendation #15: 1) WG members to suggest wording re: the method of sending and period of time (text in brackets). 2) Staff to update the context to add text on when this makes sense to be used. Candidate Recommendation #16: WG members to suggest wording re: the method of sending and period of time (text in brackets). 2. Rationale for Elimination of the Gaining FOA: WG members to review the document at Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> (beginning on p. 16) and provide suggestions and comments if any. Transfer Policy Review Phase 1 - Meeting #23 Tuesday 16 November 2021 at 16:00 UTC 1. Roll Call & SOI Updates * No updates provided. 2. Welcome & Chair updates * Will return to the lock discussion in a few weeks. * Note that since we are being so efficient, we are looking to do a Project Change Request to pull forward the NACKing discussion scheduled for Phase 2 so we can get a complete view of the transfer policy during Phase 1a. That includes copying what we are doing now to review charter questions, develop recommendations, and incorporate into the Phase 1 report. We will inform the Council that those discussions may include the TEAC – how it may change or be enhanced with respect to the NACKing of transfers, but any recommendations for changes will not be part of Phase 1, but will stay in Phase 2. * Schedule NACKing after we get through with our discussions on bulk, etc. * The RrSG is holding a poll on locking. * At-Large CPWG also will hold a poll on locking. 3. Losing FOA Candidate Recommendations – see: Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14) Candidate Recommendation #12: The Working Group recommends eliminating from the Transfer Policy the requirement that the Registrar of Record send a Losing Form of Authorization. This requirement is detailed in sections [xxxx] of the Transfer Policy. * Wonder if there should be a footnote that there will still be a notification. * It would really help to include the explanation/context so that people not familiar will know that there will still be a notification. * Context: How this is structured – the candidate recommendations are preceded by a response to the charter questions, which does provide the context, including the rationale. These recommendations won’t be presented in isolation. * ACTION ITEM: Staff will add a reference/footnote. Candidate Recommendation #13: * What do we mean by “distinct” as in “If the Registrar of Record provides the TAC by email, the email containing the TAC and the message notifying the RNH of the TAC request must be two distinct communications.” Could be “two separate communications”. * Don’t see the value of sending two separate emails. Would rather see a combination of this in one email. * The important part is the notification to the registered name holder (RNH). There is also the concept of the 5-day window at the beginning. * Definitely agree we must ensure the RNH is notified; not sure it needs to be two separate messages. But we must have had some reason for it? * Would like to include the name of the person who requested it. * If we look at rows 4 and 5 in the charter, that is what we are doing here. The question we haven’t answered is do we have to specify who the TAC is provided to? If provided to the RNH then we don’t need separate methods. If to someone other than the RNH we’ll need two messages. The security element (secondary notification to RNH) is only needed if the TAC is provided in some method OTHER than by email to the RNH * It can only go to the RNH. It only makes sense to go there. * When we are talking about how we supply the TAC, there could be other means. We could send a notice that a TAC has been created and to look in your account,. * If we look at the early deliberations, some support was expressed for making this two distinct communications for security reasons. * Maybe we split this recommendation up: 1) notification to RNH that a TAC has been requested. 2) If the RNH is receiving the TAC via a communication then they know that the request happened (so no need for a separate communication). * Our goal is to ensure that the RNH is aware of the request. * We want to say if the TAC is being communicated to the RNH then we don’t need two communications, but if provided by a different mechanism then the RNH should receive a notification that the request has happened. * It might be helpful to zoom out to look at the table at: https://docs.google.com/spreadsheets/d/17ADMRTYxN5sA-e3WoEI96KxlH5YRALBsxgw…. * Also note that the recommendations are in order of mandatory ones first then optional, rather than in order of the process steps. * Registrar doesn’t know how the reseller is going to deliver the TAC. * Maybe it will be clearer if we break this recommendation into two parts. * Try to make the type of communication/notification as generic as possible. Suggest wording. * List doesn’t say specifically that the TAC has to be provided or how. * Don’t we have recommendations relating to the TAC? We have a set of recommendations that are specific to the TAC. Notifications of the provision of the TAC are related to the Losing FOA, so that is why the reference is here. We are likely to reorganized these when they are agreed to so all of the TAC recommendations are together. * Envision a scenario where someone logs into a portal and updates the RNH email address and requests a TAC – could be fraud in the account. So, if a RNH email is changed in a certain amount of time then a notification is sent to the previous RNH. * Think the above scenario will come up as part of the change of registrant process. Not sure that is a problem we need to solve for. * We cannot stop this type of fraud with an ICANN policy. * Concerned that we are relying on laws to provide security via some cumbersome and lengthy process, rather than looking at mechanisms that can enhance the security of the transfer. * This relates to Change of Registrant (COR) so we’ll delay that part of the discussion. * ACTION ITEMS: 1) Staff to review the discussions to clarify the rationale for this recommendation to have two communications. 2) WG members to suggest wording for method of sending and period of time (text in brackets). Candidate Recommendation #14: * On number 1 and the IANA ID – losing registrar always gets the IANA ID but not the name of the gaining registrar – if we want that then the registry will have to provide it. * Does it matter that the IANA ID is provided with the name of the gaining registrar? * Think adding IANA ID will overly complicate a communication intended for non-technical people. * Agree that regular users will find IANA ID confusing and unhelpful, but also agree that we can't currently automagically get the actual registrar name. * “Regular users” have a problem when there are resellers have initiated the transfers and the RNH sees the Registrar name (with/without IANA ID). * We do not have info about resellers at the gaining registrar. * Not sure that we need to set a requirement on that. * Language seems flexible enough to allow for minimal notification. * In most cases we see reporters do not know about registrars and file reports with compliance as changing reseller/service provider, but in fact it ends up with changing registrar. * ACTION ITEM: WG members to suggest wording re: the method of sending and period of time (text in brackets). Candidate Recommendation #15: * This is one of the optional notifications. * Add a number 4, the reason for the delay, if there is one? If it is due to a delayed TAC response this would be a good idea. * Do we need to add the rationale for why this is needed? Maybe clarifying when this makes sense to be used in the context. * ACTION ITEM: 1) WG members to suggest wording re: the method of sending and period of time (text in brackets). 2) Staff to update the context to add text on when this makes sense to be used. Candidate Recommendation #16: * This is the second optional notification – the pending notification. * If this is optional, do we have to specify the period of time? * ACTION ITEM: WG members to suggest wording re: the method of sending and period of time (text in brackets). 4. Rationale for Elimination of the Gaining FOA – see: Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> (beginning on p. 16) ACTION ITEM: WG members to review the Rationale for Elimination of the Gaining FOA – see: Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> (beginning on p. 16) and provide suggestions and comments if any. 5. AOB * Next call: Tuesday 23 November 2021 at 16:00 UTC

1 0

**10-minute reminder** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 16 November 2021 at 16:00 UTC
by Julie Bisland Nov. 16, 2021

Nov. 16, 2021

**10-minute reminder** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 16 November 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/eQiHCg * Check your time zone: https://tinyurl.com/3f849rjd [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3f849rjd__;!!PtGJab4!vnP3Jqy…> 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, 16 November 2021 at 16:00 UTC
by Julie Bisland Nov. 15, 2021

Nov. 15, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 16 November 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/eQiHCg * Check your time zone: https://tinyurl.com/3f849rjd [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3f849rjd__;!!PtGJab4!vnP3Jqy…> 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 #23 on Tuesday 16 November 2021 at 16:00 UTC
by Emily Barabas Nov. 11, 2021

Nov. 11, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 16 November 2021 at 16:00 UTC. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #23 Proposed Agenda Tuesday 16 November 2021 at 16:00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Losing FOA Candidate Recommendations (75 minutes) * Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14) 1. Rationale for Elimination of the Gaining FOA (15 minutes – time permitting) * Gaining FOA Working Document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…> (beginning on p. 16) 2. AOB (5 minutes) * Next call: Tuesday 23 November 2021 at 16:00 UTC

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 16 November 2021 at 16:00 UTC
by Julie Bisland Nov. 9, 2021

Nov. 9, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 16 November 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/eQiHCg * Check your time zone: https://tinyurl.com/3f849rjd 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

Post Call | Transfer Policy Review PDP WG | Tuesday, 09 November 2021
by Julie Bisland Nov. 9, 2021

Nov. 9, 2021

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 09 November 2021 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/dwiHCg> (attendance included) and the GNSO Master calendar [gnso.icann.org]<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

Notes and action items - TPR WG Meeting #24 - 09 Nov 2021
by Julie Hedlund Nov. 9, 2021

Nov. 9, 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, 16 November at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items 1. ACTION ITEM: Staff to enquire for clarification. See below: NOTE THIS: https://www.icann.org/resources/pages/text-2012-02-25-en, ON that page: Please note that you may not transfer your domain name to a new registrar within the first 60 days after initial registration, or the first 60 days after a transfer. NOTE THIS: https://www.icann.org/resources/pages/policy-transfers-2014-07-02-en, On that page, it becomes optional for the sponsoring registrar to NACK the transfer for being within the 60-day window. No longer enforced by registry by policy. Transfer Policy Review Phase 1 - Meeting #24 Tuesday 09 November 2021 at 16:00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) * The RrSG will be providing a poll to its members on the various locks. Should have the results at the next meeting or the one after. 3. Presentation of Compliance Metrics (attached) -- TPR Team Feedback ICANN Org Compliance Overview: * Covers the period of 29 August 2020 to 30 September 2021. * Metrics are generated on a monthly basis. Report was retrieved in October 2021. * See: https://community.icann.org/display/TPRPDP/2021-11-09+Transfer+Policy+Revie… * See: Contractual Compliance Performance monthly dashboards : https://features.icann.org/compliance/dashboard/report-list * Compliance had between 1,000 and 4,000 complaints per month during the period. Unauthorized transfers represent about 1% of total complaints per month. Discussion: * Question: When do you categorize them – when received or when closed? Answer: Time depends on response, whether the registrar is following up with the reporter, it is case-by-case. * In looking at the number of complaints versus transfers, that seems to be a low rate of complaints. * A lot of these unauthorized transfers are being solved between the reseller and the registrar, rather than categorized as hijacking. * The point should be made clear, that these are the only ones that ICANN Compliance sees. There's no visibility to other unauthorized transfers where no complaint is filed with ICANN. * It would be very helpful to see the total number of complaints, not just those reported to ICANN. * The information provided by Compliance shows that most of the complaints are closed because the reporters did not respond to ICANN’s request for further information. * Question: Is it possible to summarized these as how many were closed in favor of the complainant and how many were not? How many were closed with the complainant comfortable with the determination or not? Answer: That data is already in the compliance dashboard. * Is there any visibility into the number of complaints that are filed with a transfer dispute resolution provider under the Transfer Dispute Policy? * I think the only way we'd even know is if there was some sort of aggregate reporting from Registrars. * I do not think there’s any way to get that data in an accurate manner. * An interesting metric to report would be how long a ticket is usually in process before it is closed. Compliance will take that suggestion back to the team. 4. Continued deliberations on Additional Security Measures – see: Additional Security Measures working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…>: Discussion of other security measures the WG would like to consider Registrar-applied lock * Comment from Sarah: I think this would be more clear if we indicate this lock can be applied and lifted at any time during the life of the domain. This is not specific to the creation moment * Updated the text to clarify that the lock already exists and is not specific to the creation moment, but the charter question asks if the lock should be applied by default when the domain name is registered. Post domain creation lock * Comment from Steinar: For the new gTLDs, the applicant needed to define the lifecycle. I believe the majority of the new gTLDs have a 60 days transfer lock after registration where the serverTransferProhibited is set * Comments from Barbara: In some registries, the post domain creation lock is systematically enforced and it is not possible to opt out. It is not necessarily implemented using the serverTransferProhibited EPP code. Seems that "MAY deny" is the more appropriate language unless/until all registries mandate this lock. * Not all these locks are a specific EPP code, but may be a policy that someone is trying to enforce. These are policies from the registries to the registrar, not an ICANN policy. * It should be down to the individual registrars, but not sure that is in scope of the transfer policy – but gets negotiated between the registries and registrars. * A post-domain creation lock would be out of scope because it is not an existing requirement from ICANN’s existing policy, but from an RRA between ICANN registries and registrars. That doesn’t prevent this WG from trying to create a consensus policy that is consistent across all registries. * This is a legacy items that came into several of the long-standing registry agreements. Could be unique to the legacy TLDs. * Since the registrars will talk about locks we won’t go into that much detail, but it seems that this should be part of this PDP, that it is in scope. * So the boundaries of discussion to a prevent transfer after x days of creation as a consensus policy are 1) consistency 2) security/stability. * Question: Why do these registries have a transfer lock and does it have a function today. * To that extent that a registry got a court order for a transfer, there would be ways to effectuate that. * Maybe the registries will tell us that there is a good reason for these post creation locks, or maybe they will say we no longer need them (and had nearly forgotten about them!). If no longer necessary, then based upon advise from this WG, ICANN org can consider changes to this provision in contracts as they arise. * Would be helpful to know how many registry agreements have this requirement. * The 60 days lock for transfers after creation has been implemented for many ccTLDs too. * Hard to say how many transfer disputes there would be if this requirement went away. * From an end-user perspective it would be easier to understand the requirement if everyone had it. * The Creation Lock is of the very least concern in my experience, but cleaning up an unnecessary lock could be doing everyone a favor and there is no better place for discussing it. On the other hand, if there is a reason as Barbara suggested could be possible, then consistency may be a desirable goal. Lock subject to UDRP Proceeding * Comment from Zak: Also See Paragraph 8 pf the UDRP Policy. Would we refer any changes to the RPMs PDP Phase 2 review of UDRP policy? Answer: Could keep the same NACK, but if they change the policy they’ll be required to look at that. Redemption Grace Period Lock * Comment from Barbara: Suggest changing this to "Registry imposed lock" to avoid confusion with the Registry Lock service that some registries offer for some TLDs. * Staff will make that change. Registry Lock Service * Comments from Barbara: Some registries have separate Registry Lock agreements with registrars to govern this service as not all registrars opt to offer the service. Note that in addition to the serverUpdateProhibited EPP status set, a lock on the domain name likely also has serverTransferProhibited and serverDeleteProhibited EPP status codes set. * Staff will add text to clarify. * Note that "registry lock" may be being sold under different names. Page 8: OTHER SECURITY FEATURES THAT THE WORKING GROUP MAY WANT TO DISCUSS * Requirements regarding logs that registries and/or registrars must maintain with respect to the transfer? * Multi-factor authentication? * To access the account: some WG members expressed that prescribing requirements would be out of scope, but that the WG could provide guidance about the benefits and the ways that MFA can enhance other security elements. * To access the TAC or unlock the domain: some WG members expressed that this would make the transfer process too onerous for registrants. * Other security practices/features applied in other contexts that could be relevant to this discussion? Discussion: * Comment from Steinar: Not sure this is the "place" to add, but a secure way of informing Registrant about the TAC should be implemented. This indicates that email may not be sufficient. * May not be other options than email. Should remain up to the registrar to determine what is a secure method. * Maybe some kind of wording that it has to be done it a secure manner. * Should be too specific/narrow. For the consistency idea: There being a 60-day transfer lock on creates and transferred, but with an opt-out feature. * Another question that this group might want to ask is the rationale for such a thing other than consistency – such as security components? Also, is 60 days the right length? * That transfers into a lock that’s settable by the registrant. It is in the registrant’s hands to turn that off. * So it would be a default lock but with an opt out. * What is this trying to protect against? Need some clarity on this. You may need two different mechanisms, depending on the reasons. * There could be constraints on turning off the lock. * The registrant can opt out and the registrar can opt out of the option. But would like to see transparency from registrars that they have opted out. * Apparently it [60-day lock] was a “policy” that started way back with Verisign. Legacy ROs carried it forward. For example, Afilias was required to do this for .ORG when it transferred from Verisign. Somewhere on or about the 2012 round the policy was backed off. I found a 2014 reference above. So, it seems that new registries don’t do it as they never had any reason too. “legacy” TLDs and permits RSPs do it because they always have and never had a “reason” not to. This is something we should probably clarify in our work and final recommendations. ACTION ITEM: Staff to enquire for clarification. See below: NOTE THIS: https://www.icann.org/resources/pages/text-2012-02-25-en, ON that page: Please note that you may not transfer your domain name to a new registrar within the first 60 days after initial registration, or the first 60 days after a transfer. NOTE THIS: https://www.icann.org/resources/pages/policy-transfers-2014-07-02-en, On that page, it becomes optional for the sponsoring registrar to NACK the transfer for being within the 60-day window. No longer enforced by registry by policy. 5. Losing FOA Candidate Recommendations – see: Losing FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wCUMe9ii6g05…> (beginning on p. 14) * Begin this discussion at the next meeting. 6. AOB (5 minutes): None.

1 0

Proposed Agenda: TPR Meeting #23 - 9 November 2021
by Caitlin Tubergen Nov. 9, 2021

Nov. 9, 2021

Dear TPR WG Members, Below, please find the agenda for our upcoming call on Tuesday, 9 November 2021 at 16:00 UTC. In preparation for the meeting, please review the attached ICANN org compliance metrics. Additionally, please review the other security measures added to the Additional Security Measures working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…>, beginning on p.8 of the Working Document. Please continue to add additional security measures to this section in advance of our next meeting. Thank you. Best regards, Emily, Julie, Berry, and Caitlin -- Transfer Policy Review PDP WG Meeting #23 9 November 2021, 16:00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Presentation of Compliance Metrics (attached) * TPR Team Feedback 4. Continued deliberations on Additional Security Measures * Additional Security Measures working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…> * Discussion of other security measures the WG would like to consider 5. Losing FOA Candidate Recommendations * Losing FOA Working Document<https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy…> (beginning on p. 14) 6. AOB (5 minutes)

3 2

**On in 13 minutes** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 09 November 2021 at 16:00 UTC
by Julie Bisland Nov. 9, 2021

Nov. 9, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 09 November 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/dwiHCg * Check your time zone: https://tinyurl.com/4bmm2fpp [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/4bmm2fpp__;!!PtGJab4!uMMIoi2…> 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