Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be on Tuesday, 18 January 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: 1. TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPof...> (beginning on p. 15) Recommendation #5: ACTION ITEM: Delete Recommendation #5. Recommendation #10: ACTION ITEM: Change the first sentence to: “The Working Group confirms that the Transfer Policy should continue to require Registrars to [set the TAC at the Registry] and….” Insert new text in brackets. Recommendation #11.1: ACTION ITEM: Revise the language to be more precise, as in “11. 1: A standard Time to Live (TTL) for the TAC be [14 calendar days from the time it is [set] at the Registry]…” Insert new text in brackets. 2. Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?u...> (beginning on p. 14) Recommendation 13: ACTION ITEMS: 1. 13.2: Delete it. 2. 13.3: Add two new bullet points: -- Date and time that the TAC was generated and information about when the TAC will expire. -- If the TAC has not been provided via another method, this communication will include the TAC. Recommendation #14: ACTION ITEMS: 1. Use “Losing Registrar” instead (with footnote explaining that we mean the Registrar of Record at the time of the transfer request). 2. Use 24 hours as the timing. Transfer Policy Review Phase 1 - Meeting #31 Tuesday 11 January 2022 at 16:00 UTC 1. Roll Call & SOI Updates: No updates provided. 2. Welcome & Chair updates (5 minutes): No updates provided. 3. Second reading: TAC and FOA (45 minutes) TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPof...> (beginning on p. 15) Recommendation #3: Removed “from time-to-time”. Recommendation #5: * Last week talked about removing recommendation #5. Assume that it is no longer valid and remove it. * ACTION ITEM: Delete Recommendation #5. Additional Candidate Recommendation xx: Keep as a placeholder for now. Recommendation #6: Continue with the new version. Recommendation #9: * A couple of edits to make it more clear that the TAC is only used once. * Revisit when we talk about bulk transfers. Recommendation #10: ACTION ITEM: Change the first sentence to: “The Working Group confirms that the Transfer Policy should continue to require Registrars to [set the TAC at the Registry] and….” Insert new text in brackets. Recommendation #11.1: * 11.1 is okay and keep the 14 calendar days – consider whether hours makes more sense. From when it is provisioned at the registry. But the registry isn’t actually doing it – it’s the registrar. The registry is only accepting the TAC. It is when the registry hashes and saves it to the record when the 14 days start. Could say, “set at the registry” and make the change in recommendation 10 as in 6.2. TTL starts when it is set at the registry. * ACTION ITEM: Revise the language to be more precise, as in “11. 1: A standard Time to Live (TTL) for the TAC be [14 calendar days from the time it is [set] at the Registry]…” Insert new text in brackets. Recommendation 11.2: * 11.2 there was a lot of discussion around the purpose. Leave it as is for now. * For 11.2, second bullet “After a period of less than 14 days by agreement by the Registrar of Record and the RNH?” Is it possible to specify what the agreement might be? * Not sure why we have 11.2. Think we are trying to codify what can happen today and we want to continue the ability to set the TAC to null. * Think we want to set out rules around resetting the TAC so that a registrar can't reset it so often it becomes impossible to transfer the domain. * That agreement could be part of your registration policy, indicating pre-determined reasons to reset a TAC. * Sections 3.7 and 3.8 of current policy set out why a transfer can be denied. Could be reasons to enable a reset of the TAC. Useful to review when we talk about NACKing. * If we leave it with just the first bullet, is that sufficient? Let’s keep both now and revisit in the NACK discussion. Think we need it in case of evidence of fraud. * Is the RNH and Registrar agreement a case where a circumstance arises and then it has to be agreed to at that time? It would need to be prior to being set to null. It should be that the RNH can ask for it at any time. Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?u...> (beginning on p. 14) Recommendation 12: We are good with the current language with the footnote. Recommendation 13: * The Registrar of Record will have to maintain who that was at that point in time. * No objections to “10 minutes” for the timing. Recommendations 13.2 and 13.3: * Should we had a TTL? * We don’t say that the TAC is provided, but we assume it? * See 6.3: When the Registrar of Record provides the TAC to the RNH or their designated representative, the Registrar of Record MUST also provide information about when the TAC will expire.]. Makes sense then to also include this in 13.3. * Reseller could be the designated representative. * If it’s a combined communication, is it necessary to say when the TAC was provided? * It’s almost always available via control panel. * There are registrars that only use the Registry interface. How will this work for these? * If registrars use a registry interface for transfers the question pops up how do they send the FOA? As the registry does not trigger such a process.] * Do we care if the Registrar of Record is providing the TAC via control panel? Either way we have to send an email. * Maybe “control panel” isn’t the right terminology since it could be via other methods. * What if we just say that the Registrar of Record…has to include the TAC if it has not be provided by another method, in the Notification of TAC Provision. * Maybe delete the first sentence in 13.2: “[If the Registrar of Record provides the TAC viais provided in the control panel, this notification must be provided to the RNH using a separate method of communication other than the control panel.] * Consider for bullet 3 under 13.3, perhaps include a timeframe? * Should we get rid of 13.2? Not sure we need it. Seems to be generate agreement to delete it. * ACTION ITEMS: * In 13.2: Delete it. * In 13.3: Add two new bullet points: * Date and time that the TAC was generated and information about when the TAC will expire. * If the TAC has not been provided via another method, this communication will include the TAC. Recommendation #14: ACTION ITEMS: 1. Use “Losing Registrar” instead (with footnote explaining that we mean the Registrar of Record at the time of the transfer request. 2. Use 24 hours as the timing. Recommendation #14.1, 14.2, 14.3: * On 14.3, first bullet: Waiting to hear from the RySG on the feasibility of providing the IANA ID. * Not sure that the benefit of including the IANA ID or Rr name outweighs the work to do so. 4. AOB (5 minutes) * Next call: Tuesday 18 January 2021 at 16:00 UTC