Dear TPR WG members, Please find below the brief notes and action items from today’s meeting. The next meeting will be Tuesday, 30 January 2024 at 1600 UTC. Kind regards, Christian, Caitlin, Berry and Julie ACTION ITEMS/HOMEWORK: None captured. Transfer Policy Review - Meeting #115 Proposed Agenda 23 January 2024 Notes: 1. Welcome and Chair updates * Want to get COR discussions wrapped up by ICANN79. 2. COR Sunset/Definition discussion – starting at slide 3 (see attached): Discussion: * 2.3 doesn’t really apply (subject to a UDRP). That’s an overlap in policy. Would still be covered in UDRP policy. * On slide 5: there may be circumstances to proactively opt out of this. * This is if it’s recommended to get rid of COR. Poll (slide 6): Option 1: No change to COR definition (COR = name, organization, email address) --13% Option 2: Expand COR definition (COR = name, organization, email address, and phone number) -- 20% Option 3: Reduce COR definition (or retitle to Change of Control) to email address only -- 7% Option 4: Add Change of Control definition (email address or other anchor contact method) that is treated differently/separately from a COR -- 27% Option 5: Eliminate the Change of Registrant policy (no notifications are required when updating any registrant data) -- 33% Discussion: * If we get rid of the policy, GDPR may still have requirements that apply. * Note that this is COR policy, separate from the TAC. * If we look at the second bullet, how to take action, there is no requirement associate with this – expect a lot of objections in public comment, especially Option 5 (COR elimination); need to have a rationale for what we are recommending. * Option 5: Don’t think the COR works as it currently, but some kind of notification could be useful, but maybe somewhere else. * Are you suggesting notification is a MUST for any data? Yes but not in Transfer Policy. Maybe recommend to Council. * Either Option 5 or 4 get the most support. * Maybe add an Option 6 – eliminate COR but keep in a notification requirement. * Agree that sending a notice is a good thing to prior and updated address but don’t need a lock. Do we need a Notification Policy? * It’s not about transfers so maybe it goes somewhere else. * We’ve also enhanced the TAC request process. * We aren’t providing the most secure solution; you have to find that somewhere else. * Maybe the notification is a decision by the registrar – to provide that security option to customers. * Leaving notification in place could address registrant concerns. * Eliminating could result in a backlash from the community – notification is something at least for the optics. * From a staff perspective the sunset of most of COR Policy will be a shock to the community. WG needs to coalesce around a recommendation and rationale, or present options for public comment. Also need to highlight other requirements, such as under GDPR. * Need to highlight in the rationale that the current policy doesn’t work and why. * Need to pre-emptively prepare for public comment with a rationale. 3. Privacy/Proxy charter questions – start with slide 9 Discussion: * This will go away with a notification policy. * Proxy is the registrant. Under GDPR these questions go away. d10) Should the policy be the same regardless of whether the registrant uses a privacy service or a proxy service? If not, how should these be treated differently? * If the COR is removed this (question d10) is not needed? Maybe notifications for the removal of a privacy/proxy service? * Prior to GDPR you had to turn off a privacy/proxy service before transfer. * Is it possible that privacy/proxy services are truly third parties? Hard to put all in one category -- it depends. * Should turning on or off of a privacy/proxy service trigger a notification? Some do not consider it a change of registrant. d11) Are notifications provided to privacy/proxy customers regarding COR and changes to the privacy/proxy service information sufficient? For example, should there be additional notifications or warnings given to a privacy/proxy customer if the privacy/proxy service regularly changes the privacy/proxy anonymized email address? * No. * Not suggesting notification for any change. 4. Designated Agent charter questions Discussion: d12) In its survey response, the Registrar Stakeholder Group indicated that, “There is. . . overuse of the Designated Agent, which has basically circumvented the policy.” To what extent is this the case? What is the impact? * Would like an explanation for how Designated Agent is used. * There is overuse of the Designated Agent by design. There is an operational reason it is in there. d13) If the Designated Agent function is not operating as intended, should it be retained and modified? Eliminated? * Can only eliminate it if you eliminate the COR. * It is capitalized because it’s a defined term in the policy. d14) Are there alternative means to meet the objectives of Designated Agent role? * Only if COR isn’t eliminated. * Need to look at how the DA originated. * Perhaps waiving some rights to the registrar or others would replace it. d15) Based on complaints received by ICANN’s Contractual Compliance Department, there appear to be different interpretations of the role and authority of the Designated Agent. If the Designated Agent function remains, should this flexibility be retained? Does the flexibility create the potential for abuse? * When we came up with the DA we decided not to determine who that should be. d16) If the role of the Designated Agent is to be clarified further, should it be narrowed with more specific instructions on when it is appropriate and how it is to be used? * Should the Designated Agent be given blanket authority to approve any and all CORs? Or should the authority be limited to specific COR requests? Does the authority to approve a COR also include the authority to request/initiate a COR without the Registered Name Holder requesting the COR? * If you are going to do this you may as well take the DA out of the policy. 5. AOB