The call for the Transfer Policy Review PDP Working Group will take place on Tuesday, 06 February 2024 at 16:00 UTC for 90 minutes.

For other places see:


  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



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

Alternates: Christopher Patterson (RrSG)



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: []


  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:


  • 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


  • 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.

  • No labels