2023-12-05 Transfer Policy Review PDP WG Call

Notes/ Action Items

ACTION ITEMS/HOMEWORK: 

Re: Transfer complaint metrics -- Sarah Wyld to send an email with the WG’s request for more specific data. [COMPLETE]

Notes:

1. Welcome and Chair updates

• Only two meetings left for the year then the holiday break.
• Zack Muscovitch, BC update:
• Position for the record: “Change of Registrant Lock -- The default rule should be a transfer lock following a change of registrant. However, a registrar should be required in a transparent manner, to enable a registrant, upon request to opt-out of the transfer lock or to reduce the transfer lock, rather then leave it to each registrar to decide whether they will generally permit opt-outs. Nevertheless, each registrar should retain discretion as to whether to permit a transfer even if the registrant has ostensibly opted out, for security reasons. A transfer lock should not prevent registrants and businesses from effecting bona fide transfers when necessary or desirable. There should be a fact-based rationale for the determination of the length of the default transfer lock, whether it is 60 or 30 days, for example.”
• Explained to them is that there had been some preliminary discussions on removing transfer locks, and entirely as one of the options under discussion. Part of that suggestion could be that there was only notification to the registrar and to the losing registrar rather than an ability to stop the transfer, and some of the preliminary feedback I received from the BC on that question was that the BC would be prepared to accept the removal of change of registrant locks altogether, but as a quid pro quo of that the BC would want to see that there was more than a mere notification and an ability of the registrant to stop the impending transfer. This is preliminary, there's no decision or formal policy changes being made. But just to give you a sense of what the BC is thinking at this early stage.

Discussion:

• Owen -- Question: You mentioned a quid pro quo. I was just wondering if you could clarify that. So they'd be okay with removing the lock if the registrant could get out of such a change of registrar.
• Zach: As far as the working groups is concerned, on the 30-day change of registrar lock, that provided a significant amount of protection for registrants in terms of getting back that domain name. And so in in that context it was somewhat persuasive to some in the BC. I think that removing the change of registrant lock could be acceptable, give given that additional protection was in place.  Some believe that it would only be fair if there's if there's going to be no change of registrar lock to enable a registrant to have more than a mere notification with uncertain recourse after receiving the notification, but to actually stop the transfer between registrants.
• Rich: I just wanted to further clarify something with Zack. You mentioned that your group is talking about the notice to undo a transfer during a CoR. A transfer isn't taking place. That notice is just letting them know a registering change has happened. If a transfer is happening, they're already getting notified via the FOA during the 5-day period.
• Zach: My understanding was that the preliminary discussion this working group was having was that one of the possibilities under consideration was that upon a change of registrant being initiated, the registrant would be notified right away that the
• change of registrant had been initiated but at that point it would be too late to stop it in any event. So if the registrant got the notification that would be too late in most cases, and then the registrant would be left to deal with the registrar to try to reverse it. And so
• the BC's perspective at this preliminary stage they wanted something more than a mere notification and rather an ability to
• stop that transfer.
• Rich: I think there's a little bit of debate here on whether or not for the change of registrant there's a notification that sent. There's also verifications of the new details that are happening on the RDS side. So that's another process already happening. So they're probably getting another notification of the change from that as well to confirm it. Then after such a change during the CoR as it stands right now, but we're discussing removing it. Then a request for the auth code needs to be made, at which point those verifications kick in, and the 5 day to reverse the transfer which is already in place and already part of the process. I'm just wondering if a further lock is necessary, or whether we can continue with just removing the lock from the change of registrant.
• Theo: So when you're discussing the current change of registrant process you need to keep in mind what we replace it with, and compare those two and not go back to the old transfer system, because that's going to make your discussion more complex when moving forward on this.
• Zach: Just to add a little bit more background and context for the discussion with the BC. It was noted that there's going to be what's perceived as additional security provided by the new TAC process. And so essentially, the argument goes that if your email or your registrar account was penetrated that's a whole other story. And so we presume that in order to have a TAC that it's rightfully obtained, that would by extension the argument would go, so that's yet another reason for removing the ability of the registrant to stop the transfer at that point, because the registrants already authorize that change by obtaining the TAC. And so I understand that argument, and I believe I conveyed that to the BC. I think that the counter argument goes that yes, that's all true. But when it comes to something more than a notification and ability to stop it, it is belt and suspenders. But that is an appropriate precaution for moving something as important as a name, and secondarily, that the process of providing an ability to stop a transfer isn't so much more onerous than providing a notification. So for that incremental additional effort it provides significantly more comfort for the registrant in having that ability to stop it if something had somehow gone wrong with the TAC.
• Roger: I think that we're talking about a fairly good use case here that does happen. And we're talking about a change of registrar, followed by an actual transfer from one registrar to another. We had the discussions back in in Group 1A that there is that 5-day window that the registrars have to provide the AUTH code, or to deny the transfer for whatever reasons. That the registrars need to do their due diligence and make sure. And during that 5 days, that was a look back: what was the registrar prior to this, and did someone make a big change? Or did they just make an acceptable change? My email wasn't working, now I have new one, and that's been confirmed and verified. As people have mentioned that has to occur anyway.  We're talking about one scenario where change of registrant leads to a transfer and path does seem to be very secure. The registrar still had to do that due diligence upfront before providing that TAC.

2. Transfer complaint metrics with ICANN Contractual Compliance – see attached file

Discussion:

• Questions: 1) There are sections to differentiate – ticketing system was retired and moved to NSP; reflects data from two systems but can reflect the same detailed category after August 2020 is NSP.  2) No complaints of unauthorized transfers for hijacking?  We have data up to October 2023.  Grouped together from different complaint types.
• Question: Like to understand how many complaints were there of unauthorized transfers – thinking about what is the most useful context?
• Compliance: This data only shows complaints already addressed by the registrar.  Compliance can work with their team based on the WG’s needs.
• Question: Wonder if their could be related to ERRP/EBDP (renewal complaints as a subset) that is unauthorized change of registrant.
• This is just the raw data – can we get to the real reason and get rid of the noise to refine the numbers (Sarah Wyld volunteered to start the discussion).
• Compliance: We have a category of complaint relating to renewals.

ACTION ITEM: Re: Transfer complaint metrics -- Sarah Wyld to send an email with the WG’s request for more specific data. [COMPLETE]

3. Recap of revised COR Process – see attached slides

Discussion, Slide 4:

• When it comes to confirming that the name is eligible have no way of knowing if the compliance requirement is met.
• No timeframe requirement for steps 1 and 2 – interesting.  On step 2, bullet point only the new registrant needs to be told that they need to enter into an agreement.
• Questions: 1) is this a distillation of discussions – not agreement or proposals?  Would like to see a discussion of formal proposals.  Yes, that’s correct. We will get to the point where we can discuss recommendations. 2)  In theory immediately or contemporaneously with step #2 the process in step #3 could be completed? Yes, but we should discuss if their should be time delays.  Also may depend on the type of change.
• Will depend on the business model.
• If #1 has no timeframe, my question about CoR Appeal in #4 may be moot as the legitimacy of a CoR may be stronger with a good process in #1 which might remove a need for Appeal of CoR in #4.

Discussion, Slide 5:

• Think this is already being addressed with upcoming security laws.  Also for #4 other, could identify existing registry locks as options.
• Balance need to reclaim the name with how our systems work.  Much more available if stays within the same registrar – much harder if in a different registrar.
• With a notification is there a path the registrant can take?
• The WG will have settle on an option or a combination.
• Question: Is there a dispute mechanism in the current policy? Answer: Only option #1.

Discussion, Slide 7:

• This is where the true issues would come up.
• This is an operational minefield. Looks good on paper but problems in execution – avoid all options.
• Question: Are we talking about change of control?  Answer: Don’t think we’ve narrowed that down.
• For legitimate reasons, this does occur all the time.  Needs to be safeguards to catch when it’s not legitimate.
• Guardrails can be in place, but don’t have to be at the policy level.
• There SHOULD be some guard rails -- removal of guard rails should not be our statement.  Unless we define something here, it will be implemented in diverse ways that will be confusing to registrants where there is variance from Registrar-to-Registrar in how they implement this.  Should be some appeals mechanism.
• Opt out can only be before you make a change because of the lock.  The CoR needs more resolution.  Remember it’s part of a bigger approach.
• These items are very much open.  Come back with ideas.