Dear TPR WG members,

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

The next meeting will be Tuesday, 23 January 2024 at 1600 UTC.

Kind regards,

Christian, Caitlin, Berry and Julie

ACTION ITEMS/HOMEWORK: None captured.

Transfer Policy Review - Meeting #114

Proposed Agenda

16 January 2024

Notes:

1. Welcome and Chair updates

• SOI update: Eric Rokobauer (RrSG - Squarespace) -- I am with a new registrar member. I've changed companies. I now work for Squarespace, primarily operating as a retail registrar. See: https://community.icann.org/display/gnsosoi/Eric+Rokobauer+SOI.
• Chair update: there arer only 6 or 7 more meetings for us between now and ICANN79 and our goal is to get all the change of registrant things wrapped up, and maybe even tidy up some loose ends that we had discussed previously.
• The other thing is for Compliance to get back to us, and they should have the request of Sarah's done sometime this week, so we should hear from them shortly after that -- maybe next week or the week after that.

2. Review updates to Preliminary Recommendations – see attached slides, starting at slide 3.

Discussion – Slides 7, 8, and 9:

• Questions: What is the Prior Registrant expected to do? What are we trying to achieve? It only causes issues down the line.
• Both these processes (TAC issuance and Change of Registrant) should remain separate.
• I like the idea, but don’t know if we can actually implement this.  There's probably a change of registrar, and that the current registrar is not going to know that. 
• In the case of domain name theft this can be easily bypassed.
• We'd want to probably leave room in this if we were to leave it as is for there to be exceptions, or for this to be operating within the contractual agreement with the registrant.
• What we are hearing is this is probably not operationally effective or needed.
• The most critical part of that notification that would hypothetically go to the Prior Registrant is instructions on how to take action. Allowing another means if there was an improper change of registrant to catch that and say, before the TAC is used to contact the registrar and say, this wasn't me. However, the TAC probably should not be in that notification to the prior registrar.
• According to the RFC the TAC should not be retained by the generator. It should just be sent to the person who's getting it and not retained. It's kind of odd that this would come up here, because this should be covered somewhere where we talk about the TAC, and it should say that should be sent to the requester, and nowhere else. And so this 3.1, if it would be included, should seem redundant,
• So, you're right that no one should be storing the TAC.
• If there is some sort of evidence of improper change of registrant maybe then there should be some sort of additional actions to be taken, but if there’s nothing improper this could be a security risk.
• Thought we were trying to reduce notifications.  Multiple notifications could cause problems or be ignored.
• It sounds like the Working Group doesn’t support this.
• We could add a preamble, “unless otherwise defined in the agreement between the registrar and the registrar.”
• Continue to think about if there is some kind of due diligence, rather than sending something to the prior registrant, if there's something more that the registrar should do when there is a case of a transfer.

3. Continue Definitions discussion – see attached Primer and slides 11, 12, and 13:

Discussion:

• We need to get this resolved before we can move on.
• The one thing that is important is the email address. I think if that changes that should trigger notification because that sort of can assume
• a little bit of a control on the domain name itself, where the TAC is being sent. 
• Change of email is an attack vector – a way to gain control.  We can send a notification of a change of email to the registrant and that can be a trigger.  Material change only applies to the email address.
• Looking at the last bullet (slide 11), is “material change” still relevant and worth incorporating into Change of Control?  Or looking at the second bullet, is it up to the registrar to determine Change of Control?
• I think it depends on the business model of the registrars.  It’s important to recognize that there are registrars with completely different business models.
• As a corporate registrar, we don't just focus on email. The change of registrant incorporates the ownership details. So when we're looking at the name and organization that is actually quite significant from a corporate perspective as well.
• We can come back to the concept of the anchor method – does it make sense that that is email?
• You don't always know if it's a change of control prior, or even right after a change.
• If the email does change are we saying something should occur?
• What is a material change and what triggers a notification?  If email changes should there be two notifications – one to the prior email and one to the current email? That needs to be decided as well.
• We are getting rid of the lock, does material change still need to exist?  Is it fit for purpose for notifications?
• Why do we have to send a notification to the new email address?
• One of the benefits of sending to the new email could be if there was a typo so it got sent to someone else.
• It sounds like material change is still fit for the purpose of a notification.  It sounds like there are reasons for sending to the prior and the current.
• Should the data automatically generate a notification and, if so, what’s the harm in that?
• More notifications could just be considered spam.
• Should these notifications be changed from a MUST to a MAY – that is, up to the registrar to decide?
• It should be the registrar’s business model.
• If it changes from MUST to MAY it’s no longer enforceable.
• In favor of keeping the same policy for all registrars.  The internal routine could be based on the business model.
• If you change to MAY all the problems with privacy/proxy/Designated Agent are gone.
• Do we need a Change of Registrant policy? Something to think about and take back to your Stakeholder groups.  And if it goes away, what is missing?