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

For other places see:


  1. Welcome and Chair updates
  2. Discussion of Security Measures: COR + Registrar Transfers
  3. Poll Questions
  4. AOB



Apologies: Zak Muscovitch (BC)

Alternates: Arinola Akinyemi (BC)



Audio Recording

Zoom Recording

GNSO transcripts are located on the GNSO Calendar

Notes/ Action Items



  1. Welcome and Chair updates
  • This is our last call of the year – resuming on 09 January in two weeks, same time.
  • Eight meetings before ICANN79; finish up COR and return to any outstanding items.
  • Call for updates: None provided.

2. Discussion of Security Measures: COR + Registrar Transfers – See attached slides.

  • Moving on from COR only to COR + TAC request.
  • Wrap up COR only and COR + TAC request security measures following the break and before ICANN79.
  • 60-day lock seems to be causing frustration and doesn’t seem to provide increased security.

Discussion – Option 1 (slide 3):

  • Question: Doesn’t the registrar do a validation/security check. Answer: 5-day window was for registrars to do due diligence/security/validation check. Some TAC request may be almost instantaneously fulfilled; other may take longer because of check.
  • Last bullet is an option for registrar to offer or not.
  • Usually not what happens: usually registrant logs into their account – don’t usually get a TAC request via email.
  • Thinks the intent was the above: TAC request comes in and then registrar notices it’s from a different email.
  • The order is usually that the registrant requests a TAC but then notice that they need to update their info.
  • Compliance has had lots of complaints when they need to request a TAC but can’t because they need to update their contact info.
  • This is not specific because it is registrar-specific.
  • This is one of several options.

Discussion – Option 2 (slide 5):

  • That 5-day window for the registrar allows a security check.  In the Group 1A discussions we covered this.
  • This is combining two processes – updating contact info and requesting the TAC – that is not necessary and creates a dependency.
  • If we look at the example, that is not how the TAC is requested (via email).  Agree not to combine processes and we already have an option for the registrar to validate.
  • TAC request is coming in however.
  • This could be a business decision by a registrar.  Like the email notification but don’t require approval from both the old and new registrant.
  • The timing of the email change – business decision as to whether that requires validation/5-day wait.  Losing registrar’s responsibility.  Change of registrant does happen often around a change of contact.
  • We need to factor in how some registrars are processing expired deletions.  Those may change contact info.
  • Allowing an objection by the losing registrant is an opportunity for fraud. No need for the losing registrant to be involved.
  • The above is an argument for this to be a registrar’s business decision.

Discussion – Option 3 (slide 7):

  • Not seeing how this provides an added security benefit – same security as option 1, registrar to validate.
  • This makes a lot of sense – should verify if you change contact info, but doesn’t add security.
  • This can be used against registrants. Could keep a registrant from moving to a new registrar.

Discussion – Option 4 (slide 9):

  • This option has been put up by different people.  Addresses Compliance issues.
  • Like this option – opt out is good, that the registrar can remove the lock as long as there is agreement.
  • For Compliance – is there a requirement for documentation?
  • The extra lock doesn’t add security.
  • Two things: The transfer lock after COR is causing problems so if the registrant can remove that might address those complaints, but would there be  more domain thefts?
  • Have to consider whether this adds anything. Have discussed that COR doesn’t cause domain theft.
  • Sounds like we are adding complexity without added security.  Can we get the data we requested from Compliance?
  • This feels like a security measure but not sure it is and also adds cost and risk.

Discussion --- Option 5 (slide 11):

  • Run into a whole bunch of operational issues.
  • Seems difficult to enforce.
  • Not sure the benefit outweighs the added complexity.

Discussion – Option 6 (slide 13)

  • Any additional thoughts?
  • Good support for an argument to separate these processes, such as not making the 5-day window being a dependency.  We aren’t solving the problem with these options, but we are creating more complexity.  Seems like there is some agreement to separate COR from TAC request.

3. Poll Question 2: COR Followed by a TAC Request

Of the Options discussed thus far, which can you support as a minimum requirement for Registrars when a TAC request follows a completed COR? Select your first, second, and third choices (if applicable) 

Option 1: No special requirements are necessary. 58%

Option 2: There should be a waiting period before issuing the TAC, allowing time for objections. 58%

Option 3: Before issuing the TAC, changes to RNH/Account Holder information must be verified.* 42%

Option 4: Following a COR, impose a 30-day transfer lock, but allow Registrars to lift it, if agreed. 58%

Option 5: Registrars must offer registrants an opt-in option for added protection. 67%

Option 6: Other: _________ 83%

Option 7: None of the above 42% (not making a choice)


  • Looks like other/no special requirements is the favored option.
  • Don’t think we are looking for the exact answer today.
  • Last week there was agreement if there is a change of registrant the notice goes to the losing registrant.
  • Today it seems that there is agreement that COR is handled as a COR and a TAC request is handled separately.
  • Need to get some recommendations out of this.

4. AOB

  • No labels