All,

I was able to get some additional background relating to the 60 day lock after creation of a domain name.  From Verisign’s perspective, this is definitely legacy as a form of this restriction has been in our RA and enforced by the registry since 1999. It is my understanding, from a conversation with someone who pre-dates me here at Verisign, that this was originally created as a registrar protection to prevent new registrants from hopping around to avoid payment (at least one of the considerations).  Below is from Appendix 7, Section 3.1.1 of the publicly available .COM RA.  I believe that other legacy TLDs may have similar language.  Hope this helps.

Transfer (other than ICANN-approved bulk transfer). Transfers under Part A of the ICANN Policy on Transfer of Registrations between Registrars may not occur during the Add Grace Period or at any other time within the first 60 days after the initial registration. Enforcement is the responsibility of the Registrar sponsoring the domain name registration and is enforced by the SRS.

Barbara Knight, CCEP, CCME Sr. Director - Registry Compliance bknight@Verisign.com t: 703-948-3343 12061 Bluemont Way, Reston, VA 20190 Verisign.com

From: GNSO-TPR <gnso-tpr-bounces@icann.org> On Behalf Of Julie Hedlund
Sent: Tuesday, October 19, 2021 2:01 PM
To: gnso-tpr@icann.org
Subject: [EXTERNAL] [GNSO-TPR] Notes and action items - TPR WG Meeting #22 - 19 Oct 2021

Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 

Dear TPR WG Members,

Please find below the notes and action items from today’s call.

The next TPR WG meeting will be Tuesday, 26 October at 17:30 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin 

Action Items

1. WG members to review the attached revised slides for the ICANN72 session, in particular the updated the definition on slide 8 based on the discussion on the mailing list, as well as slide 12 with the potential recommendations.

Transfer Policy Review Phase 1 - Meeting #22

Tuesday 19 October 2021 at 16:00 UTC

1. Roll Call & SOI Updates (5 minutes): No updates provided.

2. Welcome & Chair updates (5 minutes)

• ICANN72 meeting next week on Tuesday, 26 October at 17:30.
• Will send around revised slides.
• WG member updates: No updates provided.

3. Deliberations on Additional Security Measures (60 minutes) – See: Additional Security Measures Working Document

Overview:

• Kind of a broad topic, with a focus on locking.
• How to make the TAC a more consistent standard.
• Locking – mandatory or suggested; if allowed what and how.
• Some registrars impose a 60-day lock and some don’t, and some do something in between.
• Trying to get something that is consistent.

Charter Question: a6) Survey respondents noted that mandatory domain name locking is an additional security enhancement to prevent domain name hijacking and improper domain name transfers. The Transfer Policy does not currently require mandatory domain name locking; it allows a registrar to NACK an inter-registrar transfer if the inter-registrar transfer was requested within 60 days of the domain name’s creation date as shown in the registry RDDS record for the domain name or if the domain name is within 60 days after being transferred. Is mandatory domain name locking an additional requirement the Working Group believes should be added to the Transfer Policy?

Discussion:

• Question: Are we dealing with locking in Phase 1 or Phase 2?  Answer: We may bring some Phase 2 items into Phase 1.  If we get into a certain level of detail we may hold off.  Let’s open up the discussion and see where it goes.
• Context behind the question about what is in Phase 1 and Phase 2:  The Additional Security Measures document is asking if domain name locking should be mandatory.   In Phase 2 we also consider reasons for NACKing.  The Phase 1 question is a result of survey input.
• These things are linked, so it’s difficult to see how we can discuss this in a limited context.  Do want to make sure that this issue receives its due addition.
• It is open for discussion here and if people think we are getting to detailed we can pull back.
• We need to look at all of the different reasons for domains to be locked; we might want to keep some and take others away.
• Question: What would be the purpose of a mandatory lock?  Is it to prevent that a domain name is transferred multiple times – against an attack?  Answer: That is one reason to have the lock, as the charter question notes “to prevent domain name hijacking and improper domain name transfers.”
• Suggest that the first order of business is to look at what the current policy says.  It currently isn’t mandatory.  Then we should consider whether they should be mandatory and have some consistency.
• Also consider other questions, such as whether or not there is anything else that needs to happen, who has control, what is the timing?
• Question: Do we have the numbers for domain names that were hacked and were pushed from registrars to others?  Answer: Don’t think we have that specific data, but ICANN Compliance can check.
• Looking back in time, this lock for 60-days was part of IRTP Part B or C.  It would mitigate the hops to multiple registrars.  The intent of the lock for 60 days was somewhat watered down or lessened.  You had the ability to opt out of the lock, which causes confusion in the marketplace. 
• Maybe we should start with whether post-creation registration locks should be mandatory. Have heard from registrars that this lock is at the behest of registries, but not sure that is the case. Would like to know more about the policy rationale for this particular kind of lock.
• We should think about recommendations for how we can obtain the data to help inform a review of the policy, since we don’t have this level of specific data now.
• RegistryLock is a service that has to be approved by ICANN as a RSEP (still so if I call correct). Locks set by the registrar must be changed by the sponsoring registrar.  registry lock is very difficult to remove, requires passphrases etc, it's separate from the "Client Transfer Prohibited" EPP status which is applied to domains.
• We should explicitly link the post-transfer-lock to the Dispute-Policy and make it mandatory for exactly this purpose. Giving a rationale does increase the acceptance.
• We can look at the discussions around the last IRTP around the 60-day lock.
• Another reason for low numbers of complaints – not all registrants know about ICANN or how to complain.  So some unauthorized transfers are not being reported.
• These unauthorized transfers do happen, although there aren’t many of them.  Still, the impact is large.  We should look at the impact.
• The big concern is when it gets to 5 different registrars in 5 different countries, so the claw-back process is complicated.
• Some of the pressure on registrars in clawing back these domain names could be ameliorated – if the actual registrant could invoke.  We could consider who should be initiating the different processes.
• When we are talking about the claw-back, what are we talking about?  It could be getting certain assurances from the registrant – perhaps creating a type of form for registrants, whether mandatory or not. To put the registrar at ease to make this move faster and improve the coordination between registrars.
• The main point of this charter question is whether there should be a required lock on a transfer.  Specifically, “Is mandatory domain name locking [on a create or transfer] an additional requirement the Working Group believes should be added to the Transfer Policy?”  We aren’t talking about a Registry Lock, but a client lock by registrars.
• The lock after registration and after transfer are two different things and should be treated differently.  Identifying what those differences are is important.
• The issue for many registrants is not whether locks should be mandatory or not, it is the inconsistent application.  It should be consistent or the registrar’s policy should be transfer.
• Understanding of the current policy is that registrars MAY deny a transfer if a domain name has been transferred in 60 days.  Registrars have the discretion – and the charter question is asking if this lock instead should be mandatory.  There are certain instances where the registrar MUST NACK the transfer, such as in UDRP cases.
• Verisign prevents domain names from being transferred for 60 days after being created as part of our system.  We don’t get complaints from registrars during this locking period.  Can’t speak for other registries.
• Good to know where the 60-day creation lock came from.
• How do we standardize on the various options with that discretion?
• If there is text somewhere else that prevents a transfer we should look into it.  Not that we would change that if it’s not policy.
• It seems it was a legacy – there being systematic enforcement of restricting transfers for 60 days post creation.
• Seems that some WG members agree that the lock should not be mandatory, but discretionary.

Questions from the Transfer Policy Status Report Survey:

Q7) What methods do you use to mitigate domain name hijacking outside of the IRTP framework?

• We’ve kind of talked around this.  Maybe a registrar has a reason to lock this.
• Are there a finite number of scenarios?
• If you want to have good security you have to make sure everything is locked at the account level – start with the basics (the account) and that is something only the registrar can do.
• One of our outcomes is not only determining whether or not a lock should be mandatory or optional, but also to make sure we are using the proper or precise term.
• Homework: Start to review the different EPP status codes and when we are talking about a lock – what part of the EPP status codes are being used.  Are there opportunities to make it more precise?
• Can’t always see if there is a lock.

Q13) Do you lock domains by default upon registration of a name?

Q21) What do you think the ideal transfer process should look like from a policy and a technical perspective?

– Seems that we’ve covered these questions.

4. Review: Summary of “Potential Recommendations Under Consideration” to be presented to the community during ICANN72 session (15 minutes) -- See attached revised slides.

ACTION ITEM: WG members to review the attached revised slides for the ICANN72 session, in particular the updated the definition on slide 8 based on the discussion on the mailing list, as well as slide 12 with the potential recommendations.

5.   AOB (5 minutes): ICANN72 session: Tuesday, 26 October 2021 at 17:30 UTC