April 2022 - GNSO-TPR - lists.icann.org

suggested text for TAC composition
by James Galvin April 29, 2022

April 29, 2022

At our last meeting on 26 April, I agreed to provide some suggested text for the composition of the TAC. I have attached a PDF document with my suggestions. I use the plural because it turns out that specifying minimum requirements for the TAC effects 3 preliminary recommendations, #7, #9, and #11. In the attached document I have highlighted my suggestions, and included the appropriate references. Unfortunately I will not be able to attend the next two meetings of the PDP, although I will be available via email to answer any questions or concerns that can not wait until my return on 17 May. Thanks, Jim

1 0

Draft Initial Report - Input Due 14 May 2022
by Emily Barabas April 29, 2022

April 29, 2022

Dear working group members, As discussed on Tuesday’s call, staff had an action item to provide the draft Initial Report to the Working Group today for review. Please see the draft attached. Please carefully review this draft Initial Report in coordination with the groups you represent. If you feel that there are items that need to be revised, please enter them here<https://docs.google.com/document/d/1s9xumJ1XBPdTb7kQmc5sAC2AkszvfAF0freMvnx…>. For each item, please include: * Report version (the date listed in the header of the Initial Report draft) and applicable line numbers ( these are listed along the left margin of the document). * Name and group you represent: If multiple WG members represent a group, input should be in coordination with these other members. * Rationale: please provide a clear explanation for why you are proposing the revision. * Specific proposed revision: Provide the language you would like to see added/removed/edited. The deadline for submitting input is 14 May 2022. After the deadline, the working group will spend the following four working group meetings reviewing the items submitted in the input document. If your groups are unable to provide input by 14 May, feedback on the Initial Report can be provided during the public comment period. As you review, please note that some sections of the report are highlighted: * Text highlighted in purple is relatively new and should be reviewed closely. * Text highlighted in orange is still under discussion and may change. * Yellow highlights are administrative in nature can be ignored. Please do not hesitate to reach out with any questions about the review process. Kind regards, Caitlin, Julie, Berry, and Emily Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org [nam10.safelinks.protection.outlook.com]<https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…>

1 0

Pre-Reading and Proposed agenda for meeting #45 on Tuesday 3 May 2022 at 16:00 UTC
by Emily Barabas April 28, 2022

April 28, 2022

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 3 May 2022 at 16:00 UTC. Before the meeting, please review the draft recommendations on NACK Charter Question h1 produced by the small group (see working document pages 16-23 here<https://docs.google.com/document/d/1L2bZnhJUY3VxyAjVCrkyVqdttOPn2EaqBARRRnE…>) Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #45 Proposed Agenda 1. Roll Call & SOI updates 2. Welcome & Chair updates 1. Draft recommendations on NACK Charter Question h1 produced by the small group (see working document pages 16-23 here<https://docs.google.com/document/d/1L2bZnhJUY3VxyAjVCrkyVqdttOPn2EaqBARRRnE…>) 2. AOB * Next call: Tuesday 10 May 2022 at 16:00 UTC

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 26 April 2022
by Julie Bisland April 26, 2022

April 26, 2022

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 26 April 2022 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/MhAiCw> (attendance included) and the GNSO Master calendar <https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> . These include: * Attendance * 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, 03 May 2022
by Julie Bisland April 26, 2022

April 26, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 03 May 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/4BB1Cw * Check your time zone: https://tinyurl.com/mt3pwwny ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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 #44 - 26 April 2022 at 16:00 UTC
by Julie Hedlund April 26, 2022

April 26, 2022

Dear TPR WG Members, Please find below the notes and action items from today’s meeting. The next TPR WG meeting will be on Tuesday, 03 May 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: Discussion of Outstanding Items on TAC: 1. Recommendation 7 (TAC Security) Jim Galvin to suggest revisions to Sarah Wyld’s suggested text for WG members to review. 2.. Additional Candidate Recommendation xx under CQ b1 -- Staff to delete the recommendation. 3. Formerly Recommendation 6, now Recommendation 9: SME input on Recommendation 6.2: Jim Galvin to suggest some functional language for WG review. 4. Recommendation 13 --- Jim Galvin and Rick Wilhelm to consult with the RySG and either provide suggested alternative language or a rationale for why this recommendation should not be included. Previous Action Items: 1. WG members are encouraged to review the overview of proposed response to Charter Question h2 (see page 13 and 14 here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…>) and provide comments and/or suggestions. 2. WG members are encouraged to review the overview of proposed responses to EPDP Phase 1, Recommendation 27 “Wave 1” Report items (see document here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1ZLkSqD2bHDBo…>) and add comments in the column “Additional Notes/Discussion”. 3. Staff to suggest a definition along the lines of Designated Agent as referenced in the COR. Could say, “Working Group understands the Designated Representative to mean an individual or entity that the Registered Name Holder explicitly authorizes to obtain the TAC on their behalf.” Notes: Transfer Policy Review Phase 1 - Meeting #44 Tuesday, 26 April 2022 at 16:00 UTC Proposed Agenda 1. Roll Call & SOI updates 2. Welcome & Chair updates * Next few weeks will have quite a bit of reading in between our regular sessions. Staff are ramping up production of our documents for review. * Good time to touch base with your SGs/Cs so that if anyone has any comments or concerns let’s get them documented over the next two or three weeks, so that we can get the Initial Report wrapped up. 3. Upcoming milestones and deliverables for Initial Report: Initial Report Delivery 15 June 2022: * To the extent that SO/AC/SG/Cs want to provide input on the proposed recommendations to be included in the Initial Report, now is the time to provide that input through their members. * Members should be coordinating with the groups they represent. * If unable to provide input in the next three weeks, SO/AC/SG/Cs will have an additional opportunity to provide input during the public comment period on the Initial Report. Key Dates: * 29 April: Working Group members receive full draft of Initial Report for review. * 14 May: Deadline for member input on full draft of Initial Report. * 2 June: Community Webinar on Initial Report proposed recommendations. * 15 June: Publication on Initial Report for public comment. Upcoming Working Group Meetings: 3 May 2022 NACK 10 May 2022 Post-registration and post-transfer locks; Additional security measures 17 May 2022 Review of outstanding items 24 May 2022 Review of outstanding items 31 May 2022 Review of outstanding items 7 June 2022 Review of outstanding items 13 June 2022 ICANN74 session – Introduction to Change of Registrant (COR) - Phase 1(b) Highlights: * Highlight the fact that this is an Initial Report so there will be the opportunity to provide comments during the public comment period, if not before. Preferably WG members should liaise with their groups and provide any comments or concerns before the Initial Report is finalized. * Staff sent draft recommendations and the boilerplate language for the Initial Report for review. Can use line numbers to reference. * 29 April: WG members to receive full draft of the Initial Report for review for two weeks. * The two weeks are for the big type of items in the draft recommendations that the WG has been discussing for a while and the WG members should have been liaising on these during discussions, not at the end of discussions. * Note that we are avoiding using the term “lock” but instead referencing a restriction on transfers. 4. Discussion of Outstanding Items on TAC (see summary in tab 1 here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1VAeYHzXu…> and working document pages 15-19 here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…>) Row 11 -- Formerly Recommendation 3, now Recommendation 7 -- From Sarah Wyld, suggested text for Recommendation 7 (TAC Security) – See recent email: Here is the current shared draft text [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…>: The Working Group recommends that ICANN org establish minimum requirements for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards. ICANN org may change these requirements in response to new or updated standards, but any changes to the requirements must go in effect with sufficient notification and time for contracted parties to implement the necessary updates. Here is my suggested updated version: The Working Group recommends that Registrars and Registry Operators follow best practices for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards such as RFC9154 or subsequent or similar RFCs. These best practices may be updated in response to new or updated standards as appropriate. Discussion: * Remove ICANN org as setting the standard? Who is in charge of updating/maintaining the best practices? * How to use the RFCs and keep them updated? * There are two things going on – like the text in principle but it needs to be split. Jim Galvin will propose some text. First, concerns around how randomness is done and to capture that properly. The other thing with 9154 is it is about being able to exchange the new TAC value between the registrar and registry, as well as TAC management (with reference to randomness RFC 4086). This is a technical issue that we need to call out. WG members should consider this. See RFC 9154 at: https://datatracker.ietf.org/doc/html/rfc9154#section-4.3. * Need to think about enforceability or compliance. How would ICANN org make sure that contracted parties are meeting the requirements of best practices. Needs to be enforceable. * Maybe there should be some mention that ICANN org could moderate? * Not sure that every requirement in contracts is testable by compliance. * Question: Don’t think we’ve settled yet on the issue of one TAC per domain name. Talked about multiple/bulk transfers – did we settle on having on TAC per package? Answer: We have settled on one TAC per domain; have some language to consider from Sarah on one TAC per package, so this is still an open item. * Need to make sure that we highlight the security implications of having one TAC per multi-domain transfer. * There is a gray area of implementation of technical standards. There is no specific enforcement of RFCs, so not sure what ICANN org could do if there was a transfer incident. * We can ask Steve Crocker on behalf of the SSAC, but they don’t really have a process to provide quick input on random topics. We need to be careful because these are commercial topics that impact the registry/registrar businesses. Maybe get feedback from TechOps and then see if there is an open item. * Might need to make clear if there isn’t agreement that this isn’t a consensus policy. * As a reminder, we are pointing to this recommendation as part of the justification for removing requirements for the Losing and Gaining FOA. ACTION ITEMS: Recommendation 7 (TAC Security) Jim Galvin to suggest revisions to Sarah Wyld’s suggested text for WG members to review. Row 12 -- Additional Candidate Recommendation xx under CQ b1: If a Gaining Registrar requests a transfer and an inter-registrar transfer lock is in place, the transfer must not proceed. * Don’t think we need a recommendation on this. * Question: Are we talking about ClientTransferProhibited or ServerTransferProhibited? Answer: Maybe both? * Question: Thought that registry locks were out of scope? Answer: It shouldn’t matter – it’s up to the registrar to resolve the lock. * Shouldn’t use the word “stop”. * We do have a recommendation in denial of transfers/NACKing that could address this – but that is on the sponsoring side, not the gaining side. * If a registry lock is out of scope then there can’t be a recommendation that says if there is a registry lock then you can’t transfer. * Think that there is some agreement for dropping this recommendation. ACTION ITEM: Additional Candidate Recommendation xx under CQ b1 -- Staff to delete the recommendation. Row 13 -- Response to CQ b2: Compliance input: For Contractual Compliance to be able to enforce the requirements, all requirements must be clearly enumerated and described within the text of the policy. * This is a general comment. * No need to revise. Row 14 -- SME input on Recommendation 6.2: The Registry MUST securely store the TAC per the requirements specified in recommendation 3. Recommendation text: “When the Registrar of Record sets the TAC at the Registry, the Registry MUST securely store the TAC using a one-way hash that protects the TAC from disclosure.” * Misunderstanding in reading the recommendation – no need for a change to the recommendation. * One-way hash means the registry stores it, but can’t recover it. * Including the specific requirement of a “one-way hash” is inconsistent with the goal to not be prescriptive. We don’t go into details in other handling of the TAC. * Suggested language from Jim Galvin: “the policy should speak to the functional requirement of cryptographically protecting the TAC such that its value cannot be recovered or disclosed once stored.” * #2 gets into more detail. And there are also security requirements for TAC handling that (should) exist for registrars. ACTION ITEM: Formerly Recommendation 6, now Recommendation 9: SME input on Recommendation 6.2: Jim Galvin to suggest some functional language for WG review. Row 15 -- input on Recommendation 6.3: Compliance recommends detailing how this information must be provided and that the provision of this information must be documented. Recommendation text: “When the Registrar of Record provides the TAC to the RNH or their designated representative, the Registrar of Record MUST also provide information about when the TAC will expire.” * Don’t have to tell the Registrar of Record how they have to track when the TAC will expire. So no recording requirement. * No need for changes to the recommendation. Row 16 -- SME input on Recommendation 6.3: Consider developing standard easy to understand language for registrants around this additional info about when the TAC will expire, etc. * No need for changes to the recommendation. Row 17 -- Formerly Recommendation 9, now Recommendation 11: Compliance input: If this is an obligation to be added to the Transfer Policy for registries, Compliance recommends that the text in the policy explains what “clear” means (what actions this entails) so that Compliance is able to enforce it against registries where applicable. Recommendation text: “The working group recommends that the TAC MUST be “one-time use.” In other words, it MUST be used no more than once per domain name. The Registry Operator MUST clear the TAC as part of completing the successful transfer request.” * It should be clear to the RNH, but the registrar can figure out how best to explain it. * No need for changes to the recommendation. Row 18 -- Formerly Recommendation 11, now Recommendation 13: SME input on Recommendation 11.1: Suggestion to use hours instead of calendar days to avoid confusion. Recommendation text: 13.1: A standard Time to Live (TTL) for the TAC MUST be 14 calendar days from the time it is set at the Registry, enforced by the Registries. 13.2: The Registrar of Record MAY set the TAC to null: · At any time in response to a request from the RNH. · After a period of less than 14 days by agreement by the Registrar of Record and the RNH. * Not sure when we settled on this text with respect to registries. The problem is that one of two things have to be true: registrars won’t have any information why this failed, and someone will have to do some research. You will want to talk to the registry to see what happens, but this means that the registry will have to keep logs. Don’t think registries are comfortable with this. * Another alternative if the registries could reject a transfer if the user didn’t provide an AuthInfo code or presented an expired TAC, then they would have to track the time stamp and reason rejection. ACTION ITEM: Recommendation 13 --- Jim Galvin and Rick Wilhelm to consult with the RySG and either provide suggested alternative language or a rationale for why this recommendation should not be included. 5. AOB * Next call: Tuesday 3 May 2022 at 16:00 UTC

1 0

**On in 15 minutes** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 26 April 2022
by Julie Bisland April 26, 2022

April 26, 2022

**On in 15 minutes** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 26 April 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/MhAiCw * Check your time zone: https://tinyurl.com/53s57jmh [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/53s57jmh__;!!PtGJab4!tfUiVud…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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

For WG Review: All draft recommendations and Initial Report "boilerplate" language
by Emily Barabas April 25, 2022

April 25, 2022

Dear Working Group members, As discussed on our recent calls, staff has an action item to consolidate all preliminary recommendations in a single document to support your review and consideration of the TPR recommendations package as a whole. You can find the document here<https://docs.google.com/document/d/1clAqB1wBeOf9ZC5RMMxKrrUTs3N2WyaVYTIyVy_…>. To assist with version control, please use this version as a reference but do not comment or redline directly in the document. On tomorrow’s call, we will discuss methods that the WG will use for additional input on the recommendations going forward. In addition, to help members get a head start on reviewing the Initial Report, staff is providing a PDF version of the “boilerplate” portions of the Initial Report. This document gives you a sense of the structure of the report and the sections that will be included. Staff has filled in text for the standard sections including background, methodology, membership, etc. If, in reviewing this boilerplate text, you think edits are needed, please enter them here<https://docs.google.com/spreadsheets/d/1NwOtAOal-emcaRTr__ic0vOlQoitNUp8zoh…>. Kind regards, Caitlin, Julie, Berry, and Emily Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 26 April 2022
by Julie Bisland April 25, 2022

April 25, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 26 April 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/MhAiCw * Check your time zone: https://tinyurl.com/53s57jmh [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/53s57jmh__;!!PtGJab4!tfUiVud…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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

Suggested text for Rec 7 (TAC Security)
by Sarah Wyld April 25, 2022

April 25, 2022

Hello Team, I am here to propose new text for our Recommendation #7 (was #3) which sets out security requirements for the TAC. Here is the current shared draft text: The Working Group recommends that ICANN org establish minimum requirements for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards. ICANN org may change these requirements in response to new or updated standards, but any changes to the requirements must go in effect with sufficient notification and time for contracted parties to implement the necessary updates. Here is my suggested updated version: The Working Group recommends that Registrars and Registry Operators follow best practices for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards such as RFC9154 or subsequent or similar RFCs. These best practices may be updated in response to new or updated standards as appropriate. Or if redline is preferred: The Working Group recommends that ICANN org establish minimum requirements Registrars and Registry Operators follow best practices for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards such as RFC9154 or subsequent or similar RFCs. These best practices may be updated ICANN org may change these requirements in response to new or updated standards as appropriate, but any changes to the requirements must go in effect with sufficient notification and time for contracted parties to implement the necessary updates. This has been discussed (with generally positive sentiment) in the CPH TechOps team. Thank you! -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld(a)tucows.com

1 0

Suggested text for Rec 7 (TAC Security)
by Sarah Wyld April 25, 2022

April 25, 2022

Hello Team, I am here to propose new text for our Recommendation #7 (was #3) which sets out security requirements for the TAC. Here is the current shared draft text: The Working Group recommends that ICANN org establish minimum requirements for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards. ICANN org may change these requirements in response to new or updated standards, but any changes to the requirements must go in effect with sufficient notification and time for contracted parties to implement the necessary updates. Here is my suggested updated version: The Working Group recommends that Registrars and Registry Operators follow best practices for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards such as RFC9154 or subsequent or similar RFCs. These best practices may be updated in response to new or updated standards as appropriate. Or if redline is preferred: The Working Group recommends that ICANN org establish minimum requirements Registrars and Registry Operators follow best practices for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards such as RFC9154 or subsequent or similar RFCs. These best practices may be updated ICANN org may change these requirements in response to new or updated standards as appropriate, but any changes to the requirements must go in effect with sufficient notification and time for contracted parties to implement the necessary updates. This has been discussed (with generally positive sentiment) in the CPH TechOps team. Thank you! -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld(a)tucows.com

1 0

EPDP Phase 1, Rec 27, Wave 1 - Draft Responses to Charter Questions and Preliminary Recommendations
by Emily Barabas April 25, 2022

April 25, 2022

Dear Working Group members, Following the discussion on last week’s call regarding the EPDP Phase 1, Rec 27, Wave 1 analysis and seeing no additional comments or concerns raised in the working document or on the mailing list, staff has drafted responses to the charter questions on this topic and corresponding preliminary recommendations consistent with the analysis. Please take a few minutes to review the new draft text on pages 9-11 of the topic working document here.<https://docs.google.com/document/d/1ZLkSqD2bHDBoQLn8c0E2KjwWubpO7-cB9eg23uc…> Kind regards, Julie, Caitlin, Berry, and Emily Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Pre-Reading and Proposed agenda for meeting #44 on Tuesday 26 April 2022 at 16:00 UTC
by Emily Barabas April 21, 2022

April 21, 2022

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 26 April 2022 at 16:00 UTC. Before the meeting, please review the following: * Outstanding Items on TAC, Losing FOA and Gaining FOA (see tabs 1 & 2 of the summary document here<https://docs.google.com/spreadsheets/d/1VAeYHzXuA7qOYu2Fis8SlthcWsGxN6Jpzxd…>) * Draft WG outputs on TAC (see working document pages 15-19 here<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…>) * Draft WG outputs on Losing FOA (see working document pages 14-16 here<https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy…>) * Draft WG outputs on Gaining FOA (see working document pages 16-19 here<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…>) ***Note that responses to charter questions a2 through a5 are NEWLY ADDED, although they mainly reiterate points made in the response to charter questions a1.*** Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #44 Proposed Agenda 1. Roll Call & SOI updates 2. Welcome & Chair updates 1. Upcoming milestones and deliverables for Initial Report 2. Discussion of Outstanding Items on TAC (see summary in tab 1 here<https://docs.google.com/spreadsheets/d/1VAeYHzXuA7qOYu2Fis8SlthcWsGxN6Jpzxd…> and working document pages 15-19 here<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…>) 3. Discussion of Outstanding Items on Losing FOA and Gaining FOA (see summary in tab 2 here<https://docs.google.com/spreadsheets/d/1VAeYHzXuA7qOYu2Fis8SlthcWsGxN6Jpzxd…>, Losing FOA working document pages 14-16 here<https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy…>, and Gaining FOA working document pages 14-16 here<https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy…>) 4. AOB * Next call: Tuesday 3 May 2022 at 16:00 UTC

1 0

For Review: Draft recommendations on post-registration and post-transfer locks
by Emily Barabas April 21, 2022

April 21, 2022

Dear Working Group members, Draft recommendations are now available on post-registration and post-transfer locks here<https://docs.google.com/document/d/1RGow_TYPSESvI9DFweF3T_g7vgufg6zCwEdSsUj…> (see pages 5 and 6). In addition, our internal ICANN org SMEs have been invited to provide early input on the discussions covering this topic. Below you will find a responses from two of the SMEs. Kind regards, Julie, Caitlin, Berry, and Emily 1. Post-Transfer Lock: This if implemented, will greatly impact the domain name trading business. Currently, many domain name trading activities will use an “Escrow Registrar” acting as intermediary, where the domain name owner will transfer the name to that “Escrow Registrar” after a deal is agreed. Then once the “Escrow Registrar” receives the funds from the buyer, it will immediately release the domain name to the buyer, and buyer can immediately transfer the domain name to its desired registrar. By imposing this mandatory lock, will unnecessarily delay the domain name being transferred to the buyer’s own registrar. Further, to fight with fraudulent transfers, we do have TDRP that registrants can use. 1. I’d recommend that all these requirements being only registrar level policies, and all RA/RRA should be silent on this. That way, registrar can implement the policy pertain to their business model and don’t have to struggle between ICANN policies and registry requirements. Using the above Post-Transfer Lock in domain name trading business as an example, the current TP used sentence as “The Registrar of Record may deny a transfer request only in the following specific instances: …” this give the registrar the flexibility in implementation that fits their business. I think that the selection of parameters for the post-creation lock is easy. In the gTLD market, .com is the largest, and the majority of the gTLD domains are .com; therefore, .com already showed us what is possible. The rationale for post-creation lock says: "Provides registrars with a reasonable period of time to address issues related to chargebacks associated with fraudulent transactions." From my experience working for a registry and a registrar, you can get chargebacks after 10 days. A period of 60 days seems more reasonable for handling chargebacks. I think that applying the post-creation lock at the Registry-level makes more sense. From my experience, it was easier to develop security controls/policies at the Registry-level because as the Registrar deals with the public, there are more exceptions to be handled. For example, for a Registrar is easy to say, "apologies, this lock is applied at the registry, there is nothing that I can do", when you get calls from external VIPs asking you to make exceptions. From a security perspective, regarding the post-transfer lock, preventing repeated transfers in rapid succession is a control that could mitigate bad actors using rapid successions transfers to hide tracks. I think that 60 days sounds reasonable. I don’t see issues with a 60-day period for post-transfer locks, the escrow registrar would be the registrar sponsor for the gaining registrant during the 60 days-period. If the gaining registrant doesn't want to be with the escrow registrar, they can move after 60 days. If you have money to buy domain names in the secondary market, you probably have money to do another transfer after 60 days. In the end, the market adapts, and if currently, the escrow registrars don't provide all the features of a typical registrar, the escrow registrar will start delivering them, or the typical Registrar will offer escrow services.

1 1

Post Call | Transfer Policy Review PDP WG | Tuesday, 19 April 2022
by Devan Reed April 19, 2022

April 19, 2022

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 19 April 2022 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/MBAiCw> (attendance included) and the GNSO Master calendar <https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> . These include: * Attendance * 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, Devan

1 0

Notes and action items - TPR WG Meeting #43 - 19 April 2022 at 16:00 UTC
by Julie Hedlund April 19, 2022

April 19, 2022

Dear TPR WG Members, Please find below the notes and action items from today’s meeting. The next TPR WG meeting will be on Tuesday, 26 April 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: 1. WG members are encouraged to review the overview of proposed response to Charter Question h2 (see page 13 and 14 here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…>) and provide comments and/or suggestions. 2. WG members are encouraged to review the overview of proposed responses to EPDP Phase 1, Recommendation 27 “Wave 1” Report items (see document here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1ZLkSqD2bHDBo…>) and add comments in the column “Additional Notes/Discussion”. 3. Staff to suggest a definition along the lines of Designated Agent as referenced in the COR. Could say, “Working Group understands the Designated Representative to mean an individual or entity that the Registered Name Holder explicitly authorizes to obtain the TAC on their behalf.” 4. In the next 2 weeks -- Circle back to the Registrar SG (Sarah Wyld) and Registry SG (Jim Galvin and Rick Wilhelm) and also CPH TechOps (Jothan Frakes, although this would have to be coordinated with the Registrar SG) on the syntax for how to exchange and store the TAC. See Discussion of Outstanding Items on TAC summary document here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1VAeYHzXu…>. Notes: Transfer Policy Review Phase 1 - Meeting #43 Tuesday, 19 April 2022 at 16:00 UTC Proposed Agenda 1. Roll Call & SOI updates 2. Welcome & Chair updates * Small Team on Denial of Transfers/NACK: Cleaning up the draft recommendations. Likely will finish up this week and then will report to the WG. * In the phase of not detailed discussions, but focusing on what we’ve discussed and finalizing draft recommendations. * Poll on travel to ICANN74 looks great – lots of attendance in person (more than a dozen) at least for now. * Note that the locks recommendations are available now for WG members to review. Draft recommendations are now available on post-registration and post-transfer locks here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1RGow_TYPSESv…> (see pages 5 and 6). * . We’ll come back to these in a few weeks. 3. Overview of proposed response to Charter Question h2 (see page 13 and 14 here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…>) Question: h2) Should additional guidance around cases subject to a UDRP decision be provided to ensure consistent treatment by all registrars? If so, is this something that should be considered by the RPMs PDP Working Group’s review of the UDRP, or should it be conducted within a Transfer Policy PDP? The Working Group reviewed the World Intellectual Property Organization’s (WIPO) detailed comment<https://mm.icann.org/pipermail/comments-irtp-status-14nov18/attachments/201…> in response to the Transfer Policy Status Report<https://www.icann.org/uploads/ckeditor/IRTPPSRRevised_GNSO_Final.pdf> and has noted two concerns involving a UDRP proceeding vis-à-vis the Transfer Policy. Specifically, WIPO has noted issues related to: (i) the locking of a domain name subject to a UDRP proceeding (in order to prevent an inter-registrar during the pendency of the proceeding), and (ii) the implementation of a UDRP Panel’s order to transfer a domain name to a complainant. Some key points (see detail in the document at the link above): * Group had a charter question that relates to UDRP locking and WIPO concerns. * UDRP rule about locking a domain name – related to Transfer Policy on denial of transfer for a pending UDRP proceeding. The small team is considering this draft recommendation. Noted a wording change to “notified by the Provider”. * In response to WIPO’s related concern that “the ambiguity associated with ‘locking’ a domain name has resulted in many improper domain name transfers,” the Working Group notes that the definition of Locking is part of the UDRP Rules, and, accordingly, appears out of scope for this Working Group to address. * In the event a registrar mistakenly or purposefully effects an inter-registrar transfer during the pendency of a UDRP proceeding, this would be a clear violation of the Transfer Policy and should be referred to ICANN org Compliance for review. * The Working Group also discussed WIPO’s noted concern regarding the reported refusal of some registrars to effect a UDRP Panel’s decision to transfer a disputed domain name(s) to the Complainant. * The Working Group noted that a registrar refusal to implement a UDRP Panel’s decision to cancel or transfer the disputed domain name to the Complainant, absent official documentation of a court proceeding, would be a violation of the UDRP, and, accordingly, should be referred to ICANN org Compliance for review. The Working Group noted that it will refer this reported issue of UDRP decision implementation to the RPMs Phase 2 Working Group, as the Working Group believed the specific implementation around UDRP decisions to be out of scope for the Transfer Policy. Discussion: * Question: What happens if somehow the UDRP policy changes? Does that open up the Transfer Policy? Answer: If there was a PDP making changes, we should note that dependency. Should reference the UDRP policy to allow flexibility for changes in that policy (rather than stating the UDRP policy within the Transfer Policy). * Question: Does the Transfer Policy override other locks, such as Change of Registrant, that are in play during a UDRP dispute? Answer: Don’t know if the Transfer Policy should get into this question. Change of Registrar lock wouldn’t apply. Could be a government order or other outlying cases, but those would be very limited and didn’t prevent transfer in the case of UDRP. * If there was a post-creation lock in place when the transfer was to occur then the only way to transfer was a inter-registrar push, then the registrant would have to wait that X number of days during the post-creation lock. * This was the original use case for the concern raised by WIPO. Given the registration monitoring solutions a brand owner could be notified within 5-10 days, WIPO’s concern in those instances of a newly created domain name and the 60 day create lock applied, the complainant would have to wait that 60 days. * If we reduce that time to 30 days for that lock then it would reduce that wait. * It’s possible that perhaps the UDRP review/RPMs Phase 2 could address it. ACTION ITEM: WG members are encouraged to review the Overview of proposed response to Charter Question h2 (see page 13 and 14 here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…>) and provide comments and/or suggestions. 4. Overview of proposed responses to EPDP Phase 1, Recommendation 27 “Wave 1” Report items (see document here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1ZLkSqD2bHDBo…>) Estimated Impact: High Key Points: This policy is substantively affected by the new Registration Data Policy requirements. Some areas identified have been addressed by the EPDP Phase 1 recommendations. It is also noted that the GNSO has work in progress to review the Transfer Policy. Support staff team has gathered everything in the above-referenced document – Wave 1 Analysis Key Points, Potential WG Response, Additional Notes/Discussion. Summary: 1. Administrative Contact removed from the Transfer Policy. 2. Transfer Contact needs to be updated. Transfer Policy instead uses Registered Name Holder. 3. Administrative Contact: WG is not recommending any use of the term Administrative Contact. 4. Transfer Emergency Action Contact (TEAC) communication and responses – deferred to Phase 1 of the PDP. 5. Issue: not feasible for a Gaining Registrar to send an FOA to the registrant contact data associated with an existing registration; WG recommending eliminating the requirement that the Gaining Registrar send a Gaining Form of Authorization. 6. Defer discussion to Phase 1(b) of the PDP. 7. Defer discussion to Phase 1(b) of the PDP. 8. Working Group may wish to consider replacing current references to Whois to RDDS throughout the Transfer Policy for any references to Whois that remain. (Please see response to Key Item 9 below for more detail.) 9. In its draft recommendations, the Working Group is recommending eliminating the requirement that the Gaining Registrar send a Gaining Form of Authorization. The Working Group may wish to explicitly recommend the terminology changes from EPDP Phase 1, Recommendation #24. 10. The Working Group has methodically worked through its charter questions, which has enabled it to review previously identified and longstanding issues in the Transfer Policy by proposing slight adjustments to specific transfer issues and/or proposing new methods. 11. Defer discussion to Phase 1(b) of the PDP. Discussion: * Re: #10: Comments received in reference to the registrar survey about starting over. When compiling charter questions we allowed for the WG to look at the CPH TechOps proposal, but WG could concentrate on the policy language. * The losing FOA matter as written in the TechOps letter was identifying a workaround to address the sweeping redaction response to the GDPR consequences. THAT tempspec letter was official. If there's an official response needed from TechOps we are glad to engage. * Make sure the language here parallels the language in the draft recommendations on Losing FOA. * Instead of saying the “Working Group is recommending eliminating the requirement that the Gaining Registrar send a Gaining Form of Authorization” could say “replacing the requirement” or other suggested text. ACTION ITEM: WG members are encouraged to review the overview of proposed responses to EPDP Phase 1, Recommendation 27 “Wave 1” Report items (see document here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1ZLkSqD2bHDBo…>) and add comments in the column “Additional Notes/Discussion”. 5. Discussion of Outstanding Items on TAC (see summary document here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1VAeYHzXu…>) * Many of these items don’t require action/feedback. * Somewhat of a balancing act. Item 1, Response to CQ b1, row 4: Comments from ICANN Org Compliance: if a definition is added to the Transfer Policy that eliminates any mention to the term “identify”, the language in Section I.A.5.6 of the Transfer Policy (“The "AuthInfo" codes must be used solely to identify a Registered Name Holder…”) should also be amended for consistency. – staff suggestion, fairly simply solution. Add a sentence to Recommendation 2 stating that relevant policy language must be updated for consistency with the definition provided by the WG. Item 2, Response to CQ b1, row 5: No action required. Item 3, Recommendation 1, row 6: No action required. Item 4, Recommendation 2, row 7: recommends defining the term “designated representative” within the policy (like “Designated Agent” is defined for Change of Registrant (COR) requests), so that it is clear that the representative is authorized to request and receive the TAC in order to complete an inter-registrar transfer. * Support not defining it but I like including a confirmation that RNH supersedes Designated Rep. * "When we say 'Designated Representative', we mean. * ICANN Compliance: Include a definition for implementation of the policy. * From a security principles point of view, focus on what we control – what is in registrar and registry systems. Proposed principles around the TAC, but once the registrant has the TAC we have no control over that. Take out “or the Designated Representative”. * If we remove “Designated Representative” then we are removing terminology that reflects what is currently being done and reflected in contractual relationships. Need to keep this in. * Could say: “"Designated Representative" means an individual or entity that the Registered Name Holder explicitly authorizes to obtain the TAC on their behalf.” * Question: Where to put this text? Is there a definition section? Answer: Don’t think we have a definition section yet, but we can create one. ACTION ITEM: Staff to suggest a definition along the lines of Designated Agent as referenced in the COR. Could say, “Working Group understands the Designated Representative to mean an individual or entity that the Registered Name Holder explicitly authorizes to obtain the TAC on their behalf.” See Discussion of Outstanding Items on TAC summary document here [docs.google.com<http://docs.google.com>]. Item 5, Recommendation 2, row 8: RE: SME input on the sentence, “The TAC is required for a domain name to be transferred from one Registrar to another Registrar and when presented authorizes the transfer”: Who is this? The RNH/their representative, or the losing registrar? Response: The WG previously agreed that the language should not specifically address who presents the TAC. Does the WG want to revisit? Agreement to leave this as is. Item 6, Recommendation 3, rows 9, 10, and 11: Compliance input: Compliance notes that it is unclear who within the org would establish those requirements and how, as well as how the requirements (and any change to them) would be communicated to the contracted parties. For the avoidance of doubt, ICANN Contractual Compliance does not have the technical knowledge to establish those requirements or to determine whether they are appropriate or not. For ICANN Contractual Compliance to enforce these requirements, all requirements must be clearly enumerated and described within the policy itself. SME input: Add “security requirements for data at rest” to the list of examples of requirements for composition of the TAC WG members have an outstanding action item to suggest revisions to this recommendation * Take the next couple of weeks to get feedback from Registrar and Registry WG and CPH Tech Ops. ACTION ITEM: In the next 2 weeks -- Circle back to the Registrar SG (Sarah Wyld) and Registry SG (Jim Galvin and Rick Wilhelm) and also CPH TechOps (Jothan Frakes, although this would have to be coordinated with the Registrar SG) on the syntax for how to exchange and store the TAC. See Discussion of Outstanding Items on TAC summary document here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1VAeYHzXu…>. 6. AOB * Next call: Tuesday 26 April 2022 at 16:00 UTC

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 26 April 2022
by Devan Reed April 19, 2022

April 19, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 26 April 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/MhAiCw * Check your time zone: https://tinyurl.com/53s57jmh ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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

15 MINUTES**REMINDER | Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 19 April 2022
by Devan Reed April 19, 2022

April 19, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 19 April 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/MBAiCw * Check your time zone: https://tinyurl.com/369duxjf [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/369duxjf__;!!PtGJab4!vuZVcKx…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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] TPR alternative request
by DANIEL NANGHAKA April 18, 2022

April 18, 2022

Dear team, I kindly request for a proxy for this week's calls. Am not in position to attend the calls due to the Presidential Retreat happening this week. Thank you Daniel

3 2

REMINDER | Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 19 April 2022
by Terri Agnew April 18, 2022

April 18, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 19 April 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/MBAiCw * Check your time zone: https://tinyurl.com/369duxjf [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/369duxjf__;!!PtGJab4!vuZVcKx…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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 #43 on Tuesday 19 April 2022 at 16:00 UTC
by Emily Barabas April 14, 2022

April 14, 2022

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 19 April 2022 at 16:00 UTC. Before the meeting, please review the following: * proposed response to Charter Question h2 (see page 13 and 14 here<https://docs.google.com/document/d/1L2bZnhJUY3VxyAjVCrkyVqdttOPn2EaqBARRRnE…>) * proposed responses to EPDP Phase 1, Recommendation 27 “Wave 1” Report items (see document here<https://docs.google.com/document/d/1ZLkSqD2bHDBoQLn8c0E2KjwWubpO7-cB9eg23uc…>) * Outstanding Items on TAC (see summary document here<https://docs.google.com/spreadsheets/d/1VAeYHzXuA7qOYu2Fis8SlthcWsGxN6Jpzxd…>) Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #43 Proposed Agenda 1. Roll Call & SOI updates 2. Welcome & Chair updates 1. Overview of proposed response to Charter Question h2 (see page 13 and 14 here<https://docs.google.com/document/d/1L2bZnhJUY3VxyAjVCrkyVqdttOPn2EaqBARRRnE…>) 2. Overview of proposed responses to EPDP Phase 1, Recommendation 27 “Wave 1” Report items (see document here<https://docs.google.com/document/d/1ZLkSqD2bHDBoQLn8c0E2KjwWubpO7-cB9eg23uc…>) 3. Discussion of Outstanding Items on TAC (see summary document here<https://docs.google.com/spreadsheets/d/1VAeYHzXuA7qOYu2Fis8SlthcWsGxN6Jpzxd…>) 4. AOB * Next call: Tuesday 26 April 2022 at 16:00 UTC

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 19 April 2022
by Julie Bisland April 12, 2022

April 12, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 19 April 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/MBAiCw * Check your time zone: https://tinyurl.com/369duxjf ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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, 12 April 2022
by Julie Bisland April 12, 2022

April 12, 2022

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 12 April 2022 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/LhAiCw> (attendance included) and the GNSO Master calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance * 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 #42 - 12 April 2022
by Julie Hedlund April 12, 2022

April 12, 2022

Dear TPR WG Members, Please find below the notes and action items from today’s meeting. The next TPR WG meeting will be on Tuesday, 19 April 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: 1. WG members to provide language to justify the 30-day post-creation and post-transfer locks in the Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1RGow_TYPSESv…>. 2. REMINDER from 05 April meeting: WG members to review suggested new language from Sarah Wyld in the bulk use cases Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1mqPITDShqiVQ…> and possible suggested text (in recommendations 3, 8, and 9?) that the TAC has to be unique using the phrase “randomly generated value”. Notes: Transfer Policy Review Phase 1 - Meeting #42 Tuesday, 12 April 2022 Proposed Agenda 1. Roll Call & SOI updates 2. Welcome & Chair updates * Small Team on Denial of Transfer/NACKing: Meeting this week and will have draft language for the WG to review. * Single TAC for multiple domains: in Bulk Use Cases Working Document<https://docs.google.com/document/d/1mqPITDShqiVQ4rH6x-FlvePmL_c05CtyWGgkpj9…> Sarah Wyld has suggested language for the WG review and comment. * Reminder that as work is winding down the big tactical discussions are shortly behind us. We’ll be finalizing draft recommendations and closing up anything that is still open. Do think we have addressed the charter questions. Goal is to have the Initial Report in good shape in June. ACTION ITEM: REMINDER from 05 April meeting: WG members to review suggested new language from Sarah Wyld in the bulk use cases Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1mqPITDShqiVQ…> and possible suggested text (in recommendations 3, 8, and 9?) that the TAC has to be unique using the phrase “randomly generated value”. 3. Post-creation and post-transfer locks – see: Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1RGow_TYPSESv…> * Have some feedback from groups that 10 days may be too short. * Asking some questions in a short poll – whether there should be a post-creation lock, period of time, and enforcement, and same for a post-transfer lock. Not talking about a specific type of lock. Just whether there is a window of time during which a transfer shouldn’t occur. * Post-creation lock is a window of time after a domain is created that it cannot be transferred. The other item that was brought up was payment, that also had a window of time associate with it. See summary of the reasons suggested in the working document here on page 3: https://docs.google.com/document/d/1RGow_TYPSESvI9DFweF3T_g7vgufg6zCwEdSsUj…. Poll Responses: 1. Should a transfer lock be required after a domain is registered? * Yes – 88% responses * No – 13% responses * No answer – 0% responses Discussion: * Strong support for a lock. * Note that today this is an optional lock; some registrars do it and some don’t. Some registries do it. * This is what we expected. 2. What should be the period of the post-creation lock? * 10 days – 50% responses * 30 days – 39% responses * 60 days – 11% responses * Other period/don’t know – 0% responses Discussion: * Some thought 60 days was too long. Seems also that 10 days could be too short for some. * Some suggest that the period should be left to the registrar with a minimum requirement of 10 days. * Standardizing the period could be helpful. * Could there be exceptions to allow 10 days? * Could be a lot of value to aligning the time with the post-transfer lock period. Maybe we need to not decide until we decide what the fast-undo period would be, to make them aligned. * If the lock period is longer we should consider guardrails. * Question: Can we come back to Phase 1 recommendations in Phase 2? Answer: There will be a separate Final Report for Phases 1 and 2, so these are separate efforts. The idea when we drafted the charter was when the Phase 1 work is completed getting this out to market as fast as possible means that the IRT can start up the work on the Phase 1 recommendations. If Phase 2 required a change to a Phase1 recommendation this could be done because the recommendations won’t be implemented overnight, but the intention was that Phase 1 would be implemented while Phase 2 work is ongoing. * By and large there seems to be a high-degree of agreement that there should be a period of time post-creation doesn’t occur and some agreement on a 10- or 30-day period. Best if we have agreement before going into public comment on the Initial Report. If we have both options in the Initial Report we need strong rationale for each. * Key here is what the WG will take to public comment – better if we can take a limited set, with one time period being best if we can agree. * Question: Can we get justification from people who support 10 days and those who support 30 days? * There are different business registrar business models. Many of the reseller registrars take a pre-payment, so there are certain players that have surety of payment as part of their business model. Others have payment in real time and it’s not until a billing cycle occurs you wouldn’t see fraudulent payments. 60 days allows time for that to occur, but 30 days may not. This also is tethered to fast undo. * If we agree on 30 days, we need to justify it. 3. Should a transfer lock be required after a domain is transferred to a new registrar? * Yes – 94% responses * No – 6% responses * No answer – 0% responses Discussion: * Need a transfer lock because of the potential for domain theft. * Need to be thinking about the registrant and certainty of title/transfer of title. This about the period of time for lock plus undo. Need to find a sweet spot. Perhaps rather than discuss the lock period, talk about the lock plus undo period. Should be a fixed number of days and not per registrar or registry. * A flipper could wait the 30 days (post-transfer lock) before selling? You aren’t initiated a transfer in order to participate in the marketplace. Waiting period could affect when funds are released from escrow. * Would think we would want to balance protection for the average registrar and risks of abuse. * Most change of registrars would correspond with a change of registrant. When the customer changes ownership, that is the change of registrant lock. * As above, if we agree on 30 days when have to justify it. * Poll shows support for a post-transfer lock. 4. What should be the period of the post-transfer lock? * 10 days – 22% responses * 30 days – 72% responses * 60 days – 6% responses * Other period/don’t know – 0% responses Discussion: * Could there be a 3a question? Do people want continuity between a post-creation and post-transfer lock? * Seems to be support for continuity. * Poll results suggest that some people switched from 10 to 30 days. Seems that most feel 60 days is too long. * Question: Should there be no exceptions? Such if the registrar and registrant agree to a shorter period? Answer: That would not be allowed. * Reminder: We are talking about edge cases. * Wondering if 30 days could be a general rule with the possibility of exceptions? * We are again leaning towards 30 days. We haven’t yet gotten to any agreement on carve-outs. Could be a question in the Initial Report for public comment. * Seems logical that fast undo would fall within the lock period. * What if there is no quick-undo process? Maybe we shouldn’t assume that we can agree on such a process. * We brought the fast-undo process discussion forward to see if we could agree on it and to consider it in the context of locks. 5. How should the lock requirements be implemented? * Requirement in the Transfer Policy for a registrar lock – 80% responses * Requirement in the Registry Agreement for a registry lock – 13% responses * Other/don’t know – 7% responses Discussion: * Question: Registrars are bound through the RAA for consensus policies, and registries too, right? Why put a requirement in Registry Agreement. Answer: Just focus on whether it’s a registrar or registry lock. Ignore the part about the agreement. * Registrar locks can be removed, whereas that’s not possible with a registry lock. * Don’t think that registries have enough information to properly support this. You are overloading registry-specific rules with the need or purpose of registrars. Concerned about how this would be implemented. * Right now, for example, if a registry finds that there is a name being abused the registry may turn on various EPP statuses to prevent transfer, and may also take it out of the zone. Using those same locks for inter-registrar transfer would be overloading those mechanisms. * Instead of talking about a specific status, talk about a window in time. * Leaning toward registrar use and enforcement. * If there is a policy that states the period of time, could the registrar disallow these locks or set something shorter? * Big question is whether to go with 10 or 30 days. Do we have support for one or the other? Seems we have a good indication that some people want 30, but we need that to be documented with a solid rationale. ACTION ITEM: WG members to provide language to justify the 30-day post-creation and post-transfer locks in the Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1RGow_TYPSESv…>. 4. AOB * Next call: Tuesday 19 April 2022 at 16:00 UTC.

1 0

**STARTS IN 12 MINUTES** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 12 April 2022
by Julie Bisland April 12, 2022

April 12, 2022

**STARTS IN 12 MINUTES** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 12 April 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/LhAiCw * Check your time zone: https://tinyurl.com/47xbfjdu [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/47xbfjdu__;!!PtGJab4!tS6MnH2…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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