Dear TPR WG Members,
Please find below the notes and action items from today’s call.
The next TPR WG meeting will be on
Tuesday, 16 November at 16:00 UTC.
Best regards,
Emily, Julie, Berry, and Caitlin
Action Items
1. ACTION ITEM: Staff to enquire for clarification. See below:
NOTE THIS:
https://www.icann.org/resources/pages/text-2012-02-25-en, ON that page: Please note that you may not transfer your domain name to a new registrar within the first 60 days after initial registration, or the first 60 days after a transfer. NOTE THIS:
https://www.icann.org/resources/pages/policy-transfers-2014-07-02-en, On that page, it becomes optional for the sponsoring registrar to NACK the transfer for being within the
60-day window. No longer enforced by registry by policy.
Transfer Policy Review Phase 1 - Meeting #24
Tuesday 09 November 2021 at
16:00 UTC
1. Roll Call & SOI Updates (5 minutes)
2. Welcome & Chair updates (5 minutes)
- The RrSG will be providing a poll to its members on the various locks. Should have the results at the next meeting or the one after.
3. Presentation of Compliance Metrics (attached) -- TPR Team Feedback
ICANN Org Compliance Overview:
Discussion:
- Question: When do you categorize them – when received or when closed? Answer: Time depends on response, whether the registrar is following
up with the reporter, it is case-by-case.
- In looking at the number of complaints versus transfers, that seems to be a low rate of complaints.
- A lot of these unauthorized transfers are being solved between the reseller and the registrar, rather than categorized as hijacking.
- The point should be made clear, that these are the only ones that ICANN Compliance sees. There's no visibility to other unauthorized
transfers where no complaint is filed with ICANN.
- It would be very helpful to see the total number of complaints, not just those reported to ICANN.
- The information provided by Compliance shows that most of the complaints are closed because the reporters did not respond to ICANN’s
request for further information.
- Question: Is it possible to summarized these as how many were closed in favor of the complainant and how many were not? How many were
closed with the complainant comfortable with the determination or not? Answer: That data is already in the compliance dashboard.
- Is there any visibility into the number of complaints that are filed with a transfer dispute resolution provider under the Transfer
Dispute Policy?
- I think the only way we'd even know is if there was some sort of aggregate reporting from Registrars.
- I do not think there’s any way to get that data in an accurate manner.
- An interesting metric to report would be how long a ticket is usually in process before it is closed. Compliance will take that suggestion
back to the team.
4. Continued deliberations on Additional Security Measures – see:
Additional Security Measures working document [docs.google.com]: Discussion of other security measures the WG would like to consider
Registrar-applied lock
- Comment from Sarah: I think this would be more clear if we indicate this lock can be applied and lifted at any time during the life
of the domain. This is not specific to the creation moment
- Updated the text to clarify that the lock already exists and is not specific to the creation moment, but the charter question asks
if the lock should be applied by default when the domain name is registered.
Post domain creation lock
- Comment from Steinar: For the new gTLDs, the applicant needed to define the lifecycle. I believe the majority of the new gTLDs have
a 60 days transfer lock after registration where the serverTransferProhibited is set
- Comments from Barbara: In some registries, the post domain creation lock is systematically enforced and it is not possible to opt out.
It is not necessarily implemented using the serverTransferProhibited EPP code. Seems that "MAY deny" is the more appropriate language unless/until all registries mandate this lock.
- Not all these locks are a specific EPP code, but may be a policy that someone is trying to enforce. These are policies from the registries
to the registrar, not an ICANN policy.
- It should be down to the individual registrars, but not sure that is in scope of the transfer policy – but gets negotiated between
the registries and registrars.
- A post-domain creation lock would be out of scope because it is not an existing requirement from ICANN’s existing policy, but from
an RRA between ICANN registries and registrars. That doesn’t prevent this WG from trying to create a consensus policy that is consistent across all registries.
- This is a legacy items that came into several of the long-standing registry agreements. Could be unique to the legacy TLDs.
- Since the registrars will talk about locks we won’t go into that much detail, but it seems that this should be part of this PDP, that
it is in scope.
- So the boundaries of discussion to a prevent transfer after x days of creation as a consensus policy are 1) consistency 2) security/stability.
- Question: Why do these registries have a transfer lock and does it have a function today.
- To that extent that a registry got a court order for a transfer, there would be ways to effectuate that.
- Maybe the registries will tell us that there is a good reason for these post creation locks, or maybe they will say we no longer need
them (and had nearly forgotten about them!). If no longer necessary, then based upon advise from this WG, ICANN org can consider changes to this provision in contracts as they arise.
- Would be helpful to know how many registry agreements have this requirement.
- The 60 days lock for transfers after creation has been implemented for many ccTLDs too.
- Hard to say how many transfer disputes there would be if this requirement went away.
- From an end-user perspective it would be easier to understand the requirement if everyone had it.
- The Creation Lock is of the very least concern in my experience, but cleaning up an unnecessary lock could be doing everyone a favor
and there is no better place for discussing it. On the other hand, if there is a reason as Barbara suggested could be possible, then consistency may be a desirable goal.
Lock subject to UDRP Proceeding
- Comment from Zak: Also See Paragraph 8 pf the UDRP Policy. Would we refer any changes to the RPMs PDP Phase 2 review of UDRP policy?
Answer: Could keep the same NACK, but if they change the policy they’ll be required to look at that.
Redemption Grace Period Lock
- Comment from Barbara: Suggest changing this to "Registry imposed lock" to avoid confusion with the Registry Lock service that some
registries offer for some TLDs.
- Staff will make that change.
Registry Lock Service
- Comments from Barbara: Some registries have separate Registry Lock agreements with registrars to govern this service as not all registrars
opt to offer the service. Note that in addition to the serverUpdateProhibited EPP status set, a lock on the domain name likely also has serverTransferProhibited and serverDeleteProhibited EPP status codes set.
- Staff will add text to clarify.
- Note that "registry lock" may be being sold under different names.
Page 8: OTHER SECURITY FEATURES THAT THE WORKING GROUP MAY WANT TO DISCUSS
- Requirements regarding logs that registries and/or registrars must maintain with respect to the transfer?
- Multi-factor authentication?
- To access the account: some WG members expressed that prescribing requirements would be out of scope, but that the WG could provide guidance about the benefits and the ways that MFA can enhance other security
elements.
- To access the TAC or unlock the domain: some WG members expressed that this would make the transfer process too onerous for registrants.
- Other security practices/features applied in other contexts that could be relevant to this discussion?
Discussion:
- Comment from Steinar: Not sure this is the "place" to add, but a secure way of informing Registrant about the TAC should be implemented.
This indicates that email may not be sufficient.
- May not be other options than email. Should remain up to the registrar to determine what is a secure method.
- Maybe some kind of wording that it has to be done it a secure manner.
- Should be too specific/narrow.
For the consistency idea: There being a 60-day transfer lock on creates and transferred, but with an opt-out feature.
- Another question that this group might want to ask is the rationale for such a thing other than consistency – such as security components?
Also, is 60 days the right length?
- That transfers into a lock that’s settable by the registrant. It is in the registrant’s hands to turn that off.
- So it would be a default lock but with an opt out.
- What is this trying to protect against? Need some clarity on this. You may need two different mechanisms, depending on the reasons.
- There could be constraints on turning off the lock.
- The registrant can opt out and the registrar can opt out of the option. But would like to see transparency from registrars that they
have opted out.
- Apparently it [60-day lock] was a “policy” that started way back with Verisign. Legacy ROs carried it forward. For example, Afilias
was required to do this for .ORG when it transferred from Verisign. Somewhere on or about the 2012 round the policy was backed off. I found a 2014 reference above. So, it seems that new registries don’t do it as they never had any reason too. “legacy”
TLDs and permits RSPs do it because they always have and never had a “reason” not to. This is something we should probably clarify in our work and final recommendations.
ACTION ITEM: Staff to enquire for clarification. See below:
NOTE THIS:
https://www.icann.org/resources/pages/text-2012-02-25-en, ON that page: Please note that you may not transfer your domain name to a new registrar within the first 60 days after initial registration, or the first 60 days after a transfer. NOTE THIS:
https://www.icann.org/resources/pages/policy-transfers-2014-07-02-en, On that page, it becomes optional for the sponsoring registrar to NACK the transfer for being within the
60-day window. No longer enforced by registry by policy.
5. Losing FOA Candidate Recommendations – see:
Losing FOA Working Document [docs.google.com] (beginning on p. 14)
- Begin this discussion at the next meeting.
6. AOB (5 minutes): None.