- GNSO-TPR - lists.icann.org

**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

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

Nov. 8, 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

TPR-P1 // 31 Oct 2021 Project Package
by Berry Cobb Nov. 4, 2021

Nov. 4, 2021

Dear WG, Please find a link below to project package for the TPR-P1 PDP (31 Oct 2021). This package is a snap-shot at the close of each month and developed by the leadership team to report on the working group’s activities and status of the project. It is also distributed to the GNSO Council to keep them informed as managers of the PDP. The package is deposited on the wiki so that we can track access statistics. Link: https://community.icann.org/x/MQDQCQ 1. Page 01 – Summary dashboard 2. Page 02 – Project Sitrep – an extract from the Council’s Project List 3. Page 03,4 – Group roster 4. Page 05 – Work and activity metrics 5. Page 06,7 – Group attendance for plenary meetings 6. Page 08 – Project Plan, Gantt chart 7. Page 09 – Work plan & Action items for the period Key points: * The WG is proceeding according to plan against the charter topics/questions; nothing substantive to report for this period. Please let us know if you have questions. Thank you. B Berry Cobb Policy Development - Portfolio Manager Internet Corporation for Assigned Names and Numbers (ICANN) berry.cobb(a)icann.org

1 0

Input requested: More additional security measures
by Emily Barabas Oct. 29, 2021

Oct. 29, 2021

Dear WG members, As a follow-up to Tuesday’s session, staff has created a new section of the Additional Security Measures Working Document for members to list other potential security measures for the group to discuss. Please add your notes on page 8 of the working document<https://docs.google.com/document/d/1q7xaJuxi50Q6TDD26H92P6wOfZ8luap1wdWOtIg…>. We look forward to continuing the discussion on 9 November. Wishing everyone a restful break from WG activities until then. Kind regards, Caitlin, Berry, Julie, and Emily From: GNSO-TPR <gnso-tpr-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Tuesday, 26 October 2021 at 21:04 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: [GNSO-TPR] Notes and action items - TPR WG Meeting #23 - 26 Oct 2021 Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be in two weeks on Tuesday, 09 November at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items 1. ACTION ITEM: WG members to contribute to a list of additional security measures and provide other comments/suggestions in the Google doc for Additional Security Measures Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…>. Transfer Policy Review Phase 1 - Meeting #23 Tuesday 26 October 2021 at 17:30 UTC 1. Chair Update 2. About the PDP and Status Update (20 minutes) -- Slides attached * About the Transfer Policy: “ICANN consensus policy governing the procedure and requirements for registrants to transfer their domain names from one registrar to another.” * Formerly called the Inter‐Registrar Transfer Policy (IRTP) * Went into effect in November 2004 * GNSO reviewed the policy once before, shortly after implementation * Mission and Scope: PDP to conduct a holistic review of the Transfer Policy and determine if changes to the policy are needed to improve the ease, security, and efficacy of inter-registrar and inter-registrant transfers. * Conducted in 2 Phases under a single Charter<https://community.icann.org/display/TPRPDP/2.%2BWG%2BCharter> <https://community.icann.org/display/TPRPDP/2.%2BWG%2BCharter> & covering 8 topics. * PDP began Phase 1(a) in May 2021: * Phase 1(a) Topics: Forms of Authorization and AuthInfo Codes * The working group has now conducted initial deliberations on each of the Phase 1(a) topics and has begun to develop “candidate recommendations” and draft responses to charter questions. * While members and alternates are limited to representatives designated by SO/AC/SG/Cs, anyone can sign up to observe. * Topics: * AuthInfo Code Management * Gaining & Losing Registrar Form of Authorization (FOA) * FOA: Further Work Needed * EPDP included the workaround from the Temporary Specification in its recommendations, which were adopted by the ICANN Board. * Registrars identified challenges in ICANN org’s position that a Gaining Registrar is required to send a Gaining FOA where the email address “is available”, as there is no guarantee that the email goes directly to the registrant. * ICANN Board passed a resolution to defer contractual compliance enforcement of the Gaining FOA requirement pending further work in this area. * Contracted Party House Tech Ops Subcommittee has developed a proposal for a proposed transfer process. * Status: Potential Recommendations Under Consideration * Eliminate requirement for the Gaining Registrar to send the Gaining FOA and obtain consent from the Registered Name Holder before it may proceed with the transfer. * Eliminate requirement for the Losing Registrar to send the Losing FOA to the Registered Name Holder. * New notifications from the Losing Registrar to the Registered Name Holder when key changes are made to the account, some mandatory for the Losing Registrar to send, others optional. * Additional security for the AuthInfo Code, which the group is recommending be called the “Transfer Authorization Code” (TAC). Highlights: * ➔ Minimum requirements for TAC syntax/complexity, adherence to requirements confirmed by registry * ➔ Losing Registrar generates TAC upon request * ➔ TAC may only be used once * ➔ TAC is valid for a limited period of time (Time to Live) * ➔ Registry must securely store the TAC using a one-way hash that protects the TAC from disclosure * After the WG has reviewed the elements relating to single transfers, the WG will consider issues relating to bulk transfers. 3. Deliberations on Additional Security Measures (60 minutes) -- see: Additional Security Measures working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…> Overview: * Staff and leadership developed a chart of an overview of inter-registrar transfer locks following last week’s discussion. * To help everyone understand what locks we are talking about. * Where we are unsure of the origin of a lock staff has inserted an asterisk (*). * Looking for feedback to make sure this is complete and accurate. Discussion: * A lot of registrars apply locks by default to protect against unauthorized transfers. * Not all domain locking is an additional security measure – whether it prevents hijacking depends on good account security – it is a dependency. If you lose control of the account it doesn’t matter if there is a lock or not. Need to capture these details. * The key is if we say that there is a mandatory lock and if someone gets ahold of someone’s account, it doesn’t matter since it can’t be transferred for 60 days. It becomes a more difficult hack if you have to hack both the registrar and registry accounts. * The concern with these stated security features is that there is a relationship between them – we need to capture and recognize that. Challenging to talk about them in isolation. * Question: What do the asterisks mean? Answer: It denotes uncertainty on the staff support side as to the origin of a lock – indicating that the origin is a guess. * First row: If this lock that many registrars do upon creation: the charter question a6 is whether this should be mandatory or just allowed as it is today. Leaning towards keeping it optional, but focusing on trying to keep it as consistent as possible across registrars. * Is there an opportunity to get more information about the impact/concerns relating to inconsistency of application of locks? * The charter question being specific to this first row – seems that we have answered that, but we need to resolve the 60-day creation. * “Lock means a set of measures that a registrar applies to a domain name, which prevents at a minimum any modification to the registrant and registrar information by the Respondent, but does not affect the resolution of the domain name or the renewal of the domain name. (UDRP Rules, Section 1)” * The UDRP lock is different than EPP code clientTransferProhibited (which can allow change of registrant info). * There is an issue that some registrars may be imposing a UDRP lock that also locks the nameservers in place, which can prevent removal of allegedly infringing content etc. * Question: Any ideas on additional security measure we could be doing to improve this? Should we put in requirements around registrar and registry locks? * Question: Is this a place where people want to talk about multi-factor authentication? Answer: Not sure we want to include this in our policy. * Question: Is there a multi-factor piece of transfers that is possible? * We shouldn’t make assumptions about any one feature because they do have dependencies. * Multi-factor authentication is a security feature and if it is present it may help. We could note that it may or may not be present, and we could say something about it if it is present in transfers. We can mention that it adds to the security features if it is present. Different registrar models have different use cases for multi-factor authentication. * Should not make it too difficult for a registrar to do it if it wishes to use MFA. * In terms of scope and deliberation on additional security measures as they relate to transfer policy is in scope, although it might not be a consensus policy. Looking at the WG Guidelines there is nothing that would prevent the WG from providing implementation guidance. Perhaps there is language that is not consensus policy but could help the implementers. * What we could consider doing is for it to be allowed to have MFA on the TAC, but not on other actions. That would be in scope. * It’s important that we put boundaries on either side of this – can’t make it too easy to transfer a domain name but also can’t make it too hard. * Steinar Grøtterød-TPR Member (At-Large) to Everyone (2:46 PM): <COMMENT> I am in favor or adding wording that describes a requirement for registrars to make access to their control panel in a secure way. Of importance is also the distribution of the TAC to the Registrant/DNH. I find it strange that 2FA is enabled for accessing a control panel and then the TAC is sent in unsecured way (email).<COMMENT> * Question: Should we brainstorm a list of security measures? * Shouldn’t be prescriptive on the mechanism. ACTION ITEM: WG members to contribute to a list of additional security measures and provide other comments/suggestions in the Google doc for Additional Security Measures Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…>. 4. AOB (5 minutes) * Next meeting: In two weeks on Tuesday, 9 November 2021 at 16:00 UTC (no meeting next week).

1 0