Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting on Tuesday, 24 August 2021 at 16:00 UTC. The next meeting will be Tuesday, 31 August at 16:00 UTC. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items ACTION ITEM: Leadership and staff will lay out the three proposed notifications/communications concepts/proposals. WG members to review and comment in preparation for the meeting on 31 August. See the document at: Losing FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wCUMe9ii6g05k...> Also see the project workplan [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1FunWaz3gN...> for action items. Notes: Transfer Policy Review Phase 1 - Meeting #14 – Tuesday, 24 August at 16:00 UTC Proposed Agenda 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) -- NCSG is leaning to more security for the AuthInfo code; maybe to make it available to the registrant. We will discuss this further. 3. Continued discussion of Losing FOA (75 minutes) * Losing FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wCUMe9ii6g05k...> Page 7: Potential alternatives: * Provide notice before the transfer happens [option: with link to deny transfer] [option: with links to deny transfer and approve transfer] [option: with no links, notification only] * Advantage: Prior notice could reduce the number of transfers you need to reverse relative to the scenario where notification happens after the transfer has taken place. * Provide notice after the transfer has occurred. Options related to the above alternatives: * Content of the message: * Mandatory template or * Mandatory elements to include in the message and optional template or * Mandatory elements to include in the message only (no template) * Delivery of the message: * Require specific delivery method (for example email) or * Allow the registrant to choose how the message is received Discussion: * Think that the majority of transfers that occur are valid so the majority of customers would be best served by a process that lets the transfer happen as quickly as possible, with the transfer first and notice afterward; If we provide the notice before the transfer then we are building in a delay. There also should be an easy process to reverse a transfer. * As to reversing unauthorizing transfers, we need to have that discussion as soon as possible. It could be that a transfer reversal could put other processes in limbo. * There are so many interdependent processes that we may need to dig into some before we make other decisions. * Have we determined definitively that we are doing to eliminate the 5-day period? If we opted to provide a notice before a transfer that gave the registrant the option to approve the transfer that could be a middle ground option. * Don’t think we’ve agreed to get rid of the 5-day delay – even if we keep it there should be a way to do it faster. * It is important that if we send any kind of losing FOA there should be an option to approve or deny, unless the transfer is automatic. * Right now if we acknowledge a transfer because of the 5-day delay it doesn’t immediately happen. * Improvement to consider: when the registrant receives and acknowledges the transfer it should immediately go through; no 5-day wait. * Goal is to speed up the process from the end-user perspective, without losing security. * Getting back into the TAC discussions as well as how to recover bad transfers. * Once the registrar has the TAC then the transfer can go. * There are two 5-day windows – provide the TAC and unlock; 5-day window for losing FOA. We are saying the losing FOA could drop the 5-day period if we can get an update to the notification that allows them to immediately do it. * So there would be a fast-transfer process. * Relates to where we are planning to put our security? Whatever choice you make is fine; just need to understand that choice. Summary: If the TAC is supposed to be the final authority then you apply a set of security principles to the TAC; then it naturally follows that a near-real time transfer is probably okay. Separately we do need a way to reverse, but does that have to be real-time or have a delay? You can still do a notification that a transfer occurred (after the transfer) to allow the registrant to reverse. So put all the work and protections on the TAC and allow an option to reverse the transfer. * Keep in mind the possibility of multiple people being in the middle of this. * If you look at the reversal process, if there is an error made or unauthorized transfer you need a way to reverse it as quickly as possible. * Multi-factor authentication is important, but don’t think we should stipulate what it is. * Proposal: The TAC is the most important feature in the transfer process. We need to assume that the registrant has a relationship with the account holder and reseller; we could consider to put in a notification when a TAC is created with a TTL. The actual registrant would get a notification when the TAC is created and also when the transfer is completed, as well as reverse procedures. So, a pre-notification (the TAC) and also a post-notification. * Just have two notifications, one when the TAC is created and one when the transfer is complete. The notifications should go directly to the registrant. * It is possible to put information about what entity granted the TAC so the registrant can have it. * Should there be mandatory language in the notifications? Do we also mandate multiple communication mechanisms? * There should be some requirement for language but shouldn’t be very specific; leave it up to the registrar. * It is reasonable to have specific parts to include but not the exact language; just that it should say certain things. Might be worthwhile to check with ICANN’s Compliance team as to whether they can enforce without having mandatory language. * It is important that it is in the contract language, but not necessarily in English. * Don’t want to be too specific because technology changes frequently. Allow multiple communication options. Page 2: Draft New Template(s) “Notification of Transfer Completion” Requirements (MUSTs) [summary from meeting on 17 August] * Sent by losing registrar to registrant they had on file when the domain was with them * Within TBD time of transfer (within 24 hours? Depends on timeframe for reversal process) * Includes domain name(s) and new registrar (may include IANA ID) * Explanation that the domain was transferred, with date/time of transfer * What to do if this is an invalid transfer (how to start the reversal process) * In language of registration agreement with registrant * Information about who and how the TAC was given (MAYs) * Registrar may consolidate, at their option, a group of domains being transferred into a single notice where the gaining registrar and the losing registrant email are consistent. Discussion: * Can we get rid of the notification by fax? * Getting the notice to the actual registrant (domain holder) may include several people in that path. * Ultimately the registrant is in charge; but if you look at the reseller model it is based on the fact that the registrant doesn’t want to be burdened by any of the technical aspects. If we talk about reseller there is a legal basis in contracts to unburden the registrant from the technical procedures, such as transfers. * This notification on pending transfer in the document is basically a FOA. At some point we need to decide if this should still be there, if it should be removed or as suggested at last meeting being made an optional feature. Timing Considerations: * The timing of the losing FOA might be dependent on the timing of the reversal. * Are there multiple post-transfer notifications? Do we allow registrars to send follow up notification in the registrant has responded? * Is there any reason to give a registrar more than 24-hours to send a notification of transfer completion. Seems logical that it should happen as soon as possible. The reversal would then be a separate process. * In some cases a domain name may be transfers a couple of times before there is a complaint/dispute process. Something to consider if we are thinking about a 60-day lock after transfer. * Leave the dispute process mechanism timeline separate from the notification timeline, but may need to consider dependencies. * We could say the notification of transfer complete should be sent without undue delay but no more than X business days after. “Notification of Pending Transfer” Requirements (MUSTs) * Sent by losing registrar to registrant they have on file at time of transfer request * Triggered by transfer (sent within 24 hours) * Includes domain name(s) and new registrar (may include IANA ID) * Explanation that the domain was requested to transfer, with date/time of transfer request * Include maximum information (as permitted) about requesting party available * What to do if this is an invalid transfer (how to NACK) * The date and time the transfer would take effect, if no action taken. * In language of registration agreement with registrant * Information about who and how the TAC was given [Note, absent a link to ACK or NACK, the notification of pending transfer is quite similar to Losing FOA] (MAYs) Registrar may consolidate, at their option, a group of domains being transferred into a single notice where the gaining registrar and the losing registrant email are consistent. Discussion: * On the pending transfer notification, similar to the losing FOA – so we are back as to whether we should have the losing FOA or not. * Is that a business model flexibility that we want to keep? Or is that a policy? * In the current process the registrant can opt out of the 6-day lock; if we want to keep the losing FOA as optional then the registrant should be able to opt into it. * Question: At what stage should the registrant consider to opt in for the losing FOA? Answer: When you request the TAC. * Question: So are we assuming the TAC is not created when the domain is created? Answer: It seems that we are proceeding on that assumption. Though we don’t have consensus on that. * Suggest that when you create a TAC that could also be a notification of pending transfer. The losing FOA should only be done if the registrant opts into it. * Question: Are we assuming that only the registrant has access to the TAC? Answer: Don’t think that is what we are saying. Assumed whoever has access to the account where the domain is managed has access to the TAC. * We are assuming that the notifications are going to the registrant. * ACK or NACK should only be if you opt into it. Shouldn’t delay the transfer. * It doesn’t make sense to ACK or NACK a transfer that is not in process; it is not in process until the TAC is sent to the gaining registrant. * No matter where the TAC goes, it can be used to transfer the domain. * Example: You receive an email with the TAC and ACK; and that email includes a NACK. * Above example is a bad idea; most registrants would be confused by this. * We already had in mind that a TAC should be cancel-able, right? One can invalidate the TAC? So it would make sense that in the same place where the TAC is provided to the RNH they also have instructions for / ability to invalidate that TAC. * TAC should not be distributed via email. But we aren’t deciding this detail. Registrar should make this decision. * Registrant should be able to have a path to invalidate a transfer. * We shouldn’t conflate invalidating the TAC with NACKing the transfer. * The email could tell the user to go back to their CP to invalidate their TAC. * Question: Should the notification of TAC created go in here or in the AuthInfo Code documents? Answer: Staff can insert it in both documents. ACTION ITEM: Leadership and staff will lay out the three proposed notifications/communications concepts/proposals. WG members to review and comment in preparation for the meeting on 31 August. 4. AOB (5 minutes) - Next meeting: 31 August 2021 @ 16.00 UTC