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

Suggested text for Rec 7 (TAC Security)
by Sarah Wyld 25 Apr '22

25 Apr '22

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 25 Apr '22

25 Apr '22

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 21 Apr '22

21 Apr '22

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 21 Apr '22

21 Apr '22

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 19 Apr '22

19 Apr '22

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 19 Apr '22

19 Apr '22

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 19 Apr '22

19 Apr '22

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 19 Apr '22

19 Apr '22

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 18 Apr '22

18 Apr '22

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 18 Apr '22

18 Apr '22

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