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

Proposed agenda + assignment - Meeting #104 Tuesday, 19 September 2023
by Caitlin Tubergen 14 Sep '23

14 Sep '23

Dear TPR WG members, Please find below the proposed agenda for the next call on Tuesday, 19 September 2023. Support Staff had an action item to propose some options re: full portfolio transfers (ICANN-approved transfers) for the WG to consider based on the group’s discussions to date. We thought it could be helpful to reverse engineer the discussions by proposing draft policy language from different threads of the group’s discussions. The idea would be to review the current language (in the yellow box) and then review the four options (in the blue boxes) and consider the pros and cons of each option. In short, there are four options in the Draft Options Document<https://docs.google.com/document/d/1b0KIvhRyyO5QSEI4DB4vP78muKvqHneaXOZTcvI…>, though WG members are welcome to suggest alternatives: 1. Remove the reference to fees entirely 2. Remove price ceiling (but allow for reasonable fee) 3. Retain price ceiling + add language for apportionment of fees 4. Remove price ceiling + add algorithm based on number of names transferred We hope this will be helpful, but please let us know if you think it would be helpful to see the information presented in a different way. Please review the language in advance of Tuesday’s meeting. Best regards, Julie, Christian, Berry, and Marika -- Transfer Policy Review - Meeting #104 Proposed Agenda 19 September 2023 1. Welcome and Chair updates 2. Continue discussion of Charter Question i1 (Full Portfolio Transfers AKA Bulk Transfers) and Charter Question i2 (Change of Sponsorship AKA Partial Bulk Transfers) i1) In light of these challenges described in section 3.1.7.2 of the Final Issue Report<https://gnso.icann.org/sites/default/files/file/field-file-attach/final-iss…>, should the required fee in Section I.B.2 of the Transfer Policy<https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en> be revisited or removed in certain circumstances? * Review Draft Options for Policy Language * Remove the reference to fees entirely * Remove price ceiling (but allow for reasonable fee) * Retain price ceiling + Include language for apportionment of fees * Remove price ceiling + algorithm based on number of names transferred * Other? i2) 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 and partial bulk transfers? Should proposed BTAPPA updates apply to: 1. all registry operators (via an update to the Transfer Policy), OR 2. all registry operators who offer the BTAPPA (via recommended updates to the BTAPPA) 3. AOB

1 0

Notes and action items: TPR WG Meeting #103 on 12 Sept at 1600 UTC
by Julie Hedlund 12 Sep '23

12 Sep '23

Dear TPR WG members, Please find below the brief notes and action items from today’s meeting. The next meeting will be on Tuesday, 19 September at 1600 UTC. Best regards, Berry, Caitlin, and Julie ACTION ITEMS/HOMEWORK: Staff to draft options for preliminary recommendation language for the Working Group to review and discuss on the next call. Transfer Policy Review - Meeting #103 Proposed Agenda 12 September 2023 1. Welcome and Chair updates * We are a little more than a month out from ICANN78; need to get the bulk transfer concepts wrapped up in the next couple of weeks. * Work Plan: We have a few weeks left to discuss bulk transfers; there was some slack – but now there is not. Today was supposed to be about what the WG agreed on for preliminary recommendations. If we don’t finish this topic by the end of September this PDP will be downgraded to “At Risk”. So we have until meeting #105 to finish. 2. Continue discussion of Preliminary Agreements [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1gX1N8d3qoktb…> from Charter Question i1 (Full Portfolio Transfers AKA Bulk Transfers) and Charter Question i2 (Change of Sponsorship AKA Partial Bulk Transfers) i1) In light of these challenges described in section 3.1.7.2 of the Final Issue Report [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/…>, should the required fee in Section I.B.2 of the Transfer Policy<https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en> be revisited or removed in certain circumstances? See attached slides, starting at slide 61. i1) Preliminary Agreement #1 The Working Group recommends that a Registry Operators MAY charge a fee to implement a full domain name portfolio transfer* from one ICANN-accredited registrar to another ICANN-accredited registrar. The Working Group recognizes that there may be instances where the Registry Operator MAY waive this fee.** * Note: this could include all of the domain names a registrar has within a gTLD or all of the gTLD domain names a registrar has under management. ** A non-exhaustive list of examples where a Registry Operator may choose to waive the mandatory fee include cases where a registrar is involuntarily terminated by ICANN org due to a breach, ICANN terminates a registrar due to unresponsive to accreditation renewal notices, a registrar chooses to voluntarily cease operations with a specific TLD, etc. Concept 4: If the full portfolio transfer involves multiple registries, the affected registries must ensure the collective fee does not exceed the recommended ceiling, and the fee should be apportioned based on the number of domain names. By way of example, if a registrar has 60,000 domains under management under two TLDs, e.g., 40,000 names under .ABC, and 20,000 names under .DEF, the combined fee cannot exceed [$50,000] USD (per concept 3). Since two thirds of the names under management are registered to .ABC, .ABC registry may bill the Gaining Registrar for up to 66.66% of the total fee [of $50,000], e.g., up to $33,333.33, and .DEF may bill the Gaining Registrar for up to the remaining 33.33% of the total fee [of $50,000], e.g., up to $16,666.67. [If .DEF registry chooses to waive its portion of the fee for the Gaining Registrar (per Preliminary Agreement #1), .ABC registry may still only bill the Gaining Registrar up to 66.67% of the total fee of [$50,000], and not adjust it to a higher percentage in light of the other registry’s waiver.] i2) Preliminary Agreement #1 In the event a change of sponsorship is permitted by the Registry operator, Registrars shall either notify or ensure their Resellers (where applicable) notify affected Registrants at least [30 days] before the change of sponsorship will occur and provide opt out instructions where applicable. [This notification must provide the date of the change of sponsorship, the name of the Gaining Registrar, and the Gaining Registrar’s (or their Reseller’s) terms of service.] * Should we specify a link where those terms of service can be found instead of listing the full terms of service? * Also comment from Steinar: “Adding to the list the Registrant option to transfer to another Registrar other than the "Gaining Registrar"” – and question, should we include “where applicable”? * Think we don’t need the last “where applicable” before the brackets. * There are two possibilities as opting out – the path of letting the registrant know, giving the registrant the option to make that decision on their own. Need to be careful not to call it “opting out”. But both concepts need to be brought out. * Clarify under what circumstances would there not be an option for the registrant? What if there is timing that it has to happen sooner rather than later. * When dealing with change of sponsorship we have some notion of when something is supposed to happen, but only if everything goes right. What are we going to do if the date changes? Do we send another notification? * In the original notice do you set a date range? * In the chat we tried to incorporate some of the suggestions: ““In the event a change of sponsorship is permitted by the Registry operator, Registrars shall either notify or ensure their Resellers (where applicable) notify affected Registrants at least 30 days before the change of sponsorship will occur. This notification must provide (i) opt out instructions, (ii) the approximate date of the change of sponsorship, (iii) the name of the Gaining Registrar, and (iv) a link to the Gaining Registrar’s (or their Reseller’s) terms of service.” Also, change to “expected date”. * If it slips at least the registrant knows what that last date should be. * It is not only going to be the technical issues, you also need to plan way ahead. It takes a lot of planning to make this happen. * The notification can advise that the transfer will occur "no earlier than X". The registrant will be able to transfer to an alternative registrar, if available, prior to that date. * Question: If there are multiple TLDs being moved, would we need multiple emails or one? Answer: Maybe both, depending on the registries involved. * Re: 30 days – transfers don’t happen immediately, so not sure that 30 days is practical. Also, how does that work with a 30-day lock? Sponsorship change also is different. Not really a transfer. * Would it be sufficient to indicate that the requirement is notification, without saying if it’s singular (aggregate) or multiple; and on the issue of timing say, “must be notified no less than 30 days in advance and no more than 60 days in advance; also that this does not supersede any other required notifications. * Should keep the details to a minimum – don’t have to specify number of notifications. i2) Preliminary Agreement #1 Rationale: Advance notice would give affected registrants the ability to transfer their name elsewhere if they so desire or opt out of the transfer if that option is available. In some instances, such as a registrar consolidation where a registrar will cease to exist upon the transfer, the option to opt out may not be available. [Clarifying when the transfer will take place, to which registrar it will transfer, and what their terms of service are enables registrants to familiarize themselves with the new registrar and their terms before the change of sponsorship takes place.] i2) Preliminary Agreement #4 The losing registrar’s existing Registration Agreement with customers must permit the transfer of domain names in the event of the scenarios described in the Transfer Policy with respect to a change of sponsorship. [Additionally, the losing registrar’s Registration Agreement must inform registrants that in the event of a change of sponsorship, the affected registrants will be deemed to have accepted the new registrar’s terms, unless the registrant transfers their domain name(s) to a different registrar prior to the change of sponsorship. Prior to initiating the transfer, the losing registrar and gaining registrar must ensure that they, or their Resellers (where applicable), have confirmed the affected registrants have agreed to the new terms.] * Not sure how the losing and gaining registrar can confirm that the registrant has agreed to the new terms. * Maybe we had to clean that up. If you're sending a notice to the registrants and that notice includes something similar to this, then you're putting that in the registrants’ hands from a registrar standpoint. And the text clearly states they're either moving it to somewhere where they want to or they're accepting the registrar’s terms of service by continuing along this path. * The highlighted yellow text, where it says that the registration agreement must inform registrants that the new agreement comes into effect, that seems to contradict to that final sentence where it says that the registrars have to confirm that they've agreed to the new terms. If they've been deemed to have accepted it, then there's no confirmation necessary. So I wonder if we should remove that final sentence? * Maybe the last sentence isn't needed. We can do some updating. * We're ready to change these from loose agreements here to preliminary recommendations for the group to start honing in on language and syntax. Review of homework: The 5 questions pertaining to (i1) Concepts are provided below: 1. Regarding Concept 3, is $50,000 the final number to be used for the proposed price ceiling? → Concept 1: The Working Group recognizes that a fee may be involved in a full portfolio transfer but believes flexibility is necessary, and the number should not be explicitly prescribed in the Transfer Policy. → Concept 2: The Working Group also recognizes, however, that a price ceiling is helpful to include in the policy language to promote transparency in pricing. → Concept 3: In light of Concept 2, the Working Group believes the total fee for a full portfolio transfer must not exceed [$50,000 or $1.00 per domain name transferred]. Discussion: * This is in reference to the concepts we put together about the pricing. That's currently in the policy versus what it should be going forward. There were 5 questions that were posed to the Working Group. We had put those into the working document, but didn't receive any feedback on those unfortunately. So now is the time for the group to talk through some of these questions. * We’ve been talking in the abstract and in Concept 3 below. We've bracketed the actual amount since the group hasn't really agreed on an amount. And so I think you know the options in terms of the amount on the screen. The $50,000 either stays a status quo with some new parameters around it that the group has discussed, for example, the ceiling on the price would be divided amongst all the affected registry operators rather than every affected registry operator having the ability to charge that amount of money. Alternatively, the group could change that number for something that's widely accepted. The group could agree to you to remove the fee entirely and use something like cost recovery/reasonable, but of course but we've talked about some of the drawbacks of doing that. Again, the group could consider doing a tiered structure, but, so far I don't think anything that staff and leadership had suggested have been widely accepted by the group. As we noted, we're kind of running out of time to discuss this. * There's strong support for getting rid of the exact number in in the policy. It sounded like the group was very supportive of removing that from the current policy. And then we can move on to talking about do we replace it or not? * So if we, if we take it out, what would the language say? * A reasonable fee should be charged, whatever it is. Because if we don't have support for any other ideas, then maybe the language gets a lot simpler, and it does just become a reasonable fee can be charged.. * We don’t know if this is reasonable or not. How do you determine that and can it be enforced? * Without agreement the $50K remains. * Could remove it and replace with “reasonable” or comes up with the perfect algorithm. * What happens if a reasonable fee is higher than the ceiling? * This fee hasn’t been charged very much; adding in “reasonable” seems to cause uncertainty. It hasn’t caused problems so we should leave it as is. * With the policy changes we’ve agreed so far this may be used more often. * If a fee is charged it should be collectively set across parties – should not be mandatory and should be a reasonable amount. Having a predictable price has been helpful. * We are only talking about when you hit 50K names per TLD. We aren’t talking about a BTAPPA situation. It hasn’t kicked in that often. * We are either sticking with the current language -or- removing numbers and putting them some place else -or- other? * Have not found that middle ground after several weeks. People were talking about removing the fee from the policy but haven’t agreed on what to replace it with. No one is getting to that middle term. * From a RO perspective a BTAPPA is very different from a full portfolio transfer. 1. In the current policy, there is no charge to transfer less than 50,000 domains, but transferring 50,000 or more comes with a flat fee of $50,000. Is this concept of having a minimum/“ledge” of domain names still applicable? Discussion: * Doesn’t seem like there’s logic behind this – heard that maybe these aren’t the right numbers and that maybe they should be removed or replaced. * Doesn’t this invite gaming? You could do 49K. * You can’t chunk this because we know how many names the registry has – this fee would only apply when transferring a full portfolio/all names under management. * Could you do a partial and then full transfer? Maybe but that would be known fairly quickly. * There is an ambiguity – old policy would seem to suggest whether or not there is a fee it depends on the outgoing names from a registrar (50K or more). * But it is per registry operator. * The apportioning takes work, but we could figure that out. The apportionment will need an administration mechanism… likely via ICANN Org. * It sounds like we are talking about staying within the framework of the current policy and making smaller adjustments to that policy. * Whatever language we have with a fee, make sure it is “MAY”. * Yes, that is what the current preliminary agreements say. (May) Showing the currently policy for ease of reference. * Need a project manager to represent the registrant. * Need to think about how ICANN could be involved. * How can leadership and staff help the group move forward? * Helpful to give options.

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 19 September 2023
by Julie Bisland 12 Sep '23

12 Sep '23

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 19 September 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/f4jxDg * Time conversion link: https://tinyurl.com/bdsbw8sh ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 12 September 2023
by Julie Bisland 12 Sep '23

12 Sep '23

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 12 September 2023 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/fYjxDg> (attendance included) and the GNSO Master calendar<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * Transcript * Agenda and Notes/Action Items 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

**AT THE TOP OF THE HOUR** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 12 September 2023
by Julie Bisland 12 Sep '23

12 Sep '23

**AT THE TOP OF THE HOUR** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 12 September 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/fYjxDg * Time conversion link: https://tinyurl.com/2y6945sz [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2y6945sz__;!!PtGJab4!_W74gJp…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

GNSO_TPR // 11 September 2023 Project Package
by Berry Cobb 11 Sep '23

11 Sep '23

Dear WG, Please find a link below to project package for the GNSO_TPR PDP (11 September 2023). This package is a snap-shot in time and developed by the leadership team to report on the working group’s activities and status of the project. It is also distributed to the GNSO Council to keep them informed as managers of the PDP. The package is deposited on the wiki so that we can track access statistics. NOTE: I’ve attached the package here for your convenience due to performance issues with the Confluence Wiki. Link: https://community.icann.org/x/MQDQCQ 1. Page 01 – Summary Dashboard, Project SitRep, and Activity Metrics 2. Page 02 – Meeting metrics, Roster, & Group Attendance 3. Page 03 – Project Plan, Gantt chart 4. Page 04 – Workplan Key points: * Deliberations on ICANN-Approved Transfers are behind schedule, but the working group has slack in the schedule until 30 Sep 2023 to complete its work. Please let staff know if you have questions. Thank you. B Berry Cobb Policy Development – Senior Program Manager Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 424 443 8960 Phone: +1 202 570 7240 Fax: +1 202 789 0104 Twitter: @berrycobb www.icann.org<https://www.icann.org/>

1 0

Proposed Agenda - TPR Meeting #103 - 12 Sept 2023
by Caitlin Tubergen 11 Sep '23

11 Sep '23

Dear TPR Working Group Members, Please find below the proposed agenda for the next meeting on Tuesday, 12 September at 16:00 UTC. 📣 As a reminder, homework is due in advance of tomorrow’s meeting. Thus far, no one was completed the homework. 📣 Please find the homework assignment below: Support Staff has updated the TPR ICANN-Approved Transfers Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1gX1N8d3qoktb…> based on your discussion last week, during which 5 questions were proposed for the WG to answer. In preparation for your next meeting on Tuesday, 12 September (1600 UTC), please provide your response to these questions in the Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1gX1N8d3qoktb…>. The 5 questions pertaining to (i1) Concepts are provided below: 1. Regarding Concept 3, is $50,000 the final number to be used for the proposed price ceiling? 2. In the current policy, there is no charge to transfer less than 50,000 domains, but transferring 50,000 or more comes with a flat fee of $50,000. Is this concept of having a minimum/“ledge” of domain names still applicable? 3. Regarding Concept 4, if there is a sharing of the fee between registries, is there a minimum number of domain names a registry must have involved in order to qualify to share the fee? (e.g. if there are 10 registries involved and one only has 2% of the total domains involved, should they be able to partake in the sharing?) 4. If so, what is that minimum number of domain names? (e.g. is the registry allowed to bill for one domain name?) 5. How would this process be handled? Considering Concept 4(a), would ICANN org need to be involved further to help manage this process, and if so, why? At the bottom of the Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1gX1N8d3qoktb…>, you will also see a prompt to provide input relating to charter question (i2): Should the scope of voluntary bulk transfers, including partial bulk transfers, be expanded and/or made uniform across: 1. all registry operators (via an update to the Transfer Policy), OR 2. all registry operators who offer the BTAPPA (via recommended updates to the BTAPPA) Please review these questions as well as Support Staff’s highlighted changes, and provide your comments, edits, concerns, etc. within the Working Document before 12 September at 1600 UTC. Thank you for your attention to the homework. Best regards, Julie, Christian, Berry, and Caitlin -- Transfer Policy Review - Meeting #103 Proposed Agenda 12 September 2023 1. Welcome and Chair updates 2. Continue discussion of Preliminary Agreements<https://docs.google.com/document/d/1gX1N8d3qoktbniRmfGE4-8Un9dPavIKQ3IZYaoe…> from Charter Question i1 (Full Portfolio Transfers AKA Bulk Transfers) and Charter Question i2 (Change of Sponsorship AKA Partial Bulk Transfers) i1) In light of these challenges described in section 3.1.7.2 of the Final Issue Report<https://gnso.icann.org/sites/default/files/file/field-file-attach/final-iss…>, should the required fee in Section I.B.2 of the Transfer Policy<https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en> be revisited or removed in certain circumstances? * Review of homework The 5 questions pertaining to (i1) Concepts are provided below: 1. Regarding Concept 3, is $50,000 the final number to be used for the proposed price ceiling? 2. In the current policy, there is no charge to transfer less than 50,000 domains, but transferring 50,000 or more comes with a flat fee of $50,000. Is this concept of having a minimum/“ledge” of domain names still applicable? 3. Regarding Concept 4, if there is a sharing of the fee between registries, is there a minimum number of domain names a registry must have involved in order to qualify to share the fee? (e.g. if there are 10 registries involved and one only has 2% of the total domains involved, should they be able to partake in the sharing?) 4. If so, what is that minimum number of domain names? (e.g. is the registry allowed to bill for one domain name?) 5. How would this process be handled? Considering Concept 4(a), would ICANN org need to be involved further to help manage this process, and if so, why? i2) 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 and partial bulk transfers? * Review of homework 1. all registry operators (via an update to the Transfer Policy), OR 2. all registry operators who offer the BTAPPA (via recommended updates to the BTAPPA) 3. AOB

1 0

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 12 September 2023
by Julie Bisland 11 Sep '23

11 Sep '23

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 12 September 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/fYjxDg * Time conversion link: https://tinyurl.com/2y6945sz [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2y6945sz__;!!PtGJab4!_W74gJp…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

TPR WG Action Item: Provide Input in Working Document
by Christian Wheeler 07 Sep '23

07 Sep '23

Dear TPR WG members, Support Staff has updated the TPR ICANN-Approved Transfers Working Document<https://docs.google.com/document/d/1gX1N8d3qoktbniRmfGE4-8Un9dPavIKQ3IZYaoe…> based on your discussion last week, during which 5 questions were proposed for the WG to answer. In preparation for your next meeting on Tuesday, 12 September (1600 UTC), please provide your response to these questions in the Working Document<https://docs.google.com/document/d/1gX1N8d3qoktbniRmfGE4-8Un9dPavIKQ3IZYaoe…>. The 5 questions pertaining to (i1) Concepts are provided below: 1. Regarding Concept 3, is $50,000 the final number to be used for the proposed price ceiling? 2. In the current policy, there is no charge to transfer less than 50,000 domains, but transferring 50,000 or more comes with a flat fee of $50,000. Is this concept of having a minimum/“ledge” of domain names still applicable? 3. Regarding Concept 4, if there is a sharing of the fee between registries, is there a minimum number of domain names a registry must have involved in order to qualify to share the fee? (e.g. if there are 10 registries involved and one only has 2% of the total domains involved, should they be able to partake in the sharing?) 4. If so, what is that minimum number of domain names? (e.g. is the registry allowed to bill for one domain name?) 5. How would this process be handled? Considering Concept 4(a), would ICANN org need to be involved further to help manage this process, and if so, why? At the bottom of the Working Document<https://docs.google.com/document/d/1gX1N8d3qoktbniRmfGE4-8Un9dPavIKQ3IZYaoe…>, you will also see a prompt to provide input relating to charter question (i2): Should the scope of voluntary bulk transfers, including partial bulk transfers, be expanded and/or made uniform across: 1. all registry operators (via an update to the Transfer Policy), OR 1. all registry operators who offer the BTAPPA (via recommended updates to the BTAPPA) Please review these questions as well as Support Staff’s highlighted changes, and provide your comments, edits, concerns, etc. within the Working Document before 12 September at 1600 UTC. Thank you. Kind regards, Christian, Berry, Caitlin, and Julie

1 1