# GNSO: DNS Abuse Mitigation PDP1 Working Session (1 of 4) Session ID: icann87-sched-2WjfB Start: 2026-10-17T10:30:00+08:00 End: 2026-10-17T12:00:00+08:00 Location: Nusantara 1 (GNSO) Access: public Official tracks: GNSO (Generic Names Supporting Organization) Programme state: scheduled AI-generated summary The first DNS Abuse Mitigation PDP1 session reviewed public comments on Recommendations 1 and 2. Debate focused on the compromised-domain exclusion, whose knowledge or consent matters when privacy/proxy services are involved, and affiliated-registrar ADCs. The chair directed removal of legitimate or benign from proposed wording; other definition and common-control questions went back to leadership and staff. Secondary-market acquisition and leasing raised further concerns. This was drafting review, not final policy approval. TL;DR - The chair framed public-comment review as substantive clarification within the charter, with a target of final reading in November and Council submission in December. - Legitimate or benign was removed from the proposed compromised-domain definition, but the person whose knowledge or consent should count remained unsettled. - Participants disputed checks across commonly controlled registrars; reasonably accessible information emerged as a possible bridge without an adopted cross-registrar requirement. - Malicious acquisition and leasing concerns were referred back to leadership; the session also heard a warning against using majority comment support to dismiss minority concerns. Main discussion - The chair reported 42 submissions, 85% supportive inputs, about 3% seeking significant changes and 12% other or no position, with no request to delete a recommendation. Farzaneh later cautioned that majority support does not prove the group is on the right track and minority views may be valid. - The proposed compromised-domain definition used knowledge or consent of the registered name holder. Mark challenged legitimate or benign as unnecessary; the chair also worried those words could invite content judgments under jurisdictional pressure. Michaela wanted a definition but was not tied to those exact words. - Mark and Gabriel warned that a privacy/proxy service might be the registered name holder without knowing the customer’s use, undermining the exclusion. Reg urged leaving established RNH definitions to the appropriate PDPs; Martina favored existing definitions and potentially an advisory with scenarios. - The chair floated the RAA account-holder definition. Mark initially welcomed it, but Reg and Volker explained that the payer or reseller need not control the domain’s use. Gabriel proposed defining compromise through use by an unauthorized party, with leadership to bring back a proposal. - NCSG pressed for a clear exclusion or stronger safeguards so innocent registrants are not swept into ADC profiling. Registry and registrar speakers pointed to existing RAA obligations, contractual compliance and collateral-damage considerations, warning against inconsistent ADC-specific definitions. - Leadership proposed clarifying that actionable evidence can come from registrar analysis or external sources, and that intermittent or recurring abuse must have sufficient information to support a reasonable determination. Volker objected that this governed DNS abuse beyond this PDP; the chair said actionable evidence had already been discussed and moved on. - The Recommendation 2 grammatical and consistency update referred to a reasonable investigation and Recommendations 1 and 3–8. The chair saw no hands when asking about that tweak; a separate affiliated-registrar discussion then followed. - Gabriel raised a public-comment proposal for affiliated-registrar ADCs. Leadership considered inter-registrar checks outside the charter; Reg questioned feasibility and Volker described separate systems after acquisitions. Mark suggested requesting checks across related registrars, and Rod warned against ignoring other accreditations already visible on the same system. - Brian distinguished a single operation using many accreditation credentials from related businesses with separate systems. He suggested the reasonably accessible evidence standard could bridge those cases; the chair saw promise, while Mark asked how compliance would know the actual system arrangement. - Gabriel said maliciously registered misses later acquisition of existing domains; Jothan raised leasing and innocent lessors or lessees. Chris warned against over-definition, Michaela suggested an advisory scenario, and Mark urged resolving hard policy questions rather than routinely deferring them to compliance. Staff recalled that the group had chosen the compromised-domain exclusion instead of defining malicious registration. Agreements - The chair noted that IPC and NCSG both wanted a compromised-domain definition; this did not settle the wording or establish agreement from all participants. Disagreements - Participants differed over whose knowledge or consent matters: Mark sought the underlying user rather than a proxy provider, while Reg emphasized existing RNH terminology and rejected account holder as the relevant substitute. - Common-control registrar checks drew support as a way to avoid loopholes, but leadership cited charter scope and registrar speakers raised feasibility and burden concerns. - Mark urged resolving interpretive gaps in policy rather than routinely handing them to compliance; Michaela and Chris saw an advisory or implementation route, and Brian considered malicious-versus-compromised a broader contract issue. Outcomes - The chair directed deleting legitimate or benign from the proposed definition after asking for objections. - Leadership and staff were to return with a compromised-domain proposal and consider the affiliated-registrar and acquisition/leasing issues; no final replacement definition or cross-registrar requirement was settled in this session. Agreed actions - Leadership and staff would return with a proposal and a next redline after ICANN87. - Leadership would take back the acquisition and leasing concerns for further consideration. Possible follow-ups (inferred) - Possible follow-up: test the unauthorized-party formulation against privacy/proxy and leasing scenarios before settling the compromised-domain wording. - Possible follow-up: clarify how reasonably accessible evidence applies to affiliated registrars using shared versus separate systems, including what compliance can verify. - Possible follow-up: consider scenario-based advisory guidance without assuming the group agreed to defer every interpretive question to compliance. Open questions - What wording identifies the relevant party’s knowledge or consent without creating a privacy/proxy loophole or confusing domain users with payers and resellers? - How should the ADC framework address information across affiliated accreditations while respecting charter scope, operational differences and the reasonably accessible standard? - How should policy language handle secondary-market acquisitions and domain leasing, and which issues belong in this PDP versus broader contractual guidance? Recording and context ## Transcript [0:03] ICANN - MTS - A/V: Hello and welcome to the DNS Abuse Mitigation PDP-1 Working Group Session 1 of 4. Please note that this session is being recorded and is governed by the ICANN Expected Standards of Behavior, the ICANN Community Anti-Harassment Policy, and the ICANN Community Participant Code of Conduct. [0:20] ICANN - MTS - A/V: concerning statements of interest. Please observe the following guidelines to participate in the session, and I will also post them in chat for your reference. [0:29] ICANN - MTS - A/V: Only questions, please log into Zoom, as we'll be using that to ask questions and raise your hand. [0:37] ICANN - MTS - A/V: If you wish to speak, Please wait for the chair. [0:42] ICANN - MTS - A/V: to call unto your name. When speaking, please state your name for the record and speak clearly and at a moderate pace. With that, I'll hand the floor over to Paul McGrady. Please begin. [0:52] ICANN - MTS - A/V: Thank you, Terry. [0:54] ICANN - MTS - A/V: Welcome, everyone. This is session one of four. We are having two sessions today, one session tomorrow, and then a fourth session on Thursday. The break in the sessions is to give you time to go back to the groups that you are representing. [1:12] ICANN - MTS - A/V: And to socialize what we've done. [1:15] ICANN - MTS - A/V: And then we will finish up, with two last recommendations on Thursday. [1:21] ICANN - MTS - A/V: The sessions are broken into a recommendation each. [1:25] ICANN - MTS - A/V: With each recommendation, we'll also be looking at questions raised in the public comment regarding implementation guidance. [1:32] ICANN - MTS - A/V: So, that is how we will do it. [1:36] ICANN - MTS - A/V: Want to, just spend a few minutes, doing a generalized update for everyone in the room. [1:42] ICANN - MTS - A/V: And we'll go on to the next slide for that. [1:46] ICANN - MTS - A/V: So today, and tomorrow and Thursday are about public comments. [1:52] ICANN - MTS - A/V: We, put out the draft report for public comments, and the point of that is to test [1:59] ICANN - MTS - A/V: the initial report to see where it can be clarified, improved, or documented more clearly. We will then move on to a final report. [2:08] ICANN - MTS - A/V: So, we… today and tomorrow and Thursday, we're going to review comments in a structured way. We're going to focus on substance rather than preferred wording. By that, we mean [2:20] ICANN - MTS - A/V: as we talk through a concept, if we land on alternate language than what was in the initial report, staff will be capturing those. We're not going to get bogged down in placing semicolons and [2:33] ICANN - MTS - A/V: doing a lot of wordsmithing, so… but, staff will be grabbing that. [2:39] ICANN - MTS - A/V: We are going to be identifying sensible changes that are also still within the Charter. We're not going to expand the universe at the last minute and consider things that are outside of the Charter. And through this process, document how public comment was considered. That's what we're doing. [2:54] ICANN - MTS - A/V: So, how far have we come? We had 9 charter questions, 26 working group meetings, 5 reads of the initial report, 42 public comments, and we've had 3 community webinars, so the review is now focused [3:10] ICANN - MTS - A/V: on whether or not public comment identifies a reason to adjust the recommendations, strengthen rationale, or capture other considerations. It is not meant to be a relitigation of issues that have been talked about [3:23] ICANN - MTS - A/V: significantly, and, but don't raise new, new concepts. So, right now, we're in the public comment review. Our little running man here, we will update the final report and do a final read, hopefully in November. [3:39] ICANN - MTS - A/V: At the end of November and early December, if we are on track, we will have a consensus call on the final report, and we will submit this final report [3:48] ICANN - MTS - A/V: to Council in December for their, consideration. So that is the… [3:53] ICANN - MTS - A/V: That is the goal. Hopefully, we make that goal. [3:56] ICANN - MTS - A/V: So… We will, after this and after Bali 87, we will continue to meet, on Mondays. [4:06] ICANN - MTS - A/V: At the usual time, for the usual length of time, until the final report is complete. I think that's probably two more calls after Bali, but we'll see how it goes. [4:16] ICANN - MTS - A/V: All right, let's dive into the public comment review. [4:20] ICANN - MTS - A/V: And, I'll just. [4:24] ICANN - MTS - A/V: hit these fairly quick, or are you gonna hit these? I can hit these? Okay. So, here's the snapshot of the outcome. We had 42 submissions. I think that's pretty robust for a niche policy. [4:34] ICANN - MTS - A/V: And, you know, this is, nearly focused, nearly chartered, niche policy directed to do [4:41] ICANN - MTS - A/V: one thing incredibly well, as opposed to, like, something like the SubPro PDP, which was not a niche policy. So 42 submissions, 85% of the inputs, were supportive of the initial report. That was good to see. [4:57] ICANN - MTS - A/V: About 3% requested significant changes. 12% were like other comments or no position taken. [5:06] ICANN - MTS - A/V: And, we had, 8 preliminary recommendations that were, affected by the Public Comment 5 implementation guidance. [5:17] ICANN - MTS - A/V: were hit. So overall broad support for the ADC framework. [5:21] ICANN - MTS - A/V: With the review focusing on specific wording, implementation considerations, and targeted concerns, so it was not a throw the baby and the bathwater out, it was, let's adjust the baby. [5:31] ICANN - MTS - A/V: So that's good. And we did not receive any comments saying that any recommendations should be deleted. So, sounds like we landed on the right things, and so, that is… that's good. Here's a giant chart. I encourage you to read this. I'm not going to read it. The working group's had it for several days, but I think it's. [5:51] ICANN - MTS - A/V: It's good to see the level of support, support with changes. [5:56] ICANN - MTS - A/V: There's a handful of proposed significant changes and several others, as we've talked about. So you can see those down the recs. [6:04] ICANN - MTS - A/V: And down the implementation guidance that were affected, so… Good chart. [6:09] ICANN - MTS - A/V: I like charts. So… [6:12] ICANN - MTS - A/V: I think with this one, I might turn this to Feo. Is this your… this is the… this is, the high-level outcome of public comment? [6:24] ICANN - MTS - A/V: Hi, everyone. This Feodora from ICANN Org. Just similar to what Paul just introduced. [6:31] ICANN - MTS - A/V: This is on a high level in words that many comments support the overall ADC framework. [6:36] ICANN - MTS - A/V: but propose, alternative wording or greater specificity. These often, though, reflect, already discussed issues within the working group, rather than necessarily new evidence or perspective or something that the working group has not considered before. [6:52] ICANN - MTS - A/V: However, nonetheless, as discussed with Paul, there are still opportunities to clarify and strengthen the current language. [7:00] ICANN - MTS - A/V: As noted, some of the comments provide substantive input on drafting ambiguities, gaps, or potential unintended consequences. [7:09] ICANN - MTS - A/V: And those will be the ones that will be discussed during these sessions. [7:15] ICANN - MTS - A/V: Another point to consider is that a smaller set of comments raises more More, let's say, substantive concerns. [7:24] ICANN - MTS - A/V: are things that the working group should consider when it comes to potential enforceability issues, or warrant some further adjustment. And we will see that throughout the recommendations when we go through them. And back to Paul. Thank you. So… [7:39] ICANN - MTS - A/V: Let's go back one screen, if we can. So, on the gold column, several of these comments were from ICANN Org itself, and specifically [7:49] ICANN - MTS - A/V: From, you know, with the idea of contractual compliance and those kinds of things. So we have, a, willing member of the ICANN staff here to answer today's questions. If we have them, feel free to direct them [8:05] ICANN - MTS - A/V: You know, and ICANN Org will respond to them. But again, at the end of the day, we wanted a policy that's enforceable. Without enforceability, we didn't really do anything. And so, you'll see those, and they're marked as we go through them, the ones that came from Org. [8:21] ICANN - MTS - A/V: Or if they're not, they can be highlighted, or you guys can ask questions about them, so terrific. Let's move on to the next screen. [8:27] ICANN - MTS - A/V: So, we have a focused review. In other words, like I said in the emails I sent out, we are not going to read each comment. [8:36] ICANN - MTS - A/V: Comment by comment, everybody can read. [8:39] ICANN - MTS - A/V: And everybody, I'm sure, did their homework. What we put together today is essentially a, our… the leadership's own, focused review. We focused in on those that raise new information. [8:55] ICANN - MTS - A/V: New implementation considerations, unintended consequences, drafting ambiguities, or issues that may have been overlooked. We did not focus in on things that had already been discussed. [9:08] ICANN - MTS - A/V: over and over again, so you will not see the relitigation opportunities in here. We are going to focus the meeting time on those substantive or clarifying issues, rather than reopening matters that have already been extensively discussed. [9:22] ICANN - MTS - A/V: And settled, during the process. [9:26] ICANN - MTS - A/V: And then lastly, in terms of paths forward. [9:32] ICANN - MTS - A/V: We… we've put in proposed targeted wording, for the, for the implementation guidance and rationale adjustments for your consideration. These are straw… [9:45] ICANN - MTS - A/V: people. [9:47] ICANN - MTS - A/V: Right? These are not… This is not something that, if the working group [9:54] ICANN - MTS - A/V: You know, if y'all don't like them. [9:56] ICANN - MTS - A/V: speak up, right? So this is not a predetermined thing. What we're trying to do is to synthesize those new items, those new ideas, the fixes to unintended consequences, and put them out for us to discuss, rather than [10:09] ICANN - MTS - A/V: all of us weaving together directly from the public comments. So, but again, these are not predetermined, and I expect pushback on them, because I know y'all, okay? [10:19] ICANN - MTS - A/V: We're gonna go to the next screen. So, review of public comments, Rec 1 and Implementation Guidance 1.1. Staff's gonna walk us through these. [10:30] ICANN - MTS - A/V: Thank you, Paul. This is Feodora from ICANN Org again. [10:34] ICANN - MTS - A/V: So for each recommendation, we have, provided a table as introduction of the overall… overarching comments that would deserve closer look from the working group, based on discussion with Paul. Here you see for recommendation 1, the most substantive. [10:50] ICANN - MTS - A/V: comments received were on the compromised domain definition, that it would warrant further clarification, especially because it could, as it is now, create inconsistencies in implementation, or cause. [11:04] ICANN - MTS - A/V: Yeah, problems when… when operating this definition or exclusion. So there will be some path forward proposed on this. [11:14] ICANN - MTS - A/V: Furthermore, there was also many comments considering actionable evidence and clarify [11:19] ICANN - MTS - A/V: That sources for actionable evidence might come from various sources. And the group already noted that this would be the intent, but it could be further clarified based on the comments. This is not substantive, but would benefit from clarification. [11:35] ICANN - MTS - A/V: As well as the recurring and intermittent abuse sentence, where, the working group decided to note that reports trying to evidence or show these [11:46] ICANN - MTS - A/V: type of Dns abuse should clarify [11:50] ICANN - MTS - A/V: should clarify that in the report or provide according substance. However, commenters noted that this might create an undue burden on the reporters. That was not the working group intent, as we remember from the deliberation, so that could also benefit from a small [12:06] ICANN - MTS - A/V: clarification. On the next slide, you see that, as noted, the most substantive concern is on the compromised domain definition, so that's why we developed this, to note that the current wording distinguishes domains registered for the purpose of conducting DNS abuse. [12:25] ICANN - MTS - A/V: However. [12:27] ICANN - MTS - A/V: The comments note that discussing primary use or purpose of use that was also A long discussion within the [12:35] ICANN - MTS - A/V: PDP, that the sole use or purpose of something is difficult to determine. However, public comment noted there might be some changes that can be considered. [12:45] ICANN - MTS - A/V: And this is what we are trying to do today. The rationale of why this change would make sense is that it would address the specific ambiguity, and support consistent application, but would not change the trigger, just provide, better consistency along the way. Back to Paul. [13:03] ICANN - MTS - A/V: Thank you. [13:04] ICANN - MTS - A/V: So, this is where the fun starts, right? [13:08] ICANN - MTS - A/V: So the, most of the substantive comments on, Implementation Guidance 1.1, as Fayo said, had to do with the definition of compromised domain names. Potential language to replace the current compromised domain definition is below. [13:26] ICANN - MTS - A/V: I'm just gonna read it, and then I'm gonna open the floor for reactions. A compromised domain means a legitimate or benign domain name is used as a vector for DNS abuse without the knowledge or consent of the registered name holder. [13:42] ICANN - MTS - A/V: The registrar shall reasonably determine based on the information accessible to it and the circumstances applicable to the case. [13:51] ICANN - MTS - A/V: If the registered name is a compromised domain. [13:55] ICANN - MTS - A/V: Oh, is it compromised domain? I sort of up-talked at the end. Or an uncompromised domain. Okay. For the avoidance of doubt, excluding a compromised domain from the ADC trigger does not alter or limit any existing DNS abuse obligations applicable to that domain. [14:12] ICANN - MTS - A/V: All right. [14:13] ICANN - MTS - A/V: So, I will take a cue on this language. Mark Track… oh, one thing. One thing that will be very helpful, and I meant to put… I meant to say this at the beginning, so I apologize, Mark. [14:24] ICANN - MTS - A/V: When we speak around the table, because not everybody in the room knows who we represent, it will be extremely helpful to say who that is. So, for example, Mark Trachtenberg IPC, okay? And so if we can all follow that, for those in the room that [14:39] ICANN - MTS - A/V: maybe don't know everybody. We all know, but everybody else may not know, so appreciate that. Mark, your turn. [14:45] ICANN - MTS - A/V: Do I still have to do it since you just did it for me? No. Okay, for the record, thank you. [14:51] ICANN - MTS - A/V: So two, I think, questions or issues here. One, I think. [14:55] ICANN - MTS - A/V: Like, what does legitimate or benign mean? That's not necessary. I think you could just say a domain name. [15:00] ICANN - MTS - A/V: you know, as a vector for DNS abuse without the knowledge or consent of the… and here's the second issue, registered name holder, I think is problematic, because in a lot of cases, the registered name holder could be the privacy service or proxy service. [15:12] ICANN - MTS - A/V: And so, based on the strict reading of this, you know, those proxy services would never have any knowledge of what was… what it was being used for. And this goes back to some of the comments that were made, like, during the… [15:24] ICANN - MTS - A/V: initial discussions, which is, like, the distinction between the registered name holder and, like, the customer or beneficial owner or user of the domain name, which is relevant because, like, 99% of domains are registered through privacy or proxy services. So, this has to be adjusted to… [15:39] ICANN - MTS - A/V: To take into account that practical reality to address the knowledge of the ultimate [15:46] ICANN - MTS - A/V: you know, end user or customer, and, you know, we kind of, I think. [15:49] ICANN - MTS - A/V: we're never able to come to agreement on what word or definition should be used for that, but I think this concept is critical here. [15:56] ICANN - MTS - A/V: Thank you, Mark. [15:58] ICANN - MTS - A/V: Michaela [16:01] ICANN - MTS - A/V: Thank you, Michaela Shapiro, Non-Commercial Stakeholder Group. This is partly a clarifying question, but I think following up on Mark's comment, my concern with if we… if we have concerns around the definition of using the terms legitimate or benign, that would also require updating the glossary, so I'm a little confused as to [16:21] ICANN - MTS - A/V: you know, how that… whether you're suggesting changing the definition here, or just… whether it's just redundancy? Feel free to answer, and then maybe I can ask my second question after. Mark, go ahead. [16:33] ICANN - MTS - A/V: I just think it's kind of redundant or not necessary, doesn't add anything here to try and say, is it legitimate or benign? It's not really relevant. The question is, was… did the abuse occur without the knowledge of the [16:43] ICANN - MTS - A/V: beneficial owner, or whatever we want to say for it. That, I think, is a critical question. We don't need to have this additional look into legitimate or benign that's not relevant. The question is, is it abusive or not? [16:53] ICANN - MTS - A/V: And if it is abusive, did the abuse occur with or without the knowledge of the beneficial owner? [17:01] ICANN - MTS - A/V: That's, I think, an easier binary test. [17:04] ICANN - MTS - A/V: And we should try to simplify and avoid. [17:07] ICANN - MTS - A/V: Ambiguity or additional tests that aren't necessary. [17:10] ICANN - MTS - A/V: Thanks, Mark. Michaela, back to you. Yeah, thanks. But again, I think the… I think it is relevant because it's part of the definition, so I'm a little confused, again, because that's the definite… like, the legitimate or benign terminology is what we used in the glossary to define the term. [17:24] ICANN - MTS - A/V: But maybe that's just my own confusion, but I don't see it as being an additional test. It's just part of the… it's just part of the definition of compromise versus not. [17:34] ICANN - MTS - A/V: But that being said, I don't want to harp on that point too much, but [17:39] ICANN - MTS - A/V: I… I think I'm just also confused as to… is… so, if I understood correctly, this would be going just to the implementation guidance, but I… [17:48] ICANN - MTS - A/V: I wonder if it would be more helpful to have the portion… this portion in the recommendation itself, but I'm just… I wanted to put that out to the group, if that's something that others would be interested in. Thanks. [18:01] ICANN - MTS - A/V: Thanks, Michaela. Next up is Ching. [18:05] ICANN - MTS - A/V: Thank you, Paul. Ching from the BC. So, I'd like to also make this clarifying question. [18:10] ICANN - MTS - A/V: About whether a compromised domain, but it's still a benign domain, means that it's not part of the abused sets. So, if it's not part of the abused sets, you know, we don't really… or the registrar doesn't really have to do anything with it, even if it's being compromised. [18:28] ICANN - MTS - A/V: Right? Because it's not part of the abuse, the… I mean, domain is benign, it's not really being used for, you know, you know, the abusive action, so… [18:38] ICANN - MTS - A/V: That's something that we also need to come… consider, and also to clarify. [18:43] ICANN - MTS - A/V: Thanks. [18:45] ICANN - MTS - A/V: Thanks, Ching. [18:46] ICANN - MTS - A/V: Mark? [18:49] ICANN - MTS - A/V: Mark Trachtenberg from the IPC, just to respond to Michaela's point, I think. [18:53] ICANN - MTS - A/V: maybe legitimate or benign is in the glossary as part of the definition, but that's the whole purpose of the comment, which is that the definition itself is ambiguous and it's not very clear, and I think that's what we're trying to get at here. [19:06] ICANN - MTS - A/V: Thanks, Mark. We have Gabriel. [19:22] ICANN - MTS - A/V: I can run a remote mic. [19:41] ICANN - MTS - A/V: They're working on it. [19:43] ICANN - MTS - A/V: Oh. [19:45] ICANN - MTS - A/V: Okay, we have, we have live. [19:47] ICANN - MTS - A/V: Sorry, you were 5 feet away. I, I… [19:51] ICANN - MTS - A/V: It's important to get exercise after long flights. [19:55] ICANN - MTS - A/V: This is Gabriel Andrews, with GAC. So, a couple points to make. One is I plus one Mark's concern with regards to the language of registered name holder. I think that that is something that needs to be considered for use cases where you have customers or proxy services because, yeah, that that language as now doesn't address that very important use case. [20:14] ICANN - MTS - A/V: So, need to consider that. Secondarily, I think that one of the driving considerations behind the proposal for a new definition was what happens in the case of ambiguity. And I note that MOG's comment on this implementation of Guidance 1.1 in particular called this out as being very important, that sometimes registrars might [20:32] ICANN - MTS - A/V: Kind of sort of think that maybe there's a compromised domain, but not be sure. And I think it's very important to be clear what the expectation is for the ADC requirement in situations in which there is ambiguity, particularly noting that sometimes bad guys lie and they might be registering domains and saying, oh yeah, maybe this is compromised. And if they're providing that out to a registrar that otherwise doesn't want to do the ADC. [20:56] ICANN - MTS - A/V: Should there be a requirement that the registrar does the ADC unless they have a reasonable belief that the domain itself was compromised? So that's something that I think needs to be clarified in a way that this definition doesn't currently satisfy. [21:09] ICANN - MTS - A/V: And lastly, with regards to legitimate or benign domain. [21:14] ICANN - MTS - A/V: I will note… I wasn't going to raise this issue originally, but I will now, since we're talking about it. [21:19] ICANN - MTS - A/V: Sometimes bad guys will compromise the sites of… or accounts of other bad guys. [21:24] ICANN - MTS - A/V: This can happen. It's probably a rare use case, but we should still at least consider that that could happen in this case, too, and you wouldn't want there to be an out just because one bad guy compromised the account of another if there's pre-existing abuse that otherwise might justify an ADC. [21:40] ICANN - MTS - A/V: over. [21:47] ICANN - MTS - A/V: We're checking it. [22:10] ICANN - MTS - A/V: Hello? Okay, this is great. This is better anyways. [22:14] ICANN - MTS - A/V: I was gonna make a Phil Donahue comment, but there's only probably 10% of the people in the room that still remembers Phil Donahue, so I won't make the comment. [22:22] ICANN - MTS - A/V: So Gabriel. [22:25] ICANN - MTS - A/V: I think that you briefly touched on trigger, right? Because this is an exception to the trigger. [22:31] ICANN - MTS - A/V: Right, so I don't think that… By not… [22:35] ICANN - MTS - A/V: Saying again that the triggers triggered here in the implementation guidance that we've [22:41] ICANN - MTS - A/V: there wasn't… there's no intent to change that by this implementation guidance, so I'm a little bit less bothered by that, but other people may be more bothered, and Gabriel, I don't mean to be throwing cold water on that. But that's my reaction for what it's worth. Marzena. [23:11] ICANN - MTS - A/V: Thank you, Farzan Badi, Non-Commercial Stakeholder Group. I just want to remind the group why we, are… [23:18] ICANN - MTS - A/V: emphasizing in the clear definition of compromised domain. Every time we [23:26] ICANN - MTS - A/V: raised concerns that this policy could entangle innocent people that, that have had no role in the, in the DNS abuse to be surveyed on and to have their contact. [23:44] ICANN - MTS - A/V: have their, to be profiled. [23:48] ICANN - MTS - A/V: And every time, we were told that compromised domains are not [23:54] ICANN - MTS - A/V: in the, scope of this group work, and… and we also said that that is not a safeguard. We need to have better safeguards in place. So it's either that we have a very clear [24:11] ICANN - MTS - A/V: way of defining compromised domains, and not entangle them in this ADC, policy. [24:22] ICANN - MTS - A/V: Or we will have… we will have to have better safeguards, higher investigative thresholds and all that that we have been asking for since the beginning of the policy. [24:34] ICANN - MTS - A/V: That's her thing. [24:38] ICANN - MTS - A/V: Thank you. All right, we have Brian Cymbolic next. [24:58] ICANN - MTS - A/V: Thank you. Thanks, everyone. Hi, Brian Cimbolic with PIR, but here for the registries. [25:04] ICANN - MTS - A/V: Or the GTLD registries, I should say. I just wanted to… a couple points to remember, sort of, what we're rooted in here, and that's the DNS abuse, provisions in the RAA in particular. This issue with. [25:19] ICANN - MTS - A/V: compromise versus malicious is already rooted in that agreement, and I wouldn't want us to let the perfect be the enemy of the good. I don't think we can solve the… [25:30] ICANN - MTS - A/V: okay, well, sometimes a bad guy makes a case that this is compromised. The mechanism to address that is actually ICANN contractual compliance, where if a registrar, just as today, if a registrar has a clear, malicious [25:43] ICANN - MTS - A/V: maliciously registered domain, and they say for some sort of BS reason that they think it was compromised, then that would run afoul of the registrar accreditation agreement, and that… it would be no different in this case. So, I don't think it's actually a problem we need to solve. If a registrar is sort of vexatiously or in bad faith saying that we think these are compromised when they're clearly not, then ultimately there already exists [26:06] ICANN - MTS - A/V: the way to address that, and it's ICANN contractual compliance. So. [26:10] ICANN - MTS - A/V: To the extent that's a hole in the contract, that's one that exists today, that's not really what we're here to do. So I would encourage us to, again, let's not try and let the perfect be the enemy of the good here. [26:22] ICANN - MTS - A/V: The issue of compromise is an important one, and it's something that from the outset, from the charter of this, it was clear that ADCs would not necessarily be required for compromised sites. So I think that let's just kind of move forward in that path. [26:40] ICANN - MTS - A/V: And where should I bring this microphone? [26:43] ICANN - MTS - A/V: Terry's behind you. [26:44] ICANN - MTS - A/V: Thank you. [26:48] ICANN - MTS - A/V: All right, we have, Volker. [26:55] ICANN - MTS - A/V: Terry's coming to you. [26:57] ICANN - MTS - A/V: Thank you, Paul. Interesting. [26:59] ICANN - MTS - A/V: the microphones. Volker Greimann RSG, [27:04] ICANN - MTS - A/V: Yeah, Brian kind of ate my lunch, which I'm thankful for, because it helps me on my diet journey. But, we should remember that we are here in a subset of, the abuse discussions with regard to the ADCs. [27:19] ICANN - MTS - A/V: Compromised domains exist as a problem in the common abuse sector already. We already have obligations to reports of abuse that we have to take care of. And there is already in 3.18.2 of the RRA, [27:35] ICANN - MTS - A/V: a certain safeguard embedded when it says that the possibility of associated collateral damage should be taken into account when taking action. Now, we would assume that this would also apply to the ADCs, obviously, when we get a report, then. [27:49] ICANN - MTS - A/V: and move to the action phase and see that there's a compromise, then that would obviously also have associated damages going with it, and then that would be taken into the balance. [28:00] ICANN - MTS - A/V: Yeah. [28:03] ICANN - MTS - A/V: So I don't see how we need an additional, [28:06] ICANN - MTS - A/V: definition here just for ADC, because it ultimately risks of having different, standards that would apply to general abuse checks and ADCs, and that would just cause confusion. So we should always fall back on the general, regulation that is in the RIA. Thank you. [28:24] ICANN - MTS - A/V: Thanks, Volker. We have Mark. [28:28] ICANN - MTS - A/V: Marc Trachtenberg, IPC. [28:30] ICANN - MTS - A/V: I just wanted to respond to Farzana's comments and say, you know, I think we all agree that this should not apply to compromised domains, and I think everyone agrees that nobody wants harm to happen to somebody who is innocent or is not engaging in any sort of abusive behavior. [28:45] ICANN - MTS - A/V: I don't view what we're doing here as trying to erode that in any way. We're trying to maybe strengthen it in some ways, because we're trying to clarify what this definition is, so that those people can be protected, but not at the expense of the policy, and not at the expense of the effectiveness of the purpose of the ADC. [29:02] ICANN - MTS - A/V: to be able to reduce abuse. And so, that is the balance, and I think the more clarity we have in the language. [29:07] ICANN - MTS - A/V: the better off… work that… [29:10] ICANN - MTS - A/V: Innocent registrants will have… will be. And also, the better off the policy will be. [29:16] ICANN - MTS - A/V: in its purpose. [29:18] ICANN - MTS - A/V: Thanks, Mark. We have Michaela. [29:23] ICANN - MTS - A/V: Thanks, Michaela Shapiro for the record. I'm a little confused as to why we're reopening this topic in the first place, but just wanted to come in to suggest, perhaps, first, I recall that the registrar's stakeholder group had shared a document a little while ago, earlier this year, that [29:42] ICANN - MTS - A/V: put out what I thought to be a pretty helpful kind of set of best practices, talking about what a compromised domain is. [29:49] ICANN - MTS - A/V: as the registrars understand it, and as they are the group that will be implementing this, I found that to be a helpful place to start. If we're concerned about the exact wording in here, that could be one place that we could look. [30:00] ICANN - MTS - A/V: Yeah, thank you. Someone already beat me to dropping the link in there. So, you know, again, if we're concerned about the specific terminology here, that could be another place we could look as an alternative language. Thanks. [30:15] Feodora Hamza - ICANN Org: Sorry. Hi, everyone. [30:20] Feodora Hamza - ICANN Org: Awesome. [30:21] Feodora Hamza - ICANN Org: This makes sense. [30:25] Feodora Hamza - ICANN Org: Hello. [30:29] ICANN - MTS - A/V: Okay, now it's better. [30:31] ICANN - MTS - A/V: Sorry, everyone, Feodora from ICANN Org. On the definition here, as noted, we are discussing this because it was part of a substantive, public comment that the current wording was not meeting. [30:45] ICANN - MTS - A/V: or providing the clarification that was needed. However, the working group initially, when it developed its initial report, used the definitions provided in the documents Michaela just provided, so that was the first source of information for that. However, that didn't seem to meet [31:03] ICANN - MTS - A/V: everybody's, [31:05] ICANN - MTS - A/V: I don't know standard in that sense in terms of public comments. So just to note that that was considered. [31:11] ICANN - MTS - A/V: But we are here again, as it seems to not provide the needed information. [31:17] ICANN - MTS - A/V: Thanks, Fayo. Okay, we have Martina. [31:21] ICANN - MTS - A/V: Test. [31:22] ICANN - MTS - A/V: Yay. Hey, I'm Martina from the GAC, representing the GAC. I wanted to thank Brian for reminding us that we indeed, we are trying to stay in line and, you know, root ourself in existing policies and contractual agreements. [31:36] ICANN - MTS - A/V: And I think the GAC, that was the GAC position. We're comfortable with that as long as it's clear, you know, and I think in this sense, what we felt it emerged from the public comment was that there is uncertainty on certain scenarios. And this is something that in the contract amendments were sold to the advisory. [31:53] ICANN - MTS - A/V: Which gave a number of scenarios and people help, and that helped with the implementation of the amendments. [31:59] ICANN - MTS - A/V: So I don't know if we are all happy with the definition, with the approach that we had before, and we don't want to renegotiate a new definition here. Maybe what we could do is to provide more guidance in a newly suggested advisory. [32:11] ICANN - MTS - A/V: Where ICANN Org could provide a number of scenarios. Some of those scenarios, for instance, mentioned by Gabe, but also others. [32:19] ICANN - MTS - A/V: I think that was a trend that emerged not only in relation to this recommendation, but for also other recommendations. [32:24] ICANN - MTS - A/V: That they wanted more guidance, and I think some of the comments explicitly refer to the advisory that was linked to the contract amendments. But just a suggestion. [32:34] ICANN - MTS - A/V: Thank you, Martina. [32:38] ICANN - MTS - A/V: All right. Well, so here are the issues identified by our round robin. Okay. [32:44] ICANN - MTS - A/V: So, we have whether or not to keep legitimate or benign. [32:49] ICANN - MTS - A/V: How to or not adjust registered name holder to talk more about the… Underlying beneficial registrant. [33:00] ICANN - MTS - A/V: And I thought there was a third thing. [33:03] ICANN - MTS - A/V: But it's escaping me. [33:04] ICANN - MTS - A/V: If you are the champion of the third thing, please let me know. [33:08] ICANN - MTS - A/V: I will kick off discussion. [33:11] ICANN - MTS - A/V: Want another walkthrough on legitimate and benign, let's just focus on that, okay? [33:16] ICANN - MTS - A/V: My concern about legitimate and benign is the exact opposite of Mark's concern. [33:22] ICANN - MTS - A/V: Mark's concern is that, we should just be looking at whether or not there is, you know, no knowledge or consent for the… for the abuse vector. My concern about legitimate and benign is because not every registrar exists in one jurisdiction. [33:40] ICANN - MTS - A/V: And once we get into legitimate or benign, what does that mean for a registrar? What if they're in a jurisdiction that doesn't particularly like your content? [33:48] ICANN - MTS - A/V: and decides that you're not legitimate. What happens if a registrar is in a jurisdiction that doesn't make your comments terribly benign. [33:55] ICANN - MTS - A/V: Right? It used to be that [33:58] ICANN - MTS - A/V: There were high horses to ride in the world. There are very few high horses now. And so we have to be realistic that registrars may come under pressure. And so for me, adding legitimate or benign. [34:12] ICANN - MTS - A/V: adds a qualitative level on this. [34:15] ICANN - MTS - A/V: That, I think, is going to be hard [34:18] ICANN - MTS - A/V: for, you know, it may not turn out the way we want, in other words. So, Michaela, you were an advocate for legitimate and benign. Can I ask you… [34:27] ICANN - MTS - A/V: To address that concern, and let me know if you still want to keep legitimate and benign, or… [34:33] ICANN - MTS - A/V: Yeah, thank you. [34:36] ICANN - MTS - A/V: Thank you. I mean, I… you know, I'm not necessarily tied to [34:42] ICANN - MTS - A/V: those exact terms. I think the concern for the NCSG is not having a definition at all. So, you know, again, if the key concern is about legitimate. [34:54] ICANN - MTS - A/V: that perhaps we don't have to be tied to that term, if that's problematic, but again, I think the key point for the non-commercial group is that we don't want to have no definition at all. [35:06] ICANN - MTS - A/V: Thank you, Michaela, and I think that that's… that there's appetite around this table for a definition. [35:11] ICANN - MTS - A/V: Right? We have heard, well, we can just… from Martina, if we can't get there, we can revert back. [35:18] ICANN - MTS - A/V: And have ICANN explain that more in updates. That's a good fallback position, but I didn't hear anybody say that the definition's a bad idea. So, I think we're on track to have a definition. And so, if there are anybody else that wants to advocate for legitimate and benign, let's have those people in the queue. [35:37] ICANN - MTS - A/V: And, I have a hand from Reg. Reg, go ahead. [35:44] Reg Levy – Tucows: Thank you. Reg Levy from Two Cows and the Registrar Stakeholder Group. I'll advocate for no definition, but just because I think once we start defining things, we go down the road of… [35:59] Reg Levy – Tucows: people can get around things. We have… used these terms, legitimate domains, legitimate registrations, for a long time, and we have been successful in doing so, trust us, but I understand that nobody wants to trust us, so I would prefer to remove [36:18] Reg Levy – Tucows: An indication that the domain itself. [36:23] Reg Levy – Tucows: Is legitimate or benign, and rather that it's use. [36:27] Reg Levy – Tucows: is legitimate or benign. So, a compromised domain means a domain name [36:33] Reg Levy – Tucows: That is registered for a legitimate or benign. [36:37] Reg Levy – Tucows: use. [36:38] Reg Levy – Tucows: that is used as a vector for DNS abuse without knowledge or consent. I'm happy to remove legitimate Orban 9 completely, just so that we can be clear that it's being used as a vector for abuse without the knowledge or consent of the RNH, because I'm good with that. But again, I don't think this is necessary. [36:57] ICANN - MTS - A/V: Thank you, Reg. [36:59] ICANN - MTS - A/V: Any other comments on legitimate or benign? [37:04] ICANN - MTS - A/V: anybody… Deeply opposed to scratching legitimate or benign. [37:11] ICANN - MTS - A/V: And just relying on the knowledge of the Domain… [37:16] ICANN - MTS - A/V: Registrant, whoever that turns out to be. [37:20] ICANN - MTS - A/V: Okay, off goes legitimate or benign. [37:24] ICANN - MTS - A/V: Moving on to the next issue, which is registered name holder. Mark, it's been a while since you made that comment. Would you reiterate the comment, and let's see if we can figure out who we really mean here? It may be registered name holder, it may not be. [37:37] ICANN - MTS - A/V: Sure. Mark Trachtenberg, the Ipc. [37:40] ICANN - MTS - A/V: The concern here is that registered name holder has a definition. It's the registrant of the domain name, and, you know, with the RDP, there's an organization that's the registrant, and so the vast majority of domain names are registered through privacy or proxy services, and so in those situations. [37:56] ICANN - MTS - A/V: that privacy or proxy service could be deemed the registrant or the registered name holder of the domain name. They're not going to have knowledge of any of the use of the domain name. So… [38:04] ICANN - MTS - A/V: This is a gigantic hole, because that's not really the intent. The intent is the beneficial owner. [38:10] ICANN - MTS - A/V: Of the domain name. [38:12] ICANN - MTS - A/V: And that person is not a registrant, right? They're a licensee, or whatever other term you want to use. So… [38:18] ICANN - MTS - A/V: this requires clarification to get to the intent. And I think everyone's agreed on the intent, it's just the language is not matching that intent. [38:26] ICANN - MTS - A/V: Thank you, Mark Eberhardt. [38:31] ICANN - MTS - A/V: Erhard Lisse, appointed member of the CCNSO. I don't… I'm against, adding definitions where not necessary, and, beneficial owner doesn't work because it's not necessarily an owner, it's a registrant. [38:46] ICANN - MTS - A/V: The registered name holder is defined in the registrar agreement, if I'm not mistaken. [38:53] ICANN - MTS - A/V: Traditionally, you contracted with a registrar. [38:59] ICANN - MTS - A/V: now you contact with the reseller who contacts with the registrar, and now I understand, Mark, to say now you contact with the privacy provider, who then contacts with the reseller, who then contacts with the registrar, who contacts with the registry. Somehow this doesn't make sense. The privacy provider hides the names. [39:18] ICANN - MTS - A/V: But the name of the detail and the name of the registered domain holder, but the registered domain holder remains clear, and somebody, the reseller or the registrar, has those details. [39:35] ICANN - MTS - A/V: The privacy provider is only there to hide this in the WHOIS and in the RDAP. [39:43] ICANN - MTS - A/V: Thanks, Eberhard. Reg, go ahead. [39:48] Reg Levy – Tucows: Thanks, Reg Levy from Tucos again. I… [39:53] Reg Levy – Tucows: I understand where Marc is coming from. [39:55] Reg Levy – Tucows: But if it is the case that RNH is no longer sufficient to determine the RNH, then that is a determination that belongs to a different PDP, and not ours to change. [40:07] Reg Levy – Tucows: I know that there are other PDPs, DP, in progress right now that may address that, but that is certainly not something that is… [40:18] Reg Levy – Tucows: On our plate for today. [40:20] Reg Levy – Tucows: Or for as long as this PDP lasts. [40:24] Reg Levy – Tucows: And if we leave it as RNH here, then that means that it will naturally change when those PDPs come up with a different definition. [40:36] ICANN - MTS - A/V: Thanks, Reg. Martina. [40:39] ICANN - MTS - A/V: Thank you very much, Paul Martina, for representing the GAC for the records. [40:44] ICANN - MTS - A/V: I think that I tend to agree with Reg and also with Brian. I think [40:51] ICANN - MTS - A/V: we need to root into existing definitions, and it's not for us to define or invent a definition of compromised domain names, because if we want to finish this PDP in December, I assure you that it's not in our interest to spend the next 3 months defining something, which would be, on top of that, only specific to this PDP. [41:09] ICANN - MTS - A/V: Because that would be a definition of compromise domain for this PDP rather than being something that is embedded in broader ICANN policies. [41:16] ICANN - MTS - A/V: So I think we could address, and I understand the concerns that were raised in the public comment in relation to this. I just think that there might be other ways of addressing it without us opening a Pandora box of definition work. [41:30] ICANN - MTS - A/V: which I'm not sure it's the most constructive for managing the expectation, especially because, as Reg said. [41:39] ICANN - MTS - A/V: This definition are debated elsewhere, and we use, for instance, you know, registered domain holders, and the definition change… in our definition, and then the definition changes elsewhere, and, you know, it's better to keep update [41:51] ICANN - MTS - A/V: things in the sense that if the… there must be a central place where all the definitions are, it could be the contract… the contract or something else, but we should just refer to that so the policy remains updated instead of then having to update our own definition in the PDP at some point. [42:07] ICANN - MTS - A/V: Thank you, Martina. [42:09] ICANN - MTS - A/V: We have Mark. [42:11] ICANN - MTS - A/V: Mark Trachtenberg from the IPC. [42:13] ICANN - MTS - A/V: I think that we have to address this issue and have to have a definition here. I mean, this is a critical aspect of the entire policy. It's an exclusion, and so we have to know when the policy applies and when the policy doesn't apply, and I think we're not doing our job and fulfilling our responsibility if we don't determine that in this PDP. It's just a gigantic hole. [42:29] ICANN - MTS - A/V: and on the registered name holder issue. [42:31] ICANN - MTS - A/V: Yes, I understand that that has a defined… it's a defined term. I'm not looking to change that definition. I don't know what PDPs are looking at changing the definition of registered name holder. I'm just pointing out that this is a defined term that is established. We know what it means. [42:43] ICANN - MTS - A/V: in the registration data policy, we know that where there's an organization, that organization is deemed a registrant. We know that a majority of domain names are registered through privacy or proxy services, whatever they want to call themselves. A lot of them use their own entity in the organizational field, which means that that entity is the registrant. And so. [43:00] ICANN - MTS - A/V: the reality is that this doesn't accomplish the goal. So, one, we need a definition, and two, with registered name holder. [43:06] ICANN - MTS - A/V: that doesn't accomplish the goal. It misses the mark. The intent is the person who is controlling, whether you want to call them the owner, whatever, the beneficial user, the customer of the registrar or reseller. It's that person. That person's intent is what matters. I don't think anyone disagrees with that. [43:21] ICANN - MTS - A/V: And so that's the problem that we have. Registered name holder misses that mark in the practical reality of the world now, and with the definitions as they exist in the RDP. [43:32] ICANN - MTS - A/V: Thank you, Mark. [43:34] ICANN - MTS - A/V: So, I took a quick look at the RAA, and maybe I'm looking at an old version. If I am, I'm just going to publicly embarrass myself. But there's a definite… there's a definition of account holder. [43:45] ICANN - MTS - A/V: Right? Is it… is that right? [43:48] ICANN - MTS - A/V: One of the registrars can help me. [43:50] ICANN - MTS - A/V: And the account holder means the person or entity that is paying for the registered name, or otherwise controls the management of the registered name, when that person or entity is not the registered name holder. [44:02] ICANN - MTS - A/V: And so, wouldn't we just plop in account holder? [44:09] ICANN - MTS - A/V: Mark Dragtemberg from the IPC. I think that would work. I'd have to go look at that language, but that sounds right, that sounds like what we're trying to accomplish, and if that definition already exists, then fantastic. Then we address all those people's concerns of not creating new definitions. But can you point to where that is, just so we can look at it? [44:22] ICANN - MTS - A/V: Under, I think it's 1.1. I think it's the first thing, but I could be wrong. Again, I may be looking at an ancient copy of this, and if I am, I apologize. [44:33] ICANN - MTS - A/V: We're gonna go to Brian while everybody fact-checks me. Brian, go ahead. Thanks, Paul. Brian Sinbolic for the registries. I didn't… I wasn't aware of that, and I think that's a great potential solution, because I was going to suggest that, actually, we're sort of in an area of diminishing returns here. [44:47] ICANN - MTS - A/V: You know, the issue of the registrant as it relates to compromise, that exists under 3.18 today. [44:53] ICANN - MTS - A/V: And you know, you look at the ICANN contractual compliance advisory, and it uses just registrant, not as a defined term. And ICANN is able to enforce that agreement well, I think. And so, again, like, we understand the intent. It could be something that implementation guidance or another advisory, we flesh that out a little. I don't want us to get spun around the axle. You could say registrant. [45:18] ICANN - MTS - A/V: or ultimate underlying beneficial registrant. But it sounds to me as though if we say [45:22] ICANN - MTS - A/V: registrant, registered name holder, or account owner, then that might do the trick, but again, I think we all know what we're trying to accomplish here. I don't think that we need to solve a problem specific for the [45:36] ICANN - MTS - A/V: associated domain check that, in theory, also exists for 3.18.2 that we are all living under today. [45:45] ICANN - MTS - A/V: Thank you, Brian. We have Yao [45:49] ICANN - MTS - A/V: Thank you, Paul. Yao speaking, NPOC. I just wanted to make a comment regarding the definition issue overall, highlighting that, also inviting colleagues to try some time to check the… [46:02] ICANN - MTS - A/V: Other… [46:03] ICANN - MTS - A/V: appendix of the document we are already using, because from my understanding so far, we have already… all of the terms we have been using and agreed on for all. [46:13] ICANN - MTS - A/V: the last 6 or 7 months working on this Pdp. We were trying to make use of consistent term and wording here so far. I think the issue rather concerning this definition would rather be [46:27] ICANN - MTS - A/V: having sort of, I don't think glossary word is used here, but [46:33] ICANN - MTS - A/V: having a way to link all the time you've already been using to the actual document. For example. [46:40] ICANN - MTS - A/V: A lot of terms from the Raa document. [46:43] ICANN - MTS - A/V: I've been using the recommendations and… I. [46:50] ICANN - MTS - A/V: suggestion we made so far already. So, reinventing… although there might be some wording that can be confusing at the time we are reading the recommendation, but it does not mean that those terms were not defined somewhere. So, we just need to find a way to highlight those as well. I just want to make a… [47:08] ICANN - MTS - A/V: Thank you. [47:09] ICANN - MTS - A/V: Okay. [47:11] ICANN - MTS - A/V: We have, reg. [47:17] Reg Levy – Tucows: I'm so surprised. Reg Levy from Tucas and the Registrars. [47:23] Reg Levy – Tucows: Account holder is very different from RNH. I think we added, as I recall, account holder was added so that if it's a reseller. [47:33] Reg Levy – Tucows: We can review the reseller account when performing the ADC, just to bring this back to the whole point of why we're here, is ADCs. [47:40] Reg Levy – Tucows: Because sometimes that is the relevant piece for certain types of registrars. [47:48] Reg Levy – Tucows: That's what I'm gonna go with. I don't think we add AND account holder, or OR account holder, because [47:56] Reg Levy – Tucows: It's not really the account holder's consent. [47:59] Reg Levy – Tucows: that is relevant for the use of a domain, right? When… [48:05] Reg Levy – Tucows: you, my good friend Paul, buy a domain for me, and I set it up for you because I'm a real reseller now, at Two Cows. I don't know what you're doing with it, right? It's not… you just pay me. That's all that happens. So that's not the relevant piece. The relevant piece is the RNH. [48:28] ICANN - MTS - A/V: Okay, we have Volker and then Mark. [48:31] ICANN - MTS - A/V: Yeah, just oh it works for the record RRSG. [48:37] ICANN - MTS - A/V: The account holder doesn't hit the mark here, and I would like to explain why. When we added that terminology to the RA8 back in 2012-2013, [48:49] ICANN - MTS - A/V: This was understood to mean the person paying the domain name at the registrar. This is the reseller, for example. This is the web hosting provider that is registering the domain name on behalf of its clients. This is the party that comes to the registrar and pays for the domain name. He might not be the one that is using the domain name. [49:08] ICANN - MTS - A/V: this is also part of the set of data that the registrar is required to collect and store. If it were the beneficial owner, how would the registrar be expected to store that or know that data in case of a registration through a reseller? This is just… would just be impossible. So, logically. [49:24] ICANN - MTS - A/V: This is not the entity that we would be looking at when it comes to. [49:29] ICANN - MTS - A/V: the, use of the domain name. This is [49:33] ICANN - MTS - A/V: The payer, this is the payment trail that we have to follow and have to, [49:37] ICANN - MTS - A/V: keep data off, not the use trail, and therefore I would urge not to use that here. [49:46] ICANN - MTS - A/V: Thanks, Volker. Registered name holder, by the way, the definition means the holder Of a registered name. [49:54] ICANN - MTS - A/V: So, that's very, very clear. Thank you, everybody. [49:58] ICANN - MTS - A/V: Yeah, so we got that taken care of. [50:01] ICANN - MTS - A/V: All right, we're gonna go to Mark, but I will say this, we have the IPC and the NCSG. [50:10] ICANN - MTS - A/V: in agreement that they want a definition. I just want to celebrate the moment that they're in agreement on something. Okay, that's a good thing. [50:19] ICANN - MTS - A/V: So, Mark, go ahead. [50:23] ICANN - MTS - A/V: So, I take your point about the registered name holder definition, but then again, in the RDP, if there's an organization, that organization is a registered name holder, which is what kind of creates this problem. [50:32] ICANN - MTS - A/V: I… [50:34] ICANN - MTS - A/V: take into account what Volker says. He knows better about the intent of what was put into the RA, what he said makes sense, and so that seems like maybe that's not the right term, unfortunately. [50:42] ICANN - MTS - A/V: But, you know, there has to be some term, and the fact that other previous agreements made before our policies [50:47] ICANN - MTS - A/V: said a certain thing in the past, like, things change over time, which is why we have this PDP in the first place, and we can't just be stuck with whatever happened in the past, especially when we know now that even though it's kind of being clued together and being used by compliance or whoever, that it's not right and it doesn't fully capture it, we shouldn't just rely back on that. We should try to do the best we can [51:04] ICANN - MTS - A/V: to be as clear as we can with this policy as every policy subsequently should going forward. So let's just try to do that. Again, I think we're all agreed on the intent. [51:12] ICANN - MTS - A/V: Right? There's no… I don't see any disagreement on the intent. We just need to find the language that is clear, and if it requires creating some new definition for us, then let's just do it and be done so that we can be very clear in what we're talking about. The person who controls the use of the domain name. [51:28] ICANN - MTS - A/V: Thanks, Mark. All right, we have Gabriel, and then I'm gonna say, if you want to say something else about this, get in the queue. But I feel comfortable that leadership and staff have what they need to come back with a proposal on this, in, you know, after ICANN 87. [51:47] ICANN - MTS - A/V: So, hop in now, otherwise I'm gonna draw the line, after Gabriel. Gabriel, go ahead. [51:54] ICANN - MTS - A/V: Hi, so I'm going to rephrase what I heard Mark saying earlier, because I'm not sure we're all on the same page as to why this matters, but I think we can eliminate the terminology altogether, which I'll propose in a second, but [52:06] ICANN - MTS - A/V: We know that for some registrars out there, they turn on proxy service by default. Right. So for some registrars, proxy is always going to be on. [52:16] ICANN - MTS - A/V: And their proxy service is the RNH. And they could, if they wanted to, make the case then that all registrations that are used for abuse thereafter are done without the knowledge of the RNH. [52:29] ICANN - MTS - A/V: Right? And so so that is why he's saying that this is important, because otherwise it's just a a huge loophole for anyone that turns on proxy by default. Now. [52:38] ICANN - MTS - A/V: What I would propose is rephrase the definition, because the whole reason for creating the new definition in the first place was to try to make clear that registrars are supposed to make a reasonable determination. Right. You don't need to refer to RNH at all for that. [52:52] ICANN - MTS - A/V: As a suggestion, you could make it really simple and say a compromised domain means a domain name that's used by an unauthorized party as a vector for DNS abuse. [53:02] ICANN - MTS - A/V: just cut out references to our nature account holder altogether, and that's just maybe another path that might satisfy the original need over. [53:10] ICANN - MTS - A/V: Or a third party. [53:16] ICANN - MTS - A/V: Okay, interesting. [53:17] ICANN - MTS - A/V: All right, that's the end of that. If I don't move on, I think Terry's gonna come up here and kick me under the table, so let's move on. All right, [53:28] ICANN - MTS - A/V: So, this is… I think we've already talked about this. In essence, we have a slide saying, should we make the changes? I think we… we got a sense of where the room is on that. [53:36] ICANN - MTS - A/V: Okay, we have, a couple more things. They fall in the category of non-substantive comments on. [53:46] ICANN - MTS - A/V: Implementation Guidance 1.1 related to actionable evidence and recurring intermittent DNS abuse. [53:51] ICANN - MTS - A/V: and potential language to clarify the working group intent. So here's the proposed language from leadership. [53:58] ICANN - MTS - A/V: Actionable evidence may be identified through the registrar's own analysis or received from an external source. [54:06] ICANN - MTS - A/V: Consistent with existing contractual obligations. [54:09] ICANN - MTS - A/V: Where the reported DNS abuse is intermittent, recurring, or otherwise not continuously observable, the information provided should be sufficient to support a reasonable determination of the alleged abusive activity consistent with the applicable actionable evidence standard. [54:26] ICANN - MTS - A/V: So, the reason why these are marked as non-substantive is, I think, because everybody's on board with the concept. We're just playing around with the language to make it more clear. I'm going to open a queue on this language. Gabriel, go ahead. [54:43] ICANN - MTS - A/V: Any, any concerns about this language? Volker? [54:48] ICANN - MTS - A/V: Yeah, I still feel that this basically creates, definitions and obligations that govern the entire. [54:57] ICANN - MTS - A/V: field of DNS abuse, not just what happens when DNS abuse is detected. This goes beyond the scope of this PDP, in my view. [55:05] ICANN - MTS - A/V: This shouldn't be in here. [55:10] ICANN - MTS - A/V: So, Volker, we already… we already address actionable evidence, and we've talked about it a lot. I can quote the [55:17] ICANN - MTS - A/V: The dates, if you want. [55:19] ICANN - MTS - A/V: So, okay. [55:23] ICANN - MTS - A/V: Anybody else have anything to say about this? This is all good. [55:29] ICANN - MTS - A/V: going once. [55:32] ICANN - MTS - A/V: All right. Well, you know I, for one, am never going to look the gift horse in the mouth moving on. [55:43] ICANN - MTS - A/V: Okay, we're into, public comment, on Rec number 2. Fayo. [55:50] ICANN - MTS - A/V: Hi, everyone. Recommendation 2 was very short, so was also the public comment on it. The only thing here was to, clarify and reference to, the other recommendation for consistency, but I think there was a typo or inconsistency in terms of, R being used. [56:10] ICANN - MTS - A/V: And we used… is being used, even though it doesn't fit the grammar, so that was the most… [56:16] ICANN - MTS - A/V: Important part, and dr. Paul? [56:21] ICANN - MTS - A/V: Thanks, Fayo. So this is what the tweak looks like from leadership. [56:27] ICANN - MTS - A/V: Again, for discussion, a registrar must perform a reasonable investigation in order to determine whether or not associated domains of the trigger domain name of the trigger domain are being used for DNS abuse as defined in 3.18.1 of the RAA. [56:46] ICANN - MTS - A/V: Consistent with Recommendation 1, referring back to the trigger, as well as Recommendations 3 through 8. [56:56] ICANN - MTS - A/V: Any concerns about this? [56:59] ICANN - MTS - A/V: opening a queue. [57:06] ICANN - MTS - A/V: Okay. [57:08] ICANN - MTS - A/V: Town of Portsmouth, I'm seeing no hands. [57:12] ICANN - MTS - A/V: Groovy, as they say. Okay. [57:18] ICANN - MTS - A/V: Okay. [57:19] ICANN - MTS - A/V: So… Is that it for this session? [57:27] ICANN - MTS - A/V: Okay, Gabriel. [57:29] ICANN - MTS - A/V: Yeah, with respect to recommendation 2. But a different part of that I noted in my review of public comment. There was a very interesting point raised by Mog. [57:41] ICANN - MTS - A/V: That they generally align with the agreement that they [57:45] ICANN - MTS - A/V: I don't know if you want me to read it. I can read it for reference here. [57:50] ICANN - MTS - A/V: However, the draft states that this policy only requires an ADC within a registrar portfolio, and does not require cross-registrar checks or coordination. [57:58] ICANN - MTS - A/V: And this is a policy shortcoming when a company owns two or more registrar accreditations. We recommend that a registrar must reasonably examine registrars at its affiliated registrars as defined in the RAA, et cetera, et cetera. [58:12] ICANN - MTS - A/V: And under the operational control, their operational control. [58:16] ICANN - MTS - A/V: When an ADC is triggered at one of those registrars. And I found that was a point that hadn't been discussed by our group before, but I think that it was a valid expectation that when there's multiple registrar portfolios all controlled by the same entity, that there should be sharing under that specific case. [58:34] ICANN - MTS - A/V: Over. [58:37] ICANN - MTS - A/V: Thanks, Gabriel. I do not want to steal the thunder from Reg or Volker, but I will say that we did… [58:44] ICANN - MTS - A/V: briefly touch on inter-registrar checks, and determined very, very early that those were outside of the scope of the Charter, and that's one of the reasons why this… that particular comment was not baked into our proposed changes. [59:00] ICANN - MTS - A/V: Gabriel? Just to clarify, we're talking about a situation where it's the same entity controlling multiple registrar accounts, or… [59:08] ICANN - MTS - A/V: I think what the… [59:10] ICANN - MTS - A/V: the prior determination was that differing entities that weren't under common control wouldn't be required to share information. But when you're talking about the same entity that might just have different, accounts, I think that's an entirely different situation. Or at least, that's my reading of the MOG feedback. Over. [59:27] ICANN - MTS - A/V: Thanks, Gabriel. Let's hear from Reg and Volker. [59:31] ICANN - MTS - A/V: Reg first. [59:32] Reg Levy – Tucows: Thank you. Rach Levy from Tucas and the Registrar Stakeholder Group. [59:37] Reg Levy – Tucows: I would trust staff and leadership that if we didn't have a substantive point to make on this comment, we should leave it by the wayside. But also, I have no earthly understanding of how we could possibly do that. [59:54] Reg Levy – Tucows: Right now, we're focusing on accounts, and that is something that we've agreed that we can do. It's gonna be hard for some of the registrars, but trying to do that in a cross-registrar manner. [60:10] Reg Levy – Tucows: Or cross-registryment? Like, I really don't understand. I understand why this was raised, but I don't understand the actual means of getting registrars to do it. [60:24] Reg Levy – Tucows: That said, when we receive notices from reporters that say, here is a global scheme, and here's a bunch of domains at a bunch of different registrars, well, that's gonna trigger those checks within all of the registrars. [60:41] Reg Levy – Tucows: But just saying, John Smith registered a bad domain. Check and see if any John Smith has registered a domain at any of your other registrars. [60:51] Reg Levy – Tucows: It's… it's a baffling suggestion. [60:56] ICANN - MTS - A/V: Thanks, Reg. Volker? [60:59] ICANN - MTS - A/V: Thank you all for the amendment for the RSD. [61:04] ICANN - MTS - A/V: You all know that, in the first session that we had, there was something that I was advocating for, that, ADCs should not be on a single registrar, but rather extend to a system that, crosses registry boundaries, and that, would basically allow checks across [61:23] ICANN - MTS - A/V: TLDs across registrars, whether they're affiliated or not. [61:27] ICANN - MTS - A/V: And realizing that that would obviously be a system that currently doesn't exist and would need to be built out. [61:33] ICANN - MTS - A/V: The same, in many cases, applies to such checks when they extend to registrars, even when they're under affiliated ownership or common ownership. [61:45] ICANN - MTS - A/V: Because, while some registrars that have affiliated registrars are all managing them in one system and in one team, others that have, especially when they have grown through acquisitions, [61:59] ICANN - MTS - A/V: are very much operated as independent entities that are… just happen to be under common control. And for those, expecting, a common… a check of associated domain names. [62:11] ICANN - MTS - A/V: The same way that is currently being envisioned for, inside one registrar accreditation. [62:19] ICANN - MTS - A/V: would create an additional burden on those registrars that is currently not foreseen, and that probably would be out of scope for the PDP. [62:27] ICANN - MTS - A/V: just as the cross registry and cross registrar for unaffiliated registrars would be. [62:35] ICANN - MTS - A/V: Thanks, Volker. We have Mark. [62:39] ICANN - MTS - A/V: Arch Trachtenberg, Ipc. [62:41] ICANN - MTS - A/V: I think early on we did agree that there's no cross-registrar generally checking, but to Gabe's point, and thanks to him for raising it. [62:47] ICANN - MTS - A/V: it was only realized later that this kind of left this loophole where multiple registrars are under common control, and I… [62:56] ICANN - MTS - A/V: recognize and acknowledge that we have to take into account different business models, and I understand Volker's point. [63:01] ICANN - MTS - A/V: And to some extent, Reg is, but I don't think that it's so inconceivable and impossible to how this could be accomplished. You know, to the extent that you are a registrar, and you receive an abuse report, you determine there's abuse that's occurring, you now know that you have to conduct the ADDC. [63:16] ICANN - MTS - A/V: Just like in the same way that if you have resellers, you ask the resellers. [63:19] ICANN - MTS - A/V: hey, here's the domain name, here's the information, do the ADC check, you could also just send that information to all the other registrars that are under your common control. And even if they have different systems, just like with a reseller, you send them the information that you have and say, we're running an ADC in our system, please run it in yours. [63:37] ICANN - MTS - A/V: So, that seems to be a simple solution for this problem that already exists, like, with the reseller model. [63:43] ICANN - MTS - A/V: Thanks, Mark. We have Rod. [63:46] ICANN - MTS - A/V: Hi, Rod Rasmussen for the SSAC, and I'd like to point out that we had this as one of our. [63:51] ICANN - MTS - A/V: Points that we brought up in our feedback as well. [63:54] ICANN - MTS - A/V: I guess there's a difference of opinion whether it's substantive or not, and that actually begs a more generic question, is when there's something that isn't in the schedule here to talk about that a group thought was substantive, didn't make the cut, how do we… [64:08] ICANN - MTS - A/V: address that. [64:09] ICANN - MTS - A/V: And I'll take that as an aside. But to this particular point, we know that there are multiple ways of running registrars, and some are consolidated and some are not, and when a consolidation may just be at the business level. [64:24] ICANN - MTS - A/V: And you may have disparate systems where it would be very difficult to do a cross-check. Others, they're on the same exact system at the same point, where the abuse desk is looking at it all across, has access to that information. [64:37] ICANN - MTS - A/V: In that latter case, we thought that that would… [64:41] ICANN - MTS - A/V: You do not want to create a loophole where people would stop looking just because it happens to be under a different accreditation. [64:48] ICANN - MTS - A/V: You know, then another domain that they already have the ability to go and examine. [64:52] ICANN - MTS - A/V: So in that… in this case, it was more a matter of you already… you're looking across [64:58] ICANN - MTS - A/V: the portfolio anyways. [65:01] ICANN - MTS - A/V: Don't use this as a loophole. Thanks. [65:05] ICANN - MTS - A/V: Thanks, Rod. I'll address one… your question about how you raise issues that maybe leadership looked at and thought had already been discussed, or were out of scope, or… because this is… [65:16] ICANN - MTS - A/V: This is… this issue raised by Gabriel. [65:19] ICANN - MTS - A/V: you know, I… leadership viewed it as out of scope because we said early on that we would not be… that the Charter did not allow us to look at inter-registrar ADCs, right? And… [65:30] ICANN - MTS - A/V: without regard to the ease of looking into another registrar, and who owns that other registrar, it's still an inter-registrar ADC, right? And so that's why we spent zero time on it. [65:44] ICANN - MTS - A/V: And that's why it didn't end up here. In terms of raising it, you do exactly what Gabriel did. You say, hey, I want to talk about this comment, and anybody can raise any comment. [65:54] ICANN - MTS - A/V: Right? You know, this… like I said at the beginning, this is just leadership's best efforts to keep us moving forward, right? It's not… it's not Scripture. [66:03] ICANN - MTS - A/V: So, perfect. Ry, do you want to respond to that? Yeah. [66:06] ICANN - MTS - A/V: just on that last point. [66:09] ICANN - MTS - A/V: I really liked the fact that we had this all laid out to talk about these things. The question is, do we bring it up as we go, or should we bring this up [66:18] ICANN - MTS - A/V: not to… I don't want to get us off schedule, so to speak, so… I'm just asking it from a process perspective. [66:26] ICANN - MTS - A/V: So, Rod, it's exactly what Gabriel did, which was when we're raising… when we're talking about the particular recommendation, you would bring it up then, right? Because we would like to put these behind us and move on to the next recommendations. In terms of on schedule, that's my job, not yours. It's your job to talk about anything you want to talk about. [66:43] ICANN - MTS - A/V: And you know, and we'll we'll we'll address it, even if it's just to say. [66:47] ICANN - MTS - A/V: you know, great idea, let's talk about it some more, or out of scope, sorry bud, right? That's my job. You don't… you don't have to worry about my job. You… you talk, okay? [66:56] ICANN - MTS - A/V: Brian. [66:58] ICANN - MTS - A/V: Thanks, Paul. [66:59] ICANN - MTS - A/V: Brian Smolik for the registries. So, I think this is… it's an interesting and good discussion, and… but with the caveat that there's affiliated registrars under the RAA, and then there's affiliated registrars under the RAA. And by that, I mean, I'm thinking of a couple real-world registrars where there's a number of different [67:20] ICANN - MTS - A/V: you know, business models, and I looked at my registrar friends to correct me, but there's one approach where there's a number of different affiliated registrar credentials, where, let's say, I've created Brian's registrar. [67:32] ICANN - MTS - A/V: And the… I might have 50 different registrar credentials that are just labeled Brian's Registrar 1 through Brian's Registrar 50. [67:40] ICANN - MTS - A/V: And if someone goes to register a domain name, they think they're going to Brian's registrar generically, and then my system decides which registrar cred to fulfill it on. [67:50] ICANN - MTS - A/V: And so it's effectively one business operation, but you might have 50 different registrar credentials, but really it's one business line that you're interacting with, as opposed to other registrars where there might be common ownership, where you might have a wholesale registrar targeting the Indian market, and then a retail registrar targeting North America. [68:11] ICANN - MTS - A/V: all under the same corporate umbrella that have really different operational structures. So. [68:16] ICANN - MTS - A/V: you kind of think, like, well, in one situation, that might be reasonable, that for the Brian's Registrar example, perhaps an ADC should be conducted, whereas that second example, it gets trickier. You might have different teams running different systems. [68:31] ICANN - MTS - A/V: And so, the thing that I would suggest might actually bridge that gap is what's in, I think it's Recommendation 3, is what evidence is reasonably accessible. [68:40] ICANN - MTS - A/V: And so, in the Brian's Registrar example, you're very likely to have the same compliance team overseeing all 50 registrars under that umbrella, whereas the other example, where you have really fundamentally different operations, the information may not be as reasonably accessible to a registrar in one of those different silos. So, again, I look to my registrar friends to correct me if I'm wrong. [69:06] ICANN - MTS - A/V: Thanks, Brian, that may be the solution that everybody's looking for. [69:10] ICANN - MTS - A/V: Ching. [69:12] ICANN - MTS - A/V: Thank you, Paul. Ching from the, BC. So, I guess… so, first of all, I think BC will always support the concept of information. [69:20] ICANN - MTS - A/V: Sharing, just across… [69:24] ICANN - MTS - A/V: Not just the registrar under common control, but interregistrar. But understand that interregistrar topics out of scope. [69:35] ICANN - MTS - A/V: We would love to see something like, once again, information, sharing, if not in the recommendation tool, maybe in the IG, then we can put something, at least the registrars under the common control, they… [69:52] ICANN - MTS - A/V: are, you know, in some way of, you know, have the obligation to share the information once, for example, one of the registrars conducting the ADC and the other affiliated registrar should be aware of that. [70:06] ICANN - MTS - A/V: Thanks, Ching. Somebody… [70:08] ICANN - MTS - A/V: mentioned, and I don't know if it was Volker or somebody else, the concept that you are… [70:13] ICANN - MTS - A/V: Perhaps sitting at a dashboard, right? Because you are a registrar with multiple registrars, right? [70:20] ICANN - MTS - A/V: That are affiliated with each other, and don't underestimate the extreme helpfulness of the RAA definition of an affiliated registrar, which, of course, very clearly states [70:30] ICANN - MTS - A/V: Affiliated registrar is another accredited registrar that is an affiliate of registrar. So, super helpful, non-circular definition, right? And so, I think what we're getting at is that if you're sitting at that dashboard. [70:43] ICANN - MTS - A/V: And you are overseeing, essentially, multiple affiliated registrars. [70:47] ICANN - MTS - A/V: then, arguably, that information is reasonably accessible to you, right? And so, I think that we may have solved the problem by that reasonable, accessible thing, and we may want to leave it undisturbed, because it sounds like [71:04] ICANN - MTS - A/V: We may be getting what some people want, but we can keep poking at it if we want to. [71:10] ICANN - MTS - A/V: I'm gonna open this up to Mark. Go ahead. [71:15] ICANN - MTS - A/V: Mark Tragenberg from the IPC poking at it slightly. [71:20] ICANN - MTS - A/V: I think what you're saying makes sense, but the question is, from a practical perspective, does ICANN compliance have access to that information? Do they know how the system… how the registrar is running? And I think the answer is probably no. [71:30] ICANN - MTS - A/V: So that's… while on the surface, logically, it makes sense, I think there's a practical issue with that. [71:38] ICANN - MTS - A/V: There's also sort of a really big old downside [71:42] ICANN - MTS - A/V: Right, because one affiliated registrar and breach is not a great thing for the other affiliated registrar, so I do think that there is some… [71:49] ICANN - MTS - A/V: Internal motivation to get to your accessible information? [71:54] ICANN - MTS - A/V: Right? [71:56] ICANN - MTS - A/V: Okay. I'm gonna call for last comments on this. I think staff and leadership have what they need to mess around with this. [72:04] ICANN - MTS - A/V: But, anybody else? [72:08] ICANN - MTS - A/V: Okay. [72:11] ICANN - MTS - A/V: So… Is that it? [72:14] ICANN - MTS - A/V: That's it. So I'm going to do what I'm going to do for each of these at the end of this session. [72:21] ICANN - MTS - A/V: For recommendations 1 and 2, and… [72:24] ICANN - MTS - A/V: and implementation guidance. Is there anybody sitting around this table that did not get to say what they wanted to say? [72:32] ICANN - MTS - A/V: Right? Not… not that you got your way, that's not the question, but… [72:36] ICANN - MTS - A/V: Anybody have anything else that they wanted to say? Because I don't want to hear later that you weren't… [72:42] ICANN - MTS - A/V: Given a chance to talk. So, let's… Anybody else? Open mic. [72:49] ICANN - MTS - A/V: Okay. [72:52] ICANN - MTS - A/V: Great. We have… how many minutes? [72:55] ICANN - MTS - A/V: We have 15. [72:57] ICANN - MTS - A/V: What's that? [73:00] ICANN - MTS - A/V: Okay. [73:02] ICANN - MTS - A/V: So, we're, we're early. Is there anybody in the room, since this is an ICANN public meeting? [73:08] ICANN - MTS - A/V: That has anything that they would like to say about recommendations 1 and 2? [73:15] ICANN - MTS - A/V: Gabe, you're not in the room. Go ahead, buddy. [73:18] ICANN - MTS - A/V: Hi, Gabriel again. This was something that I didn't think was terribly important to raise at the time of Recommendation 1, because it seems like it's kind of, sort of, speaking to the entire document, but I'm going to raise it now since we have the time. [73:32] ICANN - MTS - A/V: I think one of the pieces of feedback that we saw in recommendation one was again from from Ogg helpfully calling out that sometimes [73:41] ICANN - MTS - A/V: while we consider malicious registration to occur, like, you know, bad guy goes to a registrar, obtains the domain. Sometimes they go to a secondary market, and by an already registered domain that's been [73:52] ICANN - MTS - A/V: in existence for some time, and then take control of it, and maybe subsequently use it for abuse, even though the original registrants might have bought it for the purpose of resale, right? [74:02] ICANN - MTS - A/V: And I think that was something I hadn't previously considered, and I found that to be a very insightful comment to make. And I think that the only real repercussion it has on this document is sometimes we're using the term maliciously registered as if that's the only way that the bad guys get ahold of domains, and we might want to change some language to, I don't know, throwing terms out there [74:20] ICANN - MTS - A/V: Maliciously acquired, or acquired for malicious purposes, to incorporate that feedback that it's both [74:27] ICANN - MTS - A/V: The situations in which the bad guys register the domain, or if they acquire it later after the fact. [74:33] ICANN - MTS - A/V: But, throwing that out there. [74:36] ICANN - MTS - A/V: Thank you, Gabriel. Jothan. [74:39] ICANN - MTS - A/V: I'd kind of like to build on Gabe's wisdom. There, there are systems and and [74:44] ICANN - MTS - A/V: Services out there where you can lease a domain. [74:48] ICANN - MTS - A/V: And You know, you could have a, you know, a party who owns a very valuable domain name. [74:54] ICANN - MTS - A/V: leasing it to another party, and that party ends up using it maliciously, or that domain gets compromised. That could be a very unfortunate circumstance here, where you've got, you know, to take action on a domain. You've got an innocent party in the person who's leasing out the name. [75:10] ICANN - MTS - A/V: potentially an innocent party in the the person who's leasing the name. [75:14] ICANN - MTS - A/V: We probably want to bake in something that protects those parties, those commercial parties, because those are… that is a very legitimate and frequently occurring situation. Thank you. [75:23] ICANN - MTS - A/V: Thank you, Jothan. Now we did it. We got Chris involved. [75:28] ICANN - MTS - A/V: Yeah, thanks. Thanks, Paul. [75:32] ICANN - MTS - A/V: I'm very wary of over-defining things. I think that… [75:37] ICANN - MTS - A/V: I don't think anyone in this room imagines that the current way it's put means you have to have decided to be bad when you registered the name. [75:47] ICANN - MTS - A/V: It's not about that. And I think it's covered anyway. And I also think that if we pick up on Gabe's point of unauthorized third parties or whatever it was, that would cover it as well. So I just don't think it's necessary to redefine… [76:03] ICANN - MTS - A/V: Going down the definition trail, it's… it's not helpful, and actually, the more you define, the less flexibility you have. [76:12] ICANN - MTS - A/V: Thanks, Chris. [76:15] ICANN - MTS - A/V: Anyone else? Oh, Mark, go ahead. [76:18] ICANN - MTS - A/V: Mar Trachtenberg, IBC. I agree with Gabe's point, and Jothan's, and I think for… to respond to Chris, I don't think unauthorized third parties does address this, because in that case, the party would be authorized. [76:29] ICANN - MTS - A/V: Because they would have acquired the domain name, and I think… [76:31] ICANN - MTS - A/V: like, under UDRP jurisprudence, a transfer is treated as a new registration, but that's not in the policy anywhere, and it's not in any sort of other policy document or agreement, so I think this is a loophole that people didn't think about before, and this is exactly the purpose. [76:44] ICANN - MTS - A/V: of the public comments and this type of session of looking at, okay, let's not relitigate things, but is there something that we missed? And I think, actually, this is something that was missed, and so, you know, thanks to MOG, but also to Gabe for raising it right now. [76:58] ICANN - MTS - A/V: Thanks, Mark. [77:00] ICANN - MTS - A/V: Michaela [77:04] ICANN - MTS - A/V: Thank you, Michaela Shapiro, for the record. No, I was just going to say that, again, it might be another elegant answer, but I really liked Martina's point earlier about maybe this could be a scenario that we address in the advisory. So, this could be also a question for compliance instead of relitigating in this room, but just a suggestion. Thanks. [77:25] ICANN - MTS - A/V: Music to your chair's ears. Okay. Chris, back to you. Yeah, I agree. I think it can be addressed. [77:33] ICANN - MTS - A/V: Otherwise, I think what we're saying is that We think that. [77:40] ICANN - MTS - A/V: Compliance would look at a domain that's being used badly and say. [77:45] ICANN - MTS - A/V: Well, because we can't show for sure it was registered with that purpose in the first place, we're not going to enforce, and that doesn't make any sense to me. So, I think… [77:54] ICANN - MTS - A/V: We can pick up that point. [77:56] ICANN - MTS - A/V: implementation. [77:59] ICANN - MTS - A/V: Thank you. All right, we're going back to Mark. [78:04] ICANN - MTS - A/V: Mark Trachtenberg, IPC. [78:06] ICANN - MTS - A/V: I guess I would just generally caution against, like, let's not just try to take the easy way out and punt to compliance every time that we have a hard question, because I don't think that's fair or reasonable, and compliance may have a different view of whether they want to address this or handle it, and also… [78:18] ICANN - MTS - A/V: Compliance may come up with a view or solution that is very different from what many of the people or the consensus here would view as what the intent was, so… [78:26] ICANN - MTS - A/V: let's try to resolve what we can, and not just punt and say, oh, you know, I can, we'll do an advisory later. [78:33] ICANN - MTS - A/V: Now, Mark, that was my very first punt of the day. [78:38] ICANN - MTS - A/V: All right. Oh, Brian. [78:40] ICANN - MTS - A/V: Yeah, thanks, Paul. And Mark, I take your point, but at the same time, I think this, like some of the other issues that have been raised, are an issue with the current contract. It's not an issue as it relates to associated domain checks. It's an issue as it relates to malicious versus compromised. [78:54] ICANN - MTS - A/V: And so I take your point, and it's something that's worth discussing, but I don't think it's necessary. It's not really this group's job to solve the wider problem. [79:04] ICANN - MTS - A/V: You know, this is about associated domain check and the trigger, but I don't think we're in a position that we can, to the extent that is a hole, that we're going to solve that hole in 3.18.2. [79:15] ICANN - MTS - A/V: here. [79:18] ICANN - MTS - A/V: Thanks, Brian. Back to Mark. [79:20] ICANN - MTS - A/V: Mark Trachtenberg for the IPC. [79:22] ICANN - MTS - A/V: I don't disagree with you, I'm making a more general point. I'm just saying, generally, like, there's a tendency, I think, when we get to these hard questions, we're like, well, let's just leave it for an advisory later, and I don't think that's a reasonable, responsible way to do it, and I don't think it will end up with good results. I know compliance, I'm sure, doesn't love it. I'm not going to speak for Leticia or compliance or Jamie, but… [79:39] ICANN - MTS - A/V: you know, I'm sure they cringe every time. It's like, oh, now we have to decide this other issue, too, and do another advisory. Let's try to decide what we can, even with the hard questions. Let's try to get to the best result that we can. It will not be perfect, nothing is, but let's… and again, let's not make the perfect enemy the good, let's just try and do whatever we can, be as clear as we can. [79:57] ICANN - MTS - A/V: You know, under the existing framework and understanding how things change, and then where there's no other way to do it. [80:03] ICANN - MTS - A/V: Leave it for later, but let's try to be the edge case and not the default. [80:09] ICANN - MTS - A/V: Thanks, Mark. We're here from Fayetteville. [80:12] Feodora Hamza - ICANN Org: No. [80:14] ICANN - MTS - A/V: Hi everyone, just… [80:15] ICANN - MTS - A/V: If I understand the discussion correctly, just a little bit of working group history, where we discussed Recommendation 1. Initially, the group tried to, put language into what malicious [80:26] ICANN - MTS - A/V: registration or domain would mean, but ultimately landed on that that would be not helpful. It would be better to focus on what compromised domains deem in terms of exclusion, because if it's not compromised, then it would be the other one, ultimately, so that's why Recommendation 1 looked… looks the way it does, hope. [80:44] ICANN - MTS - A/V: This helps a bit. [80:46] ICANN - MTS - A/V: Thank you. [80:49] ICANN - MTS - A/V: Any other comments on this? [80:54] ICANN - MTS - A/V: All right, leadership will take that back and give that some pondering. [81:01] ICANN - MTS - A/V: All right. [81:04] ICANN - MTS - A/V: I didn't see anybody else come up from the crowd. I didn't see any other hands raised about any other issues for Rec 1… oh. [81:10] ICANN - MTS - A/V: Where is it? [81:13] ICANN - MTS - A/V: Is this working? Oh, it is working, Farzad Abadi. [81:17] ICANN - MTS - A/V: Non-commercial stakeholder group. It goes back to the, one of the beginning of the slides that you were showing. It's just a method. [81:26] ICANN - MTS - A/V: Of how you display and tell us, what sorts of support. [81:33] ICANN - MTS - A/V: The PDP recommendations have had… I, advise against saying that… [81:42] ICANN - MTS - A/V: 83% of the public comments supported the recommendations, so we are on the right track. [81:51] ICANN - MTS - A/V: maybe that 15% that had other opinions, maybe there are valid opinions, and maybe it doesn't mean that because the majority is supporting this, we are absolutely on the right tracks. It's just a matter of reframing how we [82:10] ICANN - MTS - A/V: Talk about the public comments and how we, assess the… [82:15] ICANN - MTS - A/V: positive. We don't really have to say, like, there was, like, this many positive comments. I mean, we do… we do our job. [82:23] ICANN - MTS - A/V: And we take people's concerns into account. [82:26] ICANN - MTS - A/V: Thank you. [82:30] ICANN - MTS - A/V: Thank you. [82:32] ICANN - MTS - A/V: Anyone else? [82:37] ICANN - MTS - A/V: Okay, well, let's not. [82:40] ICANN - MTS - A/V: belabor it. Great session, everybody. I thought it was very useful. And, we will, leadership will come back to, all of us in the next red line after [82:50] ICANN - MTS - A/V: ICANN87. We are going to meet when? Soon, it's on your calendar. And we're going to tackle 3 and 4. All right, thank you all. [83:04] ICANN - MTS - A/V: You can stop the recording. Official source: https://icann87.sched.com/event/2WjfB/gnso-dns-abuse-mitigation-pdp1-working-session-1-of-4 Revision: 1f2d960890b5e2dee68db5762d2179c669bfd2b53a5f9062e922ad80c8c5a131 Made by AgentCommunity // Balázs Némethi ## Source and processing provenance Release: a5927a53b9ef39f2958a61187665079c9843a7fc67e30af1e1996b59901a2919 Source retrieved: 2026-10-23T21:01:03.409996+00:00 Availability: null Processing: {"human_reviewed":false,"terminology":"llm_corrected","summary":"ai_generated","asr":"completed","semantic_check":"passed"} Coverage: {"primary_track":"captions","recording_seconds":4900.048875,"asr_segments":1000,"caption_segments":603,"gaps":[]} - The chair framed public-comment review as substantive clarification within the charter, with a target of final reading in November and Council submission in December. Evidence: {"quote":"So, we… today and tomorrow and Thursday, we're going to review comments in a structured way. We're going to focus on substance rather than preferred wording. By that, we mean","start":128.63,"cue_id":"cue-17","segment_id":17} - The chair framed public-comment review as substantive clarification within the charter, with a target of final reading in November and Council submission in December. Evidence: {"quote":"We are going to be identifying sensible changes that are also still within the Charter. We're not going to expand the universe at the last minute and consider things that are outside of the Charter. And through this process, document how pu","start":159.06,"cue_id":"cue-20","segment_id":20} - The chair framed public-comment review as substantive clarification within the charter, with a target of final reading in November and Council submission in December. Evidence: {"quote":"significantly, and, but don't raise new, new concepts. So, right now, we're in the public comment review. Our little running man here, we will update the final report and do a final read, hopefully in November.","start":203.57999999999998,"cue_id":"cue-23","segment_id":23} - The chair framed public-comment review as substantive clarification within the charter, with a target of final reading in November and Council submission in December. Evidence: {"quote":"At the end of November and early December, if we are on track, we will have a consensus call on the final report, and we will submit this final report","start":219.78,"cue_id":"cue-24","segment_id":24} - The chair framed public-comment review as substantive clarification within the charter, with a target of final reading in November and Council submission in December. Evidence: {"quote":"to Council in December for their, consideration. So that is the…","start":228.57,"cue_id":"cue-25","segment_id":25} - Legitimate or benign was removed from the proposed compromised-domain definition, but the person whose knowledge or consent should count remained unsettled. Evidence: {"quote":"Okay, off goes legitimate or benign.","start":2240.73,"cue_id":"cue-257","segment_id":257} - Legitimate or benign was removed from the proposed compromised-domain definition, but the person whose knowledge or consent should count remained unsettled. Evidence: {"quote":"that doesn't accomplish the goal. It misses the mark. The intent is the person who is controlling, whether you want to call them the owner, whatever, the beneficial user, the customer of the registrar or reseller. It's that person. That per","start":2586.49,"cue_id":"cue-298","segment_id":298} - Legitimate or benign was removed from the proposed compromised-domain definition, but the person whose knowledge or consent should count remained unsettled. Evidence: {"quote":"The account holder doesn't hit the mark here, and I would like to explain why. When we added that terminology to the RA8 back in 2012-2013,","start":2917.71,"cue_id":"cue-337","segment_id":337} - Legitimate or benign was removed from the proposed compromised-domain definition, but the person whose knowledge or consent should count remained unsettled. Evidence: {"quote":"Thanks, Mark. All right, we have Gabriel, and then I'm gonna say, if you want to say something else about this, get in the queue. But I feel comfortable that leadership and staff have what they need to come back with a proposal on this, in,","start":3088.69,"cue_id":"cue-357","segment_id":357} - Legitimate or benign was removed from the proposed compromised-domain definition, but the person whose knowledge or consent should count remained unsettled. Evidence: {"quote":"As a suggestion, you could make it really simple and say a compromised domain means a domain name that's used by an unauthorized party as a vector for DNS abuse.","start":3172.24,"cue_id":"cue-364","segment_id":364} - Participants disputed checks across commonly controlled registrars; reasonably accessible information emerged as a possible bridge without an adopted cross-registrar requirement. Evidence: {"quote":"briefly touch on inter-registrar checks, and determined very, very early that those were outside of the scope of the Charter, and that's one of the reasons why this… that particular comment was not baked into our proposed changes.","start":3524.37,"cue_id":"cue-411","segment_id":411} - Participants disputed checks across commonly controlled registrars; reasonably accessible information emerged as a possible bridge without an adopted cross-registrar requirement. Evidence: {"quote":"would create an additional burden on those registrars that is currently not foreseen, and that probably would be out of scope for the PDP.","start":3739.15,"cue_id":"cue-433","segment_id":433} - Participants disputed checks across commonly controlled registrars; reasonably accessible information emerged as a possible bridge without an adopted cross-registrar requirement. Evidence: {"quote":"hey, here's the domain name, here's the information, do the ADC check, you could also just send that information to all the other registrars that are under your common control. And even if they have different systems, just like with a resel","start":3799.74,"cue_id":"cue-442","segment_id":442} - Participants disputed checks across commonly controlled registrars; reasonably accessible information emerged as a possible bridge without an adopted cross-registrar requirement. Evidence: {"quote":"You do not want to create a loophole where people would stop looking just because it happens to be under a different accreditation.","start":3881.02,"cue_id":"cue-452","segment_id":452} - Participants disputed checks across commonly controlled registrars; reasonably accessible information emerged as a possible bridge without an adopted cross-registrar requirement. Evidence: {"quote":"And so, the thing that I would suggest might actually bridge that gap is what's in, I think it's Recommendation 3, is what evidence is reasonably accessible.","start":4111.359,"cue_id":"cue-479","segment_id":479} - Participants disputed checks across commonly controlled registrars; reasonably accessible information emerged as a possible bridge without an adopted cross-registrar requirement. Evidence: {"quote":"then, arguably, that information is reasonably accessible to you, right? And so, I think that we may have solved the problem by that reasonable, accessible thing, and we may want to leave it undisturbed, because it sounds like","start":4247.96,"cue_id":"cue-494","segment_id":494} - Participants disputed checks across commonly controlled registrars; reasonably accessible information emerged as a possible bridge without an adopted cross-registrar requirement. Evidence: {"quote":"Okay. I'm gonna call for last comments on this. I think staff and leadership have what they need to mess around with this.","start":4316.56,"cue_id":"cue-504","segment_id":504} - Malicious acquisition and leasing concerns were referred back to leadership; the session also heard a warning against using majority comment support to dismiss minority concerns. Evidence: {"quote":"And I think that was something I hadn't previously considered, and I found that to be a very insightful comment to make. And I think that the only real repercussion it has on this document is sometimes we're using the term maliciously regis","start":4442.68,"cue_id":"cue-526","segment_id":526} - Malicious acquisition and leasing concerns were referred back to leadership; the session also heard a warning against using majority comment support to dismiss minority concerns. Evidence: {"quote":"leasing it to another party, and that party ends up using it maliciously, or that domain gets compromised. That could be a very unfortunate circumstance here, where you've got, you know, to take action on a domain. You've got an innocent pa","start":4494.56,"cue_id":"cue-534","segment_id":534} - Malicious acquisition and leasing concerns were referred back to leadership; the session also heard a warning against using majority comment support to dismiss minority concerns. Evidence: {"quote":"All right, leadership will take that back and give that some pondering.","start":4854.56,"cue_id":"cue-583","segment_id":583} - Malicious acquisition and leasing concerns were referred back to leadership; the session also heard a warning against using majority comment support to dismiss minority concerns. Evidence: {"quote":"83% of the public comments supported the recommendations, so we are on the right track.","start":4902.36,"cue_id":"cue-591","segment_id":591} - Malicious acquisition and leasing concerns were referred back to leadership; the session also heard a warning against using majority comment support to dismiss minority concerns. Evidence: {"quote":"maybe that 15% that had other opinions, maybe there are valid opinions, and maybe it doesn't mean that because the majority is supporting this, we are absolutely on the right tracks. It's just a matter of reframing how we","start":4911.39,"cue_id":"cue-592","segment_id":592} - The chair reported 42 submissions, 85% supportive inputs, about 3% seeking significant changes and 12% other or no position, with no request to delete a recommendation. Farzaneh later cautioned that majority support does not prove the group is on the right track and minority views may be valid. Evidence: {"quote":"hit these fairly quick, or are you gonna hit these? I can hit these? Okay. So, here's the snapshot of the outcome. We had 42 submissions. I think that's pretty robust for a niche policy.","start":264.16,"cue_id":"cue-31","segment_id":31} - The chair reported 42 submissions, 85% supportive inputs, about 3% seeking significant changes and 12% other or no position, with no request to delete a recommendation. Farzaneh later cautioned that majority support does not prove the group is on the right track and minority views may be valid. Evidence: {"quote":"one thing incredibly well, as opposed to, like, something like the SubPro PDP, which was not a niche policy. So 42 submissions, 85% of the inputs, were supportive of the initial report. That was good to see.","start":281.4,"cue_id":"cue-33","segment_id":33} - The chair reported 42 submissions, 85% supportive inputs, about 3% seeking significant changes and 12% other or no position, with no request to delete a recommendation. Farzaneh later cautioned that majority support does not prove the group is on the right track and minority views may be valid. Evidence: {"quote":"About 3% requested significant changes. 12% were like other comments or no position taken.","start":297.03,"cue_id":"cue-34","segment_id":34} - The chair reported 42 submissions, 85% supportive inputs, about 3% seeking significant changes and 12% other or no position, with no request to delete a recommendation. Farzaneh later cautioned that majority support does not prove the group is on the right track and minority views may be valid. Evidence: {"quote":"So that's good. And we did not receive any comments saying that any recommendations should be deleted. So, sounds like we landed on the right things, and so, that is… that's good. Here's a giant chart. I encourage you to read this. I'm not ","start":331.13,"cue_id":"cue-38","segment_id":38} - The chair reported 42 submissions, 85% supportive inputs, about 3% seeking significant changes and 12% other or no position, with no request to delete a recommendation. Farzaneh later cautioned that majority support does not prove the group is on the right track and minority views may be valid. Evidence: {"quote":"83% of the public comments supported the recommendations, so we are on the right track.","start":4902.36,"cue_id":"cue-591","segment_id":591} - The chair reported 42 submissions, 85% supportive inputs, about 3% seeking significant changes and 12% other or no position, with no request to delete a recommendation. Farzaneh later cautioned that majority support does not prove the group is on the right track and minority views may be valid. Evidence: {"quote":"maybe that 15% that had other opinions, maybe there are valid opinions, and maybe it doesn't mean that because the majority is supporting this, we are absolutely on the right tracks. It's just a matter of reframing how we","start":4911.39,"cue_id":"cue-592","segment_id":592} - The chair reported 42 submissions, 85% supportive inputs, about 3% seeking significant changes and 12% other or no position, with no request to delete a recommendation. Farzaneh later cautioned that majority support does not prove the group is on the right track and minority views may be valid. Evidence: {"quote":"And we take people's concerns into account.","start":4943.19,"cue_id":"cue-595","segment_id":595} - The proposed compromised-domain definition used knowledge or consent of the registered name holder. Mark challenged legitimate or benign as unnecessary; the chair also worried those words could invite content judgments under jurisdictional pressure. Michaela wanted a definition but was not tied to those exact words. Evidence: {"quote":"I'm just gonna read it, and then I'm gonna open the floor for reactions. A compromised domain means a legitimate or benign domain name is used as a vector for DNS abuse without the knowledge or consent of the registered name holder.","start":806.46,"cue_id":"cue-87","segment_id":87} - The proposed compromised-domain definition used knowledge or consent of the registered name holder. Mark challenged legitimate or benign as unnecessary; the chair also worried those words could invite content judgments under jurisdictional pressure. Michaela wanted a definition but was not tied to those exact words. Evidence: {"quote":"Like, what does legitimate or benign mean? That's not necessary. I think you could just say a domain name.","start":895.84,"cue_id":"cue-97","segment_id":97} - The proposed compromised-domain definition used knowledge or consent of the registered name holder. Mark challenged legitimate or benign as unnecessary; the chair also worried those words could invite content judgments under jurisdictional pressure. Michaela wanted a definition but was not tied to those exact words. Evidence: {"quote":"And once we get into legitimate or benign, what does that mean for a registrar? What if they're in a jurisdiction that doesn't particularly like your content?","start":2020.27,"cue_id":"cue-228","segment_id":228} - The proposed compromised-domain definition used knowledge or consent of the registered name holder. Mark challenged legitimate or benign as unnecessary; the chair also worried those words could invite content judgments under jurisdictional pressure. Michaela wanted a definition but was not tied to those exact words. Evidence: {"quote":"and decides that you're not legitimate. What happens if a registrar is in a jurisdiction that doesn't make your comments terribly benign.","start":2028.64,"cue_id":"cue-229","segment_id":229} - The proposed compromised-domain definition used knowledge or consent of the registered name holder. Mark challenged legitimate or benign as unnecessary; the chair also worried those words could invite content judgments under jurisdictional pressure. Michaela wanted a definition but was not tied to those exact words. Evidence: {"quote":"those exact terms. I think the concern for the NCSG is not having a definition at all. So, you know, again, if the key concern is about legitimate.","start":2082.02,"cue_id":"cue-238","segment_id":238} - The proposed compromised-domain definition used knowledge or consent of the registered name holder. Mark challenged legitimate or benign as unnecessary; the chair also worried those words could invite content judgments under jurisdictional pressure. Michaela wanted a definition but was not tied to those exact words. Evidence: {"quote":"that perhaps we don't have to be tied to that term, if that's problematic, but again, I think the key point for the non-commercial group is that we don't want to have no definition at all.","start":2094.12,"cue_id":"cue-239","segment_id":239} - Mark and Gabriel warned that a privacy/proxy service might be the registered name holder without knowing the customer’s use, undermining the exclusion. Reg urged leaving established RNH definitions to the appropriate PDPs; Martina favored existing definitions and potentially an advisory with scenarios. Evidence: {"quote":"you know, as a vector for DNS abuse without the knowledge or consent of the… and here's the second issue, registered name holder, I think is problematic, because in a lot of cases, the registered name holder could be the privacy service or ","start":900.67,"cue_id":"cue-98","segment_id":98} - Mark and Gabriel warned that a privacy/proxy service might be the registered name holder without knowing the customer’s use, undermining the exclusion. Reg urged leaving established RNH definitions to the appropriate PDPs; Martina favored existing definitions and potentially an advisory with scenarios. Evidence: {"quote":"This is Gabriel Andrews, with GAC. So, a couple points to make. One is I plus one Mark's concern with regards to the language of registered name holder. I think that that is something that needs to be considered for use cases where you have","start":1195.59,"cue_id":"cue-136","segment_id":136} - Mark and Gabriel warned that a privacy/proxy service might be the registered name holder without knowing the customer’s use, undermining the exclusion. Reg urged leaving established RNH definitions to the appropriate PDPs; Martina favored existing definitions and potentially an advisory with scenarios. Evidence: {"quote":"So I don't know if we are all happy with the definition, with the approach that we had before, and we don't want to renegotiate a new definition here. Maybe what we could do is to provide more guidance in a newly suggested advisory.","start":1919.37,"cue_id":"cue-213","segment_id":213} - Mark and Gabriel warned that a privacy/proxy service might be the registered name holder without knowing the customer’s use, undermining the exclusion. Reg urged leaving established RNH definitions to the appropriate PDPs; Martina favored existing definitions and potentially an advisory with scenarios. Evidence: {"quote":"But if it is the case that RNH is no longer sufficient to determine the RNH, then that is a determination that belongs to a different PDP, and not ours to change.","start":2395.59,"cue_id":"cue-276","segment_id":276} - Mark and Gabriel warned that a privacy/proxy service might be the registered name holder without knowing the customer’s use, undermining the exclusion. Reg urged leaving established RNH definitions to the appropriate PDPs; Martina favored existing definitions and potentially an advisory with scenarios. Evidence: {"quote":"And if we leave it as RNH here, then that means that it will naturally change when those PDPs come up with a different definition.","start":2424.09,"cue_id":"cue-280","segment_id":280} - Mark and Gabriel warned that a privacy/proxy service might be the registered name holder without knowing the customer’s use, undermining the exclusion. Reg urged leaving established RNH definitions to the appropriate PDPs; Martina favored existing definitions and potentially an advisory with scenarios. Evidence: {"quote":"we need to root into existing definitions, and it's not for us to define or invent a definition of compromised domain names, because if we want to finish this PDP in December, I assure you that it's not in our interest to spend the next 3 m","start":2451.72,"cue_id":"cue-284","segment_id":284} - Mark and Gabriel warned that a privacy/proxy service might be the registered name holder without knowing the customer’s use, undermining the exclusion. Reg urged leaving established RNH definitions to the appropriate PDPs; Martina favored existing definitions and potentially an advisory with scenarios. Evidence: {"quote":"And their proxy service is the RNH. And they could, if they wanted to, make the case then that all registrations that are used for abuse thereafter are done without the knowledge of the RNH.","start":3136.19,"cue_id":"cue-361","segment_id":361} - Mark and Gabriel warned that a privacy/proxy service might be the registered name holder without knowing the customer’s use, undermining the exclusion. Reg urged leaving established RNH definitions to the appropriate PDPs; Martina favored existing definitions and potentially an advisory with scenarios. Evidence: {"quote":"Right? And so so that is why he's saying that this is important, because otherwise it's just a a huge loophole for anyone that turns on proxy by default. Now.","start":3149.68,"cue_id":"cue-362","segment_id":362} - The chair floated the RAA account-holder definition. Mark initially welcomed it, but Reg and Volker explained that the payer or reseller need not control the domain’s use. Gabriel proposed defining compromise through use by an unauthorized party, with leadership to bring back a proposal. Evidence: {"quote":"And the account holder means the person or entity that is paying for the registered name, or otherwise controls the management of the registered name, when that person or entity is not the registered name holder.","start":2630.66,"cue_id":"cue-304","segment_id":304} - The chair floated the RAA account-holder definition. Mark initially welcomed it, but Reg and Volker explained that the payer or reseller need not control the domain’s use. Gabriel proposed defining compromise through use by an unauthorized party, with leadership to bring back a proposal. Evidence: {"quote":"Mark Dragtemberg from the IPC. I think that would work. I'd have to go look at that language, but that sounds right, that sounds like what we're trying to accomplish, and if that definition already exists, then fantastic. Then we address al","start":2649.1,"cue_id":"cue-306","segment_id":306} - The chair floated the RAA account-holder definition. Mark initially welcomed it, but Reg and Volker explained that the payer or reseller need not control the domain’s use. Gabriel proposed defining compromise through use by an unauthorized party, with leadership to bring back a proposal. Evidence: {"quote":"Account holder is very different from RNH. I think we added, as I recall, account holder was added so that if it's a reseller.","start":2843.57,"cue_id":"cue-328","segment_id":328} - The chair floated the RAA account-holder definition. Mark initially welcomed it, but Reg and Volker explained that the payer or reseller need not control the domain’s use. Gabriel proposed defining compromise through use by an unauthorized party, with leadership to bring back a proposal. Evidence: {"quote":"you, my good friend Paul, buy a domain for me, and I set it up for you because I'm a real reseller now, at Two Cows. I don't know what you're doing with it, right? It's not… you just pay me. That's all that happens. So that's not the releva","start":2885.28,"cue_id":"cue-334","segment_id":334} - The chair floated the RAA account-holder definition. Mark initially welcomed it, but Reg and Volker explained that the payer or reseller need not control the domain’s use. Gabriel proposed defining compromise through use by an unauthorized party, with leadership to bring back a proposal. Evidence: {"quote":"The account holder doesn't hit the mark here, and I would like to explain why. When we added that terminology to the RA8 back in 2012-2013,","start":2917.71,"cue_id":"cue-337","segment_id":337} - The chair floated the RAA account-holder definition. Mark initially welcomed it, but Reg and Volker explained that the payer or reseller need not control the domain’s use. Gabriel proposed defining compromise through use by an unauthorized party, with leadership to bring back a proposal. Evidence: {"quote":"This was understood to mean the person paying the domain name at the registrar. This is the reseller, for example. This is the web hosting provider that is registering the domain name on behalf of its clients. This is the party that comes t","start":2929.56,"cue_id":"cue-338","segment_id":338} - The chair floated the RAA account-holder definition. Mark initially welcomed it, but Reg and Volker explained that the payer or reseller need not control the domain’s use. Gabriel proposed defining compromise through use by an unauthorized party, with leadership to bring back a proposal. Evidence: {"quote":"keep data off, not the use trail, and therefore I would urge not to use that here.","start":2977.97,"cue_id":"cue-343","segment_id":343} - The chair floated the RAA account-holder definition. Mark initially welcomed it, but Reg and Volker explained that the payer or reseller need not control the domain’s use. Gabriel proposed defining compromise through use by an unauthorized party, with leadership to bring back a proposal. Evidence: {"quote":"Thanks, Mark. All right, we have Gabriel, and then I'm gonna say, if you want to say something else about this, get in the queue. But I feel comfortable that leadership and staff have what they need to come back with a proposal on this, in,","start":3088.69,"cue_id":"cue-357","segment_id":357} - The chair floated the RAA account-holder definition. Mark initially welcomed it, but Reg and Volker explained that the payer or reseller need not control the domain’s use. Gabriel proposed defining compromise through use by an unauthorized party, with leadership to bring back a proposal. Evidence: {"quote":"As a suggestion, you could make it really simple and say a compromised domain means a domain name that's used by an unauthorized party as a vector for DNS abuse.","start":3172.24,"cue_id":"cue-364","segment_id":364} - NCSG pressed for a clear exclusion or stronger safeguards so innocent registrants are not swept into ADC profiling. Registry and registrar speakers pointed to existing RAA obligations, contractual compliance and collateral-damage considerations, warning against inconsistent ADC-specific definitions. Evidence: {"quote":"raised concerns that this policy could entangle innocent people that, that have had no role in the, in the DNS abuse to be surveyed on and to have their contact.","start":1406.08,"cue_id":"cue-155","segment_id":155} - NCSG pressed for a clear exclusion or stronger safeguards so innocent registrants are not swept into ADC profiling. Registry and registrar speakers pointed to existing RAA obligations, contractual compliance and collateral-damage considerations, warning against inconsistent ADC-specific definitions. Evidence: {"quote":"in the, scope of this group work, and… and we also said that that is not a safeguard. We need to have better safeguards in place. So it's either that we have a very clear","start":1434.63,"cue_id":"cue-158","segment_id":158} - NCSG pressed for a clear exclusion or stronger safeguards so innocent registrants are not swept into ADC profiling. Registry and registrar speakers pointed to existing RAA obligations, contractual compliance and collateral-damage considerations, warning against inconsistent ADC-specific definitions. Evidence: {"quote":"way of defining compromised domains, and not entangle them in this ADC, policy.","start":1451.33,"cue_id":"cue-159","segment_id":159} - NCSG pressed for a clear exclusion or stronger safeguards so innocent registrants are not swept into ADC profiling. Registry and registrar speakers pointed to existing RAA obligations, contractual compliance and collateral-damage considerations, warning against inconsistent ADC-specific definitions. Evidence: {"quote":"Or we will have… we will have to have better safeguards, higher investigative thresholds and all that that we have been asking for since the beginning of the policy.","start":1462.12,"cue_id":"cue-160","segment_id":160} - NCSG pressed for a clear exclusion or stronger safeguards so innocent registrants are not swept into ADC profiling. Registry and registrar speakers pointed to existing RAA obligations, contractual compliance and collateral-damage considerations, warning against inconsistent ADC-specific definitions. Evidence: {"quote":"maliciously registered domain, and they say for some sort of BS reason that they think it was compromised, then that would run afoul of the registrar accreditation agreement, and that… it would be no different in this case. So, I don't thin","start":1543.04,"cue_id":"cue-167","segment_id":167} - NCSG pressed for a clear exclusion or stronger safeguards so innocent registrants are not swept into ADC profiling. Registry and registrar speakers pointed to existing RAA obligations, contractual compliance and collateral-damage considerations, warning against inconsistent ADC-specific definitions. Evidence: {"quote":"the way to address that, and it's ICANN contractual compliance. So.","start":1566.62,"cue_id":"cue-168","segment_id":168} - NCSG pressed for a clear exclusion or stronger safeguards so innocent registrants are not swept into ADC profiling. Registry and registrar speakers pointed to existing RAA obligations, contractual compliance and collateral-damage considerations, warning against inconsistent ADC-specific definitions. Evidence: {"quote":"a certain safeguard embedded when it says that the possibility of associated collateral damage should be taken into account when taking action. Now, we would assume that this would also apply to the ADCs, obviously, when we get a report, th","start":1655.04,"cue_id":"cue-180","segment_id":180} - NCSG pressed for a clear exclusion or stronger safeguards so innocent registrants are not swept into ADC profiling. Registry and registrar speakers pointed to existing RAA obligations, contractual compliance and collateral-damage considerations, warning against inconsistent ADC-specific definitions. Evidence: {"quote":"definition here just for ADC, because it ultimately risks of having different, standards that would apply to general abuse checks and ADCs, and that would just cause confusion. So we should always fall back on the general, regulation that i","start":1686.61,"cue_id":"cue-184","segment_id":184} - Leadership proposed clarifying that actionable evidence can come from registrar analysis or external sources, and that intermittent or recurring abuse must have sufficient information to support a reasonable determination. Volker objected that this governed DNS abuse beyond this PDP; the chair said actionable evidence had already been discussed and moved on. Evidence: {"quote":"Actionable evidence may be identified through the registrar's own analysis or received from an external source.","start":3238.84,"cue_id":"cue-373","segment_id":373} - Leadership proposed clarifying that actionable evidence can come from registrar analysis or external sources, and that intermittent or recurring abuse must have sufficient information to support a reasonable determination. Volker objected that this governed DNS abuse beyond this PDP; the chair said actionable evidence had already been discussed and moved on. Evidence: {"quote":"Consistent with existing contractual obligations.","start":3246.09,"cue_id":"cue-374","segment_id":374} - Leadership proposed clarifying that actionable evidence can come from registrar analysis or external sources, and that intermittent or recurring abuse must have sufficient information to support a reasonable determination. Volker objected that this governed DNS abuse beyond this PDP; the chair said actionable evidence had already been discussed and moved on. Evidence: {"quote":"Where the reported DNS abuse is intermittent, recurring, or otherwise not continuously observable, the information provided should be sufficient to support a reasonable determination of the alleged abusive activity consistent with the appli","start":3249.64,"cue_id":"cue-375","segment_id":375} - Leadership proposed clarifying that actionable evidence can come from registrar analysis or external sources, and that intermittent or recurring abuse must have sufficient information to support a reasonable determination. Volker objected that this governed DNS abuse beyond this PDP; the chair said actionable evidence had already been discussed and moved on. Evidence: {"quote":"Yeah, I still feel that this basically creates, definitions and obligations that govern the entire.","start":3288.16,"cue_id":"cue-378","segment_id":378} - Leadership proposed clarifying that actionable evidence can come from registrar analysis or external sources, and that intermittent or recurring abuse must have sufficient information to support a reasonable determination. Volker objected that this governed DNS abuse beyond this PDP; the chair said actionable evidence had already been discussed and moved on. Evidence: {"quote":"field of DNS abuse, not just what happens when DNS abuse is detected. This goes beyond the scope of this PDP, in my view.","start":3297.11,"cue_id":"cue-379","segment_id":379} - Leadership proposed clarifying that actionable evidence can come from registrar analysis or external sources, and that intermittent or recurring abuse must have sufficient information to support a reasonable determination. Volker objected that this governed DNS abuse beyond this PDP; the chair said actionable evidence had already been discussed and moved on. Evidence: {"quote":"So, Volker, we already… we already address actionable evidence, and we've talked about it a lot. I can quote the","start":3310.14,"cue_id":"cue-381","segment_id":381} - Leadership proposed clarifying that actionable evidence can come from registrar analysis or external sources, and that intermittent or recurring abuse must have sufficient information to support a reasonable determination. Volker objected that this governed DNS abuse beyond this PDP; the chair said actionable evidence had already been discussed and moved on. Evidence: {"quote":"All right. Well, you know I, for one, am never going to look the gift horse in the mouth moving on.","start":3332.07,"cue_id":"cue-386","segment_id":386} - The Recommendation 2 grammatical and consistency update referred to a reasonable investigation and Recommendations 1 and 3–8. The chair saw no hands when asking about that tweak; a separate affiliated-registrar discussion then followed. Evidence: {"quote":"Again, for discussion, a registrar must perform a reasonable investigation in order to determine whether or not associated domains of the trigger domain name of the trigger domain are being used for DNS abuse as defined in 3.18.1 of the RAA","start":3387.29,"cue_id":"cue-392","segment_id":392} - The Recommendation 2 grammatical and consistency update referred to a reasonable investigation and Recommendations 1 and 3–8. The chair saw no hands when asking about that tweak; a separate affiliated-registrar discussion then followed. Evidence: {"quote":"Consistent with Recommendation 1, referring back to the trigger, as well as Recommendations 3 through 8.","start":3406.34,"cue_id":"cue-393","segment_id":393} - The Recommendation 2 grammatical and consistency update referred to a reasonable investigation and Recommendations 1 and 3–8. The chair saw no hands when asking about that tweak; a separate affiliated-registrar discussion then followed. Evidence: {"quote":"Any concerns about this?","start":3416.48,"cue_id":"cue-394","segment_id":394} - The Recommendation 2 grammatical and consistency update referred to a reasonable investigation and Recommendations 1 and 3–8. The chair saw no hands when asking about that tweak; a separate affiliated-registrar discussion then followed. Evidence: {"quote":"Town of Portsmouth, I'm seeing no hands.","start":3428.91,"cue_id":"cue-397","segment_id":397} - The Recommendation 2 grammatical and consistency update referred to a reasonable investigation and Recommendations 1 and 3–8. The chair saw no hands when asking about that tweak; a separate affiliated-registrar discussion then followed. Evidence: {"quote":"Yeah, with respect to recommendation 2. But a different part of that I noted in my review of public comment. There was a very interesting point raised by Mog.","start":3449.93,"cue_id":"cue-402","segment_id":402} - Gabriel raised a public-comment proposal for affiliated-registrar ADCs. Leadership considered inter-registrar checks outside the charter; Reg questioned feasibility and Volker described separate systems after acquisitions. Mark suggested requesting checks across related registrars, and Rod warned against ignoring other accreditations already visible on the same system. Evidence: {"quote":"However, the draft states that this policy only requires an ADC within a registrar portfolio, and does not require cross-registrar checks or coordination.","start":3470.26,"cue_id":"cue-405","segment_id":405} - Gabriel raised a public-comment proposal for affiliated-registrar ADCs. Leadership considered inter-registrar checks outside the charter; Reg questioned feasibility and Volker described separate systems after acquisitions. Mark suggested requesting checks across related registrars, and Rod warned against ignoring other accreditations already visible on the same system. Evidence: {"quote":"When an ADC is triggered at one of those registrars. And I found that was a point that hadn't been discussed by our group before, but I think that it was a valid expectation that when there's multiple registrar portfolios all controlled by ","start":3496.86,"cue_id":"cue-408","segment_id":408} - Gabriel raised a public-comment proposal for affiliated-registrar ADCs. Leadership considered inter-registrar checks outside the charter; Reg questioned feasibility and Volker described separate systems after acquisitions. Mark suggested requesting checks across related registrars, and Rod warned against ignoring other accreditations already visible on the same system. Evidence: {"quote":"briefly touch on inter-registrar checks, and determined very, very early that those were outside of the scope of the Charter, and that's one of the reasons why this… that particular comment was not baked into our proposed changes.","start":3524.37,"cue_id":"cue-411","segment_id":411} - Gabriel raised a public-comment proposal for affiliated-registrar ADCs. Leadership considered inter-registrar checks outside the charter; Reg questioned feasibility and Volker described separate systems after acquisitions. Mark suggested requesting checks across related registrars, and Rod warned against ignoring other accreditations already visible on the same system. Evidence: {"quote":"Right now, we're focusing on accounts, and that is something that we've agreed that we can do. It's gonna be hard for some of the registrars, but trying to do that in a cross-registrar manner.","start":3594.62,"cue_id":"cue-419","segment_id":419} - Gabriel raised a public-comment proposal for affiliated-registrar ADCs. Leadership considered inter-registrar checks outside the charter; Reg questioned feasibility and Volker described separate systems after acquisitions. Mark suggested requesting checks across related registrars, and Rod warned against ignoring other accreditations already visible on the same system. Evidence: {"quote":"Or cross-registryment? Like, I really don't understand. I understand why this was raised, but I don't understand the actual means of getting registrars to do it.","start":3610.96,"cue_id":"cue-420","segment_id":420} - Gabriel raised a public-comment proposal for affiliated-registrar ADCs. Leadership considered inter-registrar checks outside the charter; Reg questioned feasibility and Volker described separate systems after acquisitions. Mark suggested requesting checks across related registrars, and Rod warned against ignoring other accreditations already visible on the same system. Evidence: {"quote":"Because, while some registrars that have affiliated registrars are all managing them in one system and in one team, others that have, especially when they have grown through acquisitions,","start":3705.16,"cue_id":"cue-430","segment_id":430} - Gabriel raised a public-comment proposal for affiliated-registrar ADCs. Leadership considered inter-registrar checks outside the charter; Reg questioned feasibility and Volker described separate systems after acquisitions. Mark suggested requesting checks across related registrars, and Rod warned against ignoring other accreditations already visible on the same system. Evidence: {"quote":"are very much operated as independent entities that are… just happen to be under common control. And for those, expecting, a common… a check of associated domain names.","start":3719.1,"cue_id":"cue-431","segment_id":431} - Gabriel raised a public-comment proposal for affiliated-registrar ADCs. Leadership considered inter-registrar checks outside the charter; Reg questioned feasibility and Volker described separate systems after acquisitions. Mark suggested requesting checks across related registrars, and Rod warned against ignoring other accreditations already visible on the same system. Evidence: {"quote":"would create an additional burden on those registrars that is currently not foreseen, and that probably would be out of scope for the PDP.","start":3739.15,"cue_id":"cue-433","segment_id":433} - Gabriel raised a public-comment proposal for affiliated-registrar ADCs. Leadership considered inter-registrar checks outside the charter; Reg questioned feasibility and Volker described separate systems after acquisitions. Mark suggested requesting checks across related registrars, and Rod warned against ignoring other accreditations already visible on the same system. Evidence: {"quote":"hey, here's the domain name, here's the information, do the ADC check, you could also just send that information to all the other registrars that are under your common control. And even if they have different systems, just like with a resel","start":3799.74,"cue_id":"cue-442","segment_id":442} - Gabriel raised a public-comment proposal for affiliated-registrar ADCs. Leadership considered inter-registrar checks outside the charter; Reg questioned feasibility and Volker described separate systems after acquisitions. Mark suggested requesting checks across related registrars, and Rod warned against ignoring other accreditations already visible on the same system. Evidence: {"quote":"And you may have disparate systems where it would be very difficult to do a cross-check. Others, they're on the same exact system at the same point, where the abuse desk is looking at it all across, has access to that information.","start":3864.91,"cue_id":"cue-450","segment_id":450} - Gabriel raised a public-comment proposal for affiliated-registrar ADCs. Leadership considered inter-registrar checks outside the charter; Reg questioned feasibility and Volker described separate systems after acquisitions. Mark suggested requesting checks across related registrars, and Rod warned against ignoring other accreditations already visible on the same system. Evidence: {"quote":"You do not want to create a loophole where people would stop looking just because it happens to be under a different accreditation.","start":3881.02,"cue_id":"cue-452","segment_id":452} - Brian distinguished a single operation using many accreditation credentials from related businesses with separate systems. He suggested the reasonably accessible evidence standard could bridge those cases; the chair saw promise, while Mark asked how compliance would know the actual system arrangement. Evidence: {"quote":"And so it's effectively one business operation, but you might have 50 different registrar credentials, but really it's one business line that you're interacting with, as opposed to other registrars where there might be common ownership, whe","start":4070.06,"cue_id":"cue-476","segment_id":476} - Brian distinguished a single operation using many accreditation credentials from related businesses with separate systems. He suggested the reasonably accessible evidence standard could bridge those cases; the chair saw promise, while Mark asked how compliance would know the actual system arrangement. Evidence: {"quote":"all under the same corporate umbrella that have really different operational structures. So.","start":4091.23,"cue_id":"cue-477","segment_id":477} - Brian distinguished a single operation using many accreditation credentials from related businesses with separate systems. He suggested the reasonably accessible evidence standard could bridge those cases; the chair saw promise, while Mark asked how compliance would know the actual system arrangement. Evidence: {"quote":"you kind of think, like, well, in one situation, that might be reasonable, that for the Brian's Registrar example, perhaps an ADC should be conducted, whereas that second example, it gets trickier. You might have different teams running dif","start":4096.85,"cue_id":"cue-478","segment_id":478} - Brian distinguished a single operation using many accreditation credentials from related businesses with separate systems. He suggested the reasonably accessible evidence standard could bridge those cases; the chair saw promise, while Mark asked how compliance would know the actual system arrangement. Evidence: {"quote":"And so, the thing that I would suggest might actually bridge that gap is what's in, I think it's Recommendation 3, is what evidence is reasonably accessible.","start":4111.359,"cue_id":"cue-479","segment_id":479} - Brian distinguished a single operation using many accreditation credentials from related businesses with separate systems. He suggested the reasonably accessible evidence standard could bridge those cases; the chair saw promise, while Mark asked how compliance would know the actual system arrangement. Evidence: {"quote":"And so, in the Brian's Registrar example, you're very likely to have the same compliance team overseeing all 50 registrars under that umbrella, whereas the other example, where you have really fundamentally different operations, the informa","start":4120.14,"cue_id":"cue-480","segment_id":480} - Brian distinguished a single operation using many accreditation credentials from related businesses with separate systems. He suggested the reasonably accessible evidence standard could bridge those cases; the chair saw promise, while Mark asked how compliance would know the actual system arrangement. Evidence: {"quote":"then, arguably, that information is reasonably accessible to you, right? And so, I think that we may have solved the problem by that reasonable, accessible thing, and we may want to leave it undisturbed, because it sounds like","start":4247.96,"cue_id":"cue-494","segment_id":494} - Brian distinguished a single operation using many accreditation credentials from related businesses with separate systems. He suggested the reasonably accessible evidence standard could bridge those cases; the chair saw promise, while Mark asked how compliance would know the actual system arrangement. Evidence: {"quote":"I think what you're saying makes sense, but the question is, from a practical perspective, does ICANN compliance have access to that information? Do they know how the system… how the registrar is running? And I think the answer is probably ","start":4280.19,"cue_id":"cue-498","segment_id":498} - Brian distinguished a single operation using many accreditation credentials from related businesses with separate systems. He suggested the reasonably accessible evidence standard could bridge those cases; the chair saw promise, while Mark asked how compliance would know the actual system arrangement. Evidence: {"quote":"Okay. I'm gonna call for last comments on this. I think staff and leadership have what they need to mess around with this.","start":4316.56,"cue_id":"cue-504","segment_id":504} - Gabriel said maliciously registered misses later acquisition of existing domains; Jothan raised leasing and innocent lessors or lessees. Chris warned against over-definition, Michaela suggested an advisory scenario, and Mark urged resolving hard policy questions rather than routinely deferring them to compliance. Staff recalled that the group had chosen the compromised-domain exclusion instead of defining malicious registration. Evidence: {"quote":"while we consider malicious registration to occur, like, you know, bad guy goes to a registrar, obtains the domain. Sometimes they go to a secondary market, and by an already registered domain that's been","start":4421.63,"cue_id":"cue-524","segment_id":524} - Gabriel said maliciously registered misses later acquisition of existing domains; Jothan raised leasing and innocent lessors or lessees. Chris warned against over-definition, Michaela suggested an advisory scenario, and Mark urged resolving hard policy questions rather than routinely deferring them to compliance. Staff recalled that the group had chosen the compromised-domain exclusion instead of defining malicious registration. Evidence: {"quote":"in existence for some time, and then take control of it, and maybe subsequently use it for abuse, even though the original registrants might have bought it for the purpose of resale, right?","start":4432.75,"cue_id":"cue-525","segment_id":525} - Gabriel said maliciously registered misses later acquisition of existing domains; Jothan raised leasing and innocent lessors or lessees. Chris warned against over-definition, Michaela suggested an advisory scenario, and Mark urged resolving hard policy questions rather than routinely deferring them to compliance. Staff recalled that the group had chosen the compromised-domain exclusion instead of defining malicious registration. Evidence: {"quote":"Maliciously acquired, or acquired for malicious purposes, to incorporate that feedback that it's both","start":4460.77,"cue_id":"cue-527","segment_id":527} - Gabriel said maliciously registered misses later acquisition of existing domains; Jothan raised leasing and innocent lessors or lessees. Chris warned against over-definition, Michaela suggested an advisory scenario, and Mark urged resolving hard policy questions rather than routinely deferring them to compliance. Staff recalled that the group had chosen the compromised-domain exclusion instead of defining malicious registration. Evidence: {"quote":"leasing it to another party, and that party ends up using it maliciously, or that domain gets compromised. That could be a very unfortunate circumstance here, where you've got, you know, to take action on a domain. You've got an innocent pa","start":4494.56,"cue_id":"cue-534","segment_id":534} - Gabriel said maliciously registered misses later acquisition of existing domains; Jothan raised leasing and innocent lessors or lessees. Chris warned against over-definition, Michaela suggested an advisory scenario, and Mark urged resolving hard policy questions rather than routinely deferring them to compliance. Staff recalled that the group had chosen the compromised-domain exclusion instead of defining malicious registration. Evidence: {"quote":"potentially an innocent party in the the person who's leasing the name.","start":4510.18,"cue_id":"cue-535","segment_id":535} - Gabriel said maliciously registered misses later acquisition of existing domains; Jothan raised leasing and innocent lessors or lessees. Chris warned against over-definition, Michaela suggested an advisory scenario, and Mark urged resolving hard policy questions rather than routinely deferring them to compliance. Staff recalled that the group had chosen the compromised-domain exclusion instead of defining malicious registration. Evidence: {"quote":"I'm very wary of over-defining things. I think that…","start":4532.95,"cue_id":"cue-539","segment_id":539} - Gabriel said maliciously registered misses later acquisition of existing domains; Jothan raised leasing and innocent lessors or lessees. Chris warned against over-definition, Michaela suggested an advisory scenario, and Mark urged resolving hard policy questions rather than routinely deferring them to compliance. Staff recalled that the group had chosen the compromised-domain exclusion instead of defining malicious registration. Evidence: {"quote":"Going down the definition trail, it's… it's not helpful, and actually, the more you define, the less flexibility you have.","start":4563.87,"cue_id":"cue-542","segment_id":542} - Gabriel said maliciously registered misses later acquisition of existing domains; Jothan raised leasing and innocent lessors or lessees. Chris warned against over-definition, Michaela suggested an advisory scenario, and Mark urged resolving hard policy questions rather than routinely deferring them to compliance. Staff recalled that the group had chosen the compromised-domain exclusion instead of defining malicious registration. Evidence: {"quote":"Thank you, Michaela Shapiro, for the record. No, I was just going to say that, again, it might be another elegant answer, but I really liked Martina's point earlier about maybe this could be a scenario that we address in the advisory. So, t","start":4624.75,"cue_id":"cue-551","segment_id":551} - Gabriel said maliciously registered misses later acquisition of existing domains; Jothan raised leasing and innocent lessors or lessees. Chris warned against over-definition, Michaela suggested an advisory scenario, and Mark urged resolving hard policy questions rather than routinely deferring them to compliance. Staff recalled that the group had chosen the compromised-domain exclusion instead of defining malicious registration. Evidence: {"quote":"I guess I would just generally caution against, like, let's not just try to take the easy way out and punt to compliance every time that we have a hard question, because I don't think that's fair or reasonable, and compliance may have a dif","start":4686.43,"cue_id":"cue-560","segment_id":560} - Gabriel said maliciously registered misses later acquisition of existing domains; Jothan raised leasing and innocent lessors or lessees. Chris warned against over-definition, Michaela suggested an advisory scenario, and Mark urged resolving hard policy questions rather than routinely deferring them to compliance. Staff recalled that the group had chosen the compromised-domain exclusion instead of defining malicious registration. Evidence: {"quote":"If I understand the discussion correctly, just a little bit of working group history, where we discussed Recommendation 1. Initially, the group tried to, put language into what malicious","start":4815.71,"cue_id":"cue-578","segment_id":578} - Gabriel said maliciously registered misses later acquisition of existing domains; Jothan raised leasing and innocent lessors or lessees. Chris warned against over-definition, Michaela suggested an advisory scenario, and Mark urged resolving hard policy questions rather than routinely deferring them to compliance. Staff recalled that the group had chosen the compromised-domain exclusion instead of defining malicious registration. Evidence: {"quote":"registration or domain would mean, but ultimately landed on that that would be not helpful. It would be better to focus on what compromised domains deem in terms of exclusion, because if it's not compromised, then it would be the other one,","start":4826.51,"cue_id":"cue-579","segment_id":579} - The chair noted that IPC and NCSG both wanted a compromised-domain definition; this did not settle the wording or establish agreement from all participants. Evidence: {"quote":"All right, we're gonna go to Mark, but I will say this, we have the IPC and the NCSG.","start":3001.37,"cue_id":"cue-347","segment_id":347} - The chair noted that IPC and NCSG both wanted a compromised-domain definition; this did not settle the wording or establish agreement from all participants. Evidence: {"quote":"in agreement that they want a definition. I just want to celebrate the moment that they're in agreement on something. Okay, that's a good thing.","start":3010.6,"cue_id":"cue-348","segment_id":348} - Participants differed over whose knowledge or consent matters: Mark sought the underlying user rather than a proxy provider, while Reg emphasized existing RNH terminology and rejected account holder as the relevant substitute. Evidence: {"quote":"that doesn't accomplish the goal. It misses the mark. The intent is the person who is controlling, whether you want to call them the owner, whatever, the beneficial user, the customer of the registrar or reseller. It's that person. That per","start":2586.49,"cue_id":"cue-298","segment_id":298} - Participants differed over whose knowledge or consent matters: Mark sought the underlying user rather than a proxy provider, while Reg emphasized existing RNH terminology and rejected account holder as the relevant substitute. Evidence: {"quote":"And so that's the problem that we have. Registered name holder misses that mark in the practical reality of the world now, and with the definitions as they exist in the RDP.","start":2601.77,"cue_id":"cue-299","segment_id":299} - Participants differed over whose knowledge or consent matters: Mark sought the underlying user rather than a proxy provider, while Reg emphasized existing RNH terminology and rejected account holder as the relevant substitute. Evidence: {"quote":"But if it is the case that RNH is no longer sufficient to determine the RNH, then that is a determination that belongs to a different PDP, and not ours to change.","start":2395.59,"cue_id":"cue-276","segment_id":276} - Participants differed over whose knowledge or consent matters: Mark sought the underlying user rather than a proxy provider, while Reg emphasized existing RNH terminology and rejected account holder as the relevant substitute. Evidence: {"quote":"Account holder is very different from RNH. I think we added, as I recall, account holder was added so that if it's a reseller.","start":2843.57,"cue_id":"cue-328","segment_id":328} - Participants differed over whose knowledge or consent matters: Mark sought the underlying user rather than a proxy provider, while Reg emphasized existing RNH terminology and rejected account holder as the relevant substitute. Evidence: {"quote":"It's not really the account holder's consent.","start":2876.44,"cue_id":"cue-332","segment_id":332} - Participants differed over whose knowledge or consent matters: Mark sought the underlying user rather than a proxy provider, while Reg emphasized existing RNH terminology and rejected account holder as the relevant substitute. Evidence: {"quote":"you, my good friend Paul, buy a domain for me, and I set it up for you because I'm a real reseller now, at Two Cows. I don't know what you're doing with it, right? It's not… you just pay me. That's all that happens. So that's not the releva","start":2885.28,"cue_id":"cue-334","segment_id":334} - Common-control registrar checks drew support as a way to avoid loopholes, but leadership cited charter scope and registrar speakers raised feasibility and burden concerns. Evidence: {"quote":"When an ADC is triggered at one of those registrars. And I found that was a point that hadn't been discussed by our group before, but I think that it was a valid expectation that when there's multiple registrar portfolios all controlled by ","start":3496.86,"cue_id":"cue-408","segment_id":408} - Common-control registrar checks drew support as a way to avoid loopholes, but leadership cited charter scope and registrar speakers raised feasibility and burden concerns. Evidence: {"quote":"briefly touch on inter-registrar checks, and determined very, very early that those were outside of the scope of the Charter, and that's one of the reasons why this… that particular comment was not baked into our proposed changes.","start":3524.37,"cue_id":"cue-411","segment_id":411} - Common-control registrar checks drew support as a way to avoid loopholes, but leadership cited charter scope and registrar speakers raised feasibility and burden concerns. Evidence: {"quote":"Or cross-registryment? Like, I really don't understand. I understand why this was raised, but I don't understand the actual means of getting registrars to do it.","start":3610.96,"cue_id":"cue-420","segment_id":420} - Common-control registrar checks drew support as a way to avoid loopholes, but leadership cited charter scope and registrar speakers raised feasibility and burden concerns. Evidence: {"quote":"would create an additional burden on those registrars that is currently not foreseen, and that probably would be out of scope for the PDP.","start":3739.15,"cue_id":"cue-433","segment_id":433} - Common-control registrar checks drew support as a way to avoid loopholes, but leadership cited charter scope and registrar speakers raised feasibility and burden concerns. Evidence: {"quote":"hey, here's the domain name, here's the information, do the ADC check, you could also just send that information to all the other registrars that are under your common control. And even if they have different systems, just like with a resel","start":3799.74,"cue_id":"cue-442","segment_id":442} - Common-control registrar checks drew support as a way to avoid loopholes, but leadership cited charter scope and registrar speakers raised feasibility and burden concerns. Evidence: {"quote":"You do not want to create a loophole where people would stop looking just because it happens to be under a different accreditation.","start":3881.02,"cue_id":"cue-452","segment_id":452} - Mark urged resolving interpretive gaps in policy rather than routinely handing them to compliance; Michaela and Chris saw an advisory or implementation route, and Brian considered malicious-versus-compromised a broader contract issue. Evidence: {"quote":"Thank you, Michaela Shapiro, for the record. No, I was just going to say that, again, it might be another elegant answer, but I really liked Martina's point earlier about maybe this could be a scenario that we address in the advisory. So, t","start":4624.75,"cue_id":"cue-551","segment_id":551} - Mark urged resolving interpretive gaps in policy rather than routinely handing them to compliance; Michaela and Chris saw an advisory or implementation route, and Brian considered malicious-versus-compromised a broader contract issue. Evidence: {"quote":"Music to your chair's ears. Okay. Chris, back to you. Yeah, I agree. I think it can be addressed.","start":4645.17,"cue_id":"cue-552","segment_id":552} - Mark urged resolving interpretive gaps in policy rather than routinely handing them to compliance; Michaela and Chris saw an advisory or implementation route, and Brian considered malicious-versus-compromised a broader contract issue. Evidence: {"quote":"implementation.","start":4676.71,"cue_id":"cue-557","segment_id":557} - Mark urged resolving interpretive gaps in policy rather than routinely handing them to compliance; Michaela and Chris saw an advisory or implementation route, and Brian considered malicious-versus-compromised a broader contract issue. Evidence: {"quote":"I guess I would just generally caution against, like, let's not just try to take the easy way out and punt to compliance every time that we have a hard question, because I don't think that's fair or reasonable, and compliance may have a dif","start":4686.43,"cue_id":"cue-560","segment_id":560} - Mark urged resolving interpretive gaps in policy rather than routinely handing them to compliance; Michaela and Chris saw an advisory or implementation route, and Brian considered malicious-versus-compromised a broader contract issue. Evidence: {"quote":"Yeah, thanks, Paul. And Mark, I take your point, but at the same time, I think this, like some of the other issues that have been raised, are an issue with the current contract. It's not an issue as it relates to associated domain checks. I","start":4720.91,"cue_id":"cue-565","segment_id":565} - Mark urged resolving interpretive gaps in policy rather than routinely handing them to compliance; Michaela and Chris saw an advisory or implementation route, and Brian considered malicious-versus-compromised a broader contract issue. Evidence: {"quote":"And so I take your point, and it's something that's worth discussing, but I don't think it's necessary. It's not really this group's job to solve the wider problem.","start":4734.95,"cue_id":"cue-566","segment_id":566} - The chair directed deleting legitimate or benign from the proposed definition after asking for objections. Evidence: {"quote":"anybody… Deeply opposed to scratching legitimate or benign.","start":2224.35,"cue_id":"cue-254","segment_id":254} - The chair directed deleting legitimate or benign from the proposed definition after asking for objections. Evidence: {"quote":"And just relying on the knowledge of the Domain…","start":2231.5,"cue_id":"cue-255","segment_id":255} - The chair directed deleting legitimate or benign from the proposed definition after asking for objections. Evidence: {"quote":"Okay, off goes legitimate or benign.","start":2240.73,"cue_id":"cue-257","segment_id":257} - Leadership and staff were to return with a compromised-domain proposal and consider the affiliated-registrar and acquisition/leasing issues; no final replacement definition or cross-registrar requirement was settled in this session. Evidence: {"quote":"Thanks, Mark. All right, we have Gabriel, and then I'm gonna say, if you want to say something else about this, get in the queue. But I feel comfortable that leadership and staff have what they need to come back with a proposal on this, in,","start":3088.69,"cue_id":"cue-357","segment_id":357} - Leadership and staff were to return with a compromised-domain proposal and consider the affiliated-registrar and acquisition/leasing issues; no final replacement definition or cross-registrar requirement was settled in this session. Evidence: {"quote":"Okay. I'm gonna call for last comments on this. I think staff and leadership have what they need to mess around with this.","start":4316.56,"cue_id":"cue-504","segment_id":504} - Leadership and staff were to return with a compromised-domain proposal and consider the affiliated-registrar and acquisition/leasing issues; no final replacement definition or cross-registrar requirement was settled in this session. Evidence: {"quote":"All right, leadership will take that back and give that some pondering.","start":4854.56,"cue_id":"cue-583","segment_id":583} - Leadership and staff were to return with a compromised-domain proposal and consider the affiliated-registrar and acquisition/leasing issues; no final replacement definition or cross-registrar requirement was settled in this session. Evidence: {"quote":"belabor it. Great session, everybody. I thought it was very useful. And, we will, leadership will come back to, all of us in the next red line after","start":4960.29,"cue_id":"cue-600","segment_id":600} - Leadership and staff were to return with a compromised-domain proposal and consider the affiliated-registrar and acquisition/leasing issues; no final replacement definition or cross-registrar requirement was settled in this session. Evidence: {"quote":"ICANN87. We are going to meet when? Soon, it's on your calendar. And we're going to tackle 3 and 4. All right, thank you all.","start":4970.33,"cue_id":"cue-601","segment_id":601} - Leadership and staff would return with a proposal and a next redline after ICANN87. Evidence: {"quote":"Thanks, Mark. All right, we have Gabriel, and then I'm gonna say, if you want to say something else about this, get in the queue. But I feel comfortable that leadership and staff have what they need to come back with a proposal on this, in,","start":3088.69,"cue_id":"cue-357","segment_id":357} - Leadership and staff would return with a proposal and a next redline after ICANN87. Evidence: {"quote":"belabor it. Great session, everybody. I thought it was very useful. And, we will, leadership will come back to, all of us in the next red line after","start":4960.29,"cue_id":"cue-600","segment_id":600} - Leadership and staff would return with a proposal and a next redline after ICANN87. Evidence: {"quote":"ICANN87. We are going to meet when? Soon, it's on your calendar. And we're going to tackle 3 and 4. All right, thank you all.","start":4970.33,"cue_id":"cue-601","segment_id":601} - Leadership would take back the acquisition and leasing concerns for further consideration. Evidence: {"quote":"All right, leadership will take that back and give that some pondering.","start":4854.56,"cue_id":"cue-583","segment_id":583} - Possible follow-up: test the unauthorized-party formulation against privacy/proxy and leasing scenarios before settling the compromised-domain wording. Evidence: {"quote":"As a suggestion, you could make it really simple and say a compromised domain means a domain name that's used by an unauthorized party as a vector for DNS abuse.","start":3172.24,"cue_id":"cue-364","segment_id":364} - Possible follow-up: test the unauthorized-party formulation against privacy/proxy and leasing scenarios before settling the compromised-domain wording. Evidence: {"quote":"leasing it to another party, and that party ends up using it maliciously, or that domain gets compromised. That could be a very unfortunate circumstance here, where you've got, you know, to take action on a domain. You've got an innocent pa","start":4494.56,"cue_id":"cue-534","segment_id":534} - Possible follow-up: test the unauthorized-party formulation against privacy/proxy and leasing scenarios before settling the compromised-domain wording. Evidence: {"quote":"Mar Trachtenberg, IBC. I agree with Gabe's point, and Jothan's, and I think for… to respond to Chris, I don't think unauthorized third parties does address this, because in that case, the party would be authorized.","start":4578.81,"cue_id":"cue-545","segment_id":545} - Possible follow-up: clarify how reasonably accessible evidence applies to affiliated registrars using shared versus separate systems, including what compliance can verify. Evidence: {"quote":"And so, the thing that I would suggest might actually bridge that gap is what's in, I think it's Recommendation 3, is what evidence is reasonably accessible.","start":4111.359,"cue_id":"cue-479","segment_id":479} - Possible follow-up: clarify how reasonably accessible evidence applies to affiliated registrars using shared versus separate systems, including what compliance can verify. Evidence: {"quote":"And so, in the Brian's Registrar example, you're very likely to have the same compliance team overseeing all 50 registrars under that umbrella, whereas the other example, where you have really fundamentally different operations, the informa","start":4120.14,"cue_id":"cue-480","segment_id":480} - Possible follow-up: clarify how reasonably accessible evidence applies to affiliated registrars using shared versus separate systems, including what compliance can verify. Evidence: {"quote":"then, arguably, that information is reasonably accessible to you, right? And so, I think that we may have solved the problem by that reasonable, accessible thing, and we may want to leave it undisturbed, because it sounds like","start":4247.96,"cue_id":"cue-494","segment_id":494} - Possible follow-up: clarify how reasonably accessible evidence applies to affiliated registrars using shared versus separate systems, including what compliance can verify. Evidence: {"quote":"I think what you're saying makes sense, but the question is, from a practical perspective, does ICANN compliance have access to that information? Do they know how the system… how the registrar is running? And I think the answer is probably ","start":4280.19,"cue_id":"cue-498","segment_id":498} - Possible follow-up: consider scenario-based advisory guidance without assuming the group agreed to defer every interpretive question to compliance. Evidence: {"quote":"So I don't know if we are all happy with the definition, with the approach that we had before, and we don't want to renegotiate a new definition here. Maybe what we could do is to provide more guidance in a newly suggested advisory.","start":1919.37,"cue_id":"cue-213","segment_id":213} - Possible follow-up: consider scenario-based advisory guidance without assuming the group agreed to defer every interpretive question to compliance. Evidence: {"quote":"Where ICANN Org could provide a number of scenarios. Some of those scenarios, for instance, mentioned by Gabe, but also others.","start":1931.89,"cue_id":"cue-214","segment_id":214} - Possible follow-up: consider scenario-based advisory guidance without assuming the group agreed to defer every interpretive question to compliance. Evidence: {"quote":"Thank you, Michaela Shapiro, for the record. No, I was just going to say that, again, it might be another elegant answer, but I really liked Martina's point earlier about maybe this could be a scenario that we address in the advisory. So, t","start":4624.75,"cue_id":"cue-551","segment_id":551} - Possible follow-up: consider scenario-based advisory guidance without assuming the group agreed to defer every interpretive question to compliance. Evidence: {"quote":"I guess I would just generally caution against, like, let's not just try to take the easy way out and punt to compliance every time that we have a hard question, because I don't think that's fair or reasonable, and compliance may have a dif","start":4686.43,"cue_id":"cue-560","segment_id":560} - What wording identifies the relevant party’s knowledge or consent without creating a privacy/proxy loophole or confusing domain users with payers and resellers? Evidence: {"quote":"that doesn't accomplish the goal. It misses the mark. The intent is the person who is controlling, whether you want to call them the owner, whatever, the beneficial user, the customer of the registrar or reseller. It's that person. That per","start":2586.49,"cue_id":"cue-298","segment_id":298} - What wording identifies the relevant party’s knowledge or consent without creating a privacy/proxy loophole or confusing domain users with payers and resellers? Evidence: {"quote":"you, my good friend Paul, buy a domain for me, and I set it up for you because I'm a real reseller now, at Two Cows. I don't know what you're doing with it, right? It's not… you just pay me. That's all that happens. So that's not the releva","start":2885.28,"cue_id":"cue-334","segment_id":334} - What wording identifies the relevant party’s knowledge or consent without creating a privacy/proxy loophole or confusing domain users with payers and resellers? Evidence: {"quote":"The account holder doesn't hit the mark here, and I would like to explain why. When we added that terminology to the RA8 back in 2012-2013,","start":2917.71,"cue_id":"cue-337","segment_id":337} - What wording identifies the relevant party’s knowledge or consent without creating a privacy/proxy loophole or confusing domain users with payers and resellers? Evidence: {"quote":"As a suggestion, you could make it really simple and say a compromised domain means a domain name that's used by an unauthorized party as a vector for DNS abuse.","start":3172.24,"cue_id":"cue-364","segment_id":364} - How should the ADC framework address information across affiliated accreditations while respecting charter scope, operational differences and the reasonably accessible standard? Evidence: {"quote":"briefly touch on inter-registrar checks, and determined very, very early that those were outside of the scope of the Charter, and that's one of the reasons why this… that particular comment was not baked into our proposed changes.","start":3524.37,"cue_id":"cue-411","segment_id":411} - How should the ADC framework address information across affiliated accreditations while respecting charter scope, operational differences and the reasonably accessible standard? Evidence: {"quote":"Because, while some registrars that have affiliated registrars are all managing them in one system and in one team, others that have, especially when they have grown through acquisitions,","start":3705.16,"cue_id":"cue-430","segment_id":430} - How should the ADC framework address information across affiliated accreditations while respecting charter scope, operational differences and the reasonably accessible standard? Evidence: {"quote":"are very much operated as independent entities that are… just happen to be under common control. And for those, expecting, a common… a check of associated domain names.","start":3719.1,"cue_id":"cue-431","segment_id":431} - How should the ADC framework address information across affiliated accreditations while respecting charter scope, operational differences and the reasonably accessible standard? Evidence: {"quote":"And so, the thing that I would suggest might actually bridge that gap is what's in, I think it's Recommendation 3, is what evidence is reasonably accessible.","start":4111.359,"cue_id":"cue-479","segment_id":479} - How should the ADC framework address information across affiliated accreditations while respecting charter scope, operational differences and the reasonably accessible standard? Evidence: {"quote":"And so, in the Brian's Registrar example, you're very likely to have the same compliance team overseeing all 50 registrars under that umbrella, whereas the other example, where you have really fundamentally different operations, the informa","start":4120.14,"cue_id":"cue-480","segment_id":480} - How should the ADC framework address information across affiliated accreditations while respecting charter scope, operational differences and the reasonably accessible standard? Evidence: {"quote":"I think what you're saying makes sense, but the question is, from a practical perspective, does ICANN compliance have access to that information? Do they know how the system… how the registrar is running? And I think the answer is probably ","start":4280.19,"cue_id":"cue-498","segment_id":498} - How should policy language handle secondary-market acquisitions and domain leasing, and which issues belong in this PDP versus broader contractual guidance? Evidence: {"quote":"And I think that was something I hadn't previously considered, and I found that to be a very insightful comment to make. And I think that the only real repercussion it has on this document is sometimes we're using the term maliciously regis","start":4442.68,"cue_id":"cue-526","segment_id":526} - How should policy language handle secondary-market acquisitions and domain leasing, and which issues belong in this PDP versus broader contractual guidance? Evidence: {"quote":"Maliciously acquired, or acquired for malicious purposes, to incorporate that feedback that it's both","start":4460.77,"cue_id":"cue-527","segment_id":527} - How should policy language handle secondary-market acquisitions and domain leasing, and which issues belong in this PDP versus broader contractual guidance? Evidence: {"quote":"leasing it to another party, and that party ends up using it maliciously, or that domain gets compromised. That could be a very unfortunate circumstance here, where you've got, you know, to take action on a domain. You've got an innocent pa","start":4494.56,"cue_id":"cue-534","segment_id":534} - How should policy language handle secondary-market acquisitions and domain leasing, and which issues belong in this PDP versus broader contractual guidance? Evidence: {"quote":"like, under UDRP jurisprudence, a transfer is treated as a new registration, but that's not in the policy anywhere, and it's not in any sort of other policy document or agreement, so I think this is a loophole that people didn't think about","start":4591.98,"cue_id":"cue-547","segment_id":547} - How should policy language handle secondary-market acquisitions and domain leasing, and which issues belong in this PDP versus broader contractual guidance? Evidence: {"quote":"Yeah, thanks, Paul. And Mark, I take your point, but at the same time, I think this, like some of the other issues that have been raised, are an issue with the current contract. It's not an issue as it relates to associated domain checks. I","start":4720.91,"cue_id":"cue-565","segment_id":565} - How should policy language handle secondary-market acquisitions and domain leasing, and which issues belong in this PDP versus broader contractual guidance? Evidence: {"quote":"registration or domain would mean, but ultimately landed on that that would be not helpful. It would be better to focus on what compromised domains deem in terms of exclusion, because if it's not compromised, then it would be the other one,","start":4826.51,"cue_id":"cue-579","segment_id":579} ## Materials and complete resources - https://icann-assets.agentcommunity.org/icann/87/sessions/sched-2WjfB/revisions/1f2d960890b5e2dee68db5762d2179c669bfd2b53a5f9062e922ad80c8c5a131/ai-context.md - https://icann-assets.agentcommunity.org/icann/87/sessions/sched-2WjfB/revisions/1f2d960890b5e2dee68db5762d2179c669bfd2b53a5f9062e922ad80c8c5a131/transcript-corrected.json - https://icann-assets.agentcommunity.org/icann/87/sessions/sched-2WjfB/revisions/1f2d960890b5e2dee68db5762d2179c669bfd2b53a5f9062e922ad80c8c5a131/captions-original.vtt - https://icann-assets.agentcommunity.org/icann/87/sessions/sched-2WjfB/revisions/1f2d960890b5e2dee68db5762d2179c669bfd2b53a5f9062e922ad80c8c5a131/context-package.zip - https://icann-assets.agentcommunity.org/icann/87/sessions/sched-2WjfB/revisions/1f2d960890b5e2dee68db5762d2179c669bfd2b53a5f9062e922ad80c8c5a131/wiki.wikitext - https://icann-assets.agentcommunity.org/icann/87/sessions/sched-2WjfB/revisions/1f2d960890b5e2dee68db5762d2179c669bfd2b53a5f9062e922ad80c8c5a131/session.json ## Source hashes - captions-original.vtt: 8810ab50067187ac177fee59944786a46b44d99c14e0dd46e615d97a9dc032b8 (107873 bytes); source https://icann87.sched.com/event/2WjfB/gnso-dns-abuse-mitigation-pdp1-working-session-1-of-4 - transcript-raw.json: 81c32f130b1d69e3a2df4b9c75f2969649c64da62979c40c4018c3c05d348a9f (215087 bytes); source https://icann87.sched.com/event/2WjfB/gnso-dns-abuse-mitigation-pdp1-working-session-1-of-4 - transcript-corrected.json: 6241020ef87fe2eb06936445f109e2ae8c731a511d8f02a7b30dfb9d4427c623 (215603 bytes); source https://icann87.sched.com/event/2WjfB/gnso-dns-abuse-mitigation-pdp1-working-session-1-of-4 - transcript-asr.json: 9b17585213044d24d3aeb3b16ef3f468f41a70f0c0ae233c52d0b9e728ec1907 (222392 bytes); source https://icann87.sched.com/event/2WjfB/gnso-dns-abuse-mitigation-pdp1-working-session-1-of-4 - audio/session.mp3: 642b4ec9992e16909d62061d3259c7ae078ce089b7c51ccd83eeff9d096c44f7 (39200774 bytes); source http://audio.icann.org/meetings/dps87/dps87-OPEN-2026-10-17-T0225-nusantara1-en-01-GNSO-DNS-Abuse-Mitigation-PDP1-W_.mp3 - sources.json: 3b759938c82ed830822f275fa1c304fa320a5139732ece75acc31ea6e4c02e39 (957 bytes); source https://icann87.sched.com/event/2WjfB/gnso-dns-abuse-mitigation-pdp1-working-session-1-of-4 - summary.json: 39d4a3a452d09731f6e6e70e1311722673909314d179809dfb064dafd43c2eaf (51391 bytes); source https://icann87.sched.com/event/2WjfB/gnso-dns-abuse-mitigation-pdp1-working-session-1-of-4 - summary.md: b4252e36fad9219a8bc63e877da6d2bd6f0f6222123b08a73506a916c31bc538 (42817 bytes); source https://icann87.sched.com/event/2WjfB/gnso-dns-abuse-mitigation-pdp1-working-session-1-of-4 - wiki.wikitext: 8248c5e0e019b9be0d086115293eac531ccb772cf1a39aaff3d2d45ddb93f185 (56634 bytes); source https://icann87.sched.com/event/2WjfB/gnso-dns-abuse-mitigation-pdp1-working-session-1-of-4 - ai-context.md: ddd2073f2c95807037030cb46c9ea45ad38c990dbbf6fea0c010d385566ade65 (140285 bytes); source https://icann87.sched.com/event/2WjfB/gnso-dns-abuse-mitigation-pdp1-working-session-1-of-4 - context.md: f1c6b245a72a4425d8b8fd60c79ae28bd46dfbb15a1ef274c26acb4be4a55aa1 (141293 bytes); source https://icann87.sched.com/event/2WjfB/gnso-dns-abuse-mitigation-pdp1-working-session-1-of-4