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 April 4, 2022

April 4, 2022

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 March 31, 2022

March 31, 2022

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 March 29, 2022

March 29, 2022

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 March 29, 2022

March 29, 2022

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 March 29, 2022

March 29, 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<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 March 29, 2022

March 29, 2022

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 March 29, 2022

March 29, 2022

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 March 29, 2022

March 29, 2022

**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 March 28, 2022

March 28, 2022

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 March 24, 2022

March 24, 2022

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

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

March 23, 2022

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

3 2

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 29 March 2022
by Julie Bisland March 22, 2022

March 22, 2022

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 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 #39 - 22 Mar 2022
by Julie Hedlund March 22, 2022

March 22, 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, 29 March 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: None captured. Transfer Policy Review Phase 1 - Meeting #39 Tuesday 22 March 2022 at 1600 UTC 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) a. Update from Steinar Grøtterød, ALAC: Distributed results of discussion in the CPWG on locks. Based on that discussion we had a poll. There were around 40 responses. The results showed support for a 60-day period for locks as well as 30 days. Positive response to keeping the same policy for all locks. This input should be taken as informal. Questions/Comments: * Question: Noted that in the time period for the transfer locks there was equal support for 10 and 60 days, but for creation lock there was support for the 30-day period. Any explanation for that result? Answer: There was a concern about whether there was enough time for the UDRP with 10 days, so less support for that, but in general there was support for keeping the shorter period. * Question: Seems like the respondents didn’t understand the locks relating to the UDRP, would more information help? Also, isn’t a goal to standardize the time periods for the lock? * Question: Could you say what the policy was supposed to be that would be the same for all registry operators? Answer: We thought it would be more user friendly to have the same policy. That it should be the same number of days for creation and transfer locks. * There are more registries that would prefer not to have activities in this space. Need a discussion as to whether there should be a requirement on registry operators. This has not been decided in this WG. * Steinar: Would like to hear if 10 days is a real show stopper for the UDRP policy. * 60 days seems far too long and 10 days seems to have general support. * Question: Are we asking whether 10 days from creation enough time to file a UDRP? Answer: In post-create and post-transfer is 10 days enough time to complete a UDRP? * Once a UDRP is notified the name is locked until settled, so the creation or transfer lock no longer applies. * Don’t think the creation or transfer locks had anything to do with the UDRP. The lock for the UDRP on notification is separate. The length of a creation lock shouldn’t have any bearing on how long it takes to complete a UDRP. These locks should be mutually exclusive. * The brand protection services are pretty quick to file a UDRP. Once settled, the creation lock would still apply. * This seems a non-issue… very few UDRPs filed within first 30 days as there would rarely be any usage by then, plus time to prepare and file. * Once the creation lock expires, the UDRP lock still applies. If we are looking at 10 days, if a UDRP is filed in 12 days then the name might have been transferred, in which case some of the UDRP filing would have to be updated to reflect the transfer. This was also an issue that WIPO brought up. If a complaint is filed, but the domain is not locked in time, and transferred to a new Registrar, then the admin process has to reset as owner(RNH)/Registrar have changed. * Even if they were to change the registrar, another 10-day transfer lock would apply. * Question: If we were to standardize a post-creation or transfer lock, would this be a registry lock or a registrar lock? Answer: Roger’s assumption was that the lock was enforced at the registrar level. Registries would only be brought in if there was a court case. The post-creation and post-transfer would be the registrar handling the locking of the domain during that period. * Question: There this also an open question as to how registry lock is handled during the transfer process? When is a registry lock removed or put back on? * Think the registry lock is outside the transfer policy. * Question: While the registry lock service is out of scope, there still is an issue of when the registry lock is dealt with? Seems like that point is in scope for this WG. * If the registry lock doesn’t come off, then the losing registrar will deny the transfer to the gaining registrar. * Seems that it would be good to have a stated policy on this – even if the statement is that the policy does not address this. But think the registrars would want to know what are their obligations. * Don’t see why it needs to be treated differently than any other lock? If the domain owner who requested it in the first place asked for it to be removed, then it gets removed. if not, isn't the whole point of the lock to prevent a transfer? * In the swimlane it is the sponsoring registrar’s responsibility to address any locks, including registry locks. * Seems that we’ll need another swimlane review session. In relation to who does what and when, if we look at this in the swimlane in general the moment the TAC is provisioned (which is an automated step), if there are any locks that the sponsoring registrar determines would prevent the transfer they shouldn’t be provisioning the TAC, the losing/sponsor registrar should resolve any locks. If all the locks are not cured there is an out to kick it back to the losing registrar. * The registry still has to do that final check. * The locks that we are talking about are in terms of EPP statuses being set. There really is no such thing as a “registry lock”, but a set of EPP statuses. Should talk in terms of service statuses. * “5. Registry Lock: Registry Operator may offer the Registry Lock service, which is a registry service that allows an authorized representative from the sponsoring Registrar to request the activation or deactivation of any of the following EPP statuses: serverUpdateProhibited, serverDeleteProhibited and⁄or serverTransferProhibited.” * A registry will set these EPP statuses as part of a registry lock service in order to protect registrants. There is an interaction with these registry lock statuses with the transfers that we need to understand. A registry to create a lock service that a RNH could ask for a transfer, registrar handles the client statuses that they have to cure, but the registry statuses stay in place. The registry gets a transfer request, but how do they distinguish that from an attack? The registrar of record would get a notification and then would have to notify the RNH, cure the lock, get the name transferred, and then the registry would reinstitute the lock. * Maybe the Registry which offers the lock service could include in the lock removal process that the RNH should tell them the correct gaining registrar and the Registry only allows the transfer to that registrar. * Don’t think we should treat registry lock as any special. Could simplify it by looking just at the EPP status. * The window of vulnerability is the time period between when the registry lock status is removed until it is restored. That’s a vulnerability for the registrant, since the TAC is at risk of getting lost or stolen. b. Update From ICANN Org Compliance re: “3.9.3 Domain name in Registrar Lock Status, unless the Registered Name Holder is provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request.” * Compliance invokes 3.9.3 when the domain has an internal lock applied. Example is an internal lock for additional security. The registrant had to follow some steps to request for the lock to be disabled. Generally, the registrar can’t deny a transfer if an internal lock has been applied without giving an opportunity for the registrant to request that the internal lock is removed. Helpful if the policy could provide clarification on what is “reasonable.” 3. Begin discussion on bulk use cases (60 minutes) Related 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?” See AuthInfo Codes Working Document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…>, page 9. * Theo Geurts: In the Netherlands, if you want to transfer your portfolio from one registrar to another, you provide the names to the gaining registrar, the registry contacts the losing registrar to get the necessary verifications, then the registry moves the database. Pretty easy and cost effective. Dutch registry charges 50 Euro for a database switch. Current bulk transfers are overly complex. * For a lot of TLDs it’s even easier as the transfer is instant. * Would like to see an additional security level and claw back because of the number of domains. * Think we should be aware that this already happens in the gTLD space. As long as there can be a transfer that doesn’t go against the transfer policy, those transfers can happen. * We are talking about large-scale transfers outside of BTAPPA. * Overall the bulk transfer process should be similar to the single-domain transfer. * Question: Have we talked about the contact information – how would that be handled for bulk transfers? Couldn’t find recommendations on contact information in the AuthInfo Code working document. * I don’t think that contact info is needed… because the gaining registrar literally has to know the registrant. * Think that the BTAPPA is a fast-track registry service. There is pre-approved boilerplate language, so we would have to make sure that our recommendations don’t interfere with things that already exist. Also, not clear in the charter question what “bulk” means, but it is defined in the BTAPPA process. * Think we are going to discuss what “bulk” is. * So areas that could be different are (1) how the TAC is obtained, (2) if the notice of TAC provision needs to be sent once or multiple times, (3) if multiple domains + TACs can be submitted in one order to the registry (does it matter?) (4) how is it verified that they should all go together, (5) does the contact info all have to be the same pre-transfer, (6) does the contact info all have to be the same post-transfer. * Need to think also about whether a year is added to the extension. * Need to separate this out from BTAPPA. 4. AOB (5 minutes) * Next call: ICANN73 session on Tuesday 29 March 2022 at 16:00 UTC

1 0

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

March 22, 2022

**STARTING IN 15 MINUTES** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 22 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/KBAiCw * Check your time zone: https://tinyurl.com/fh6m7max [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/fh6m7max__;!!PtGJab4!tKeGu8Y…> 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

AT-LARGE INPUT TO THE DISCUSSION OF POST-CREATION AND POST-TRANSFER LOCKS
by Steinar Grøtterød March 22, 2022

March 22, 2022

Dear TPR Work Group members, The Consolidated Policy Working Group (CPWG) is the At-Large forum for discussing policy related issues and giving advice to the ICANN community. At-Large is represented in the GNSO transfer Policy Review Policy Development Process (TPR-PDP) with 2 members, 2 alternates and 4 observers. The At-Large TPR-PDP members continuously inform the CPWG members about the progress in the TPR-PDP working group and seek feedback and advice in essential questions given by the work in the TPR-PDP. In order to get the CPWG input to questions connected to post-creation and post-transfer locks, an informal “poll” was held at the CPWG meeting on March 16, 2022. In front of the meeting, information about the discussion and work done by the GNSO TPR-PDP were distributed to the CPWG members. The information also included the “poll questions”. The “poll questions” were conducted based on the work done in the TRP-PDP. In addition, the “poll” included a question reflecting CPWG input to a mandatory policy for all Registry Operators. The poll questions and the results For the post-creation lock question What lock period will be of preference: * 10 days post-creation lock: 31% * 30 days post-creation lock: 59% * 60 days post-creation lock: 7% * Not sure: 0% * Abstain: 3% For the post-transfer lock question What lock period will be of preference: * 10 days post-transfer lock: 41% * 30 days post-transfer lock: 45% * 60 days post-transfer lock: 7% * Not sure: 3% * Abstain: 3% For the question regarding Registry Operator * Same policy for all Registry Operator: 76% * A Registry Operator MAY define a different transfer lock policy: 14% * Not sure: 7% * Abstain: 3% Please note that the 30 days alternative is added to the poll to get more alternatives. The 30 days locks are not discussed as an alternative in the TRP-PDP WG. The result may be seen as: * CPWG is in the opinion that the present practice with a 60 day post-creation and post-transfer lock is too long. * The poll may signal that there could be a different lock periode between the post-creations and the post-transfers. * A significant number of CPWG members favors that the updated Inter-Registrar Transfer Policy should be the same for all Registry Operators. In our opinion, this makes it more user friendly by having a level playing field across all operators. We emphasize the fact that the results of the poll and this feedback to the TRP-PDP is informal and may not reflect At-Large view when the PDP is up for vote to be finalized. Regards, Steinar Grøtterød At-Large

1 0

Proposed agenda for meeting #39 on Tuesday 22 March 2022 at 16:00 UTC
by Emily Barabas March 21, 2022

March 21, 2022

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 22 March 2022 at 16:00 UTC. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #39 Proposed Agenda 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 1. Begin discussion on bulk use cases (60 minutes) 2. Continued deliberations on Denial of Transfers (15 minutes) * Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…> 3. AOB (5 minutes) * Next call: ICANN73 session on Tuesday 29 March 2022 at 16:00 UTC

1 0

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 22 March 2022
by Julie Bisland March 21, 2022

March 21, 2022

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

Staff action item: origins of NACKing categories MAY, MUST, and MAY NOT
by Emily Barabas March 17, 2022

March 17, 2022

Dear Working Group members, Following the most recent WG meeting, staff had an action item to research the origins of the terms “MAY”, “MUST”, and “MAY NOT” as categories related to denial of transfers in general and specifically as it relates to I.A.3.9.5. Going back to the 2002 ICANN DNSO Transfers Task Force Final Report & Recommendations<http://www.dnso.org/dnso/notes/20030212.NCTransferTF-gaining-and-losing-reg…>, recommendation 24 lists circumstances under which a Losing Registrar MAY deny a transfer. Recommendation 25 provides a non-exhaustive list of circumstances under which a transfer MAY NOT be denied (the language specifically states: “Instances when the Losing Registrar may not deny a transfer include, but are not limited to;”). The list includes “e. General payment defaults between Registrar and business partners / affiliates in cases where the Registrant for the domain in question has paid for the registration.” This same language is currently reflected in I.A.3.9.5. The introduction of a category of circumstances under which a Losing Registrar MUST deny a transfer came with the implementation of recommendations associated with IRTP Part C<https://gnso.icann.org/sites/default/files/filefield_34607/irtp-c-final-rep…>. The updated policy went into effect on December 2016<https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en>. In short, the “MAY” and “MAY NOT” not categories were the two originally introduced, with the “MUST” category following via later policy development work. Staff did not find any documentation of why it was decided to use the term “MAY NOT” as opposed to “MUST NOT” in the 2002 report. Please let us know if you have any questions. Kind regards, Caitlin, Berry, Julie and Emily Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 22 March 2022
by Julie Bisland March 9, 2022

March 9, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 22 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/KBAiCw * Check your time zone: https://tinyurl.com/fh6m7max [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/fh6m7max__;!!PtGJab4!tKeGu8Y…> 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: ICANN Zoom room requirements: Zoom Logins: First & Last Name/ Surname Only
by Nathalie Peregrine March 9, 2022

March 9, 2022

Dear all, To ensure transparency of participation in ICANN’s multistakeholder model, please remember to sign in to Zoom sessions using your full name (e.g. First Name + Last Name/Surname). If you are in a session using the webinar format, you will need to first exit the Zoom room prior to rejoining. Please reach out to your support staff if you have any difficulties joining a Zoom session. To rename in a regular Zoom room: 1. Join the meeting. 2. Tap Participants. 3. Hover over your name on the participants list. 4. Click More. 5. Click Rename. 6. Enter the name you desire then click Rename. 7. Your name has now been changed within the meeting. To rename in a webinar Zoom room: 1. BEFORE entering the meeting, and during the login phase, update your Zoom name here: [cid:image001.png@01D83300.B8213430] 1. If you forget to do so, you can always log out of the webinar Zoom room and edit your name upon re-entering. Please contact your support staff if you run into any issues. Thank you! Kind regards, Nathalie

1 0

Notes and action items - TPR WG Meeting #39 - 08 Mar 2022
by Julie Hedlund March 8, 2022

March 8, 2022

Dear TPR WG Members, Please find below the notes and action items from today’s session at ICANN73. The next TPR WG meeting will be on Tuesday, 22 March 2022 at 16:00 UTC. Note that there will be no meeting next week on Tuesday, 15 March. Best regards, Emily, Julie, Berry, and Caitlin Action Items: Continued deliberations on Denial of Transfers (NACKing) (60 minutes) -- see: Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…> 3.7.1: If we want to expand beyond “fraud” or clarify. WG members should suggest new language. 3.7.2: WG members to review and suggest language relating to clarify the dispute and requested by issue. 3.8.1: Staff to add the suggestion to remove “pending” and to change “informed of” to “notify”. 3.9.3: Add language to be more explicit on the order of applicability and reorder the list as MUST, MAY, MAY NOT. WG members are requested to suggest edits to make it more clear. 3.9.3: Staff to research where the language of 3.9.5 was developed and the context/rationale. In general staff to review the entire list (MAY, MUST, MAY/MUST NOT) as a package and see which might be combined/eliminated/changed. Bulk Use Cases: WG members to look at bulk transfer charter questions in the charter<https://gnso.icann.org/sites/default/files/file/field-file-attach/draft-cha…> on bulk use of AuthInfo codes, specifically b5, b6, and b7. Transfer Policy Review Phase 1 - Meeting #39 Tuesday 08 March 2022 at 14:30 UTC 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) * Just a couple of items left to talk about in Phase 1 before starting on drafting the recommendations. * The WG is on schedule. * RySG is looking at a couple of questions for us and will provide an update when ready. 3. Continued deliberations on Denial of Transfers (NACKing) (60 minutes) -- see: Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…> Charter Question: h1) Are the current reasons for denying or NACK-ing a transfer sufficiently clear? Should additional reasons be considered? For instance, ICANN Contractual Compliance has observed difficulties from registrars tying transfer denials involving domain names suspended for abusive activities to the denial instances contemplated by the Transfer Policy; or should any reasons be removed? In considering this question, the WG may wish to consider: * Should any or all of the reasons that registrars MAY NACK a transfer be changed to MUST NACK to promote consistency and reduce potential registrant confusion?Contractual Compliance has noted that many registrars and registrants remain confused by the terminology used in I.3.9.1, “Instances when the requested change of Registrar MAY NOT be denied include, but are not limited to: 3.9.1 Nonpayment for a pending or future registration period.” Does the Working Group have suggestions for clarifying this language, or does it believe it should remain as is? Discussion of Comments (beginning on page 1): 3.7.1 Evidence of fraud. * Does “fraud” need to be further defined to distinguish between “fraud” as it refers to the legitimacy of the transfer itself vs. “fraud” in related to the content of the website? It was noted that there is not currently evidence that this provision has been problematic to implement with the current language, so fraud may not need to be further defined. * Agree we need more than just “fraud” because some abuse might not considered fraud. * Abuse is an undefined concept at ICANN. Why would we try to define it here? * There are other types of abuse such as spam might not be fraud but might be abuse and still blocked. * RAA could be too broad and provide too many reasons for denial of transfer. * Broad terms like “abuse” and “fraud” could lead to too many reasons for denial. * In theory the registration agreement can say the customer must send weekly messages to registrar by carrier pigeon. Does not violate RAA/Consensus policies, but then failure to send the pigeon message could lead to denial of transfer. * But getting very specific doesn’t allow the policy to grow, but if “fraud” as currently referenced in the policy has not been a problem then leave it? Or is there better language? Maybe work on the scope of the words. ACTION ITEM: If we want to expand beyond “fraud” or clarify. WG members should suggest new language. 3.7.2 Reasonable dispute over the identity of the Registered Name Holder or Administrative Contact. * Potential edits: “reasonable concern [over the identity of the Registered Name Holder], that the transfer was not requested by the RNH, [or that the transfer request is otherwise not valid].” * Say something like if the transfer was done against the will of the RNH (or intent). * We should word it as "Reasonable concern that the transfer…" * Look at this language and suggest revisions. ACTION ITEM: WG members to review and suggest language relating to clarify the dispute and requested by issue. 3.7.3 Edits are acceptable. 3.7.4 and 3.7.5 Support for moving to MUST. 3.8.1 – 3.8.4 – Support to keep in this section. 3.8.1 A pending UDRP proceeding that the Registrar has been informed of. * Remove “pending”. Want to make sure there is an active UDRP in process, a potential dispute is not a reason to block. * Some prefer the original language. ACTION ITEM: Staff to add the suggestion to remove “pending” and to change “informed of” to “notify”. Poll to aid in discussion (continued from meeting #38): NOTE: Some of the provisions below are only displayed in part due to character limits in the polling tool. In such cases, the text ends with “. . .” Reasons that the Registrar of Record MAY NOT deny a transfer request (Cont.) 3.9.2 No response from the Registered Name Holder or Administrative Contact. * Leave as MAY NOT and keep language as-is – 35% * Leave as a MAY NOT but make edits – 29% * Remove from list – 24% * Other/don’t know – 12% Discussion: * There is no requirement for a direct response from the RNH. * Prior to the acknowledgement – think we can remove it from the list. Don’t think it’s needed, but might keep it if revised. No response is required so it is redundant? * Think we could keep it but at least remove the Administrative Contact. WG members review to see how we can make it more clear. 3.9.3 Domain name in Registrar Lock Status, unless the Registered Name Holder is provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request. * Leave as MAY NOT and keep language as-is – 50% * Leave as a MAY NOT but make edits – 22% * Remove from list – 11% * Other/don’t know – 17% Discussion: * We can still have the ability to block abusive domain names. * Should try to use standardized terms. Use “ClientTransferProhibited” – use the EPP status. * ICANN has kept it flexible rather than requiring a specific EPP status – could interfere with some business models. * Do need to find a common understanding. * Do we want the lock to be specific or flexible? * What is our goal with this item. If the RNH can unlock the domain but didn't, then it's OK to deny the transfer because the domain is locked. If the RNH has no way to unlock the domain, then the lock can't prevent the transfer. * From an ICANN perspective the ClientTransferProhibited prevents the transfer, but from a gaining registrar's perspective it can also mean that it will be retried as they would expect the Registered Nameholder to be able to remove the lock at the losing registrar. * Thought the concern was, if the Registrar locks for abuse that lock should prevent the transfer, regardless of what the RNH wants to do. * We have to make these clear as to why you can do this or not – what type of lock are we talking about? We should be clear. * Make it clear that if there is a lock for abuse then it is not eligible for transfer. These don’t apply. * 3.18.1 Registrar shall maintain an abuse contact to receive reports of abuse involving Registered Names sponsored by Registrar, including reports of Illegal Activity. Registrar shall publish an email address to receive such reports on the home page of Registrar's website (or in another standardized place that may be designated by ICANN from time to time). Registrar shall take reasonable and prompt steps to investigate and respond appropriately to any reports of abuse. * If one supersedes the other we should make that explicit. Don’t think any of these MAY NOT items supersedes a MAY or MUST. * This still is applicable but maybe we need to change the language. Change the order – MUST, MAY, MAY NOT. The prior sections override. * Could we ask ICANN Compliance for an example of this item, or where there’s been a disagreement on how to apply them. * ICANN Compliance: Example – registrant comes to Compliance and says they can’t unlock a domain name and registrant is not responding. Registrant does not have access to the account. From Compliance failed access to the account is out of scope for transfer policy. Respond that the registrar has provided the unlocking via the account. Educate the registrant and registrar. * [Additional Candidate Recommendation xx: If a Gaining Registrar requests a transfer and an inter-registrar transfer lock is in place, the transfer must not proceed.] ACTON ITEM: Add language to be more explicit on the order of applicability and reorder the list as MUST, MAY, MAY NOT. WG members are requested to suggest edits to make it more clear. 3.9.4 Domain name registration period time constraints, other than during the first 60 days of initial registration, during the first 60 days after a registrar transfer, or during the 60-day lock following a COR pursuant to Section II.C.2. * Leave as MAY NOT and keep language as-is – 47% * Leave as a MAY NOT but make edits – 42% * Remove from list – 0% * Other/don’t know – 11% Discussion: * Is there an example of this? ICANN Compliance: 2 years after renewal – don’t fall into the allowed non-transfer period. * Has anybody tried to deny? Think this is a catch-all situation – the only time constraints are those that we have explicitly enumerated. * So this is saying that except for the no-transfer times we already agreed on, the Rr can't deny a transfer due to what time it is? * Poll shows strong support for leaving it on the list but with edits. * Based on where we sit today this item seems like a catch all for the inconsistencies that exist in the market today. The WG seems to be coalescing that there is going to be a standard create lock of X duration and a post-transfer lock of X duration, and if assume that core doesn’t change except duration and all will be MUST, wonder if this item will need to be necessary. * If we agree on the timelines maybe we revisit this. * Picked 2nd option, I think that will let us adjust the time period and also maybe consider including that expired domains can be transferred. Not sure if that goes here or if it is a new one? * Do we need to specify if we agree on the timeframes where we can deny. If not in those then you can’t deny. Or do we need to be explicit? * It might not be intuitive that you can’t deny a transfer during expiry, so I feel like it should be mentioned. * Maybe add as an implementation note? * Think about adding a footnote to this but keeping it. 3.9.5 General payment defaults between Registrar and business partners / affiliates in cases where the Registered Name Holder for the domain in question has paid for the registration. * Leave as MAY NOT and keep language as-is – 59% * Leave as a MAY NOT but make edits – 35% * Remove from list – 0% * Other/don’t know – 6% Discussion: * Poll shows strong support for keeping this with edits. * Need clarification on this scenario. * Maybe use the language that is in the RAA. This wording here is old and predate reseller. * In practice, some registrar may advise not to transfer (but not deny) before 45 days after renewal so that they do not lose renewal period. * Steinar posted to the list about registrars charging for the transfer – what if RNH cannot pay? Should a registrar be able to block a transfer even if the registration is paid for? * Maybe an open question here is whether this should be even more general. * From the policy: .10 The Registrar of Record has other mechanisms available to collect payment from the Registered Name Holder that are independent from the Transfer process. Hence, in the event of a dispute over payment, the Registrar of Record must not employ transfer processes as a mechanism to secure payment for services from a Registered Name Holder. Exceptions to this requirement are as follows: (i) In the case of non-payment for previous registration period(s) if the transfer is requested after the expiration date, or (ii) In the case of non-payment of the current registration period, if transfer is requested before the expiration date. * Charging a fee is no explicitly prohibited. * Think this should be changed to MUST NOT deny. * But registrar cannot block for failure to pay the transfer fee. * MUST NOT seems more appropriate, but ask staff to research where this language came from/context/rationale. * What we may be seeing is an artifact from years ago before there was a transfer policy. * Staff next step will be to review these as a package including reordering. ACTION ITEM: Staff to research where the language of 3.9.5 was developed and the context/rationale. In general staff to review the entire list (MAY, MUST, MAY/MUST NOT) as a package and see which might be combined/eliminated/changed. 4. Begin discussion on bulk use cases: ACTION ITEM: WG members to look at bulk transfer charter questions in the charter<https://gnso.icann.org/sites/default/files/file/field-file-attach/draft-cha…> on bulk use of AuthInfo codes, specifically b5, b6, and b7. 5. AOB (5 minutes) * Next call: 22 March 2022 1600 UTC. Note that there will be no meeting next week on Tuesday, 15 March.

1 0

ICANN Zoom room requirements: Zoom Logins: First & Last Name/ Surname Only
by Nathalie Peregrine March 8, 2022

March 8, 2022

Dear all, To ensure transparency of participation in ICANN’s multistakeholder model, please remember to sign in to Zoom sessions using your full name (e.g. First Name + Last Name/Surname). If you are in a session using the webinar format, you will need to first exit the Zoom room prior to rejoining. Please reach out to your support staff if you have any difficulties joining a Zoom session. To rename in a regular Zoom room: 1. Join the meeting. 2. Tap Participants. 3. Hover over your name on the participants list. 4. Click More. 5. Click Rename. 6. Enter the name you desire then click Rename. 7. Your name has now been changed within the meeting. To rename in a webinar Zoom room: 1. BEFORE entering the meeting, and during the login phase, update your Zoom name here: [cid:image001.png@01D83300.B8213430] 1. If you forget to do so, you can always log out of the webinar Zoom room and edit your name upon re-entering. Please contact your support staff if you run into any issues. Thank you! Kind regards, Nathalie

1 0

**STARTING IN 2 MINUTES** Transfer Policy Review PDP WG call / ICANN73
by Julie Bisland March 8, 2022

March 8, 2022

Dear all, As a reminder the TPR PDP WG meeting being held during ICANN73 takes place today, Tuesday, March 08 2022 at 10:30 local time (14:30 UTC). * ICANN73 wiki agenda page: https://community.icann.org/x/ywEiCw * Please be sure you are registered for ICANN73! * Zoom participation links will be published 24 hours before the ICANN73 sessions start. For more information on how to participate, visit: https://73.schedule.icann.org/attend [73.schedule.icann.org]<https://urldefense.com/v3/__https:/73.schedule.icann.org/attend__;!!PtGJab4…> Thank you. Kind regards, Julie

1 0

Staff Action Item: Origins of language in 1.A.3.7.3
by Emily Barabas March 7, 2022

March 7, 2022

Dear Working Group members, Following Tuesday’s WG call, staff had an action item to research the origins of the following sentence, in bold, included in one of the reasons that a transfer may be denied: 1.A.3.7.3: No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired. In all such cases, however, the domain name must be put into "Registrar Hold" status by the Registrar of Record prior to the denial of transfer. This sentence appears in the 2002 ICANN DNSO Transfers Task Force Final Report & Recommendations<http://www.dnso.org/dnso/notes/20030212.NCTransferTF-gaining-and-losing-reg…>, under recommendation 24. In the Report section Other Observations and Considerations, the following additional text is included “9. It is recommended that the Losing Registrar use the EPP or RRP command set equivalent of “Registrar Hold” prior to receiving a transfer notification from the Registry as a mechanism to secure payment from a Registrant in the event of non-payment. The Losing Registrar should not use the EPP or RRP command set equivalent of “Registrar Lock” for this same purpose.” We found some additional discussion on page 13 of the 2008 GNSO Final Report on Inter-Registrar Transfer Policy:<https://gnso.icann.org/sites/default/files/filefield_6444/final-report-irt-…> Clarification of Reasons for Denial<https://gnso.icann.org/sites/default/files/filefield_6444/final-report-irt-…>, which was carried over from the Issue Report: “"4.2.8 The current provision in the Inter-Registrar Transfer Policy also provides that prior to denying any transfer requests for non-payment under this clause, a registrar must have placed the domain name on “Registrar Hold” status. This does not appear to be the usual practice, with many registrars using “Registrar Lock” status instead. It should be noted that “Registrar Hold” removes the name from the zone and causes it not to resolve, while a name in “Registrar Lock” may continue to function but will not be able to be transferred. As part of the discussion regarding this provision, it may be helpful to consider whether one is preferable to the other in instances of nonpayment.” It does not appear that the subsequent policy development work resulted in any changes to the language referenced above. Please let us know if you have any questions. Kind regards, Caitlin, Berry, Julie, and Emily Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

2 2

Registrar charging fees given out the TAC and transfer-out
by Steinar Grøtterød March 5, 2022

March 5, 2022

Dear all, I have recently been informed that some registrars charge a fee for issuing a TAC to the Registered Name Holder. The examples given to me is a fee of USD 250(!) for sending a TAC to the RNH. I have also been given examples of registrar charging for accepting a transfer out, purely for the «job» that has to be done. My question is whether this (IMHO) unfriendly practices should be discussed in our working group and (maybe) incorporated in the new Inter-Registrar Transfer Policy. Regards, Steinar Grøtterød At-Large

5 4