2024-02-06 Transfer Policy Review PDP WG Call

PROPOSED AGENDA

1. Welcome and Chair Updates

2. Mandatory Notifications wrap-up

3. "Change of Registrant Data" discussion

4. CORD Availability and Placement (time allowing)

5. AOB

BACKGROUND DOCUMENTS

PARTICIPATION

Apologies: Jody Kolker (RrSG), Osvaldo Novoa (GNSO Council Liaison), Juan Manuel Rojas

Alternates: Christopher Patterson (RrSG)

Attendance

RECORDINGS

Audio Recording

Zoom Recording

GNSO transcripts are located on the GNSO Calendar

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.