Dear TPR WG members, Please find below the brief notes and action items from today’s meeting. The next meeting will be Tuesday, 20 February 2024 at 1600 UTC. Kind regards, Christian, Caitlin, Berry and Julie ACTION ITEMS/HOMEWORK: WG to complete the COR Reduction Rationale document at: https://docs.google.com/document/d/1DpDO2BYTl6TA7ApfPpG3Hpl13nrv4y4x9B3hImrx... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1DpDO2BYTl6TA7ApfPpG3Hpl13nrv4y4x9B3hImrx_Fc/edit?usp=sharing__;!!PtGJab4!5AMC2yyFuiAuDP4NVzqpIuVbN_QeariExytXRoJUCPWEFXwih6H_FltoJa3yAsqzuSgtz-VVaOL5fxb7jnSTUnXPeXp6qWg3vw$> Transfer Policy Review - Meeting #118 Proposed Agenda 13 February 2024 1. Welcome and Chair Updates * Three sessions with this one before ICANN79. * Two sessions scheduled for ICANN79 – COR and impacts. See TPR agendas at: agenda:(https://community.icann.org/display/TPRPDP/2024-03-02+ICANN79+Transfer+Polic...). It is currently a rolling agenda for both sessions, part 1 being discussion of the draft COR recommendations, and part 2 being discussion of the Group 1(a) 30-day transfer restriction (and whether the existing recs need to be updated in light of the CORD recs). * ALAC will be meeting at ICANN79 to discuss COR on Saturday, 02 March; open to the public. Follows the TPR sessions. * Still no rationale in the document at: COR Reduction Rationale document at: https://docs.google.com/document/d/1DpDO2BYTl6TA7ApfPpG3Hpl13nrv4y4x9B3hImrx... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1DpDO2BYTl6TA7ApfPpG3Hpl13nrv4y4x9B3hImrx_Fc/edit?usp=sharing__;!!PtGJab4!5AMC2yyFuiAuDP4NVzqpIuVbN_QeariExytXRoJUCPWEFXwih6H_FltoJa3yAsqzuSgtz-VVaOL5fxb7jnSTUnXPeXp6qWg3vw$> * WG Self-Assessment Survey is still open – 9 responses so far. Closes 21 February. 2. CORD Availability discussion – See attached slides, starting at slide 3. Discussion: * Numbers 2 and 3 can go away completely. No longer relevant. * 2.3 is probably duplicate policy language. * Don’t know what harm there is in allowing someone to update their data – would be less harmful to allow (2.1). * If there is a domain name for which you could update the registrant data would think there would be a contract between the registrar and registrant. * Unless there is disagreement it seems we could simplify the policy by eliminating 2 and 3. * Does 2.2 still make sense if authorization is not required? We now have a notification-only policy so you don’t need it. 3. Preliminary Recommendations – See attached slides. Discussion Prelim Recs 1.1 and 1.2, slide 5: * This is impossible to code for – hard to define a typo or not. * Original language assumed some manual processes. * Think about how this would work in the real world. No notion of typo. * Nothing to prevent a registrar from treating any change as material. Discussion Prelim Rec 1.3, slide 6: * Make sure we are talking about the underlying customer data. * Question: Why do we care about this and how does it tie into change of registrant data? Answer: To clarify in response to charter questions. * If a registrant applies a privacy proxy service, that’s not a material change. * But there is underlying customer data and if that changes there is a notification. Changing the name would trigger notification because it’s out there. * We're getting into a discussion that no longer has anything to do with a change of registrant data in combination with the privacy proxy service. * We had a couple of charter questions on privacy proxy that needed to be addressed. * Do we eliminate it? * It may have been important when we wrote the charter but we can say it’s no longer applicable. Discussion Prelim Rec 2, slide 7: * It’s redundant language. Discussion Prelim Rec 3, slide 8: * Question: Should we change “registrant data” to “registration data”? * Why would we change anything? This section is no longer relevant. There is no confirmation process anymore. There's only notification. Just remove it. Discussion Prelim Rec 4.1, slide 9: * No comments. Discussion Prelim Rec 4.2, slide 10: * Question: Send to the previous or only the new RNH? Answer: We discussed getting rid of the prior and sticking with just RNH. I don’t think we decided that you couldn’t send to both of them if you chose to. * Since this is framed as a change of data the only time it would make sense to notify both is if email changes, which is addressed in 4.4. Discussion Prelim Rec 4.3, slide 11: * No comments. Discussion Prelim Rec 4.4, slide 12: * Question: What are we trying to achieve? Answer: When you are changing the email address the registrar is required by contract to verify that email address -- the new one. So there is work that goes into that. So it's not like it's just changed. Getting a positive notification that email is updated. * Don’t see any good reasons from a policy perspective. * From a registrant perspective see the benefit but if already done by WHOIS verification then that is the complete solution. * Could think about turning the MUST into a MAY? * Notifications might typically go to the account control panel. Discussion Prelim Rec 4.5, slide 13: * No comments. Discussion Prelim Rec 4.6, slide 14: * No comments. Discussion Prelim Rec 4.7, slide 15: * Wonder if we need to be that specific. Discussion Prelim Rec 5.1, slide 16: * Concerns with this: when it comes to a new RNH that is out of the registrar’s control if there is a new agreement. * Question: Maybe we could incorporate more about the decision to be informed and when can an opt out be reversed. Answer: See slide 17. * Question: When a domain name changes hands is there anything that needs to be done about the opt out continuing? Answer: Talked about whether to opt out every time you make a change. * It can be a permanent flag not an every time flag. * Change MUST to MAY? We kept MUST for consistency across registrars. Discussion Prelim Rec 5.2, slide 17: * Question: If a registrant makes a CORD and prior to that opts out there still would be a verification email – any concern about fraud in opting out? * Continue discussion at the next meeting. 4. AOB: None.