Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting on Tuesday, 07 September 2021 at 16:00 UTC. The next meeting will be Tuesday, 14 September at 16:00 UTC. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items ACTION ITEM: Homework: WG members should look at reasons for denial in the current policy and comment on whether or not we need to update those reason. Add lines or comments to the Transfer Steps and Notifications Chart: Transfer Steps and Notifications chart [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/17ADMRTYxN...> ACTION ITEM: Leadership and staff to clean up the document based on comments and determine where steps can be combined. See the updated Work Plan and Action Items here: https://docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8uR... Notes: Transfer Policy Review Phase 1 - Meeting #16 – Tuesday, 07 September at 16:00 UTC Proposed Agenda 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) * Updates from WG member: None. * There will be a PDP WG meeting at ICANN72. 3. Continued discussion of Losing FOA (45 minutes) – See: Losing FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wCUMe9ii6g05k...> Transfer Steps and Notifications Chart: Transfer Steps and Notifications chart [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/17ADMRTYxN...> * Sarah’s goal was to document the process step-by-step to see where steps could be eliminated or combined. 1. Request to prepare domain for transfer * May not be the registrant; or it might be the registrant. * This is where there might be a transfer request notification with the idea that there was a request so a notification goes to the registrant; some support for providing a 5-day window for the registrar to provide the TAC (leading into step 2). * Question: Could there be a communication at this point, outlining the process, and that it might take up to 5 days to issue the TAC. * Could request the TAC even if the domain name is still locked. Don’t make it dependent on whether it’s locked or unlocked. The lock could come off later. * Today the status of a domain name (locked or not) is not a part of the transfer policy – should we add it for the next round? Which one of the locks should be controlled by the policy? * This is all pre-transfer, before a transfer is in a pending state. * 5-day window might be at this step. 2. Prepare domain for transfer * “verify validity of request” – should be optional; could mean different things for different types of registrars. Even “verify request” should be optional. * All of these sub steps are being done by the losing registrar. 3. Fulfill request to prepare domain for transfer * This is the biggest action step. Does this need to be communicated to certain specific people? * The requester may not be the registrant. So, should it also be sent to the registrant? * Should reduce the number of notifications. Maybe a lot of the communications could be combined. Steps 1-5 should only be one email. For example, you don’t have to notify of a TAC request if you have already provided a TAC. * Method of communication should be left open. * The few steps here could all happen basically at the same time, via the automated control panel (as it does today). - Do we still want the 5 day window for Losing Rr to provide the TAC? - Do we need to dictate who the TAC is provided to? * Seems to be some agreement to keep the 5-day window. * In the reseller model we have to assume that the reseller is doing things on behalf of the registrant – so no need to also notify the reseller. This is redundant. So, no need to dictate to whom the TAC is provided. * Today we have a state of pending transfer – should we change that to when the TAC is provided? Is the pre-transfer notification step the new pending transfer? We think not. * Could say it’s being transfer (pending) when the registry is aware. * If we have immediate transfers do we eliminate the pending state? Think this requires more work to figure out. * If we change pending transfer status and make it policy, we’ll have to change all of the other states. Pending shouldn’t happen until the registry is informed. * Think we should skip the whole pending transfer state when the transfer is immediate. 4. Notify domain owner (pre-transfer) * Could be different parties doing the requests. * Avoid pending transfer until someone comes up with a good spot for that. * We are starting to combine the notifications. This is one notification. 5. Initiate transfer * This is when they submit it to the gaining registrar. * Anyone who has the TAC at this point can initiate the transfer. * Gaining FOA is likely to send a welcome message, but this is up to the registrar or reseller. * In combining notifications there still needs to be a way to stop the transfer. Once the requester receives the TAC, it should be able to invalidate the TAC so it can’t be used. This needs to be part of the notification – steps to take so the domain name can’t be transferred. * Transfer status is important. * But if the transfer happens immediately then there isn’t a transfer status. Maybe it will go from locked to unlocked, but that is up to the registrar. * The important thing is that the NACK has gone away in this new model. The window of time to invalidate the TAC is between the requester receives the TAC and when it is provided to the gaining registrar. * If there is an option in the notification for the registrar to stop or reverse the transfer, then that is a NACK option. * We should be able to prevent unauthorized transfer of the Domain BEFORE it would happen, proactively. As opposed to having to react to it having been transferred. * If a hacker wants to steal a domain name, they will be in full control of all communications. So, there is no way to stop it. You won’t see the notification email. Could suggest some policy language such as, “Registrars and resellers should provide multifactor authentication of transfers.” * Getting a notification at the request time allows for more time for mitigation, but may not matter if the hacker controls the communications. * There are some cases where the IT department has the ability to get the auth code and open a transfer but the legal department has the ACK/NACK control now. * Need to keep in mind that no matter what we do we can’t prevent all unauthorized transfer. * One of the problems we have today is that the gaining FOA can’t be provided. Need to be able to tell the community that the new policy is as secure as the old one. * Most TACs that are created are given out right away at the request, but still keep the 5-day timeframe as an option. Could say it should be provided at the earliest at the request and at the latest at the end of the 5-day window, to provide flexibility. * None of these policies will create a super-secure system, so make sure that whatever you have in the policy, you have a way to easily reverse the transfer. * Today, even fraudulent transfer follow the policy, so any new policy will create a map for how to get around it. 6. Request transfer at Registry * Transfer should be as immediate as possible. 7. Move domain to new Registrar * Question: Is adding a year to the registration term up for modification in this PDP? Do we want to consider that? * The one-year renewal at transfer stops the registrant from changing the registrar too frequently. * Keep the current settings – don’t automatically gain a year upon transfer of the domain name. * Just assume that we don’t change the one-year add-on period. * Goes to the next step: there was discussion early on about the TAC being reset on transfer – when the registry completes the transfer. 8. Post-transfer updates * Early on we talked about a one-time TAC. If you want to transfer again you need to create a new TAC. But who does that? Gaining registrar wouldn’t have the access. Needs to be done at the registry level. Maybe we can state this unless someone comes up with a better solution. * The registry should reset it when it has been used and/or when it’s TTL expires. * (With Co-Chair Techops hat on) There have been discussions here in this group and in Techops about clearing tac - but non-conclusive. * Registry Stakeholder Group should consider this and get back with comments. 9. Notify domain owner (post-transfer) * Questions: * Does (should) the gaining Registrar also have a policy obligation to send a notice at this stage? They will likely want to send one for business/marketing purposes, but are they required to do so? * Should the Losing Registrar be required to provide links/info about procedures to follow if Registrant feels the transfer was done in error? * Just a simple message that a domain has been transferred, with no requirements on language, should be enough. * There are several registrars that operate among themselves to quickly reverse transfers – should not mandate certain procedures. * Would like it to include the name and/or IANA ID of the new registrar. Think it should be required, but we shouldn’t specify the mechanism. 10. Fast-Undo Transfer * Need to keep notes of these discussions when we get to our transfer dispute topics later. Reasons for denial: * Need to show where transfers can fail and make sure we have those items covered. Such as for the Max renewal term (transfer would >10 y from today). * Hard coded requirements on the registry level should guide us for the creation of the TAC – such as for incorrect syntax. When the losing registrar goes to create the TAC they could potentially not get the TAC created at the registry. ACTION ITEM: Homework: WG members should look at reasons for denial in the current policy and comment on whether or not we need to update those reason. Add lines or comments to the Transfer Steps and Notifications Chart: Transfer Steps and Notifications chart [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/17ADMRTYxN...> ACTION ITEM: Leadership and staff to clean up the document based on comments and determine where steps can be combined. 4. AOB (5 minutes) - Next meeting: 14 September 2021 @ 16.00 UTC