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

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

VOLUNTEERS NEEDED: Small group on reasons for denial (NACK)
by Emily Barabas 31 Mar '22

31 Mar '22

Dear all, As a reminder, we are looking for a handful of volunteers to join a small group that will finalize proposed revisions on the reasons for denial. This will be a short-lived group and participation is not expected to be a significant time commitment. Please respond here if you are interested in participating. Kind regards, Julie, Caitlin, Berry, and Emily From: GNSO-TPR <gnso-tpr-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Tuesday, 29 March 2022 at 19:40 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: [GNSO-TPR] Notes and action items - TPR WG Meeting #40 - 29 Mar 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, 05 April 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: ACTION ITEM: WG members to reply to the WG email distribution list if they are interested in joining a small team to review the NACKing/reasons for denial working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…> to finalize draft language for review by the full WG. Transfer Policy Review Phase 1 - Meeting #40 Tuesday 29 March 2022 at 1600 UTC 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) * We left our denial/reasons for NACKing with open items; we are looking to have a spin-off small team to look at the NACKing working document to clean up any items we left open. Maybe 5-6 people. Trying to get the draft language solidified to bring to the group. If you are interested let us know. Good to have a representative group if possible. ACTION ITEM: WG members to reply to the WG email distribution list if they are interested in joining a small team to review the NACKing/reasons for denial working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…> to finalize draft language for review by the full WG. 3. Continue discussion on bulk use cases (75 minutes) – See: Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1mqPITDShqiVQ…> * Question for discussion: Are there two different paths – one where a year is added on; the other moving from one registrar to another but not changing the life cycle? * Question for discussion: Registry back-end operators – how would a transaction identify as a bulk transfer when it was one of many? In a bulk scenario even if only 10 when they are going to multiple back-end registries? Would this be allowed? Put it differently, how many domain names do you need to make a bulk transfer? * Suggested Answer: (Theo Guerts) It is a question of scale. The sweet spot is around 2500 hundred domain names, because then you have to plan your transfers in batches. Suggest not adding an extra year with a bulk transfer. * Maybe there’s two types of bulk. Some registries do this already and some don’t. * If you transfer with multiple registries involved: If a registrar is contemplating transferring a bunch of names across registries – you could have ones that aren’t interrelated. * When we think about the normal transfer process it includes the extension of the registration term by 1 year in an automated fashion over EPP, subject to FOA and NACKing. ICANN has a bulk transfer method without term extensions, but that involves certain business considerations. There is a PPA (partial portfolio) not by EPP and not with a term extension, but as a registry service. * BTAPPA already does that and leaves the expiry date intact. (BTAPPA = Verisign bulk transfer service.) * Other registries offer BTAPPA as well. But certain qualifications have to be met to use it. Simple bulk transfers not in conjunction with a merger, sale, etc. are not allowed under BTAPPAs. * Question for Roger or staff: Is this out of scope for this WG? * When you do bulk transfers you have to prioritize. You go from TLD to TLD. * it’s not clear how us adding simple bulk transfer would impact ICANN’s expedited RSEP for BTAPPA. * Resellers often are out of the question and we are stuck. * Bulk transfer is a database switch from registrar to registrar. * When two different back-end registries are involved there are two different thought processes. Two separate scenarios. * Question: What number is considered bulk and does it apply to the registrar or registry? * Bulk transfers are a very sharp knife/powerful tool. They are a very focused thing. * Question for Theo: What did you mean by “resellers are stuck”? Answer: The transfer process is focused on the registrant being able to transfer wherever they like, and they have to help the resellers. Some registrars create barriers for resellers to transfer. A reseller can't easily move its business to a new Registrar. Resellers have the issue that they have no rights under the RAA. * For bulk transfers you may have three scenarios – a few names, some names, a huge number of names. Are there three buckets or more? * Holida can correct me if I am wrong, but I don't believe that there is a limit on who can report issues to Compliance. (Compliance agrees that this is a correct observation.) * How can we make a policy binding for a contracted party but also for resellers who are not contracted? Or is there a different way to handle this? We cannot create contract language for registrars. * RAA Sec. 3.12: Registrar is responsible for the provision of Registrar Services for all Registered Names that Registrar sponsors being performed in compliance with this Agreement, regardless of whether the Registrar Services are provided by Registrar or a third party, including a Reseller. * There are two things: bulk transfers and BTAPPA. Standard transfer policy has a lot of requirements, while the BTAPPA is an industry tool. BTAPPA wasn’t designed for bulk commercial use. * This bulk discussion is not about BTAPPA; we will talk about that later. Is there a policy that falls somewhere in between? * Don’t think there is a charter question related to extending a year for a transfer. (Staff confirmed that there is not.) * BTAPPA comes at a pretty high cost – would there be fees associated with a bulk transfer between BTAPPA and the current policy? * Is this a problem that this transfer policy should resolve, or does it fall outside of this policy? Maybe pose the question to the community and ask for suggestions? * Here is the charter question for the current phase of work: b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered? * Not sure the charter question above relates to the current discussion. * Questions for phase 2: * In light of these challenges described in section 3.1.7.2 of the Final Issue Report, should the required fee in Section I.B.2 of the Transfer Policy be revisited or removed in certain circumstances? * Should the scope of voluntary bulk transfers, including partial bulk transfers, be expanded and/or made uniform across all registry operators? If so, what types of rules and considerations should govern voluntary bulk transfers to partial bulk transfers? * Some of this discussion may be more appropriate for phase 2. Charter Question b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered? Note: As a starting point, this charter question was added in response to the following feedback to the Transfer Policy Status Report Survey from the RrSG:[It’s] [d]ifficult for Registered Name Holders to retrieve [AuthInfo Codes] for a long list of domains as there are no requirements to permit bulk [AuthCode] requests. (Note: the discussion of partial bulk transfers and the BTAPPA process will be discussed in Phase 2 under question i2. This discussion is limited to the consideration of bulk retrieval of AuthInfo Codes.) * Do think there need to be additional security measures, compliance, and registries adding a claw-back option. * This is an interesting question – you get a bunch of names move in volume, but the request is to lower the security, which would make it more dangerous. Seems that we should be looking at additional security measures. * Notifications are a big part of that security mechanism – do they need to be enhanced? * Could bring in a lot of legal issues and problems for individual registrants, so having a claw-back mechanism could be helpful. * Re: the TAC and moving large numbers of names from one registrar to another – from a security point of view there should be one TAC per name, but if you want to simplify the process maybe think about extra security for getting the single TAC for multiple domain names. If you are going to do multiple transfers in parallel then the TACs should have extra security, such as two-factor authentication. * I’d like to see an additional communication method, requirement for password to be re-entered, capture of IP login etc. Just throwing some ideas out there. * In that scenario (using the same TAC on multiple domains) the Registrar could also remove (expire) the TAC after a shorter window. * Just because it’s possible to generate a TAC for each domain name transfer, doesn’t mean that all registrars will do it that way. * Should check to see if the current draft recommendations allow for efficient bulk transfers. * If we wanted to be most security then the TAC should be unique for each domain name at the registrar. If you are randomly generating them at each usage then you achieve that. But that is a bit tedious and not customer service friendly for bulk transfer, so you could add additional security feature for bulk transfers per domain name, such as two-factor authentication, or a shorter window for TAC identity. Maybe as a suggestion rather than a must. * If a TAC is unique at the registrar level is different from saying the TAC and domain name is unique. * 136867 – example authorization code from Google as a two-factor authentication. It expires after a short time, a window during which it is valid. Needs to be paired with a URL for a certain amount of time. * The big focus is whether one TAC can be assigned to transfer multiple domain names and, if so, are there additional security measures. 4. AOB (5 minutes) * Next call: Tuesday 5 April 2022 at 16:00 UTC

1 1

Post Call | Transfer Policy Review PDP WG | Tuesday, 29 March 2022
by Julie Bisland 29 Mar '22

29 Mar '22

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

Re: [GNSO-TPR] Reasons to deny a transfer
by Rich 29 Mar '22

29 Mar '22

Hi team, I know this is a topic we’ve already discussed but it came up again for us at Tucows recently and I want to share some more thoughts for the group’s consideration before we come back to it in a meeting I think we should keep ‘violation of the registration agreement’ in the reasons why the losing registrar MAY deny a transfer. If we want the DNS space to have the trust and respectability of the Internet community, we must take a ‘responsible registrar’ approach to certain types of domain. Issues outlined in the DNS Abuse Framework <https://dnsabuseframework.org/>, for example, may extend beyond standard DNS Abuse in some cases, but absolutely causes terrible harm to the world that disallowing domain transfer is appropriate. For example, a domain suspended for promoting terrorism, shouldn’t simply be allowed to be transferred to a less-aware registrar and continue promoting terrorism. The extremely minor speed bump of having to find a new domain and a new registrar is the literal least we can do. I’m concerned that by removing this option from registrars we lose an important measure to prevent abuse and other online harms. When we discussed this topic in a recent meeting, I had thought that the registrar would address the harm by revoking ownership of the domain name (e.g. by updating the RNH contact info to their own), but upon further discussion both internally and with some other Rr’s I have come to understand that is not common practice nor should it be the expected path. As such, there needs to be some method for the Rr to deny the transfer in this type of situation while the original RNH remains listed on the registration record. I know there’s a concern that some registrars might have unreasonable terms, but don't we generally expect that the Rr will set reasonable terms and the RNH will understand those terms prior to accepting them? If we start assuming that the RNH did not understand the terms they accepted, that seems like a dangerous path to go down. Going back to the terrorism example, a registrar that hasn’t signed on to the DNS Abuse Framework isn’t required to suspend a domain for terrorism (unless told to by appropriate LEA, but that’s a different case). But one that has shouldn’t be forced to allow terrorists to continue at another Registrar, they should be able to follow their published policy of suspending the service and denying transfer away. I understand this isn’t simple and there are valid concerns about Registrars setting impossible or inappropriate Terms in order to retain customers by preventing transfer out. I hope that as a team we can find some way to balance all these issues and include violation of the registration agreement in our updated reasons why the Registrar MAY deny the transfer. Thank you, *Rich Brown* Compliance Officer Tucows, Inc

1 0

Notes and action items - TPR WG Meeting #40 - 29 Mar 2022
by Julie Hedlund 29 Mar '22

29 Mar '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, 05 April 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: ACTION ITEM: WG members to reply to the WG email distribution list if they are interested in joining a small team to review the NACKing/reasons for denial working document<https://docs.google.com/document/d/1L2bZnhJUY3VxyAjVCrkyVqdttOPn2EaqBARRRnE…> to finalize draft language for review by the full WG. Transfer Policy Review Phase 1 - Meeting #40 Tuesday 29 March 2022 at 1600 UTC 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) * We left our denial/reasons for NACKing with open items; we are looking to have a spin-off small team to look at the NACKing working document to clean up any items we left open. Maybe 5-6 people. Trying to get the draft language solidified to bring to the group. If you are interested let us know. Good to have a representative group if possible. ACTION ITEM: WG members to reply to the WG email distribution list if they are interested in joining a small team to review the NACKing/reasons for denial working document<https://docs.google.com/document/d/1L2bZnhJUY3VxyAjVCrkyVqdttOPn2EaqBARRRnE…> to finalize draft language for review by the full WG. 3. Continue discussion on bulk use cases (75 minutes) – See: Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1mqPITDShqiVQ…> * Question for discussion: Are there two different paths – one where a year is added on; the other moving from one registrar to another but not changing the life cycle? * Question for discussion: Registry back-end operators – how would a transaction identify as a bulk transfer when it was one of many? In a bulk scenario even if only 10 when they are going to multiple back-end registries? Would this be allowed? Put it differently, how many domain names do you need to make a bulk transfer? * Suggested Answer: (Theo Guerts) It is a question of scale. The sweet spot is around 2500 hundred domain names, because then you have to plan your transfers in batches. Suggest not adding an extra year with a bulk transfer. * Maybe there’s two types of bulk. Some registries do this already and some don’t. * If you transfer with multiple registries involved: If a registrar is contemplating transferring a bunch of names across registries – you could have ones that aren’t interrelated. * When we think about the normal transfer process it includes the extension of the registration term by 1 year in an automated fashion over EPP, subject to FOA and NACKing. ICANN has a bulk transfer method without term extensions, but that involves certain business considerations. There is a PPA (partial portfolio) not by EPP and not with a term extension, but as a registry service. * BTAPPA already does that and leaves the expiry date intact. (BTAPPA = Verisign bulk transfer service.) * Other registries offer BTAPPA as well. But certain qualifications have to be met to use it. Simple bulk transfers not in conjunction with a merger, sale, etc. are not allowed under BTAPPAs. * Question for Roger or staff: Is this out of scope for this WG? * When you do bulk transfers you have to prioritize. You go from TLD to TLD. * it’s not clear how us adding simple bulk transfer would impact ICANN’s expedited RSEP for BTAPPA. * Resellers often are out of the question and we are stuck. * Bulk transfer is a database switch from registrar to registrar. * When two different back-end registries are involved there are two different thought processes. Two separate scenarios. * Question: What number is considered bulk and does it apply to the registrar or registry? * Bulk transfers are a very sharp knife/powerful tool. They are a very focused thing. * Question for Theo: What did you mean by “resellers are stuck”? Answer: The transfer process is focused on the registrant being able to transfer wherever they like, and they have to help the resellers. Some registrars create barriers for resellers to transfer. A reseller can't easily move its business to a new Registrar. Resellers have the issue that they have no rights under the RAA. * For bulk transfers you may have three scenarios – a few names, some names, a huge number of names. Are there three buckets or more? * Holida can correct me if I am wrong, but I don't believe that there is a limit on who can report issues to Compliance. (Compliance agrees that this is a correct observation.) * How can we make a policy binding for a contracted party but also for resellers who are not contracted? Or is there a different way to handle this? We cannot create contract language for registrars. * RAA Sec. 3.12: Registrar is responsible for the provision of Registrar Services for all Registered Names that Registrar sponsors being performed in compliance with this Agreement, regardless of whether the Registrar Services are provided by Registrar or a third party, including a Reseller. * There are two things: bulk transfers and BTAPPA. Standard transfer policy has a lot of requirements, while the BTAPPA is an industry tool. BTAPPA wasn’t designed for bulk commercial use. * This bulk discussion is not about BTAPPA; we will talk about that later. Is there a policy that falls somewhere in between? * Don’t think there is a charter question related to extending a year for a transfer. (Staff confirmed that there is not.) * BTAPPA comes at a pretty high cost – would there be fees associated with a bulk transfer between BTAPPA and the current policy? * Is this a problem that this transfer policy should resolve, or does it fall outside of this policy? Maybe pose the question to the community and ask for suggestions? * Here is the charter question for the current phase of work: b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered? * Not sure the charter question above relates to the current discussion. * Questions for phase 2: * In light of these challenges described in section 3.1.7.2 of the Final Issue Report, should the required fee in Section I.B.2 of the Transfer Policy be revisited or removed in certain circumstances? * Should the scope of voluntary bulk transfers, including partial bulk transfers, be expanded and/or made uniform across all registry operators? If so, what types of rules and considerations should govern voluntary bulk transfers to partial bulk transfers? * Some of this discussion may be more appropriate for phase 2. Charter Question b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered? Note: As a starting point, this charter question was added in response to the following feedback to the Transfer Policy Status Report Survey from the RrSG:[It’s] [d]ifficult for Registered Name Holders to retrieve [AuthInfo Codes] for a long list of domains as there are no requirements to permit bulk [AuthCode] requests. (Note: the discussion of partial bulk transfers and the BTAPPA process will be discussed in Phase 2 under question i2. This discussion is limited to the consideration of bulk retrieval of AuthInfo Codes.) * Do think there need to be additional security measures, compliance, and registries adding a claw-back option. * This is an interesting question – you get a bunch of names move in volume, but the request is to lower the security, which would make it more dangerous. Seems that we should be looking at additional security measures. * Notifications are a big part of that security mechanism – do they need to be enhanced? * Could bring in a lot of legal issues and problems for individual registrants, so having a claw-back mechanism could be helpful. * Re: the TAC and moving large numbers of names from one registrar to another – from a security point of view there should be one TAC per name, but if you want to simplify the process maybe think about extra security for getting the single TAC for multiple domain names. If you are going to do multiple transfers in parallel then the TACs should have extra security, such as two-factor authentication. * I’d like to see an additional communication method, requirement for password to be re-entered, capture of IP login etc. Just throwing some ideas out there. * In that scenario (using the same TAC on multiple domains) the Registrar could also remove (expire) the TAC after a shorter window. * Just because it’s possible to generate a TAC for each domain name transfer, doesn’t mean that all registrars will do it that way. * Should check to see if the current draft recommendations allow for efficient bulk transfers. * If we wanted to be most security then the TAC should be unique for each domain name at the registrar. If you are randomly generating them at each usage then you achieve that. But that is a bit tedious and not customer service friendly for bulk transfer, so you could add additional security feature for bulk transfers per domain name, such as two-factor authentication, or a shorter window for TAC identity. Maybe as a suggestion rather than a must. * If a TAC is unique at the registrar level is different from saying the TAC and domain name is unique. * 136867 – example authorization code from Google as a two-factor authentication. It expires after a short time, a window during which it is valid. Needs to be paired with a URL for a certain amount of time. * The big focus is whether one TAC can be assigned to transfer multiple domain names and, if so, are there additional security measures. 4. AOB (5 minutes) * Next call: Tuesday 5 April 2022 at 16:00 UTC

1 0

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

29 Mar '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 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

Update from NCSG
by farzaneh badii 29 Mar '22

29 Mar '22

All, We have discussed some of the issues with NCSG, and here are some points they raised: 1. Transfer fee: NCSG is asking whether there are recorded cases of registrars charging for doing transfers and if we can find a few policies that mention transfer fee. 2. Adding abuse: we are still discussing this but we wanted to ask whether it is not at all possible to just provide a list of abusive conduct that can lead to denial of transfer instead of mentioning fraud or abuse. 3. Identity: as much as possible we need to leave whatever mentions of "identity" of domain name registrants in the transfer policy and come up with alternative terms that can meet our objectives but do not require identification of domain name registrant. I am so sorry I have weekly schedule conflicts with the meetings of this group but with Wisdom we catch up and be engaged. Best regards, Farzaneh

1 0

**STARTING IN 12 MINUTES** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 29 March 2022
by Julie Bisland 29 Mar '22

29 Mar '22

**STARTING IN 12 MINUTES** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 29 March 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/KhAiCw * Check your time zone: https://tinyurl.com/42rdpvy9 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/42rdpvy9__;!!PtGJab4!r1TaB5z…> 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

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 29 March 2022
by Julie Bisland 28 Mar '22

28 Mar '22

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 29 March 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/KhAiCw * Check your time zone: https://tinyurl.com/42rdpvy9 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/42rdpvy9__;!!PtGJab4!r1TaB5z…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Proposed agenda for meeting #40 on Tuesday 29 March 2022 at 16:00 UTC
by Emily Barabas 24 Mar '22

24 Mar '22

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 29 March 2022 at 16:00 UTC. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #40 Proposed Agenda 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 1. Continue discussion on bulk use cases (75 minutes) * Working document<https://docs.google.com/document/d/1mqPITDShqiVQ4rH6x-FlvePmL_c05CtyWGgkpj9…> 2. AOB (5 minutes) * Next call: Tuesday 5 April 2022 at 16:00 UTC

1 0