2023-12-19 Transfer Policy Review PDP WG Call

Notes/ Action Items

 ACTION ITEMS/HOMEWORK: None captured.

Notes:

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)

Discussion:

• 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