Dear TPR WG members, Please find below the notes and action items from yesterday’s meeting. The next meeting will be on Tuesday, 07 March 2023 at 16:00 UTC. Please contact the GNSO Secretariat at gnso-secs@icann.org<mailto:gnso-secs@icann.org> ASAP if you cannot attend. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: Actions from Meeting on 21 February (ongoing): 1. Re: 07 March meeting -- If WG members cannot attend the 07 March meeting please let the Secretariat staff know at gnso-secs@icann.org<mailto:gnso-secs@icann.org> so we can decide if we have enough attendance to hold the meeting. 2. Re: The time frame (4 hours) for registrars to respond to communications via the TEAC channel – WG members should consider a provisional recommendation to change the time frame to 24 hours. Notes: Transfer Policy Review - Meeting #82 Proposed Agenda 28 February 2023 1. Roll Call & SOI updates 2. Welcome and Chair Updates * We have one more meeting planned before ICANN76, next week on Tuesday, 07 March. If there are a lot of apologies we may cancel, but right now it’s on the schedule. * We have two meetings at ICANN76 on Saturday and Sunday. * We did not receive any input on the questions for early input on the Phase 2 topics so those have been sent out to the SOs and ACs. * On the work plan, we have been keeping it up to date. At the beginning of each meeting we’re going to quickly touch on where we are in the work plan and the items highlighted in green at the top – the outstanding action items: * In particular, please let us know if you can’t attend the next meeting. * WG members also should think about the proposal mentioned last week about possibly changing the 4-hour response window for the transfer emergency action contact to 24 hours. * Also to note that we will be talking about the TEAK for approximately the next 6 meetings, which will put us to the end of April or mid-April. 3. Presentation of ICANN Compliance Metrics – TEAC and TDRP (https://mm.icann.org/pipermail/gnso-tpr/2023-February/000797.html) Holida Yanik, ICANN Compliance: To address the request for metrics from Contractual Compliance: * That was needed during the review of Phase 2 topics relating to TEAC, TDRP, and ICANN-approved bulk transfers. Compliance has prepared the metrics for transfer complaints that we received. * So I want to make a small disclaimer: Contractual Compliance migrated its operations to the Naming Services Portal at the end of August 2020 and the smart forms used after this migration started capturing additional reporting criteria like reporter type. For example, if it's law enforcement, agency or registrar, and subject matter categories for the complaints received and processed. * So, for example, these are whether the complaint specifically refers to non-response to transfer emergency action, TEAC contact, request, and that no complaint type had cases with this complaint category provided in red, and here that means that no other complaints like whether it's renewal, abuse, or anything else. * We’ve reported with this TEAC category selected, so the subject matter category is initially selected by the complainant. * When the complaint is filed with Compliance, and when necessary Compliance amends it; * When the selected category does not properly reflect the issue that the complainant is reporting about; * So additionally invalid complaints like complaints that refer to ccTLD domain names, or to parties over whom ICANN does not have any contractual authority, are closed without initiating a case with the registrar. * So from 01 September 2020 to 31 December 2022 compliance received altogether 162 complaints for which complainant selected the TEAC category. * However, only 5 cases were validated and confirmed to refer to TEAC obligations that are described in the transfer policy, and finally addressed with the relevant registrar. * So, as a further aside, in these TEAC complaints the reported issue was non-response to requests to TEAC contact within the 4-hour time period. * And in all these addressed cases we saw that reported registrants were located in different time zones and all cases have been closed after the reported registrars took corrective actions like allocating special staff that would monitor TEAC contact emails for 24 hours and 7 days a week, and be able to investigate and address urgent transfer matters. * And another interesting point to mention is that in the past Compliance also received feedback from reported gaining registrars concerning the language in which the complaining registrar sent their requests to TEAC. * So the policy states that the goal of the TEAC is to quickly establish a real-time conversation between registrars in a language that both parties can understand in an emergency. * So, but for the receiving registrar, it may take more than 4 hours to translate, understand the matter, and respond if the request was not provided in a language that they understand. * So, I will move to TDRP related complaints. * Compliance received 141 cases where complaint and selected categories, indicating transfer, dispute resolution, policy matters. For example, into registrar transfers or change of registrant requests denied due to ongoing TDRPs. However, no valid case was initiated with the registrar referring to TDRP-related obligations. * Finally, with regard to the request for metrics for compliance metrics relating to ICANN-approved bulk transfers, I would like to clarify that ICANN Contractual Compliance does not track complaints that relate to ICANN-approved bulk transfers, but transfers may occur as a result of complaints received by ICANN Contractual Compliance when such complaints result in termination of the registrar's accreditation and after a bulk transfer has taken place. Compliance sometimes receives complaints alleging unauthorized transfer, because the registrant was not aware of the back transfer, and was either confused by the change, or did not agree to the new registrar as renewal fees or any other term. And in these cases compliance provides the relevant education to the reporter and closes the case because the gaining registrar did not violate any obligations. Discussion: * Question: TDRP I always understood it is a mechanism to dispute transfers. If there was a transfer out that wasn't authorized. So how are the UDRP and the URS tied into the TDRP process? * Answer (Holida, ICANN Compliance): That's a good question. So with within the transfer complaint category we receive complaints from the registrants that can complain about the transfer requests that were denied by their registrar due to UDRP, URS, or TDRP proceedings. However, we have a separate UDRP complaint, type, category, in which the UDRP complainants complain to Compliance regarding non-implementation of the UDRP decision or the domain name was not locked upon the provision of verification and lock requests by the provider. Those are different complaint, type, categories, and the main difference is who is complaining. Is it the current registrant, or the UDRP, or URS, or TDRP complainant? So this is why, in the transfer category. We have bundled all these UDRP, URS, and TDRP proceedings for the complaining registrants to complain about the he registrar of record that is denying COR transfer due to these pending proceedings. * Question re: the TEAC non-response: How many registrars were non-responsive to the TEAC request out of those numbers? Also do we know from the non-responses if the registrar then remediated the issue with ICANN Compliance? * Answer: (Holida, ICANN Compliance): So these 5 validated complaints that we received and addressed since September 2020 does not mean that they were 5 different registrations. They were multiple complaints and validated, and addressed with the same registrar and at the same time we had some cases that the reporting registrar had issue with the same gaining registrar not responding about multiple domain names, and the TEAC request was sent to at the same time but separately. And so the number of complaints does not mean that they were this number of non-compliant registrations. And as for the reason the receiving registrars brought us this as a reason for non-response, for quite different, most of them for small registrars. Maybe they were a couple of persons working as a registrar, and they were not able to monitor the emails or monitor the TEAC contact for 24 hours, and after the case was addressed to them, they said that we took corrective action, and we assigned an additional personnel or hired additional staff specifically for this purposes that would be monitoring the TEAC emails for 24 hours. However, we closed all those cases with the relevant resource code that the registrar took corrective action. However, after these cases were addressed with them, we didn't have any reoccurring instances, or any repeated complaints about those registrants. And at this stage, where we see the evidence of the responses and the copies of communication. There is nothing to do for compliance other than closing. * Re: low numbers there are probably several reasons but the biggest one is that most of the time registrars work together to resolve the issues and a TDRP doesn’t get filed. * Maybe we should look at the fees associated with the TDRP and whether they are too high. 4. Continued Discussion of Transfer Emergency Action Contact (TEAC) (working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1ejqMnKrN5Pnqy...>) Poll: What is an appropriate deadline for initial response by the TEAC? 1. 4 hours (status quo) 2. 24 hours 3. Other 4. Not sure/no answer Discussion: * I don't feel that I yet have enough information to make a choice here like are we deciding that the TEAC is the only point of contact that will exist to all, do all transfer problems go through this point of contract? Or is there like some kind of tiered system with low-level problems and big-level problems? Because maybe only some transfer issues need a 4-hour response period. * That's kind of the point of the polls, I think, is to try to tease those out. Maybe 4 hours is still appropriate for some level. If there's a tier or a or we think about it. Is there a priority, or is there an urgency to some of them that may dictate? You know a a different set of policy requirements than others * We did get a lot of discussion last week. The thought was that 4 hours was pretty extreme. But it sounds like there should be multiple timeframes there that you're looking at -- if it's a direct customer impact, you know that's bigger -- so maybe there's multiple tiers that we can look at. * There’s a whole level of things that are going on before it even gets to the TEAC. Results: * This is what we heard last week. It's still an unknown thing. But there, there is a thought that that the 4 hours is too restrictive, especially on the outcome of not responding within 4 hours to transfer automatically. You can revert back it doesn't have to, but can revert back. We've got a pretty big granularity here -- 4 to 24 hours -- is there something in between that makes sense? Maybe it’s 12 hours or maybe 24 hours does make sense. Should there be a cutoff timeframe for initial contact to the TEAC following the alleged unauthorized loss of a domain? 1. Yes 2. No 3. No, but add guidance 4. Not sure/no answer Discussion: - Our second question -- should there be a cut off timeline timeframe for the initial contact to the TEAC following the alleged, unauthorized loss of domain? So this this question came up last week as well. - So are we expecting that the TEAC is the only point of contact to raise a dispute with the transfer, or is the TEAC for emergency disputes and other transfer disputes go elsewhere because I feel like that's going to change the answer. - Understanding is that the TEAC is for emergency processes only. Results: * A cut off seems logical, and last week there was discussion around whether the cut off is the same as the transfer prohibited window of 30 days. If it’s after 30 days maybe the TEAC shouldn’t be used. * Question: If there is a cut-off point, what does that mean with respect to policy or operations? * Answer: if there was a transfer on day 35 you wouldn’t be required to respond within that 4 or 24-hour time period. You would follow other processes in place. * Suggest that there could be a standard type of problem – regular and emergency. We can define what is an emergency and who is allowed to say that a certain situation is an emergency, then we could say the registrar could downgrade it to non-emergency under specific circumstances. So maybe with this cut-off time frame they're allowed the domain owners to say, “this is an emergency” even though it's been 40 days since the transfer happened, and normally we should submit within 30. * That question is definitely worth pursuing. Should there be a required timeframe for resolution of an issue raised through the TEAC? 1. Yes 2. No 3. No, but add guidance 4. Not sure/no answer Discussion: * Okay, should there be a required timeframe for resolution of an issue raised through TEAC. Should there be a timeframe for a TEAC or for any dispute? Or one or the other? Results: * Maybe that falls into the unsure ideas. So that's something we can continue to work through. * You can have a scenario. There is no resolution, or whatever reason there is and then it becomes a dispute. So you have another piece of the policy that addresses the dispute part. * Maybe not a lot of different processes but a stronger timeline to get those processes completed. * So if somebody contacts the emergency contact and says, there's a problem. And the decision is okay you're going to work with our transfer dispute team, that's not a resolution, that's passing the problem on to the next team that needs to address it. But if, instead, the emergency contact determines that they cannot resolve the issue and says you're going to need to contact this third party arbitration body that will review the transfer and its side, that's a resolution because you're moving to a completely different process outside of the TEAC and outside of the standard process. * It sounds like we're saying, yes, if it's urgent, then there is a different timeline -- an escalated timeline. Should the WG make recommendations about the TEAC method of contact? 1. No, status quo works 2. Initial contact must be by email, additional channels optional 3. All substantive communications must be by email 4. All substantive communications must be via centralized system 5. Other 6. Not sure/no answer Discussion: - Do we specifically say a TEAC emergency contact has to be a phone number? Can it be anything as long as that mechanism is responding within whatever timeline we're giving it 4 houra or 24 hours? Should those be documented somewhere? And how is that documented? - If it was a centralized system and you were responsible for being notified, you could theoretically select send me a text or send me an email. You could even have the thing phone you. But operationally and being effective, a centralized system would carry a ton of benefits, including the benefit of the documentation. - There was back in the day a centralized system for something like that, just because email is imperfect. - It's a real-time communication is what it says in in the current policy. Results: - What we're seeing the in the discussion we've had is that it kind of leans toward the bottom of this discussion about not sure. - If you're talking about a central system that TAC update becomes less of an issue. The update, you know, when the TAC is updated, sharing that out is less of an important thing if it's a centralized system that's already handling everything. - When we are discussing such a system there will be some hurdles in convincing certain registers in moving that direction, and spend all that money. - The status quo received the smallest number of responses, and so I think that we need to look at some kind of change to this language or functionality. Are any changes needed to enable Rys to validate transfer undo requests when a TEAC allegedly fails to respond in 4 hours? 1. Yes 2. No 3. Other 4. Not sure/no answer Discussion: * There any changes needed to enable registries to validate transfer undo requests when it allegedly fails to respond in 4 hours. * So I think that that's where this question comes up is if that 4 hours is gone and the registrar is claiming they didn't respond, how does the registry consume that information and make sure that it's correct? * I think there's a couple of possible ways to go here. So if the registry is required to validate that the dispute is correct, or that the transfer should be reversed, they need to know not only that the dispute was raised, but also that there was no response within the 4-hour timeframe, and proving that something has not happened is, I think, difficult, unless that whole process of raising and responding to the issue happens through a centralized system. * So the only way we can properly expect a registry to validate that it is a dispute that's been raised and not responded to would be, if it's going through a central system that I don't think we should build. * And then, on the other hand, the other option would be that the registry doesn't have a way to validate it. And so then it's not fair to expect them to do so. So maybe a path to consider would be that if a dispute is sent to the registry, as this was a TEAC it was not responded within the timeframe. You got to reverse it. Maybe the registry is just required to reverse the transfer, and they don't get to make a decision. But then also they're not liable for it. They don't get in trouble if it turns out to have been the wrong decision. * So maybe we have to think about who's responsible and who's liable, and who has access to the information before we can come up with this, and then ultimately also, I would like to hear if the registries have a preference. * It was this very interesting scenario where a registrar in theory could wait weeks before raising at a communication with our registrar, and then if they don't respond within those 4 hours, then the transfer can be 100% reversed. There's no discretion to a registry there to kind of make that determination. There's no ability for other facts or scenarios to be interpreted in there, whether it's reasonable to do or reversal in that, so I think there needs to be a little bit more flexibility for a registry and others to determine whether or not it's a warranted in every scenario. * So if the registries are in a position where there are fewer decisions that is preferable, because right now the registry is in a spot where it's having to make a decision and making that decision typically on very sketchy or suspect information. * So in theory, a registrar who receives a TAC request and responds at 3 h 59 min and says, okay, we're on this and then takes 3 months to resolve the transfer. They're compliant, but a registrar who responds at 4 h 1 min and says, okay, we we're okay. We'll reverse the transfer. That's technically non-compliant and so I think there's a there's a big discrepancy between those two because I think one of them is a much more desirable outcome. The responsive registrar that's dealing with a reversing the transfer although they missed an arbitrary deadline. Versus the other registrar who's just not collaborative, and draws everything out over a period of months. Results: * Seems like there's strong support for changes. The majority see some changes necessary. Should Rrs be required to track and report on TEAC communications to enable future review of the mechanism? 1. Yes 2. No 3. Other 4. Not sure/no answer Discussion: * Should registrar be required to track and report on TEAC communications to enable future review of mechanism. * So this isn't just documented, this is a concept of trying to create metrics, so that it can be reviewed in an ongoing way. * And again, you know we're talking about the transfer specifically here. But should there be metrics for the dispute process in in total? Results: - So good support on requiring something to be tracked, and so this is the point of this question. - We'll get that clarity as we work through that, and then see what's being tracked, and if it is useful or not. 5. AOB