Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting on Tuesday, 31 August 2021 at 16:00 UTC. The next meeting will be Tuesday, 07 September at 16:00 UTC. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items ACTION ITEM: Sarah Wyld volunteered to create a flow chart. Staff will create a Google doc template for this. Notes: Transfer Policy Review Phase 1 - Meeting #15 – Tuesday, 31 August at 16:00 UTC Proposed Agenda 1. Roll Call & SOI Updates (5 minutes) * Update to SOI – Steinar Grøtterød at: https://community.icann.org/display/gnsosoi/Steinar+Grøtterød+SOI 2. Welcome & Chair updates (5 minutes) * Updates from WG member: None. * Leadership and staff are working on draft candidate recommendations on the TAC. These will be circulated on list in the background, concurrent with the meetings. Plan is to keep the TAC discussion moving. 3. Continued discussion of Losing FOA (30 minutes) – See: Losing FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wCUMe9ii6g05k...> Poll Results: Notification of TAC Request: (Q1) Should the losing registrar notify the registrant when the TAC is requested? -- 16 responses * Yes, This notification should be required in policy – 69% * It should be up to the registrar if and how they do this – 25% * No, I do not support this type of notification – 6% * Not sure/needs further discussion – 0% (Q2) What, if anything, should be required in this communication? – 16 responses * The notification should contain all of the elements listed in the Working Document – 56% * The notification should include only some of the elements listed in the Working Document – 31% * The notification should include a different set of elements, which have not yet been discussed – 0% * I do not support this type of notification – 6% * Not sure/needs further discussion – 6% Discussion: * Send way too many notifications in the first place. * Can live with option #2. But try to trigger multiple notifications to the registrant. Registrants become numb to over notification. * For Q#2 – for those who answered that “only some of the elements” should be included – what items should be included? * You might include only the IANA ID. * Useful information to the end user in the transfer process – it all depends on the wording you put into this; how you formulate the communication. You could compromise and still keep the same bullet points as in the working document. * Also wondering if perhaps the message should require logging in at the registrar to see messages, as opposed to getting the message in email. it’s a common practice today in various retail contexts so just a thought. * What if we make it an option for the registrar to send the notification and the reseller has to ask for it to be sent? * If you make it too hard to transfer then a reseller won’t want to bother to transfer and may stick with a bad registrar. * Don’t understand why the TAC should be sent in an email – security issue? Should not include the TAC. * One of the reason for the notification of the TAC request is that we don’t have the losing FOA. If you request the TAC it probably means that you intend to do a transfer. If we have the losing FOA it won’t be necessary. * Note that the notification goes out when the registrant makes the request – but will get notified if someone has hacked the account also. Note that reseller requests are outside of this scenario. There are cases where a reseller makes a request as part of the regular business, although the registrant will get a notice. Need to take into account other types of requests. Need to make the distinction between registrant requests for transfer and reseller requests for transfer. Important to document those other types of transfers. * There can always be the option of the registrar authorized transfer in scenarios of needing to do bulk transfer for a reseller. Notification of Pending Transfer: (Q1) Should the losing registrar notify the registrant when a transfer is pending? – 19/16 responses * Yes, This notification should be required in policy – First response: 74%/Second response: 56% * It should be up to the registrar if and how they do this – First response: 21%/Second response: 13% * No, I do not support this type of notification – First response: 5%/Second response: 31% * Not sure/needs further discussion – First response: 0%/Second response: 0% (Q2) What should be included in the notification of pending transfer? – 19 responses/16 responses * Include a link to deny transfer (status quo - Losing FOA) – First response: 26%/Second response: 13% * Include a link to deny the transfer and a link to approve the transfer – First response: 58%/Second response: 50% * Include no links (the message serves as a notification only) –First response: 11 %/Second response: 13% * I do not support any notification of pending transfer – First response: 0%/Second response: 25% * Not sure/needs further discussion – First response: 5%/Second response: 0% Discussion: * Question: Is the transfer already done when the notification is sent out? Answer: the transfer is not complete. The notification is providing the TAC – that the registrar has updated the registry with the TAC and the transfer can go through. * Maybe we should have an explanation for the different notifications. But noting that this is just a discussion of the various examples. * Confusing – not sure how this is different than the previous TAC notification – notification of TAC request, not pending transfer. This is kind of, but not quite, the current losing FOA – you aren’t going to NACK this, but just approve it. * Doesn’t make sense. The registrant or reseller will go to the registrar and ask for the TAC. Then the registrant will go to the new registrar with the TAC and the registrar will go to the registry with the TAC. This notification of pending transfer seems to be a new way to describe the losing FOA. This will only be implemented if we decide to keep the losing FOA. * One of the good things about the losing FOA today is that you can see where the name is going. * Seems that immediate transfer is something everyone wants. * This pending idea – there is no pending if there’s an immediate transfer. It is pending between when the registrar creates the TAC but before it is used. * You don’t know who the gaining registrar is in this notification because you only created the TAC. * If the transfer is immediate then it is never pending. * It sounds like we're all in agreement to get rid of this middle email; maybe we should consider if any required elements listed here should be stuck into the Notification of TAC email instead? * Doesn’t the loosing registrar who the transfer request is coming from (name of registrar)? * There is the window of when the registrant requests the TAC and when the registrant gets the TAC. * The losing registrar do know who will be the gaining registrar – because they know where the TAC request is coming from, correct? No, when the registrant requests the TAC the registrar of record doesn’t know where it will go. In an instant transfer, you wouldn’t know the gaining registrar until the transfer is complete. * This should be combined with the TAC request notification. Then we aren’t sending two emails at the same time. Just put more information in the TAC request notification. * If the notifications are combined, will the registrant be able to NACK or ACK? * if we combine this into the notification of TAC request, then this is sent before the transfer has been submitted to the new Registrar, so there is no ACK or NACK yet. * The “NACK” process at this point would be to cancel or overwrite the TAC since the transfer then would not be able go ahead, and that cancel TAC is part of the first email template, right? * If we decide to go with immediate transfers then this information would be in the notification that the transfer is complete. * In our previous discussions we agreed that immediate transfer was the outcome we were looking for. * If we go to immediate transfer then we should take out the pending transfer notification. * Members should be talking with their Stakeholder Groups during these discussions, and not waiting. * Question: If we combine this into one notification – TAC request and possibility to provide a NACK/ACK – how do we solve the issue that the registrant might be different from the account holder? Answer: Are there logical points in the flow where a notification should happen? Where in the logical flow does notification have to happen or could occur? * If the pending transfer starts if a registrar is allowed 5 days to produce the TAC and send to the registrant, and that causes an email notification, the registrant could present the TAC to the account holder. * The experience when transferring away should be so good that the customer would want to come back to the registrar. Notification of Transfer Completion: (Q1) Should the losing registrar notify the registrant when a transfer is complete? 12 responses * Yes, This notification should be required in policy -- 42% * It should be up to the registrar if and how they do this -- 42% * No, I do not support this type of notification -- 17% * Not sure/needs further discussion -- 0% (Q2) What, if anything, should be required in this communication? 12 responses * The notification should contain all of the elements listed in the Working Document -- 17% * The notification should include only some of the elements listed in the Working Document -- 58% * The notification should include a different set of elements, which have not yet been discussed -- 0% * I do not support this type of notification -- 25% * Not sure/needs further discussion -- 0% Discussion: * For those who don’t support submitting the notice, from a registrant point of view the losing registrar should be off the hook; this should be a gaining registrar notification. * The problem is that the gaining registrar does not know who the domain owner is at this point. * Concern with the gaining Registrar sending it is that the contact info on the domain can change when the transfer happens, so it might not go to the original pre-transfer domain owner. * We can allow the reseller to send it, as long as there' a record that it was sent, contains what it should, etc. ? * A registrar can relay it’s requirements to the reseller but the registrar would still be on the hook for compliance if the reseller did not do it. * Compomise could be to not make this mandatory. See Losing FOA Working Document: Losing FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wCUMe9ii6g05k...> Start at page 3: * Fourth bullet and items below go through the thought process of the in between time. * At some point we need to discuss when the losing registrar can prevent a TAC being created and thus block the transfer. Agree that we need to discuss this, but we first need to agree on a more streamlined process. * Could there be a notification when a transfer is requested – whether the registrant or someone else? “Transfer being requested” is confusing – that could be preparing it for transfer, but not initiated in the gaining registrar’s system. There should be two notices to the registrant, with the first being a combination of the TAC request and the pending transfer: 1) notification of TAC request/pending with ACK/NACK/cancel TTL; 2) losing registrar send notification to pre-transfer contact saying “goodbye”. Make sure there is no confusion in how we describe these steps. * Due diligence should happen before the TAC is provided – so first notification is only that a TAC is requested; second is when the registrar approves it based on due diligence. * Need a chart with the different stages of the transfer process and when notifications are sent. But need to get to one chart, not multiple options. * There should be available options, which we have now because of the 5-day delay. * Maybe call it “pre-transfer notification” which includes notification of TAC request and pending transfer. * Don’t include different options in the policy, but just what has to be included. Have a standardized process for most cases. * Helpful if Sarah and Kristian can propose how this flow would look, with or without a diagram. * Hard to do due diligence, so should be up to the registrars. We don’t have to stipulate what happens during the up-to-5-day period. Leave it as an available option. * If we combine notifications 1 and 2, then we can’t do the ACK/NACK. ACTION ITEM: Sarah Wyld volunteered to create a flow chart. Staff will create a Google doc template for this. 4. New Topic: Gaining FOA (45 minutes) – See: Gaining FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hdi...> * Postpone discussion to next meeting. 5. AOB (5 minutes) * Next meeting: 7 September 2021 @ 16.00 UTC