Dear TPR WG members, Please find below the brief notes and action items from today’s meeting. The next meeting will be Tuesday, 13 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/1DpDO2BYTl6TA7...> Transfer Policy Review - Meeting #117 Proposed Agenda 06 February 2024 Notes: 1. Welcome and Chair updates * Less than a month from ICANN79 – just four scheduled calls. Get our recommendations in place. * Take self-assessment survey by Feb 21. * COR Reduction Rationale doc still has no input – need to fill that out. See action item above. * Zak, BC: Gave an update to BC – expressed their deep concern to remove all notifications and default locks. If that was a recommendation, would likely be a minority report: * Question – what locks? Answer – Opt out to be accepted on a 60-day lock: BC would like to see a default lock that registrars could opt out, with consistency in application. BC is interested in reducing the lock but against removing it. * That’s why we need the rationale document to be completed, such as the reason to remove the 60-day lock. * Steinar, ALAC: Looks like at ICANN79 will discuss the COR with public participation – will provide info if that is the case. 2. Mandatory Notifications wrap-up – see attached slides, starting at slide #5: Discussion: * Second bullet point, which do we want? Are we saying generic your info was updated? Or confirm specific change? WG needs to decide. * Stay away from the word “contact” – Suggest changing “contact information” to “registrant data”. Need to be clear. * Prefer the message lists field that was updated but not what changed in the field. * Look at the alert you get from a responsible bank as an example and minimize the amount of info provided in case the email was compromised and also avoid being too prescriptive. * Question: Wasn’t there another item re: triggers? Answer: We still need to discuss. * Ask ourselves what security goals we want to achieve if COR is not in the Transfer Policy. * Sounds like the group is okay specifying what fields have changed, but not what in that field changed. Identify known RDDS field but not what. * Question: Change of ownership with registrant data – who will see it (the old/new registrant)? Answer: That’s something that needs to be addressed. It depends, but I don’t think we can say how that would work. Need to get into these things more deeply. Notifications – Opt Out Pros/Cons: See Slide 6 Discussion: * Key point: registrant opt out. * If account is hacked notification goes to fraudulent registrant. If registrant opted out wouldn’t get notifications. * Need to look at what other industries do and why – should be a defensible rationale. It’s not about transfers – it’s about information changing. * Could turn on by default and let registrant opt out. * Uncomfortable with being able to turn off notifications – only the owner and only proactive. * Don’t see the outcry from registrants getting emails. * Could be situations when registrant would want to opt out. * maybe it should be an account setting, but not a registrar default in their terms etc. That seems like a good middle ground. * Agreement on mandatory with/without opt out. * Support for the three minimum fields (name, org, email) as triggers – see #3 below. * If there were a proactive opt out that might be okay if it was an informed decision. * If multiple changes notifications should be able to be combined. * Opt out okay if informed. * If we do have a registrant opt out it should be the same across the board for all registrars. * Note that we are talking about opting out of notifications, not locks. And should be consistently applied. * Agree: Same fields as today; mandatory but registrant can actively choose to opt out. 3. "Change of Registrant Data" discussion -- see attached slides, starting at slide #7: Discussion – slide 8 – Change of Registrant Data: * Need to decide what is that minimum set of triggers. * Prefer to keep the current set of triggers – second row. Ability to combine notifications is really helpful. * Look at what needs to be notified for security purposes. * Can still do verification even if combined. * Support for the three minimum fields (name, org, email) as triggers. Discussion – slide 9 – Material Change: * Need to decide what is that minimum set of trigger. * Include addition of data? That could be a material change if field was blank. * WG supports leaving Material Change as is. Discussion -- slide 10 – Privacy/Proxy/Designated agent * Question: Remove Designated Agent? Answer: WG has decided it won’t be defined in policy. * Registrar wouldn’t know if third-party privacy/proxy; If registrar does know, would a change trigger a notice? If assigned back to the registrant is that a notification? * No matter what: WG is saying, it doesn’t matter if it’s privacy/proxy if any one of those three fields changes it will trigger a notification. Note that the PPSAI process is still being worked out. * One of the important things is that it relates to the registrant data and not the PUBLIC data - so if the real data is redacted (not with P/P service) and is changed then the CORD is triggered. Discussion -- slides 11 & 12 – Prior and New Registrant * These terms are out of date. * Send notification when data changes in those three fields – see above – to prior registrant. * Is the opt out on the person or the domain name? Need to discuss details. * Need to continue discussion at the next meeting. 4. CORD Availability and Placement (time allowing) -- see attached slides, starting at slide #13: * Deferred to next meeting. 5. AOB: None.