Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be in two weeks on Tuesday, 14 February 2023 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: Actions from Meeting on 31 January: 1. Re: Recommendation 13 small group work on TTL enforcement: https://docs.google.com/document/d/1Wq4dHcIFR5XogoutSh0klkCyhZFUlS1z7cl2ilv9... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Wq4dHcIFR5Xog...> 1) Rick Wilhelm to post to the list thoughts about the proposal of the registry for flexibility to shorten the TTL. 2) WG members to suggest language, if any, relating to disallowing long-lived TACs. 2. Re: Recap of Phase 1B deliberations, including touchpoints for Phase 2 topics, WG members should review the document at: https://docs.google.com/document/d/1sVvWazAu6TR-W191wOO_ZYKmZxGP7-lxB_AxaIf-... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sVvWazAu6TR-W...>. Notes: Transfer Policy Review - Meeting #79 Proposed Agenda 31 January 2023 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Today we are wrapping up deliberations for now on Phase 1A topics and then briefly recapping Phase 1B deliberations to date before starting Phase 2 discussions the week after next. * There will be no call next week on 07 February. * We'll share the Project Change Request with the WG this week and submit to Council on Monday. * The next redline of the Initial Report is coming out soon. Folks can be reviewing that in the background while we get started on Phase 2 deliberations. There will be a few things you haven’t seen before – ensuring every recommendation has a rationale and making them consistent, among other things. Not recommendation text, but still important, so please review that new text too. * Any updates from the threat vectors small team? Not hearing any, staff will take a first stab at providing some placeholder text and we encourage comments/edits from the small team. 3. Proposed revisions based on 24 January call (Recommendations 2, 16, 17, and new Recommendation yy on record keeping) and continued discussion of outstanding questions on transfer confirmation/Losing FOA (Recommendation 2, see inline for discussion questions): https://docs.google.com/document/d/10lRyhg9t8vY_HGB5GsCMIQmmafnBecuNoQA5Djaq... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/10lRyhg9t8vY_H...> * Came to some convergence last week. We will summarize: * Record keeping: * New Draft Language: “The working group acknowledges that with the elimination of the Gaining FOA requirement, the AuthInfo code becomes even more important for the transaction and for any Compliance investigation related to it. The working group further agrees that it is important to properly document and retain all notifications related to the transfer sent by the Losing Registrar, so that information about such records can be sent to ICANN Compliance when investigating a complaint, as needed. Therefore, the working group is providing a specific recommendation on requirements regarding the retention of these records and provision to ICANN upon reasonable notice.” * Preliminary Recommendation yy: The Registrar MUST retain all records pertaining to the provision of the TAC to a Registered Name Holder, as well as all notifications sent per the requirements under this Transfer Policy. At a minimum, the records retained in accordance with this section shall MUST document the date/time and, means and contact(s) to whom the TAC and notifications are sent. The Registrar MUST shall maintain these records for the shorter of 15 months or the longest period permitted by applicable law, and during such period, MUST provide such records to ICANN upon reasonable notice. Rationale for Preliminary Recommendation yy: This recommendation seeks to ensure that the necessary information is available to ICANN org in the case of a Compliance investigation related to an inter-Registrar transfer. The 15-month retention period specified in this recommendation is consistent with requirements anticipated to be included in the Registration Data Policy. * Question: Is this doable for registrars? Answer: Most registrar do this anyway. They are already retaining records concerning AuthInfo code provision. Can’t provide customer support without logging. Although this type of record keeping shouldn’t be taken as a given. * Recommendations 16 & 17: Minor adjustments to clarify that the new 30-day requirement would replace any existing 60-day requirements. Also a suggestion to include the number of hours and the word “calendar”: * Preliminary Recommendation 16: The Registrar MUST restrict the RNH from transferring a domain name to a new Registrar within 30 calendar days / 720 hours of the initial registration date. To the extent that a Registry and/or Registrar has an existing policy and/or practice of restricting the RNH from transferring a domain name to a new Registrar for a different period of time following initial registration, all policies and practices MUST be updated to be consistent with this new requirement. * Preliminary Recommendation 17 : The Registrar MUST restrict the RNH from transferring a domain name to a new Registrar within 30 calendar days / 720 hours of the completion of an inter-Registrar transfer. To the extent that a Registry and/or Registrar has an existing policy and/or practice of restricting the RNH from transferring a domain name to a new Registrar for a different period of time following an inter-Registrar transfer, all policies and practices MUST be updated to be consistent with this new requirement. * Some support but not enough to put into the recommendations right now. Pick back up in Phase 2. * Recommendation 2 – new text: “[The timeframe of five (5) calendar days specified in section I.A.3.5 of the policy MUST be expressed in both calendar days and hours, “Failure by the Registrar of Record to respond within five (5) calendar days / 120 hours to a notification from the Registry regarding a transfer request will result in a default "approval" of the transfer.”] [As with the new notifications described in Preliminary Recommendations 3 and 4, the working group recognizes that this notification MAY be sent via email, SMS, or other secure messaging system. These examples are not intended to be limiting, and it is understood that additional methods of notification MAY be created that were not originally anticipated by the working group.]”. This is a new item for discussion. * “Or other secure messaging system” – some would argue that mail is not secure. May want to tweak that language. Or drop the word “secure”. * There's a mixed sentiment on this - the FOA that provides NAK agency to the RnH being furnished out of band to a possibly compromised system. If the API is compromised - the FoA can be bypassed. * I think we are talking about delivering payload via the SMS. Not sure these are the same situations. Don’t want to suggest that SMS is secure. * It sounds like the language in a footnote for Recs 3 and 4 – WG members provide feedback on that footnote/language. * Question: whether this group want to make changes to the mechanism for delivering the TAC in the losing FOA in the status quo. Is the status quo correct or not? If there is no momentum to change the status quo on the Losing FOA --- then this language would only be included for Recs 3 and 4, and not for Rec 2. * No concerns about the change to hours and calendar days. 4. Recommendation 13 small group work on TTL enforcement: https://docs.google.com/document/d/1Wq4dHcIFR5XogoutSh0klkCyhZFUlS1z7cl2ilv9... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Wq4dHcIFR5Xog...> New language: * For accuracy: if the sponsoring Registrar is required to expire the TAC by updating it to null, there is a possibility that at the time when the TAC is set to expire, either the Registrar or Registry systems have an outage (or there is a communication interruption), this means that the TAC expiration would be delayed until the transaction could be completed, opening a window for possible usage of a TAC that the sponsoring registrar had deemed expired. * For consistency: having a centralized approach at the registry allows prospective gaining registrars to know that every TAC will be expired at 14 days regardless of the sponsoring/provisioning registrar * For security: having every TAC in a registry have a maximum lifetime that is enforced consistently prevents the existence of any long-lived TAC which could be used at part of an unauthorized or unintended inter-registrar transfer Discussion: * New rationale --- having the timeout at the registry is more accurate. * Sarah Wyld may have some minor changes. * This has support from the RySG. * Re: “must be valid for” enforces a minimum, but not a maximum. So maybe we need to tweak the wording. This also doesn’t seem to allow a registry to have a standard less than 14 days. * Also update to make consistent with use of hours. * What if we say “the TAC MUST [normally] be valid for”? * Don’t think you should leave it up to the registrar to shorten that period. * The original goal was to stop love-lived TACs – not trying to prevent a minimum. * Suggestion: “The TAC TTL MUST not exceed 14 calendar days..” * Could there be a 13.1.1 – allowing the registry to shorten to a standard of less than 15 days as long as it is consistently enforced? * With small team hat on: MUST = low variation (ie no variation) - this being consistent across gTLDs is good -- altering this to "MUST not exceed" will introduce variation opportunities that will complicate integrations and customer service, which IMHO is less good. * Suggest going back to the standard of 14 days. * Why would registrar be able to shorten but not registry? This is a new concept not discussed before. * Is there a way to define which TLD Ry's would have the option to shorten it (to include .bank)? OR the suggestion is any could? * Needs to be an edit to disallow long-lived TACs – continue this discussion on the list. Note also the recommendation should be read along with the rationale that makes it clear that the TTL is no longer than 14 days. * Recap: For now for the redline use the existing language from the small team but add hours to be consistent. Also adopt the new rationale for the redline. ACTION ITEM: Re: Recommendation 13 small group work on TTL enforcement: https://docs.google.com/document/d/1Wq4dHcIFR5XogoutSh0klkCyhZFUlS1z7cl2ilv9... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Wq4dHcIFR5Xog...> 1) Rick Wilhelm to post to the list thoughts about the proposal of the registry for flexibility to shorten the TTL. 2) WG members to suggest language, if any, relating to disallowing long-lived TACs. 5. Recap of Phase 1B deliberations, including touchpoints for Phase 2 topics: https://docs.google.com/document/d/1sVvWazAu6TR-W191wOO_ZYKmZxGP7-lxB_AxaIf-... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sVvWazAu6TR-W...> * Purpose is to remind everyone where we were in our discussions – a refresher. It will be a while before we go back to COR, but for homework WG members should review the document. ACTION ITEM: Re: Recap of Phase 1B deliberations, including touchpoints for Phase 2 topics, WG members should review the document at: https://docs.google.com/document/d/1sVvWazAu6TR-W191wOO_ZYKmZxGP7-lxB_AxaIf-... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sVvWazAu6TR-W...> 6. AOB