Dear TPR WG members,

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

The next meeting will be Tuesday, 26 July at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

Action Items: WG members to consider the best way to frame the discussion of the CoR policy and review the Cor Foundation Brainstorm document at:  https://docs.google.com/document/d/1Fjkdk6VSWHw-ZjRfHHL0vGeWw9NKcf7IsT8eT8T2VYw/edit.

Notes:

Transfer Policy Review Phase 1(b) - Meeting #54

Proposed Agenda

19 July 2022

1. Roll Call & SOI updates

2. Welcome and Chair Updates

• Phase 1A created several new mechanisms that apply to the CoR concepts as well in a positive way.  WG should take note of those things, such as the 5-day window to provide the TAC.
• While it is Phase 2, everyone can assume we will create a more robust dispute mechanism not just for change of registrar, but could also be for CoR.
• As a reminder, PC closes 2 August. 4 submissions thus far.  https://www.icann.org/en/public-comment/proceeding/initial-report-on-the-transfer-policy-review-21-06-2022/submissions?page=1&sort-direction=newest.  We have three meetings before we take a break and then staff write up the public comment summary.
• Re: Mike Rodenbaugh sent an email last week Tuesday about the 60-day lock being optional and since it’s optional why do we need recommendations – any comments?
  • From Mike: “I want to get clear on the effect of this proposed change.  This 60-day lock is optional now.  We are talking about removing that optional lock from the IRTP, and it seems we are getting to consensus to remove it.  I suppose that removing it from the Policy is not the same as prohibiting registrars from imposing such a lock anyway via their TOS.  So, are we also talking about prohibiting registrars from imposing any such lock upon Change of Registrant?  Otherwise, I guess I do not see the point of removing it from the Policy.  Maybe I am just missing something here...”
  • Discussion:
    • If you can opt out of it, what reason would there be to have a 30-day lock as a default?
    • Makes sense to remove it entirely.  Registrars could still choose to do that and registrants could pick registrars accordingly.
    • Not a comment to Mike's email, but CoR was something that guarded against parties that had made a malicious registration from rotating the registrant of record frequently as a means of evasion - but this was more of a thing when more of the whois information was public.
    • +1 Jothan, and with a 30 day lock on transfers, it would remain at that registrar.
    • Good thing to think about, whether it even belongs or not.
    • Does the lock even need to exist for the CoR?
  • Locks from Phase 1a – transfer can’t occur 30 days from registration or transfer.  It is a delay, not a lock per se.  If you have a case where a name has changed to another registrant a lock would prevent moves to another registrar, but not a registrant within a registrar. We may need to diagram the different scenarios.
  • We don’t have any numbers so it’s not clear how much a problem are domain name hijacks.
  • Still a large impact (hijacks) even if there aren’t many of them.
  • The current Registrar of Record on a given domain name is the party with the highest ability to resolve matters related to that domain name.  Change of Registrant, as long as the name remains at the most recent gaining registrar, does not introduce additional challenge to transfer related matters.
  • If we remove the locks it can be gamed and it is a little bit more risky.
  • The majority of CoRs are legitimate, but there can be a big impact from a few illegitimate changes.
  • We already have some security mechanisms, particularly from Phase 1a.
  • How to evaluate the impact from illegitimate CoRs: even if it is an intra-registrar transfer the rules should be the same – have the same locks.
  • GDPR (and subsequent Privacy Regulation) - and the affectation on the amount of redaction it caused to RDAP/WHOIS - have lowered the impact of Change of Registrant (CoR) related matters, because the majority of the information has become redacted or otherwise is not displayed publicly.
  • When providing a service to the registrant, you want some type of lock to mitigate hijacking.  If you are going to have a lock in both cases, maybe 30 days is too long, or maybe not.  It’s about providing a good service and keeping things the same.
  • I don’t think I agree that the transfers are similar enough to require the same locks for both...I like consistency (lock periods should be uniform) but I think updating owner data is different enough from changing Rrs that they're not the same thing.
  • It is not just about Registrar Hopping and domain theft, but preventing fraud on the Internet.  If a registrant is doing something bad, the registrar knows that.  If the registrar prevents fraud, the domain should not be able to move for a period of time to prevent the fraudster / phisher / bad guy continuing the fraud they are committing.
  • What is the criteria for a material change that today triggers a CoR lock?
  • 1.1 "Change of Registrant" means a Material Change to any of the following: 1.1.1 Prior Registrant name, 1.1.2 Prior Registrant organization, 1.1.3 Prior Registrant email address, 1.1.4 Administrative Contact email address, if there is no Prior Registrant email address.

3. Risk-based approach: What problems are we trying to solve with CoR? 

Here is the document we will use for today's discussion: Cor Foundation Brainstorm --  https://docs.google.com/document/d/1Fjkdk6VSWHw-ZjRfHHL0vGeWw9NKcf7IsT8eT8T2VYw/edit

• This is an open-ended table.  We can rank these and see if they help us get to the same spot.
• Context: One of the things we are hoping to do is to take a step back from the current policy, think about the problems we are trying to solve and the risks.  If a registrant name is changed, for example, is that something we need to worry about.   We also don’t need to come up with solutions at this point.

Discussion:

• There is a big difference between changing the information about a registrant (name, etc.) then if there is a move to a different account (intra-registrar transfer).  Not sure we need to care about changes to an account.
• Account is difficult as that might not be in scope.  Only if there is a true change of ownership.
• If there is going to be a change that causes a lock a user should be warned before they commit to that. 
• Propose that we limit what we do to transfers.  Some changes in a registrant’s account aren’t a transfer.
• Change of ownership is valid to discuss.
• See the definitions at: https://docs.google.com/document/d/1gu4sXGvyJeWJIfvaK_I7GKA6lAdfKFPQKaN4UMgzmcE/edit.
• What we are trying to do is to determine the problems, not the solutions.
• Also, registrars are responsible for keeping their accounts accurate, while registrants have rights to make changes.
• At the end of the day the WG has to have consensus recommendations to change any of the CoR policy.
• For example, does the change of a name warrant restrictions on subsequent changes or change of registrar?
• Another example, if the WG agrees that a material change should no longer include a registrant name change then we need to thoroughly document the reason for the change.
• 60-day lock is the action based on what is considered a “material change.”  The WG could decide that something isn’t a “material change” but keep the subsequent action (lock), or decide to scrap both what are material changes as well as the actions – once we go through the various scenarios.
• Maybe we decide something else is better than a lock.
• If we look at today’s environment it doesn’t seem that there is much policy to prevent an illegitimate transaction.  And the AuthInfo Code has been there since the name was created.  But with the Phase 1A recommendations the TAC will not be sitting there, but not provisioned until requested.
• Any transaction from column 1 with no other follow-on action would not invoke the TAC.  But others would invoke the inter-registrar transfer policy.
• The policy today originated through a discussion of change of control.
• There has to be a way for registrants to dispute a change, beyond an intra-registrant policy.
• No matter the original intent the policy has not worked well.
• Should look at why an action was put in place and whether it is still needed.
• We need to come up with a way to get to a rationale—either to keep the policy or to change it.
• Example: If there is an illegitimate name change that stays within the registrar is that a problem particularly if easily corrected?
• Could say that we don’t need to look at the definition or trigger, but maybe the possible action (notification, lock, dispute mechanism).
• However the contact is made between the registrar and registrant, what is important is when that contact changes.
• Can we create a baseline?
• Don’t think the trigger is the update to the communication, but the owner.  We will at least have to update the list of changes to remove the Administrative Contact.

ACTION ITEM: WG members to consider the best way to frame the discussion of the CoR policy and review the Cor Foundation Brainstorm document at:  https://docs.google.com/document/d/1Fjkdk6VSWHw-ZjRfHHL0vGeWw9NKcf7IsT8eT8T2VYw/edit.

4. AOB