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

Proposed agenda for meeting #30 on Tuesday 4 January 2021 at 16:00 UTC
by Emily Barabas Jan. 3, 2022

Jan. 3, 2022

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 4 January 2021 at 16:00 UTC. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #30 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 11 January 2021 at 16:00 UTC

1 1

ICANN Presents Estimated SSAD Costs and Fees to GNSO Council
by Julie Bisland Dec. 21, 2021

Dec. 21, 2021

https://www.icann.org/en/blogs/details/icann-presents-estimated-ssad-costs-… 21 December 2021 Göran Marby<https://www.icann.org/>, President and Chief Executive Officer (CEO) I'm pleased to announce that ICANN org has completed its assessment and potential design for the System for Standardized Access/Disclosure (SSAD) as a part of the Operational Design Phase (ODP). The Operational Design Assessment (ODA) is the final outcome of the ODP, which we expect to deliver to the ICANN Board and publish in February 2022. With this work, we have reached a significant milestone in supporting the Board's preparation to consider the Recommendations 1-18 of the Final Report [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/…> of the GNSO Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data Phase 2<https://community.icann.org/display/EOTSFGRD>. The Board is reviewing the draft ODA, which highlights some of the challenges inherent in the set of policy recommendations related to the SSAD. As work on finalizing the ODA continues, ICANN org and several Board members met [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/rec/play/Bf0Oxue4R9KAxaGqv…> with the Generic Names Supporting Organization (GNSO) Council on 20 December 2021 to brief them on the initial findings of the org's analysis. In that discussion with the GNSO Council, the SSAD ODP team presented<https://www.icann.org/en/system/files/files/ssad-odp-discussion-gnso-counci…> its overall findings of what will be required to implement the SSAD-related recommendations, including the estimated range of costs and fees, related assumptions and considerations, and noted strategic questions that the ICANN Board is considering. It was a useful and important opportunity to work together and engage with the GNSO council to discuss the findings and reasoning behind the design choices. When the GNSO Council adopted the EPDP Phase 2 Team's policy recommendations, they requested a formal engagement with the Board to further discuss the costs and benefits of the SSAD. The 20 December meeting was a first step as the org prepares to brief the full community on the costs and overall findings, and was meant to help prepare for the Council and the Board to engage in that cost/benefit analysis discussion. The next step will be a webinar<https://www.icann.org/en/announcements/details/register-for-icanns-next-ssa…> held by the SSAD ODP team for the community that expands on the presentation that was made to the GNSO Council on 20 December 2021. That webinar will take place 18 January 2022 at 1500 UTC. After the community webinar on the SSAD costs and overall findings, the Council and the Board will discuss the costs and benefits of the SSAD. The Board and I are eager to discuss these findings with the Council and engage in a dialogue with the community. As such, the Board will discuss the next steps during the upcoming Board Workshop, and engage with the Council on the planned formal consultation following the community webinar that will expand upon the findings presented to the GNSO Council. Click here<https://www.icann.org/en/announcements/details/register-for-icanns-next-ssa…> for more information on how to register for this webinar. If you would like to provide input or ask questions, I encourage you to attend the webinar, which will provide information presented to the GNSO Council in more detail. -- Julie Bisland Policy Operations Sr. Coordinator (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: 79613b691cb8a6c1 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

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

Dec. 21, 2021

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 21 December 2021 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/gwiHCg> (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, 04 January 2022 at 16:00 UTC
by Julie Bisland Dec. 21, 2021

Dec. 21, 2021

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

Dec. 21, 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, 04 January 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items Recommendation 3: ACTION ITEM: WG to suggest/comment on the current language and suggest changes if any. Recommendation 5: ACTION ITEM: For recommendation 5.1 revise the recommendation to remove the second bullet. ACTION ITEM: For recommendation 5.2 the WG to review and suggest revisions. Transfer Policy Review Phase 1 - Meeting #29 Tuesday 21 December 2021 at 16:00 UTC 1. Roll Call & SOI Updates: No updates provided. 2. Welcome & Chair updates (5 minutes) * There will not be a WG meeting on 28 December. * The Project Change Request was approved by the GNSO Council on 16 December to move NACKs from Phase 2 to Phase 1a. The Project Plan and charter are updated. * Update from Jim Galvin, RySG: drafted a summary about including the IANA ID about including it in the Registrar of Record. Several ways that information could be provided. Whatever choice will impact registrars. The RySG will present a proposal to the registrars via the Tech Ops group with the result to feed into the WG’s discussion. * Would be useful to have the various options presented to the WG. * Jim noted that several WG members will be involved in the Tech Ops discussions, but he will make sure that the WG will be in the loop. 3. Second reading: TAC and FOA (45 minutes) TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> (beginning on p. 15) Recommendation 3: ACTION ITEM: WG to suggest/comment on the current language and suggest changes if any. Recommendation 5.1: * What are we trying to solve with this recommendation? Is it brute-force attacks? Or a user issue? Or both? * Should we ask the Registry Stakeholder group whether brute-force attack is really a problem? Registries would have the most information. If they see this as a possible problem then we need to address it. * Staff was doing some thinking about this and wondering how much of an issue brute force is. Maybe it was more of an issue when the TAC is generated with registration, but not with the recommendation to have the TAC generated on request. We have changed the TAC considerable from how AuthInfo works today based on our recommendations. * Jim Galvin RySG: Never heard another registry talk about it. This is more of an ordinary operational issue for a registry. They monitor their systems. If a registrar is doing brute-force attacks it isn’t going to tell anyone/no registrar will see it. Only the registry can see it. This doesn’t need attention. Don’t think we will get any information by asking registries. * Let’s assume that this is not a brute-force recommendation but a user experience recommendation. We should clean it up accordingly. * Shouldn’t the Gaining Registrar get a notification? They should be notified, but that should be covered in the normal operations. * Not sure we need a notification for every successive failure. * From a user experience point of view we should think about the right way to handle this. Maybe the path is what the registry does after X failed attempts it disables the transfer, negates the code, and tells the registrar that transfers aren’t allowed. For the user experience consider what type of action you want to get the situation fixed? * Combine bullets 1 and 2: As an alternative to “successive attempts” – after the 5th and every 5th after that the registry sends the notice to the Registrar of Record. * We don’t have any data on how often this happens. * We are trying to give the best user experience around the transfer. * In favor of data that would support a certain number of failed attempts. * If we’re wanting to provide notice to the RNH, a single notice after a # of failures would suffice. The question then becomes what that # is. * Helpful to improve the registrant experience, but one notification should be enough. * Think about what problem we are trying to solve. The Registrar of Record needs to know that an invalid TAC is presented if they have no knowledge that a domain name is transferable. The onus falls on the Gaining Registrar to deal with invalid TACs. It might be helpful to present one notification to the Registrar of Record, but otherwise there isn’t a need for anything further. * If the Losing Registrar gets a notice (as the Registrar of Record) that an invalid TAC was provided to the RNH then the Losing Registrar will want to get in touch with the Gaining Registrar and to notify the RNH as good customer service. * Should we add language that talks about what happens if the registry fails it where there’s a lock? Does it matter why the registry is failing the transfer. * What happens when the TAC exists with a lock? If a domain name is locked and you can’t set a TAC, that will create operational issues. * Think we all know that there is an intersection between transfers and locks. There is a user experience issue to be addressed here. Can locks be present if you set a TAC? How would a registry make the distinction between a lock that makes a domain name transfer eligible and one that doesn’t. You want a lock on to protect until the transfer. From a registry point of view some registries offer lock services and registrars also offer them. What happens when you have both? We haven’t played all of the scenarios. * Seems that the lock overrides everything. Should the TAC be able to be set at the registry with the lock on? Can a lock be put on if there is a TAC? Would the lock override the TAC? * A lock should be able to be placed on the domain even if a TAC is set for the domain. * But then how do you effect the transfer? How does a registry know it’s valid? * Today’s policy says the Registrar of Record has to remove the locks within 5 days or allow the RNH to remove them. * If the TAC matches and the domain is unlocked, it’s a valid request. * The registrar has to remove their locks for a domain name to be transfer eligible. * The policy needs to say something about the registry removing its locks when presented with a valid TAC. * Don't think the registry should even check the TAC if the domain is locked. * It's an order of operations really: Is domain locked? Yes, deny transfer request. No, check TAC. * No reason to check the TAC if it’s locked. * Could be that there is a step to be taken if the domain name is locked. * There are other reasons (like court orders) that domains can be locked. We need to recognize that at the registry or registrar. Don’t think that we have to differentiate too much. The registrant still has to go back to the Registrar of Record to resolve that lock. That covers all the locks we are talking about. * Think that the Registrar of Record has to be responsible for resolving all locks that they were a party to before they set a TAC. Leaves open the possibility that if the registry has it locked then the Registrar of Record may not know. That should be addressed too. * Three scenarios: Registrar or Record can resolve just by explaining to the RNH that there’s a lock. Resolve may not be to the transfer. * It may be that the manual process has to transfer from the Registrar of Record to the Gaining Registrar. The Registrar of Record should not be obligated to notify the RNH of a lock that it doesn’t know about. * Policy has to say that the registry has to account for the transfer process in the case of a commercial lock. * Think we have the basic framework: Is domain locked? Yes, deny transfer request. No, check TAC. Need to put in place where the difference decisions/triggers happen. ACTION ITEM: For recommendation 5.1 revise the recommendation to remove the second bullet. Recommendation 5.2: * Maybe an intermediate step – need to clear out the language and somehow put that in place of the Registrar of Record has to take action. * Don’t think the Registrar of Record should have to reach out (MUST). Could be changed to MAY. But this help ICANN Compliance to follow up, such as a requirement to document? * If we set this to 5 attempts and the Registrar of Record sees it but it is successful after that, maybe the Registrar or Record could just note that in its investigation in case Compliance follows up. * Do we have data that justifies this recommendation? What are we trying to solve here? * The purpose is for the user experience to be consistent and predictable for the registrant. * Maybe it should be that the Registrar of Record MAY notify the RNH or investigate. Or just leave as MAY investigate. Don’t make either one more important. Maybe once you investigate you decide you don’t need to notify. * If you have the option to notify or to investigate, then you can choose what to do. * No sense in creating a requirement that can’t be enforced. * Maybe a way to get out of this: Instead of 5.2 this could be changed to an implementation note to accompany this section that for notifications in 5.1 the Registrar or Record should investigate and notify as necessary. * Even if it’s a implementation note isn’t it still a requirement? * If we make it a MUST but a big OR – between investigation and notification that addresses enforcement. * If we use SHOULD or MAY then there is no way to check compliance. * Make sure the language is crystal clear. ACTION ITEM: For recommendation 5.2 the WG to review and suggest revisions. 4. AOB (5 minutes): Next call: Tuesday 4 January 2021 at 16:00 UTC

1 0

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

Dec. 21, 2021

**ON IN 15 MINUTES** 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 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/gwiHCg * Check your time zone: https://tinyurl.com/26vjzu4h <https://urldefense.com/v3/__https:/tinyurl.com/26vjzu4h__;!!PtGJab4!q2n5UEg…> 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, 21 December 2021 at 16:00 UTC
by Devan Reed Dec. 20, 2021

Dec. 20, 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 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/gwiHCg * Check your time zone: https://tinyurl.com/26vjzu4h <https://urldefense.com/v3/__https:/tinyurl.com/26vjzu4h__;!!PtGJab4!q2n5UEg…> 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

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

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

Dec. 7, 2021

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 07 December 2021 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/fwiHCg> (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

Notes and action items - TPR WG Meeting #27 - 07 Dec 2021
by Julie Hedlund Dec. 7, 2021

Dec. 7, 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, 14 December at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items Revisit TAC recommendations (60 minutes) – see: TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> (beginning on p. 15) Recommendation 1: Revise text to (new text in brackets): “The Working Group recommends that the Transfer Policy and all related policies use the term “Transfer Authorization Code (TAC)” in place of the currently-used term “AuthInfo Code”[ and related terms].” Recommendation 2: Revise the wording (new text in brackets) to ““A Transfer Authorization Code (TAC) is a token created by the Registrar of Record and provided upon request to the registrant or [their designated representative.] Change “registrant” to “Registered Name Holder” throughout. Recommendation 3: WG members to suggest alternate/revised language. Recommendation 4: Change “created” to “stored”. Recommendation 5: WG to review revised text as suggested: “The Working Group recommends that the Registry notify the Registrar of Record after the Gaining Registrar has made [3-5] failed attempts to present a valid TAC to the Registry for a domain name, and for each successive failed attempt as long as a TAC is present. The Registrar of Record must notify the registrant that the failed attempts have taken place, and may take additional action, for example resetting the TAC.” Recommendations 6-11: WG to review and comment. Transfer Policy Review Phase 1 - Meeting #27 Tuesday 07 December 2021 at 16:00 UTC 1. Roll Call & SOI Updates * No updates provided. 2. Welcome & Chair updates (5 minutes) * Owen Smigelski: Questions about registrar type in the survey. Provided responses grouped by type and size. See attached. There are several types and we had responses to the survey from several different types and sizes. Could not correlate between type and size. Did seems to be more support for having locks than not, but could not correlate that response by type or size. 3. Rationale for elimination of the Gaining FOA (15 minutes) – see: Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> (beginning on p. 16) * Have not seen comments on the final revisions. We will read it out to see if there are more comments. We will come back to it so we aren’t done yet. * In October the WG agreed that we would draft a summary of the discussion on the elimination of the Gaining FOA. * We provided some of the background for context. Discussion: * Question: Why do we say this? “The Working Group believes that the notifications detailed in recommendations [xxx-xxx] ensure that the Registered Name Holder receives the necessary information when a key change has been made to their account.” This is no longer true based on current discussion. Answer: We have updated the text to reflect the recent discussion in the Losing FOA document and we’ll update the language here to be consistent. 4. Revisit TAC recommendations (60 minutes) – see: TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> (beginning on p. 15) * We updated this to no longer be candidate recommendations since we’ve reviewed it several times – now these are draft recommendations. * Not every charter question ended up with a recommendation. Charter Question b1) Is AuthInfo Code still a secure method for inter-registrar transfers? What evidence was used by the Working Group to make this determination? Recommendations 1-5: Recommendation 1: * Big change was to eliminate the confusion over terminology. * As an editorial comment – in place of the currently used term also add “and related terms” to be more inclusive. Don’t want to lose the opportunity to cover everything appropriate. ACTION ITEM: Revise text to (new text in brackets): “The Working Group recommends that the Transfer Policy and all related policies use the term “Transfer Authorization Code (TAC)” in place of the currently-used term “AuthInfo Code”[ and related terms].” Recommendation 2: * Are we consistent in terminology throughout when referencing the registrant? Should we be using Registered Name Holder? * Registrant and admin are the only ones authorized. * Registrant is not necessarily the account holder. Good to show the ultimate decision maker as the registrant. * Suggest change to “registrant or [their] designated representative” – new text in brackets. Need to be mindful of how this policy will work with the transfer dispute policy. * Some registrars use a designated agent for a transfer, so “designated representative” is still accurate. * The Definition should not exclude other security mechanisms. * Avoid using the administrative contact language since that is going away. * Question: To be precise, the admin contact in RDDS is going away, but is it conceivable that via the account panel that the RNH will assign a non-RDDS admin contact? How does a RNH go about designating that person? Answer: Could be that their provider that allows a log in for the account that provides access to certain things – they could give that info to a representative, but we shouldn’t get too specific here. * The sole Point is to reach the registrant, so we do not need to define the various opportunities. So, “send to the registrant” is sufficient. * Change “registrant” to Registered Name Holder” throughout? ACTION ITEM: Revise the wording (new text in brackets) to ““A Transfer Authorization Code (TAC) is a token created by the Registrar of Record and provided upon request to the registrant or [their designated representative.] Change “registrant” to “Registered Name Holder” throughout. Recommendation 3: * Question re: “ICANN org may change these requirements from time to time in response to new or updated standards, but any changes to the requirements must go in effect with sufficient [notification and] time for registrarsregistries to implement the necessary updates.” Is it normal for ICANN Org to establish this type of requirement? * If this were a protocol issue those statements would be done in the IETF. This is a security requirement. IETF is a source we can go to for this. Could be a statement that it “should be based on applicable security standards” and add a reference. * The key here is that ICANN would be initiating it – should other parties be able to initiate? * In the last sentence, change “registrars and registries” to “contracted parties”. * See IETF language at: https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-transfer/ ACTION ITEM: WG members to suggest alternate/revised language. Recommendation 4: * Suggest it should say “stored” or “set” rather than “created”. ACTION ITEM: Change “created” to “stored”. Recommendation 5: * May need to look at this recommendation again for bulk transfers. * Question: Are we failing to set a new TAC, or providing the wrong TAC? Answer: We need to revise the language to make it clearer. * Question: If we are setting the number of failed attempts as a trigger, can ICANN Org change it later? Or is that a policy change? * Question: Should we set a period of time? * If you want to detect brute-force attempts then we should make that clear. Brute force was one example, could also just be a system error. * Could change to: “The Working Group recommends that, if the Gaining Registrar presents an invalid TAC [$number] times, or [$number within $period] times, the Registry MUST notify the Registrar of Record of the invalid attempts.” * Comment: from a security perspective – from the principle of wanting to provide protection to the registrant in this case there may be a malefactor involved so we are trying to provide an extra layer of protection. If everything is working as it should then the only risk here is that the value has been mis-entered. We should put a number here; a small number of attempts. Something to think about is the transfer should not be allowed if you have entered X number of failed attempts. Maybe the registry disables the transfer and make them go to get another TAC. * One thing to keep in mind, in order for this system to work if the registry is going to be telling you something it should be required – “MUST” not “MAY”. As a security mechanism using “MUST” makes more sense. * Number of failed attempts could be between 3-5. * Recalling earlier discussions: there were originally two formations of this recommendation. It sounded like the recommendation to cancel the transfer was not selected because it would be a way to derail a transfer. * If after the failed attempts (3 or 5), a notification to the registrant is sufficient. I think changing it automatically isn’t a good idea, as it’s done its job. * Clarify that this is per domain (issue of bulk transfers). * From a security perspective if you aren’t going to disable the transfer then you could force a reset; if you don’t want to do that you should say that the registry after X number of attempts an any attempt that failed you MUST send a notification. * A notification is sufficient of the failed attempts. * Suggest, “registrar of record MUST notify the registrant and MAY take further action such as resetting the TAC.” If we do say the registrar MUST notify we should decide if we need to provide a template for that communication. * What is the process for changing the number of failed attempts? If we put a number here do we need policy to change it? Maybe suggest a number to the IRT that they can update. ACTION ITEM: WG to review revised text as suggested: “The Working Group recommends that the Registry notify the Registrar of Record after the Gaining Registrar has made [3-5] failed attempts to present a valid TAC to the Registry for a domain name, and for each successive failed attempt as long as a TAC is present. The Registrar of Record must notify the registrant that the failed attempts have taken place, and may take additional action, for example resetting the TAC.” 5. AOB (5 minutes) * Next call: Tuesday 14 December 2021 at 16:00 UTC

1 0

15 MINUTES | **REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 07 December 2021 at 16:00 UTC
by Devan Reed Dec. 7, 2021

Dec. 7, 2021

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

1 0

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 07 December 2021 at 16:00 UTC
by Julie Bisland Dec. 6, 2021

Dec. 6, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 07 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/fwiHCg * Check your time zone: https://tinyurl.com/2p83v35x [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2p83v35x__;!!PtGJab4!pfyUo3b…> 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, Devan

1 0

Proposed agenda for meeting #27 on Tuesday 7 December 2021 at 16:00 UTC
by Emily Barabas Dec. 6, 2021

Dec. 6, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 7 December 2021 at 16:00 UTC. In addition to reviewing the latest versions of the resources linked below in the agenda, please note that the Losing FOA recommendations have been updated based on feedback during last week’s call (see Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> beginning on p. 14). Please take a few minutes to review and provide any feedback you may have. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #27 Proposed Agenda Tuesday 7 December 2021 at 16:00 UTC 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 1. Rationale for elimination of the Gaining FOA (15 minutes) * Gaining FOA Working Document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…> (beginning on p. 16) 2. Revisit TAC recommendations (15 minutes) * TAC Working Document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…> (beginning on p. 15) 3. AOB (5 minutes) * Next call: Tuesday 14 December 2021 at 16:00 UTC

1 1

RrSG survey re: domain locks
by Owen Smigelski Dec. 3, 2021

Dec. 3, 2021

Hi all, Attached is the document I shared during Tuesday’s meeting regarding RrSG member feedback regarding domain name locks at creation and transfer. As requested, I added a breakdown by registrar type and size. I was not able to find any correlation between either registrar size or type and the preferred lock period. Please let me know if you have any questions. Regards, Owen

1 0

TPR-P1 // 30 Nov 2021 Project Package
by Berry Cobb Dec. 2, 2021

Dec. 2, 2021

Dear WG, Please find a link below to project package for the TPR-P1 PDP (30 Nov 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. * A PCR has been submitted to Council to include the NACK policy topics from Phase 2 into Phase 1A. 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