- GNSO-TPR - lists.icann.org

Notes and action items - TPR WG Meeting #30 - 04 Jan 2022
by Julie Hedlund Jan. 4, 2022

Jan. 4, 2022

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, 11 January 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items -- See: TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> Recommendation 3: ACTION ITEM: WG to suggest/comment on the current language and suggest changes if any. Beth Bacon volunteered also to consult with the RySG. WG members to review the RFC at: https://datatracker.ietf.org/doc/rfc9154/ Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer. Recommendation 5: ACTION ITEM: WG members to review the recommendation and ask whether it helps to answer any of the charter questions or address a security issue. Recommendations 6 and 7: ACTION ITEM: WG members to provide suggestions for requirements for the one-way hash and Beth Bacon to use that information to consult with the RySG. WG members to review and comment on the suggested new wording combining recommendations 6 and 7. Recommendation 9: ACTION ITEM: Revise the recommendation to say that “The Working Group recommends that the TAC [MUST be used no more than once per domain name].” New text in brackets. Recommendation 11: ACTION ITEM: WG members to review 11.2 and consider whether to comment or suggest changes, and revisit at the next meeting. Transfer Policy Review Phase 1 - Meeting #30 Tuesday 04 January 2022 at 16:00 UTC 1. Roll Call & SOI Updates: * Kristian Ormen: Updating SOI to reflect changing jobs to ccNSO from the Registrar Stakeholder Group. Not sure when his replacement will join the TPR PDP WG 2. Welcome & Chair updates (5 minutes): No updates provided. 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: * Still looking for suggestions for revised language. * Should we be looking for a standard? Problem when all of the TLDs switch to backends. Then have to update to new requirements set by the registry. Any TLD can set any requirement if there is no standard. Better if there is a standard for all TLDs. * Could at least set bounds – but need to get wording that is consistent across all TLDs but allows flexibility. Don’t need to get more specific, or maybe the IRT can work out the details. * Re: wording about ICANN changing the requirements and concerns if the requirement is a policy, then there needs to be a policy making process, or at least involving the contracted parties. * Would like to go back to the registries to see if there is a technical reason to allow some flexibility. Beth Bacon volunteered to take this question back to the RySG. * Challenge to find some balance – a consensus policy recommendation can only be changed through a PDP. Not sure that was the intent for a purely technical requirement. Should be more prescriptive to make it easier for the IRT, but also to word it so that ICANN can make the changes. * Not sure we need “from time to time”. Reads more smoothy without it. Action is to delete it. (DONE) * Add “in collaboration with the Registrar and Registry Stakeholder Groups” for both mentions of ICANN Org. But might be helpful to better understand what “collaboration” means in this context and include then in the recommendation. The community would in any case be involved in setting the standards through the IRT. Would there be an IRT to update the standard too? * Would it not be better for changes to the standards happen via the IETF? Need to take a look at the RFCs relating to the TAC. Don’t know if any standards on the TAC at this time. Not sure the IETF is the best place. This there is a secure AuthInfo Code standard already out there. Need to check. * See the draft RFC at: https://datatracker.ietf.org/doc/rfc9154/ Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer – Seems to have a lot of what we are discussing. Maybe the contracted parties should review it. Recommendation 3: ACTION ITEM: WG to suggest/comment on the current language and suggest changes if any. Beth Bacon volunteered also to consult with the RySG. WG members to review the RFC at: https://datatracker.ietf.org/doc/rfc9154/ Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer. Recommendation 5: * These notifications need to be subject to standard EPP poll messages. * In general, don’t see how the notification is of any value. Think the recommendation in 5.2 will be exploited. Would be better if the registry also informs ICANN compliance. * Looking at 5.1 the notification sounds good on paper – any attacker could easily figure out how to stymie the notifications via DDoS. * Maybe need to make the investigation requirement more clear in 5.2. * Step back and look at the purpose of these requirements – operational goals. Think about if we were to remove this recommendation, would there be a gap in the goals of this PDP and the transfer policy? Consider whether this needs to stay in. * This seems to be more of an operational/user experience concept. Does it help answer the charter question? Does it address something that nothing else is resolving? Recommendation 5: ACTION ITEM: WG members to review the recommendation and ask whether it helps to answer any of the charter questions or address a security issue. [Additional Candidate Recommendation xx: If a Gaining Registrar requests a transfer and an inter-registrar transfer lock is in place, the transfer must not proceed.] * Question: Is this a requirement, or just a statement? Answer: The discussion around this was that when this occurs there could be different locks for different reasons and it’s up to the registrar of record (losing registrar) to resolve those issues. * There is an educational purpose – for the registrants to understand the different types of locks. * Is this useful – does it serve a purpose? * Is this overly broad? Could be used to block transfers. * This might be another case when we take a step back and ask what we are trying to achieve with a recommendation on this item. * Seems that we should park this one and see if we address it in another way. * We will come back to this on the 60-day lock discussion. Recommendations 6 and 7: * Discussion with leadership about whether to condense 6 and 7 in a logical manner. See revised suggested combination text. * Question: We set requirements around the TAC, but not on the one-way hash? Answer: That is true. Don’t know if we need to do so. * Maybe need to set some minimum level for the hash. * Could Beth Bacon go back to the registries to see if they have any comment on whether we need to set parameters for the hash. * If there are standards for the one-way hash it would be helpful if they could be included in the document. If Kristian or Theo could provide it. * 6.2 appears to be addressed by RFC9154. ACTION ITEM: WG members to provide suggestions for requirements for the one-way hash and Beth Bacon to use that information to consult with the RySG. WG members to review and comment on the suggested new wording combining recommendations 6 and 7. Recommendation 8: * Make sure the language is consistent with current ICANN policy, without referring to specifics. Do we need to point to the Temp Spec? Not sure if this recommendation is necessary. Recommendation 9: * Why do we have “may” instead of “MUST”? Change to “MUST” to be consistent with the rest of the recommendation? * Trying to say that you don’t want the same TAC for multiple domain names. * Could say “MUST be used no more than once”. * Could be problematic if the TAC is already used. Could cause operational issues. Don’t think it means the uniqueness, but per that domain – one time use only. * Maybe add “per domain name transfer”? Look at language we used elsewhere. * Prefer a requirement that the TAC needs to be randomly generated – think that goes back to recommendation 3 and the syntax of the TAC as well as the RFC. But perhaps that isn’t enough? * Seems we are saying that the registrar of record generates the TAC – check to make sure that is clear and also with reference to the uniqueness. * Definition of designated representative would be helpful. Some registrars or resellers may add provisions in the registration agreement forcing the RNH to agree that the account holder or the reseller may be a designated representative. Bearing in mind the fact that many registrants do not carefully read the registration agreements/Terms of Service before signing, this may lead to more unauthorized transfer complaints. ACTION ITEM: Revise the recommendation to say that “The Working Group recommends that the TAC [MUST be used no more than once per domain name].” New text in brackets. Recommendation 11: * Staff have suggested alternative language and added a footnote. * Drop “retain the ability”? Sounds like they MAY set the tac to null in those cases, rather than MAY be able to do so. * Think what we were trying to do was to allow a registrar and registrant to agree on automatic nulling. * RFC 9154 has information about TTL – that there is no current definition; flexibility on proprietary registrar criteria. * We used 120 hours for sending the TAC to the RNH, should we convert this to hours? Sound like 14 days is agreeable. Recommendation 11: ACTION ITEM: WG members to review 11.2 and consider whether to comment or suggest changes, and revisit at the next meeting. 4. AOB (5 minutes): Next call: Tuesday 11 January 2021 at 16:00 UTC

1 0

**On in 13 minutes** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 04 January 2022 at 16:00 UTC
by Julie Bisland Jan. 4, 2022

Jan. 4, 2022

**On in 13 minutes** 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 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/sb3srr8b__;!!PtGJab4!qEXiv7a…> 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, 04 January 2022 at 16:00 UTC
by Julie Bisland Jan. 3, 2022

Jan. 3, 2022

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 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/sb3srr8b__;!!PtGJab4!qEXiv7a…> 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 #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