Page History

Notes/ Action Items

ACTION ITEMS/HOMEWORK: WG members should review the CoR process in the attached slides, starting at slide 2, and consider the changes that the WG is suggesting in red to see how the process looks with the changes and if it’s a good solution.

Transfer Policy Review - Meeting #109

Proposed Agenda

28 November 2023

1. Welcome and Chair updates

• Four meetings remaining this year.
• Steinar’s ALAC, report on the CPWG poll/update on CoR:
  • Lively discussion.
  • More than 40% were not sure about removing CoR from Transfer Policy so continuing to educate.

Discussion:

• Question: When we're talking aboutremoving the change of registrant from the Transfer Policy, are we talking about removing it from the Transfer Policy and putting it somewhere else? Are we talking about removing the restrictions on change of registrant? Answer: I don't think we've gotten far enough in our discussions to go down either one of those paths. I think both of those paths are valid. And I think that you know, if it's removed out of policy, that's it's assumed and maybe even language put back in that the registrars are responsible for that.  But again, I'm not sure that we're far enough down the path to say either way.
• If we remove it from the inter-transfer policy, does it have to be a new PDP? That could be the alternative. This is an operational issue that can be handled directly by the registrar.
• The Transfer Policy was technically an Inter-Registrar Transfer Policy.  At the time it seemed like a an appropriate decision to drop the Inter-Registrar Transfer Policy and call it a Transfer Policy that really has two sections—inter-registrar transfers and CoR.  In reality it's really two separate policies embedded on the same policy page. Because when you read through the definitions and the process for a CoR, it has zero connective tissue to anything of the traditional Inter-Registrar Transfer Policy. There have been discussions about whether CoR can somehow be embedded into the Inter-Registrar Transfer Policy, and maybe it can, maybe it can't. Maybe it needs to be something standalone. What is somewhat new to us is twofold: One is, there is connective tissue back to the whois accuracy policy, and some of those changes that occur there also align or coincide with what is being labeled as a material change in the CoR policy. So we need to look out for that and also thank you to Theo for mentioning the emphasis being provided on the organization field from the draft version of the Registration Data Policy. This group may want to pay a little bit of attention to that. The second block is we need to constantly remind ourselves of the draft preliminary recommendations that the group has come up with the Inter-Registrar Transfer Policy and the entire foundation has shifted because we're introducing the TAC meaning that there are several steps that are going to occur before the TAC is actually revealed to the registered name holder. There is a difference of when CoR, assuming that it were to remain in its current state, could be invoked before the actual Inter-Registrar Transfer Policy. Put another way, if the registered name holder makes a material changed as defined in CoR today and doesn't have the intent of doing an inter-registrar transfer these material changes are still invoked, whether that includes notifications or locks, or whatever the group ultimately comes up with. I'm starting to wonder if it's even possible to salvage components of the CoR that would be embedded just in the Transfer Policy by itself when they're, in fact, kind of distinct components. And again, we do have some sort of connective tissue back to the whois accuracy specification as well as the organization name field that now has bigger emphasis.
• One of the original concerns for registrants was navigating what is, even to a lawyer, very complex and intricate, intricate document to this transfer policy that combines those two spheres is Barry mentioned. And so there was this interest in discussing, considering whether there should be a standalone portion just dealing with the change of registered provisions that a registered can more easily comprehend and navigate. But I think that, based upon my understanding of this group's discussions, particularly in the last call there seem to be some suggestions of getting rid of the restrictions on change, of registering altogether, and it seems to me that if that that suggestion were to have considerable support in the working group. Then that could impact the group's decision about whether there's an a need to have it as a standalone policy, or whether there's just nothing to say, because there's no restrictions, or maybe just has to do with the notice provisions. And so I think that rather than discuss the removal of the transfer locks in the sense of transferring it to a new standalone document. It might make sense to discuss the merits or lack of merit of changing or changing and or removing the transfer restrictions first.
• Sounds like group is leaning towards removing most of the CoR from the Transfer Policy and making it standalone or replacing it with notification requirements.
• Maybe the overarching security  model has changed with the TAC: Transfers are based on the usage/exchange of the TAC and contactability.  So whatever happens inside a registrar is up to the registrar – intra-registrar transfers.  Inter-registrar transfers are about the TAC and contactability.
• Seems we are moving to removing locks and only requiring notifications.
• This is about the appropriate level of restriction to protect a domain name in an inter-registrar transfer.  The interdependencies to maintain the integrity of the registration.
• There is a point where the inter-registrar transfer isn’t invoked until the TAC is requested – WG could consider extra protections up to that point.
• Think we could create a separate policy if that is a result of answering the charter questions.
• One of the ALAC arguments re: preventing domain name hijacking – we don’t have any evidence that the policy does this.  Want to have the update of registrant data as smooth and secure as possible.
• Doesn’t do anything to create a new policy.  Doesn’t have to be so complicated.
• It is more or less a definitional issue.
• Think a lot of this discussion relates to agenda item #2.

2. COR Process and Discussion – see attached slides.

Discussion:

• Question: Should we still use the phrase “security threats”? Answer: We should track any updates with terminology.
• Thoughts on change of control/ownership change?  That implies more than change of registrant.
• Locks make sense with inter-registrar transfer, but not sure it makes sense for change of registrant contact info.
• Are we still okay to eliminate the confirmation?
• Question: If we go to notifications only, and we rely on the lock that applies for a change of registrar, there's going to be 30 days where the name can't move, and that provides the window of opportunity for the registrant upon notification to do something about it. What can the registrant do about it? The registrant can't invoke the transfer dispute resolution policy. Some registers may be happy to look into it for them, but there's no procedure in place. The UDRP can't be used unless in cases of domain theft, unless the complaint happens, have a trademark in other circumstances. So my question really is, is that the notification seems like an elegant solution but what can a register and do upon notification if it's a bad transfer?  Answer: That notification should probably include something on if you disagree contacts -- there has to be that next step.
• The issue is, do we put language around that that registrars notification has to include whatever we're going to call it, you know, at least a path for the registrar to at least ask, and is that as simple as the notification has to include Register our contact information, whatever it is.
• If we, as a working group, proposed this, we would get all kinds of negative feedback on it. Just giving a phone number, an email address or a link to a complaints form really isn't going to do much for registrants that are left to their own devices. But if you go into notification there really needs to be another piece added to the puzzle to provide some kind of direct remedy. That that's an actual enforce standard for registrars.
• We're not talking about a transfer. It's just a notification like the data set which you supplied back then, during your registration, has changed and it's up to the registrants, the current domain name owner to confirm this was an update.
• It's one of those standard things that to me occurs across online environments today pretty regularly. It's definitely a model that we can take a look at.
• So what I'm hearing now is consideration of a dispute process for a registrant contact info updates, and we barely even have one for inter register transfers; the fast undo suggestion didn't go anywhere. So as we discussed I'm not certain that the Transfer Policy is the right place for this requirement, especially since there are related obligations in the RAA, like the Whois accuracy program, has validation and verification. That's the same data set being reviewed. So if we're just keeping the CoR and like lightening it up to be a notification process, maybe even with no lock process, that would be great. We're chartered to do it. Let's make a useful change.
• If I am a registrant and my domain name was changed and email and I was notified of that and it was unauthorized why is there no option to dispute it since it is essentially a transfer?
• I don't think it's wrong to say that if there's a problem with your service, then you contact your service provider.
• But what we have learned now is that this mechanism doesn't actually prevent domain name theft. What it does is it puts a burden on registrants, and that's why we are revisiting this.
• We do have a slide that talks about what needs to be in the notification, so we will get to more in depth discussion on that.
• I think one of the issues we're having today is this group is so efficient. We're talking about the things that we wanted to talk about. We're just talking about them in advance.
• And I think one of the issues here to kind of pull out is this two notifications? Is that still a valid notification process, or should there just be one notification? Where a request is probably followed directly by the completion. Or both a request when the change of registrar is being requested, and then when it's actually completed in the system. So think about that.

HOMEWORK: WG members should review the CoR process in the attached slides, starting at slide 2, and consider the changes that the WG is suggesting in red to see how the process looks with the changes and if it’s a good solution.

3. AOB – None.