2024-02-06 Transfer Policy Review PDP WG Call

Notes/ Action Items

ACTION ITEMS/HOMEWORK: WG to complete the COR Reduction Rationale document at: https://docs.google.com/document/d/1DpDO2BYTl6TA7ApfPpG3Hpl13nrv4y4x9B3hImrx_Fc/edit?usp=sharing [docs.google.com]

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.