Dear TPR WG members, Please find below the notes and action items from today’s meeting. We will not meet again in August. The next meeting will be Tuesday, 06 September at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: WG members should be prepared to discuss the public comments on the Phase 1A Initial Report. See: https://www.icann.org/en/public-comment/proceeding/initial-report-on-the-tra.... Notes: Transfer Policy Review Phase 1(b) - Meeting #57 Proposed Agenda 09 August 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Taking a pause, starting back on 06 September to allow for compilation the the public comments into the review tool. * Current extension is almost to 60 days, which fits perfectly into our schedule. We have had a few more requests for another extension, but don’t see that we’ll be doing that. This is the Initial Report and there will be further opportunities to comment Final Report. * Question from Keiron: Why it was that Section I.A, 1.1.4 – if there is no prior registrant email address and the Admin Contact trigger: where did that come from. Asked ICANN Org staff confirmed Theo’s recollection – that there were some legacy domain names that didn’t have a prior registrant email address, but had an Admin Contact. We will come around back to that since Admin Contact will likely go away. * From Jim Galvin, speaking personally: Suggestion to make it very concrete, that Change of Registrant policy doesn’t need to exist and we can relay on the recommendations we’ve already made. Let’s focus on change of control of the domain name, as we did when something moves between registrars. What is change of control within a registrar? It is about contactabality – we could define control as a change in contactability. Only these changes would need restrictions, and we could use the steps we came up with in Phase 1A. Example: provide TAC to old address, or call a phone number – need the TAC to make the change to the contact. It would be managed in the registrar. If the email or phone is problematic, the registrar should already have processes to deal with that. Lastly, sometimes registrars have other things (like organization) to be points of control, and they can add these if they wish. But change of control should be the minimum mandatory requirement – with the notifications and locking as we devised in the Phase 1A recommendations. * Like using the same process as much as usual, but not sure it applies in this case. There are still notifications to deal with. May take more thought. * Not sure why we have policy around a change of registrant within a registrar. Seems that the industry has moved passed this concept. * We did a lot of security enhancements in Phase 1A, where we streamlined the inter-registrar process and still made it more secure. Are there pieces of that that we can use for intra-registrar change of registrant. * Jim Galvin: Coming at this from a place of first principles – can we agree that we are focused on change of control. With respect to the wholesale market: there is no new work that you are not already doing. There are things you will have to do to apply Phase 1A to the resellers and you should be able to use that with change of registrant. * This is about Change of Registrant, not Change of Control. * The complexity of changing an email address for a registrant will be different under this proposal but it will be the same. If we replaced the TAC system with a notification system would be better. * There is diversity within registrars, but they try to simplify these systems for their downline. We are diving into adding complexity without showing that it’s needed. * There are some changes at the account level that the registrar would not be able to tell whether they are minor updates, or change of ownership. * What are we talking about? The Change of Registrant process. We need to agree on the purpose of the policy – what it is doing – and whether it is needed or if there is another way to do it. * If the main communication is being updated should the same processes apply as in Phase 1A? * We could decide based on what we are trying to accomplish that we can get rid of the Change of Registrant policy. * The ICANN registrant ecosystem focuses on contactability. That’s why if that is what a transfer process is supposed to do, then change of contact methods is also a transfer process and restrictions would apply. * From a technical point of view you need the manual process you have today if you have triggers when someone changes email that was problematic. * Back in the day one of the things that made the policy workable was the Designated Agent (reseller). For data accuracy you want as few barriers as possible. * It is the registrar that has the responsibility to keep their registrant data up to date. * [Continue this discussion under #3 below.] 3. CoR Triggers and Actions Matrix – focus on primary method of contact (currently email) (Transfer Policy section II.A.1.1.3 + II.A.1.3.3), and secondary method of contact (phone number) – see https://docs.google.com/spreadsheets/d/1eB3cowSoEp4ERoqQmlc3hc5dpV4g5NzP/edi... * Roger Carney: Question for the WG: If the registrar determines that there is a true Change of Control, should there be any policy around that (rather than just an update by the same registrant). * Need to be careful to define our terms. IRTP-B introduced the terminology of “Change of Control”. If we continue to use these terms we should devise a precise definition. The title of “Inter-Registrant Transfer” is poorly defined, subject to interpretation. We also need to agree on what is a “Material Change”. * This is the last time for a while (a couple of months) that we’ll be talking about Change of Registrant/Inter-Registrant Transfer for some time until after the WG reviews and discusses the public comments. When we come back to this we should be very precise about our terminology. As homework, WG members could consider what “Change of Control” actually means. And we’ll need a strong rationale for any recommended changes to the current policy. * We are talking about a material change to the contact information for the RNH. * Think the degree of thin or thick is a discussion that will happen outside of this WG. * There are so many edge cases that it would be impossible to come up with a definition of “material change” that would cover all cases. Don’t think we should try to do that. Locks shouldn’t be necessary. Might want notifications. * A lot of the changes we are seeing is registrants changing their own contact information and don’t think they should be penalized for that. * When we hit the end of Phase 2, there would be an option for some kind of a roll back. Would want some indication of what has changes that could be considered in the rollback period. * Some disagreement with the above proposal from a registry. 4. Preview: Phase 1(a) Initial Report public comment review * Public comments are being submitted here: https://www.icann.org/en/public-comment/proceeding/initial-report-on-the-tra.... * Scheduled to close on 16 August. * On 17 August staff will get a spreadsheet as a master of all comments in one place. * Staff will produce a summary report on 30 August. * Depending on the number and type of comment will determine what tool to use for review – but the most common tool is the Public Comment Review Tool with one document by question, arranged by support, or not, etc. * Depending on the volume of the comments we may cluster them together. * When we come back on 06 September, everyone will have had a chance to review the comments. * We will have two meetings before ICANN75, and then continue the review during the ICANN meeting and after, but the hope is that discussions on Phase 1B can happen simultaneously on the mailing list, so keep an eye on the list. ACTION ITEM: WG members should be prepared to start discussing comments on 06 September. See: https://www.icann.org/en/public-comment/proceeding/initial-report-on-the-tra.... 5. AOB * Next session: Tuesday 6 September at 16:00 UTC