January 2023 - GNSO-TPR - lists.icann.org

Re: [GNSO-TPR] Notes and action items - TPR WG Meeting #76 - 10 January 2023 at 16:00 UTC
by Emily Barabas Jan. 10, 2023

Jan. 10, 2023

For those who might like to take a closer look at the slides on the proposed work plan revisions, please see attached. From: GNSO-TPR <gnso-tpr-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Tuesday, 10 January 2023 at 18:24 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: [GNSO-TPR] Notes and action items - TPR WG Meeting #76 - 10 January 2023 at 16:00 UTC Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Tuesday, 17 January 2023 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: 1. Small Team on Exemption for Recommendation 16 and 17 to send proposed language and rationale to the list before the next meeting. 2. Small Team on TTL enforcement to send proposed rationale to the list before the next meeting. Notes: Transfer Policy Review - Meeting #76 Proposed Agenda 10 January 2023 1. Roll Call & SOI updates 2. Welcome and Chair Updates 3. Proposed Work Plan Update & Project Change Request * Plan for the PDP looking at the subjects in the charter, timeline, and what was planned. * GNSO Council agenda for 19 January to provide an update on the work plan and proposed Project Change Request. Summary: Original phased approach: Phase 1(a): * Form of Authorization (including Rec. 27, Wave 1 FOA issues) * AuthInfo Codes * Denying (NACKing) Transfers Phase 1(b): * Change of Registrant (including Rec. 27, Wave 1 Change of Registrant issues) Phase 2: * Transfer Emergency Action Contact * Transfer Dispute Resolution Policy (including Rec. 27, Wave 1 TDRP issues) * Reversing transfers * ICANN-approved transfers As a reminder, the phased approach initially seemed logical for two reasons: * The phased approach is consistent with PDP 3.0 Guidelines, Enhancement 11, which provides “a PDP should have a narrow scope and, in those cases where a subject is broad, it needs to be broken into manageable pieces.” * It also allowed for the possibility of implementation work for Phase 1 recommendations in parallel with Phase 2 policy development work. Original timing: Phase 1A Initial Report June 2022 (complete) Phase 1B Initial Report March 2023 Combined Phase 1 Final Report August 2023 Phase 2 Initial Report TBD Phase 2 Final Report January 2026 (approximate) Why is a change needed? * The Working Group identified dependencies between the Phase 2 and Phase 1 work. Specifically, the working group will need to make substantial progress on Phase 2 topics TDRP and/or TEAC before it can finalize Phase 1A and 1B recommendations pertaining to inter-registrar and inter-registrant transfers. The current project plan anticipates two fully independent phases, but this is not workable in practice. * Phase 1A preliminary recommendations have been substantially revised following the public comment period and may be revised further following discussion of TDRP and/or TEAC. Additional community input through public comment is warranted on these revisions. * Phase 1A is behind schedule due to a public comment extension and the need to consider a number of substantive comments, which has also resulted in Phase 1B work falling behind schedule. A work plan adjustment would be needed for this reason alone, independent of the above points. Proposed change: Combine Phase 1 and Phase 2 into a single body of work, with a combined Initial Report and Final Report covering all topics. Reorder the sequence in which topics are addressed by the PDP to account for dependencies between topics. Proposed work plan: Milestone Target Date Phase 1A Initial Report June 2022 (complete) Combined Phase 1A (revised), 1B, and 2 Initial Report (75 day public comment) August 2024 Combined Phase 1A (revised), 1B, and 2 Final Report February 2025 Benefits of the proposed change: * Allows the working group to deliberate on all topics iteratively and consider the dependencies between recommendations in different topic areas. * Allows the community to review all draft recommendations as a single package, taking into account dependencies between recommendations in different topic areas. * A single, extended public comment period of the combined Initial Report will allow ample opportunity for the community to review the package of draft recommendations and provide input. * Fewer public comment periods and combination of outputs will allow the working group to reduce the overall timeline of the PDP. * Reduces burden on the volunteers, as the PDP no longer anticipates a Phase 1 IRT in parallel with Phase 2 policy development. In addition, only a single IRT will now be needed. Additional Considerations: * The draft revision of the work plan anticipates that the PDP will conclude in Q1 2025. Some working group members may not be able to commit for the full length of the PDP. * The working group may want to consider if there if there is a logical point in the PDP in which groups are invited to adjust their membership. * Given that participation in the PDP is already uneven in terms of both membership and attendance (e.g. real-time participation) and attendance overall is trending downward, this may be a good moment for groups to consider how they can best ensure sustained engagement through the life of the PDP. Next steps: * PDP update and preview of the Project Change Request during 19 January GNSO Council meeting. * Wrap up discussion on Phase 1A topics by end of January. * Briefly revisit status of Phase 1B discussions, including any touchpoints with Phase 2 Topics in early February. * Begin Phase 2 deliberations in early February. * GNSO Council vote on Project Change Request during 16 February GNSO Council meeting. Discussion/Questions: * Question: Is ICANN approved transfers a topic for discussion? Yes, for bulk transfers. We aren’t changing any of the original charter questions. There are a couple relating to bulk transfers in Phase 1a. ICANN-approved transfers has always been part of Phase 2. Said we would talk about bulk transfers later at the same time as ICANN-approved transfers. This is about changing the plan to make sure the work is sequenced in a logical way. * Should help to minimize the lost cycles – good change. * We aren’t changing the scope, just trying to be more efficient. * Hopefully the extended, consolidated comment period reduces the concerns from those beyond this group who'd have preferred two comment periods. 4. Proposed redline from Small Group on Exemption for Recommendation 16 and 17 * On final edits and hope to get the proposal out today. * Steinar: discussion in At-Large WG – If you have the opt out feature it could encourage registrar jumping. No consensus but will discuss again tomorrow. See Google doc of comments at: https://docs.google.com/document/d/1O3vBcIr-mkDcdF5hX8jRcLXu0DoIWDTgMl4HrUQ… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O3vBcIr-mkDc…>. ACTION ITEM: Small Team on Exemption for Recommendation 16 and 17 to send proposed language and rationale to the list before the next meeting. 5. Rationale for Recommendation 13 - Registry enforcement of TTL Enforcement * Here is a draft rationale for registry enforcement based on the public comments received at: https://docs.google.com/document/d/1Wq4dHcIFR5XogoutSh0klkCyhZFUlS1z7cl2ilv… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Wq4dHcIFR5Xo…> and here: Draft Rationale: The purpose of the standard TTL is to enforce security around unused TACs (e.g., requested/received but not used), in a situation where the TAC may be stored in a registrant’s email or other communications storage. The working group supports the CPH TechOps conclusion that the TAC TTL should be no more than 14 calendar days and notes that a 14-day period is appropriate in order to accommodate transfer-related business processes associated with different registrar models. The working group extensively discussed whether the Registry or Registrar should enforce the 14-day TTL and requested community input on this question through public comment on the Phase 1A Initial Report. The working group recommends enforcement by the Registry for the following reasons: * The Registry is the central authority for registrations, and therefore is the appropriate party to enforce a standardized and consistent TTL. * It is a more secure and streamlined approach due to the lesser number of Registry Operators as compared to ICANN-accredited Registrars. * The TAC is set at the Registry, and therefore it is logical for the Registry to set the TTL and enforce the 14-day limit through the system as soon as the TTL expires. With respect to 13.2, the working group acknowledged that there may be a variety of circumstances in which the Registrar of Record and the registrant may want to mutually agree to reset the TAC to NULL prior to the end of the 14th calendar day. The working group included this language to ensure that Registrars are permitted to do so under relevant circumstances. Discussion: * Question: In Rec #3 We proposed “Date and time that the TAC was issued and information about when the TAC will expire”, will the expire be given by the Registry? * 13.2 came up because a 14-day window may seem large to some people and that’s why it says agreement of the registrar and the RNH. * Left some flexibility to shorten the time, but didn’t define how much time the registrant had for the transfer. We did find that there is a diversity among registrars for various shorter periods. * One of the reasons the TTL was proposed was to stop having no limit – the longer side, to make sure it didn’t live forever. * Small Team and registries are likely to shorten the draft rationale language. * Trying to make as few changes as possible to a complex process. * Basically, some registrars might implement the NACK by setting TAC to NULL , either to ensure no transfer could be initiated or to be thorough, with or without the eligibility statuses. * Having a TTL is a key security feature. * The idea of including the TTL in the TAC was discussed in the review of public comments and not adopted because of security issues relating to gaming the system. * Did not consider where the TTL would be stored at the registry – that should be private for security reasons, and because we are talking about making modest changes. * Recommendation #3 does require that the expiration is notified to the RNH. * Small Team will suggest a revised rationale to the WG on the list before the next meeting. ACTION ITEM: Small Team on TTL enforcement to send proposed rationale to the list before the next meeting. 6. AOB: Revised Swimlane – see attached. * Request was for staff to update the Swimlane. * Staff will send a revised version (see also attached). * Extend the deadline for the review of the redline of the Phase 1a recommendations to 23 January. This is not meant to be a big exercise -- just focus on the specific redline edits to the recommendations based on the review of the public comments and the WG’s preliminary agreement.

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 10 January 2023
by Julie Bisland Jan. 10, 2023

Jan. 10, 2023

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 10 January 2023 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/HIw-DQ> (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 recording (including audio, visual, rough transcript. NOTE: Chat Messages tab is not displaying properly, see Zoom chat transcript attached) * 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, 17 January 2023
by Julie Bisland Jan. 10, 2023

Jan. 10, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 17 January 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/H4w-DQ * For other places see: https://tinyurl.com/2cstkh8m ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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 #76 - 10 January 2023 at 16:00 UTC
by Julie Hedlund Jan. 10, 2023

Jan. 10, 2023

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Tuesday, 17 January 2023 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: 1. Small Team on Exemption for Recommendation 16 and 17 to send proposed language and rationale to the list before the next meeting. 2. Small Team on TTL enforcement to send proposed rationale to the list before the next meeting. Notes: Transfer Policy Review - Meeting #76 Proposed Agenda 10 January 2023 1. Roll Call & SOI updates 2. Welcome and Chair Updates 3. Proposed Work Plan Update & Project Change Request * Plan for the PDP looking at the subjects in the charter, timeline, and what was planned. * GNSO Council agenda for 19 January to provide an update on the work plan and proposed Project Change Request. Summary: Original phased approach: Phase 1(a): * Form of Authorization (including Rec. 27, Wave 1 FOA issues) * AuthInfo Codes * Denying (NACKing) Transfers Phase 1(b): * Change of Registrant (including Rec. 27, Wave 1 Change of Registrant issues) Phase 2: * Transfer Emergency Action Contact * Transfer Dispute Resolution Policy (including Rec. 27, Wave 1 TDRP issues) * Reversing transfers * ICANN-approved transfers As a reminder, the phased approach initially seemed logical for two reasons: * The phased approach is consistent with PDP 3.0 Guidelines, Enhancement 11, which provides “a PDP should have a narrow scope and, in those cases where a subject is broad, it needs to be broken into manageable pieces.” * It also allowed for the possibility of implementation work for Phase 1 recommendations in parallel with Phase 2 policy development work. Original timing: Phase 1A Initial Report June 2022 (complete) Phase 1B Initial Report March 2023 Combined Phase 1 Final Report August 2023 Phase 2 Initial Report TBD Phase 2 Final Report January 2026 (approximate) Why is a change needed? * The Working Group identified dependencies between the Phase 2 and Phase 1 work. Specifically, the working group will need to make substantial progress on Phase 2 topics TDRP and/or TEAC before it can finalize Phase 1A and 1B recommendations pertaining to inter-registrar and inter-registrant transfers. The current project plan anticipates two fully independent phases, but this is not workable in practice. * Phase 1A preliminary recommendations have been substantially revised following the public comment period and may be revised further following discussion of TDRP and/or TEAC. Additional community input through public comment is warranted on these revisions. * Phase 1A is behind schedule due to a public comment extension and the need to consider a number of substantive comments, which has also resulted in Phase 1B work falling behind schedule. A work plan adjustment would be needed for this reason alone, independent of the above points. Proposed change: Combine Phase 1 and Phase 2 into a single body of work, with a combined Initial Report and Final Report covering all topics. Reorder the sequence in which topics are addressed by the PDP to account for dependencies between topics. Proposed work plan: Milestone Target Date Phase 1A Initial Report June 2022 (complete) Combined Phase 1A (revised), 1B, and 2 Initial Report (75 day public comment) August 2024 Combined Phase 1A (revised), 1B, and 2 Final Report February 2025 Benefits of the proposed change: * Allows the working group to deliberate on all topics iteratively and consider the dependencies between recommendations in different topic areas. * Allows the community to review all draft recommendations as a single package, taking into account dependencies between recommendations in different topic areas. * A single, extended public comment period of the combined Initial Report will allow ample opportunity for the community to review the package of draft recommendations and provide input. * Fewer public comment periods and combination of outputs will allow the working group to reduce the overall timeline of the PDP. * Reduces burden on the volunteers, as the PDP no longer anticipates a Phase 1 IRT in parallel with Phase 2 policy development. In addition, only a single IRT will now be needed. Additional Considerations: * The draft revision of the work plan anticipates that the PDP will conclude in Q1 2025. Some working group members may not be able to commit for the full length of the PDP. * The working group may want to consider if there if there is a logical point in the PDP in which groups are invited to adjust their membership. * Given that participation in the PDP is already uneven in terms of both membership and attendance (e.g. real-time participation) and attendance overall is trending downward, this may be a good moment for groups to consider how they can best ensure sustained engagement through the life of the PDP. Next steps: * PDP update and preview of the Project Change Request during 19 January GNSO Council meeting. * Wrap up discussion on Phase 1A topics by end of January. * Briefly revisit status of Phase 1B discussions, including any touchpoints with Phase 2 Topics in early February. * Begin Phase 2 deliberations in early February. * GNSO Council vote on Project Change Request during 16 February GNSO Council meeting. Discussion/Questions: * Question: Is ICANN approved transfers a topic for discussion? Yes, for bulk transfers. We aren’t changing any of the original charter questions. There are a couple relating to bulk transfers in Phase 1a. ICANN-approved transfers has always been part of Phase 2. Said we would talk about bulk transfers later at the same time as ICANN-approved transfers. This is about changing the plan to make sure the work is sequenced in a logical way. * Should help to minimize the lost cycles – good change. * We aren’t changing the scope, just trying to be more efficient. * Hopefully the extended, consolidated comment period reduces the concerns from those beyond this group who'd have preferred two comment periods. 4. Proposed redline from Small Group on Exemption for Recommendation 16 and 17 * On final edits and hope to get the proposal out today. * Steinar: discussion in At-Large WG – If you have the opt out feature it could encourage registrar jumping. No consensus but will discuss again tomorrow. See Google doc of comments at: https://docs.google.com/document/d/1O3vBcIr-mkDcdF5hX8jRcLXu0DoIWDTgMl4HrUQ…. ACTION ITEM: Small Team on Exemption for Recommendation 16 and 17 to send proposed language and rationale to the list before the next meeting. 5. Rationale for Recommendation 13 - Registry enforcement of TTL Enforcement * Here is a draft rationale for registry enforcement based on the public comments received at: https://docs.google.com/document/d/1Wq4dHcIFR5XogoutSh0klkCyhZFUlS1z7cl2ilv… and here: Draft Rationale: The purpose of the standard TTL is to enforce security around unused TACs (e.g., requested/received but not used), in a situation where the TAC may be stored in a registrant’s email or other communications storage. The working group supports the CPH TechOps conclusion that the TAC TTL should be no more than 14 calendar days and notes that a 14-day period is appropriate in order to accommodate transfer-related business processes associated with different registrar models. The working group extensively discussed whether the Registry or Registrar should enforce the 14-day TTL and requested community input on this question through public comment on the Phase 1A Initial Report. The working group recommends enforcement by the Registry for the following reasons: * The Registry is the central authority for registrations, and therefore is the appropriate party to enforce a standardized and consistent TTL. * It is a more secure and streamlined approach due to the lesser number of Registry Operators as compared to ICANN-accredited Registrars. * The TAC is set at the Registry, and therefore it is logical for the Registry to set the TTL and enforce the 14-day limit through the system as soon as the TTL expires. With respect to 13.2, the working group acknowledged that there may be a variety of circumstances in which the Registrar of Record and the registrant may want to mutually agree to reset the TAC to NULL prior to the end of the 14th calendar day. The working group included this language to ensure that Registrars are permitted to do so under relevant circumstances. Discussion: * Question: In Rec #3 We proposed “Date and time that the TAC was issued and information about when the TAC will expire”, will the expire be given by the Registry? * 13.2 came up because a 14-day window may seem large to some people and that’s why it says agreement of the registrar and the RNH. * Left some flexibility to shorten the time, but didn’t define how much time the registrant had for the transfer. We did find that there is a diversity among registrars for various shorter periods. * One of the reasons the TTL was proposed was to stop having no limit – the longer side, to make sure it didn’t live forever. * Small Team and registries are likely to shorten the draft rationale language. * Trying to make as few changes as possible to a complex process. * Basically, some registrars might implement the NACK by setting TAC to NULL , either to ensure no transfer could be initiated or to be thorough, with or without the eligibility statuses. * Having a TTL is a key security feature. * The idea of including the TTL in the TAC was discussed in the review of public comments and not adopted because of security issues relating to gaming the system. * Did not consider where the TTL would be stored at the registry – that should be private for security reasons, and because we are talking about making modest changes. * Recommendation #3 does require that the expiration is notified to the RNH. * Small Team will suggest a revised rationale to the WG on the list before the next meeting. ACTION ITEM: Small Team on TTL enforcement to send proposed rationale to the list before the next meeting. 6. AOB: Revised Swimlane – see attached. * Request was for staff to update the Swimlane. * Staff will send a revised version (see also attached). * Extend the deadline for the review of the redline of the Phase 1a recommendations to 23 January. This is not meant to be a big exercise -- just focus on the specific redline edits to the recommendations based on the review of the public comments and the WG’s preliminary agreement.

1 0

**AT THE TOP OF THE HOUR** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 10 January 2023
by Julie Bisland Jan. 10, 2023

Jan. 10, 2023

**AT THE TOP OF THE HOUR** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 10 January 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/HIw-DQ * For other places see: https://tinyurl.com/2b9x28mt [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2b9x28mt__;!!PtGJab4!51dhvwz…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * Alternate assignments 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 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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 #76 on Tuesday 10 January 2023 at 16:00 UTC
by Emily Barabas Jan. 10, 2023

Jan. 10, 2023

Dear Working Group members, Please find below the proposed agenda for the next meeting scheduled to take place on Tuesday 10 January at 16:00 UTC. Kind regards, Caitlin, Berry, Julie, and Emily ________________________________________________________________________________________________ Transfer Policy Review - Meeting #76 Proposed Agenda 10 January 2023 1. Roll Call & SOI updates 2. Welcome and Chair Updates 3. Proposed Work Plan Update & Project Change Request 4. Proposed Redline from Small Group on Exemption for Recommendation 16 and 17 5. Rationale for Recommendation 13 - Registry Enforcement of TTL 6. AOB

2 1

TPR-P1 // 31 December 2022 Project Package
by Berry Cobb Jan. 9, 2023

Jan. 9, 2023

Dear WG, Please find a link below to project package for the TPR-P1 PDP (31 December 2022). This package is a snap-shot at the close of each month and developed by the leadership team to report on the working group’s activities and status of the project. It is also distributed to the GNSO Council to keep them informed as managers of the PDP. The package is deposited on the wiki so that we can track access statistics. Link: https://community.icann.org/x/MQDQCQ 1. Page 01 – Summary Dashboard and project SitRep 2. Page 02 – Activity metrics 3. Page 03 – Meeting metrics, Roster, & Group attendance 4. Page 04 – Project Plan, Gantt chart 5. Page 05 – Workplan Key points: * The WG Status is Behind Schedule and Health is At-Risk due to substantive review of the public comments for Phase 1A that in turn impacts restarting deliberations on Phase 1B. Please let staff know if you have questions. Thank you. B Berry Cobb Policy Development – Senior Program Manager Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 424 443 8960 Phone: +1 202 570 7240 Fax: +1 202 789 0104 Twitter: @berrycobb www.icann.org<https://www.icann.org/>

1 0

REMINDER | Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 10 January 2023
by Devan Reed Jan. 9, 2023

Jan. 9, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 10 January 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/HIw-DQ * For other places see: https://tinyurl.com/2b9x28mt [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2b9x28mt__;!!PtGJab4!51dhvwz…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * Alternate assignments 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 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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