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

Reminder: Input needed on proposal re: same TAC for multiple domains
by Emily Barabas 06 Apr '22

06 Apr '22

Dear all, Please take a few minutes before our next call to review Sarah’s draft on page 3 of the bulk use cases Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1mqPITDShqiVQ…> and provide input. If you do support allowing use of the same TAC for multiple domains, please assist in fleshing out the proposal. If you don’t support allowing use of the same TAC for multiple domains, please share this in the document, as well, along with any rationale. This will assist the leadership team in determining the path forward on charter question b5. Kind regards, Julie, Berry, Caitlin, and Emily From: GNSO-TPR <gnso-tpr-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Tuesday, 5 April 2022 at 19:35 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: [GNSO-TPR] Notes and action items - TPR WG Meeting #41 - 05 April 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, 12 April 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: 1. Take to the list, starting with 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”. 2. Leadership and staff to research the issue of whether changes to the extension of the expiration date after a transfer are in scope. Notes: Transfer Policy Review Phase 1 - Meeting #41 Tuesday, 05 April 2022 Proposed Agenda 1. Roll Call & SOI updates 2. Welcome & Chair updates a. Zack Muscovitch, update from the BC: Transfer Policy Locks -- short summary on three different kinds of locks. See email<https://mm.icann.org/pipermail/gnso-tpr/2022-April/000395.html> and below: Post-Creation Lock Ten days is too short. Leave it at 60 days if possible. Maybe 30 days is a happy medium, but 60 days is still preferable. The longer the better from a trademark enforcement perspective as it prevents having to redo a UDRP or demand letter, and also assists with preventing registrar hopping when a registrar is asked to take enforcement proceedings against an infringing or unlawfully used domain name. There may be an issue in shortening the period from a registrar’s perspective, in that a registrar customer may take advantage of promotional / loss-leader type pricing for the initial year and then the customer moves away to another registrar. Change of Registrant Lock The default rule should be a transfer lock following a change of registrant. However, a registrar should be required in a transparent manner, to enable a registrant, upon request to opt-out of the transfer lock or to reduce the transfer lock, rather then leave it to each registrar to decide whether they will generally permit opt-outs. Nevertheless, each registrar should retain discretion as to whether to permit a transfer even if the registrant has ostensibly opted out, for security reasons. A transfer lock should not prevent registrants and businesses from effecting bona fide transfers when necessary or desirable. There should be a fact-based rationale for the determination of the length of the default transfer lock, whether it is 60 or 30 days, for example. A BC member is looking to see whether Domain Abuse Activity Reporting data can provide any insight into the appropriate length for transfer locks. Change of Registrar Lock This lock does not appear to be of significant concern as it would usually coincide with a change of registrant lock. However, a registrant should not be prevented from transferring a domain name from one registrar to another, even after a recent registrar change, unless there is another type of lock at play. Questions/Discussion: * Question: Post-creation lock – why is 10 days too short? Answer: When a brand-protection company contacts a registrant about an abuse domain name, the registrant could say that the name just got transferred. Longer post-creation lock there is a longer period to deal with abuse issues with the registrant. * Question: Moving from registrar to another: gaining registrar wouldn’t know it was a transfer. Answer: If there is a change of registrant there should be a lock by default, but a change of registrar without a change of registrant shouldn’t have a lock. * Question: post-creation lock or change to registrant – what is the EPP status? Answer: We weren’t considering the technical term. Just no ability to move it. * Comment: Standardizing across the board should make it easier for registrants. * Comment from BC: Agree with standardization as long as it is a longer period. * Comment: When we do a change of registrar it could also be a change of registrant, so that would argue for the same lock period. b. Schedule leading up to ICANN74 and production of Initial Report (see attached PDF): * Several more sessions before we can wrap up our discussions. * This week bulk use and fast undo. * Small Team on NACK meeting on 06 April. * Next week is locking. * Re-evaluate TAC discussions. * Then swimlane and draft recommendations for WG review. * Goal is to get the report out right around ICANN74. 3. Continue discussion on bulk use cases – see: Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1mqPITDShqiVQ…> * Last talked about whether the registrar could assign the same TAC to a bulk transfer, as an option or a registrar/registrant agreement. * BTAPPA is not viable. * Plus BTAPPA is not available with every gTLD. Need a solution that works across all gTLDs. * With any transfer today the expiration date is extended by one year. If there is no consensus to change it, it will stay that way. * As much as possible any bulk action should mirror a single transfer. * Not sure if changing the expiration date in in scope for this group. We will check. * Expiration date can be reduced, not sure which registrars have extensions. * What about the ICANN transfer/transaction fee? Also to be “removed”? Not sure this is in scope. * Extending the expiration for a year gives some incentive to the gaining registrar. * Could include a question on this in the Initial Report. * On the TAC, the requirement is always that the TAC is unique to the domain. * This could mean that it needs to be the same TAC for each domain. Not sure that the registry cares; whatever the registrar sets the registry takes. * Are we recommending that the TAC is different for each domain in the transfer? That each TAC and domain is a unique combination – the domain name could be the unique aspect. But if this is the case, then we didn’t need to change the policy – they would all be unique by default. * For bulk, you could have multiple domains but each one would have its own TAC. * So maybe the question is if we want to make an exception to the requirement and allow one TAC per multiple domains? * If the TAC is not null, it would be unique in the registry generally. * In multi-domain transfers, for usability sake if the TTL on the TAC is sufficiently short you might be able to use the same TAC for multiple domains. * What’s important if – currently the TAC is defined as unique in the domain name in the registrar. If we are trying to make security better and more efficient, you need to add some rationale for why we are changing the security positioning in the policy and you should have some suggestions (maybe not policy) for solutions – such as short TTLs for multiple domains if you have one TAC for multiple, and addition identity checks for the registrant – such as two-factor authentication. * Current recommendations don’t say anything about uniqueness, but it is in the policy: See Auth-Info Codes Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…>: “Recommendation 9: The Working Group recommends that the TAC MUST be used no more than once per domain name. The Registry Operator MUST clear the TAC as part of completing the transfer request.” * This is about uniqueness per domain name; and it needs to be one-time use because a registrar should have a single source of TACs and you don’t want replay attacks. * The original intent was the one-time use. Once the registry accepts the TAC it can’t be used again. * We should make it clear that registrars should not restrict the number of domain names that can be transferred out. But today’s policy doesn’t state this. Say that registrants can do multi-domains at a single request. * Critical phrase is “randomly generated value” for each domain name. Don’t have to keep track because only used once, and you don’t have replay attacks, and doesn’t have to be stored. See: https://datatracker.ietf.org/doc/html/rfc9154#section-4.1 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc9154*se…>. * Could probably provide examples of good practice if we leave this as an optional registrar decision re: multiple domains to be transferred with a single TAC. * Is it the thought that registrars would expose this on the account manager interface, or only on customer service? That might dictate how you want this to work. * There is a minimum requirement of one TAC per domain name; if you want to change this then there needs to be an exemption/carve out. * Suggested new recommendation (from Sarah Wyld): “The Working Group recommends that the registrar MAY allow the use of the same TAC for multiple domains, provided the following requirements are met: * the domains must all be owned by the same registrant (what actually do we mean by this, is it every contact element or only the email?) * the domains are all being transferred to the same gaining registrar, etc.” * So maybe we're just requiring that the RNH can decide to set the same TAC on multiple domains, with corresponding security requirements, and that's as far as it needs to go. * I like the concept, and would suggest it should be included in the rationale about how the security profile is changed, as further support for being careful about multiple-domain transfers. * Uniqueness depends on who is to check – if registrars are creating a “randomly generated value” then that check is taken care of; registries should not be keeping track about uniqueness. * To say it another way, multi-domain is only seen at the registrar, not the registry; the protocol doesn't support it any other way. ACTION ITEM: Take to the list, starting with 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”. ACTION ITEM: Leadership and staff to research the issue of whether changes to the extension of the expiration date after a transfer are in scope. 4. Fast Undo Procedure * We intent in bringing this forward is to solidify the time window around post-create and post-transfer to make sure that time makes sense. Today there is no quick reversal. * WG members should review the homework, if they have not already done so. * When IRTP-B was done in 2011, The difference between Rr and Ry was crisp. There was little or no Vertical Integration. Since then, there is tremendous vertical integration within Registry/Registrar worlds and blurrier lines. We keep treating things as if there are still in place those crisp boundaries, and the reality is that it is different, and clawback/rollback and ERTP could behave differently where gaining or losing Registrar are vertically integrated with the Registry. * If a clawback was to happen it should have a time-scale or stamp. * Wonder how often the undo function is being used now in Verisign? Maybe we could reach out to Verisign? 5. AOB * Next call: Tuesday 12 April 2022 at 16:00 UTC

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 05 April 2022
by Julie Bisland 05 Apr '22

05 Apr '22

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

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 12 April 2022
by Julie Bisland 05 Apr '22

05 Apr '22

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 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 #41 - 05 April 2022
by Julie Hedlund 05 Apr '22

05 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, 12 April 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: 1. Take to the list, starting with 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”. 2. Leadership and staff to research the issue of whether changes to the extension of the expiration date after a transfer are in scope. Notes: Transfer Policy Review Phase 1 - Meeting #41 Tuesday, 05 April 2022 Proposed Agenda 1. Roll Call & SOI updates 2. Welcome & Chair updates a. Zack Muscovitch, update from the BC: Transfer Policy Locks -- short summary on three different kinds of locks. See email<https://mm.icann.org/pipermail/gnso-tpr/2022-April/000395.html> and below: Post-Creation Lock Ten days is too short. Leave it at 60 days if possible. Maybe 30 days is a happy medium, but 60 days is still preferable. The longer the better from a trademark enforcement perspective as it prevents having to redo a UDRP or demand letter, and also assists with preventing registrar hopping when a registrar is asked to take enforcement proceedings against an infringing or unlawfully used domain name. There may be an issue in shortening the period from a registrar’s perspective, in that a registrar customer may take advantage of promotional / loss-leader type pricing for the initial year and then the customer moves away to another registrar. Change of Registrant Lock The default rule should be a transfer lock following a change of registrant. However, a registrar should be required in a transparent manner, to enable a registrant, upon request to opt-out of the transfer lock or to reduce the transfer lock, rather then leave it to each registrar to decide whether they will generally permit opt-outs. Nevertheless, each registrar should retain discretion as to whether to permit a transfer even if the registrant has ostensibly opted out, for security reasons. A transfer lock should not prevent registrants and businesses from effecting bona fide transfers when necessary or desirable. There should be a fact-based rationale for the determination of the length of the default transfer lock, whether it is 60 or 30 days, for example. A BC member is looking to see whether Domain Abuse Activity Reporting data can provide any insight into the appropriate length for transfer locks. Change of Registrar Lock This lock does not appear to be of significant concern as it would usually coincide with a change of registrant lock. However, a registrant should not be prevented from transferring a domain name from one registrar to another, even after a recent registrar change, unless there is another type of lock at play. Questions/Discussion: * Question: Post-creation lock – why is 10 days too short? Answer: When a brand-protection company contacts a registrant about an abuse domain name, the registrant could say that the name just got transferred. Longer post-creation lock there is a longer period to deal with abuse issues with the registrant. * Question: Moving from registrar to another: gaining registrar wouldn’t know it was a transfer. Answer: If there is a change of registrant there should be a lock by default, but a change of registrar without a change of registrant shouldn’t have a lock. * Question: post-creation lock or change to registrant – what is the EPP status? Answer: We weren’t considering the technical term. Just no ability to move it. * Comment: Standardizing across the board should make it easier for registrants. * Comment from BC: Agree with standardization as long as it is a longer period. * Comment: When we do a change of registrar it could also be a change of registrant, so that would argue for the same lock period. b. Schedule leading up to ICANN74 and production of Initial Report (see attached PDF): * Several more sessions before we can wrap up our discussions. * This week bulk use and fast undo. * Small Team on NACK meeting on 06 April. * Next week is locking. * Re-evaluate TAC discussions. * Then swimlane and draft recommendations for WG review. * Goal is to get the report out right around ICANN74. 3. Continue discussion on bulk use cases – see: Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1mqPITDShqiVQ…> * Last talked about whether the registrar could assign the same TAC to a bulk transfer, as an option or a registrar/registrant agreement. * BTAPPA is not viable. * Plus BTAPPA is not available with every gTLD. Need a solution that works across all gTLDs. * With any transfer today the expiration date is extended by one year. If there is no consensus to change it, it will stay that way. * As much as possible any bulk action should mirror a single transfer. * Not sure if changing the expiration date in in scope for this group. We will check. * Expiration date can be reduced, not sure which registrars have extensions. * What about the ICANN transfer/transaction fee? Also to be “removed”? Not sure this is in scope. * Extending the expiration for a year gives some incentive to the gaining registrar. * Could include a question on this in the Initial Report. * On the TAC, the requirement is always that the TAC is unique to the domain. * This could mean that it needs to be the same TAC for each domain. Not sure that the registry cares; whatever the registrar sets the registry takes. * Are we recommending that the TAC is different for each domain in the transfer? That each TAC and domain is a unique combination – the domain name could be the unique aspect. But if this is the case, then we didn’t need to change the policy – they would all be unique by default. * For bulk, you could have multiple domains but each one would have its own TAC. * So maybe the question is if we want to make an exception to the requirement and allow one TAC per multiple domains? * If the TAC is not null, it would be unique in the registry generally. * In multi-domain transfers, for usability sake if the TTL on the TAC is sufficiently short you might be able to use the same TAC for multiple domains. * What’s important if – currently the TAC is defined as unique in the domain name in the registrar. If we are trying to make security better and more efficient, you need to add some rationale for why we are changing the security positioning in the policy and you should have some suggestions (maybe not policy) for solutions – such as short TTLs for multiple domains if you have one TAC for multiple, and addition identity checks for the registrant – such as two-factor authentication. * Current recommendations don’t say anything about uniqueness, but it is in the policy: See Auth-Info Codes Working Document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…>: “Recommendation 9: The Working Group recommends that the TAC MUST be used no more than once per domain name. The Registry Operator MUST clear the TAC as part of completing the transfer request.” * This is about uniqueness per domain name; and it needs to be one-time use because a registrar should have a single source of TACs and you don’t want replay attacks. * The original intent was the one-time use. Once the registry accepts the TAC it can’t be used again. * We should make it clear that registrars should not restrict the number of domain names that can be transferred out. But today’s policy doesn’t state this. Say that registrants can do multi-domains at a single request. * Critical phrase is “randomly generated value” for each domain name. Don’t have to keep track because only used once, and you don’t have replay attacks, and doesn’t have to be stored. See: https://datatracker.ietf.org/doc/html/rfc9154#section-4.1. * Could probably provide examples of good practice if we leave this as an optional registrar decision re: multiple domains to be transferred with a single TAC. * Is it the thought that registrars would expose this on the account manager interface, or only on customer service? That might dictate how you want this to work. * There is a minimum requirement of one TAC per domain name; if you want to change this then there needs to be an exemption/carve out. * Suggested new recommendation (from Sarah Wyld): “The Working Group recommends that the registrar MAY allow the use of the same TAC for multiple domains, provided the following requirements are met: * the domains must all be owned by the same registrant (what actually do we mean by this, is it every contact element or only the email?) * the domains are all being transferred to the same gaining registrar, etc.” * So maybe we're just requiring that the RNH can decide to set the same TAC on multiple domains, with corresponding security requirements, and that's as far as it needs to go. * I like the concept, and would suggest it should be included in the rationale about how the security profile is changed, as further support for being careful about multiple-domain transfers. * Uniqueness depends on who is to check – if registrars are creating a “randomly generated value” then that check is taken care of; registries should not be keeping track about uniqueness. * To say it another way, multi-domain is only seen at the registrar, not the registry; the protocol doesn't support it any other way. ACTION ITEM: Take to the list, starting with 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”. ACTION ITEM: Leadership and staff to research the issue of whether changes to the extension of the expiration date after a transfer are in scope. 4. Fast Undo Procedure * We intent in bringing this forward is to solidify the time window around post-create and post-transfer to make sure that time makes sense. Today there is no quick reversal. * WG members should review the homework, if they have not already done so. * When IRTP-B was done in 2011, The difference between Rr and Ry was crisp. There was little or no Vertical Integration. Since then, there is tremendous vertical integration within Registry/Registrar worlds and blurrier lines. We keep treating things as if there are still in place those crisp boundaries, and the reality is that it is different, and clawback/rollback and ERTP could behave differently where gaining or losing Registrar are vertically integrated with the Registry. * If a clawback was to happen it should have a time-scale or stamp. * Wonder how often the undo function is being used now in Verisign? Maybe we could reach out to Verisign? 5. AOB * Next call: Tuesday 12 April 2022 at 16:00 UTC

1 0

**STARTS IN 15 MINUTES** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 05 April 2022
by Julie Bisland 05 Apr '22

05 Apr '22

**STARTS IN 15 MINUTES** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 05 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/LBAiCw * Check your time zone: https://tinyurl.com/yfh6jc8x [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/yfh6jc8x__;!!PtGJab4!v8Q3co5…> 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

2 1

HOMEWORK ASSIGNMENT & Proposed agenda for meeting #41 on Tuesday 5 April 2022 at 16:00 UTC
by Emily Barabas 04 Apr '22

04 Apr '22

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 5 April 2022 at 16:00 UTC. Prior to Tuesday’s call, please review the following materials covering previous discussions on a potential fast undo procedure: * Initial Report – IRTP Part B: pages 49-54 * Final Report – IRTP Part B: pages 14-19 Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #41 Proposed Agenda 1. Roll Call & SOI updates 2. Welcome & Chair updates 1. Continue discussion on bulk use cases * Working document<https://docs.google.com/document/d/1mqPITDShqiVQ4rH6x-FlvePmL_c05CtyWGgkpj9…> 2. Fast Undo Procedure 3. AOB * Next call: Tuesday 12 April 2022 at 16:00 UTC

2 2

May & June 2022 calls | Transfer Policy Review PDP WG
by Julie Bisland 04 Apr '22

04 Apr '22

**We are sending in advance to get dates on everyone’s calendar. Dear all, The calls for May & June 2022 for the Transfer Policy Review PDP WG are listed below. The .ics file attached is a recurring order; please be sure to download it as “recurring” vs. a one-time event to ensure all the dates show up on your calendar. The scheduled start time is 16:00 UTC for 90 minutes. * Tuesday, 03 May 2022 * Tuesday, 10 May 2022 * Tuesday, 17 May 2022 * Tuesday, 24 May 2022 * Tuesday, 07 June 2022 Future invitations will be sent out closer to the date of the call. The next call is scheduled for tomorrow, 05 April 2022, you should have already received the meeting invite. Thank you. With kind regards, Julie

1 0

Transfer Policy Review PDP WG
by ICANN Policy Calendar 04 Apr '22

04 Apr '22

Meeting: Transfer Policy Review PDP WG Date/Time: Recurring every Tuesday at 16:00 UTC for 90 minutes, 03 May 2022 through 07 June 2022 Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# 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> Wiki Agenda meeting pages 2022: https://community.icann.org/x/Z4HOCg ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form<https://docs.google.com/forms/d/e/1FAIpQLScXP3-H595xH4EFgaR3ydOr-1o9BLAVGUI…> to communicate who the alternate is replacing and for which period. This information will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Everyone when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and 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. For 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

1 0

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 05 April 2022
by Julie Bisland 04 Apr '22

04 Apr '22

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 05 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/LBAiCw * Check your time zone: https://tinyurl.com/yfh6jc8x [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/yfh6jc8x__;!!PtGJab4!v8Q3co5…> 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