Dear TPR WG members, Please find below the brief notes and action items from yesterday’s meeting. The next meetings will be Saturday, 02 March at ICANN79: Session 1 at 13:15-14:30 and Session 2 at 1500-1600 San Juan (UTC-4). Kind regards, Christian, Caitlin, Berry, Julie and Feodora ============================================================================================ 2024-02-27 Transfer Policy Review PDP WG Call<https://community.icann.org/display/TPRPDP/2024-02-27+Transfer+Policy+Review+PDP+WG+Call> Main discussion and action items 1. Welcome and Chair Updates * Link to the slides: https://docs.google.com/presentation/d/1JIYvzbYHJxK5srf2qbdKr_qslCl-TOcv9iQs... * Members are encouraged to take a look at the rationale document (https://docs.google.com/document/d/1DpDO2BYTl6TA7ApfPpG3Hpl13nrv4y4x9B3hImrx...) and add input where possible 2. ICANN79 TPR sessions Agenda * Two sessions during ICANN79 Saturday 2nd of March (link) * Links to wiki page agenda of ICANN79 sessions: * Session 1: Focus on Recommendations * https://community.icann.org/display/TPRPDP/2024-03-02+ICANN79+Transfer+Polic... * Session 2: Focus on Established Relationships: https://community.icann.org/display/TPRPDP/2024-03-02+ICANN79+Transfer+Polic... * 4 Members are encouraged to serve as volunteers to present during ICANN79 to present/read out recommendations * Volunteers: Rec 1: Prudence Rec 2: Theo Rec 3: Owen Rec 4: Sarah * Will rationale document be presented? Focus will be on recommendations document as rationale document is still work in progress. 1. CORD Prelim Recs & Rationale (& volunteers) * Link to doc: https://docs.google.com/document/d/1DpDO2BYTl6TA7ApfPpG3Hpl13nrv4y4x9B3hImrx.... * Rec 1.3. change included revised language to clarify if P/P is involved. * Rec 2 the order has been updated based on previous call. Clarifies what to keep Section II from the transfer policy. * Current Section II needs it own policy. * Recs should be taken into consideration as a whole and not in isolation. * Rec 2.1 includes changes that clarifies that the “designated agent” is not used properly and new wording has been added. “Designated agent”should be eliminated from “future standalone Change of Registrant Data Policy”. * “Designated Agent” removed from transfer policy, but it could be used elsewhere if need be for other processes. * Rec 2.2 Eliminate Section II b “Availability of Change of Registrant” from future standalone policy. It not necessary to include here. * Rec 2.4 Eliminiate 60-day lock from future policy. * Perception could arise that this Rec 2.4 might take away security measured. Hence, more rationale could be needed in the rational document? * Members referred also to other options for registrants to increase security for their domains. * Rec 3 group is adding that Registrars have to provide instructions how registrants can take action if the change was invalid. * Rec 3.4 wording changed from MUST to MAY send CORD notification to new Email address. * Rec 4 Registrars must provide an opt out for Change of Registrant Data notifications. * Rec 4.1. Registrars MUST enable Change of Registrant Data notifications by default when a domain name is initially registered. Registrars MAY disable Change of Registrant Data notifications if the Registered Name Holder elects to opt out of these notifications. * Discussion on is this a security feature and is this hapering security or enhancing it? Opt out as part of data protection option? * Email verification process is in place and could pose an overlap with Rec 4.1? Verification Email only goes to updated Email not existing Email. 2. Recap “Established Relationship” topic * Link to slides: https://docs.google.com/presentation/d/1JIYvzbYHJxK5srf2qbdKr_qslCl-TOcv9iQs... * TPR Swimlane Overview included in the slides. Two yellow boxes are included for the established relationship procedure: * Initiation * Transfer * Refresher on NACK-ing recommendations (Prelim Rec 16 and Prelim Rec 17). How does this affect registration data? * Small group redlined Rec 17 where registrars MUST apply 30-day post change lock and included that they may unlock earlier if an established relationship exists. * Rationale will be further explained and presented during ICANN79 and group should be prepared to speak for or against it during ICANN79. * Does the group believe that an “Established Relationship” role/procedure should be created? If so, what exemptions should customers be provided with? How do these exemptions impact TPR? 1. AOB * No comment