WEBVTT 1 00:00:03.080 --> 00:00:21.539 ICANN - MTS - A/V: Hello, and welcome to the DNS Abuse Mitigation PDP-1 Working Group Session 2 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 Concerning Statements of Interest. 2 00:00:21.710 --> 00:00:39.059 ICANN - MTS - A/V: Please observe the guidelines to participate in this session. I will also post them in the chat for your reference. If you wish to speak, please raise your hand in Zoom or otherwise as directed. 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. 3 00:00:40.580 --> 00:00:44.289 ICANN - MTS - A/V: Thank you, Terry. Welcome, everyone, to Session 2. 4 00:00:44.390 --> 00:00:46.880 ICANN - MTS - A/V: of PDP1? 5 00:00:47.340 --> 00:00:52.590 ICANN - MTS - A/V: We retained part of our crowd. How about that? We must have been very enthralling. 6 00:00:52.820 --> 00:00:56.090 ICANN - MTS - A/V: We are going to be going through 7 00:00:56.300 --> 00:01:01.369 ICANN - MTS - A/V: Recs 3 and 4, along with implementation guidance. 8 00:01:01.620 --> 00:01:09.989 ICANN - MTS - A/V: 3.1 and 4.1 In this session, so… Let's get started. 9 00:01:11.720 --> 00:01:12.440 ICANN - MTS - A/V: Bam. 10 00:01:13.810 --> 00:01:24.320 ICANN - MTS - A/V: Hi, everyone, welcome back. As noted by Paul, as you see on the screen, the main comments received on Recommendation 3 that leadership thought 11 00:01:24.610 --> 00:01:35.969 ICANN - MTS - A/V: could be implemented, considered in the language update, or, clarify what reasonably accessible information encompass in more specificity. We know that the group talked about this 12 00:01:36.000 --> 00:01:46.649 ICANN - MTS - A/V: in the past, and it was quite strong compromise. However, I think there might be some changes justified to just explain the notion a bit better. 13 00:01:46.650 --> 00:01:59.849 ICANN - MTS - A/V: Similarly, another cluster of public comment noted clarity or clarify reseller held information, registrar responsibility. So in the following slide, Paul will introduce how 14 00:01:59.870 --> 00:02:02.829 ICANN - MTS - A/V: That could look like, in terms of language, we hope. 15 00:02:03.050 --> 00:02:04.980 ICANN - MTS - A/V: that would address it. Back to Paul. 16 00:02:06.500 --> 00:02:08.310 ICANN - MTS - A/V: Thank you. Fail. Okay. 17 00:02:08.729 --> 00:02:17.260 ICANN - MTS - A/V: This is a proposed, language update to Rec 3, based upon, as you guys saw. 18 00:02:17.470 --> 00:02:22.190 ICANN - MTS - A/V: Comments from lots of people saying we need to do some clarification here. 19 00:02:22.300 --> 00:02:28.830 ICANN - MTS - A/V: It's considered a substantive Comment, or reason… so let's jump into it. 20 00:02:29.250 --> 00:02:34.139 ICANN - MTS - A/V: The updated REC proposal I'll read it. 21 00:02:34.470 --> 00:02:49.389 ICANN - MTS - A/V: A reasonable investigation by a registrar must consist of reviewing information reasonably accessible to the registrar in the normal course of its operations to determine whether associated domain names are being used for DNS abuse. 22 00:02:49.620 --> 00:02:54.450 ICANN - MTS - A/V: As defined in 3.18.1 of the RAA. 23 00:02:54.680 --> 00:03:03.229 ICANN - MTS - A/V: For the purposes of this recommendation, information reasonably accessible to the Registrar includes, but is not limited to, and here's the change. 24 00:03:03.470 --> 00:03:07.560 ICANN - MTS - A/V: Information the Registrar is required to collect or maintain. 25 00:03:07.710 --> 00:03:13.320 ICANN - MTS - A/V: Under its contractual obligations, Information available through its technical systems. 26 00:03:13.470 --> 00:03:22.080 ICANN - MTS - A/V: and reasonably accessible to it directly or through resellers and information and records contained in abuse reports it receives. 27 00:03:23.030 --> 00:03:28.519 ICANN - MTS - A/V: So, that's the proposed change. We're going to open a queue on this. Reg, please go ahead. 28 00:03:31.480 --> 00:03:35.419 Reg Levy – Tucows: Thank you. Reg Levy from the Registrars and 2CAS. 29 00:03:35.830 --> 00:03:44.699 Reg Levy – Tucows: I feel like we went over this many, many, many, many times and moved away from this, so it's kind of frustrating to see it back again. 30 00:03:45.100 --> 00:03:46.140 Reg Levy – Tucows: Umm. 31 00:03:46.640 --> 00:03:47.450 Reg Levy – Tucows: Yeah. 32 00:03:47.950 --> 00:03:49.110 Reg Levy – Tucows: That's where I am. 33 00:03:51.190 --> 00:03:52.940 ICANN - MTS - A/V: Thanks, Reg. 34 00:03:53.990 --> 00:04:00.050 ICANN - MTS - A/V: And remember, this is just a straw person. If nobody wants to make any changes, we don't have to make any changes. 35 00:04:06.060 --> 00:04:07.689 ICANN - MTS - A/V: Mark Trachtenberg for the IPC. 36 00:04:08.040 --> 00:04:10.260 ICANN - MTS - A/V: This language looks good. 37 00:04:10.380 --> 00:04:14.890 ICANN - MTS - A/V: to me, and I think would be acceptable to the IPC. I take Reg's point about how this was discussed. 38 00:04:15.360 --> 00:04:16.170 ICANN - MTS - A/V: A lot. 39 00:04:16.430 --> 00:04:33.569 ICANN - MTS - A/V: During the working group sessions, and it was, but there's a reason we have public comment, which is to solicit feedback from everyone. I mean, we have people that are representative of the different communities, but not everyone participates in the actual discussions and has access to everything, and so that's why we put it out for public comment. And there was substantial public comment on this issue. 40 00:04:34.460 --> 00:04:45.289 ICANN - MTS - A/V: you know, raise some of these points that also were raised during our discussion. So, I think that the public comments show that there is a lot of interest in this, and that this was a hole, and that maybe here, the group didn't get it right. 41 00:04:47.240 --> 00:04:49.359 ICANN - MTS - A/V: Thank you, Mark Volker. 42 00:04:50.180 --> 00:04:52.900 ICANN - MTS - A/V: Yeah, Volker Kleiman, RRSG. 43 00:04:53.910 --> 00:04:56.329 ICANN - MTS - A/V: I share a registered position that. 44 00:04:56.510 --> 00:05:14.190 ICANN - MTS - A/V: We have been over this time and again, and really, this seems like a second bite of the apple by those that didn't get what they wanted originally. I also seem to recall, when I looked at the chart of support of the original recommendations, that the original recommendations had very high levels of support, and there was 45 00:05:14.260 --> 00:05:22.239 ICANN - MTS - A/V: a significantly lower amount of people that want to change and had significant issues with that, so I would see this as a minor position, and 46 00:05:22.300 --> 00:05:35.750 ICANN - MTS - A/V: The majority seems to be, of the commenters as well, and of the people that previously decided on the language that we had before, and that that language that we had before was the way to go, and the ideal solution. So I would. 47 00:05:36.130 --> 00:05:45.209 ICANN - MTS - A/V: say that if this was something that was basically proposed by a majority of the commenters, then we should probably consider this. But if it's only a minority, then. 48 00:05:45.840 --> 00:05:47.280 ICANN - MTS - A/V: Yeah, we've been over it. 49 00:05:48.830 --> 00:05:50.179 ICANN - MTS - A/V: Thank you. Volker. 50 00:05:50.320 --> 00:05:57.070 ICANN - MTS - A/V: And just to, Bring in some facts to support the 51 00:05:57.320 --> 00:06:05.600 ICANN - MTS - A/V: concerns that we've been over it, because I'm not trying to put my thumb on the scale, but we're not… for those in the room that maybe weren't on all the working group calls, we did talk about this. 52 00:06:06.000 --> 00:06:09.390 ICANN - MTS - A/V: On April 13th, May 4th. 53 00:06:09.910 --> 00:06:12.939 ICANN - MTS - A/V: At ICANN 86 in sessions 1 and 2. 54 00:06:13.100 --> 00:06:17.899 ICANN - MTS - A/V: ICANN 86 is sessions 3 and 4. We talked about it again on the 22nd of June. 55 00:06:18.050 --> 00:06:22.990 ICANN - MTS - A/V: July 13th and August 3rd. So we have talked about this quite a bit. 56 00:06:23.270 --> 00:06:29.070 ICANN - MTS - A/V: So, I… Again, the language that we have out here is just a… 57 00:06:29.370 --> 00:06:31.809 ICANN - MTS - A/V: Straw person, in an attempt to… 58 00:06:32.010 --> 00:06:35.730 ICANN - MTS - A/V: respond to the public comment. And 59 00:06:35.890 --> 00:06:42.299 ICANN - MTS - A/V: So far, we've got some support for, others saying we've… without… 60 00:06:42.940 --> 00:06:50.040 ICANN - MTS - A/V: necessarily saying there's anything wrong with the new language, just saying that, you know, we've been over it. Sounds like a second bite at the apple. 61 00:06:50.290 --> 00:06:53.159 ICANN - MTS - A/V: We're gonna go to Martina, and go ahead. 62 00:06:54.110 --> 00:07:03.600 ICANN - MTS - A/V: Thank you very much, Paul Martina, representing the GAC for the records. I mean, I think as the GAC, we were fine and accepted the previous language, but this specific comment comes from ICANN Org. 63 00:07:04.020 --> 00:07:14.100 ICANN - MTS - A/V: So that puts me in a very uncomfortable chair, because if ICANNORC tells me that I should be worried about this language, then I'm double guessing myself, of course, and I would like to hear from the registrars 64 00:07:14.390 --> 00:07:23.330 ICANN - MTS - A/V: Because we have trusted ICANN Org's judgment on a number of occasions, so maybe ICANN can explain why the comment came through, and the register can develop on, 65 00:07:23.430 --> 00:07:26.200 ICANN - MTS - A/V: What's their interpretation of this concern from Eigenorg? 66 00:07:27.060 --> 00:07:37.009 ICANN - MTS - A/V: Thanks, Martina. We have a representative of ICANN Org, and since we've used their name, why don't we ask them why they've asked for this change, what the enhancement is? 67 00:07:38.120 --> 00:07:43.960 ICANN - MTS - A/V: Sure, Peter Rieken ICANN Org. So, I just want to clarify, this is a drafting clarification. 68 00:07:44.400 --> 00:07:53.139 ICANN - MTS - A/V: So, we're not seeking to change the standard of a reasonably accessible information, or tell registers how to conduct. 69 00:07:53.310 --> 00:07:59.450 ICANN - MTS - A/V: Their investigations, but to us, The, sort of, the current language of 70 00:07:59.700 --> 00:08:03.149 ICANN - MTS - A/V: Contractual obligations, technical systems, research reports. 71 00:08:03.440 --> 00:08:06.520 ICANN - MTS - A/V: Was… wasn't precise, it wasn't particularly clear. 72 00:08:06.660 --> 00:08:15.619 ICANN - MTS - A/V: What that meant. So, we wanted to clarify that our understanding, right, was that that covers information that registrars are required to collect. 73 00:08:16.050 --> 00:08:29.939 ICANN - MTS - A/V: through their own systems, or resellers, and information about the abuse reports that they received. So the aim of this was to make the scope of the standard clearer, without changing what registers are required to do, or prescribe how they do it. 74 00:08:30.440 --> 00:08:32.409 ICANN - MTS - A/V: So if that potentially helps. 75 00:08:35.559 --> 00:08:43.449 ICANN - MTS - A/V: I guess I'm going to be mean to you, hope you don't mind. What is in here that would not make its way into a contractual 76 00:08:43.720 --> 00:08:48.719 ICANN - MTS - A/V: compliance, you know, guideline, because you're gonna… at the end of implementation. 77 00:08:49.280 --> 00:08:54.199 ICANN - MTS - A/V: there'll be… Some documents that go to registrars to explain what the new obligations are. 78 00:08:54.620 --> 00:08:58.099 ICANN - MTS - A/V: Is there something about the initial definition that would 79 00:08:58.320 --> 00:09:00.660 ICANN - MTS - A/V: Tie your hands in that, or… 80 00:09:01.260 --> 00:09:06.209 ICANN - MTS - A/V: I mean, is this the only place this can be, is what I'm asking, or could it be downstream someplace else? 81 00:09:07.290 --> 00:09:12.899 ICANN - MTS - A/V: I mean, potentially, we are really just commenting on the recommendation. 82 00:09:13.040 --> 00:09:31.679 ICANN - MTS - A/V: So, obviously, in implementation, when it comes to discussing how to turn this into consensus policy, it helps to be as precise as possible, because often these arguments become, you know, they're revived, and people start, people in the IRT representative start to say no, but when we meant, what we meant by this was. 83 00:09:32.000 --> 00:09:36.830 ICANN - MTS - A/V: Okay, so… Our understanding was that this is what the working group. 84 00:09:37.560 --> 00:09:41.459 ICANN - MTS - A/V: tended by this definition. So, where possible. 85 00:09:41.600 --> 00:09:47.730 ICANN - MTS - A/V: We were asking if this is what the working group intended, maybe it's best Just to state it clearly. 86 00:09:48.210 --> 00:09:52.699 ICANN - MTS - A/V: So, it involves, potentially revisiting this and implementation. 87 00:09:53.010 --> 00:09:59.629 ICANN - MTS - A/V: However, it is a refinement change. It's really just to improve the clarification. We're not, suggesting, like, a change of approach. 88 00:09:59.890 --> 00:10:00.550 ICANN - MTS - A/V: somewhere. 89 00:10:01.010 --> 00:10:02.760 ICANN - MTS - A/V: All right, thank you. Chris? 90 00:10:03.710 --> 00:10:10.119 ICANN - MTS - A/V: Thank you, Paul. And thanks, Peter, for clarifying it. 91 00:10:10.590 --> 00:10:16.119 ICANN - MTS - A/V: I originally put my hand up to ask what was the justification for the wording. 92 00:10:17.040 --> 00:10:18.720 ICANN - MTS - A/V: Having listened to you. 93 00:10:20.030 --> 00:10:24.290 ICANN - MTS - A/V: I suppose my comment would be that I'm not sure that it is just a clarification. 94 00:10:26.170 --> 00:10:34.330 ICANN - MTS - A/V: What… the sentence that's been… or the words that have been removed say, information ordinarily accessible to the registrar through its contractual obligations. 95 00:10:34.600 --> 00:10:42.160 ICANN - MTS - A/V: What you've said is information the registrar is required to collect or maintain, so you have removed the ordinarily accessible. 96 00:10:42.390 --> 00:10:50.350 ICANN - MTS - A/V: And it's entirely possible it could be information that the registrar was contractually obliged to collect 6 years ago. 97 00:10:50.580 --> 00:10:52.870 ICANN - MTS - A/V: Which is no longer ordinarily accessible. 98 00:10:53.180 --> 00:10:55.400 ICANN - MTS - A/V: So I do think it makes a change. 99 00:10:55.860 --> 00:11:00.019 ICANN - MTS - A/V: By removing the reference to ordinarily accessible. 100 00:11:00.990 --> 00:11:04.020 ICANN - MTS - A/V: Do you think that… 101 00:11:04.430 --> 00:11:09.649 ICANN - MTS - A/V: Was ordinarily accessible a problem for you? Is that why you asked for the change? 102 00:11:11.190 --> 00:11:12.010 ICANN - MTS - A/V: Thank you. 103 00:11:16.350 --> 00:11:18.270 ICANN - MTS - A/V: I think we were just, I think… 104 00:11:18.390 --> 00:11:22.079 ICANN - MTS - A/V: When we were looking at this, we were trying to unpack exactly what was meant. 105 00:11:22.610 --> 00:11:23.480 ICANN - MTS - A/V: So. 106 00:11:23.860 --> 00:11:27.659 ICANN - MTS - A/V: For us, the original information ordinarily accessible. 107 00:11:28.390 --> 00:11:45.020 ICANN - MTS - A/V: through its contractual obligations, it wasn't quite clear what that meant. It obviously could vary technical systems and boost reports. So, we were trying just to make, you know, based on our understanding of what the working group intended, obviously. 108 00:11:45.450 --> 00:11:49.889 ICANN - MTS - A/V: What you're saying is this is not what you intended. Take that on board. 109 00:11:50.820 --> 00:11:57.049 ICANN - MTS - A/V: We just wanted, maybe just… Just to be quite clear, you know, we think this is what you mean. 110 00:11:57.370 --> 00:12:03.250 ICANN - MTS - A/V: So, I take your point if this is… if you think this language is not representative. 111 00:12:05.200 --> 00:12:07.560 ICANN - MTS - A/V: Thank you. Okay, we have Mark. 112 00:12:08.750 --> 00:12:10.559 ICANN - MTS - A/V: Mark Trachtenberg of the IPC. 113 00:12:11.070 --> 00:12:15.660 ICANN - MTS - A/V: We did discuss this a lot, and there was some significant disagreement, and there was some compromise here. 114 00:12:15.780 --> 00:12:16.690 ICANN - MTS - A/V: Right, so… 115 00:12:17.290 --> 00:12:22.720 ICANN - MTS - A/V: But even though the window's compromised, I think people have the ability to still make public comments to put their views on the record of what they think it should be, and… 116 00:12:22.870 --> 00:12:30.489 ICANN - MTS - A/V: I think on this one, part of what we discussed is, well, why do we have to be so precise here? I can't compliance, we'll figure it out, and they'll tell us in an advisory. 117 00:12:30.530 --> 00:12:45.979 ICANN - MTS - A/V: Well, now we don't have to wait. Now they're telling us how they view it. They're telling us what they view, and so they're telling us already, why put it in an advisory? Why not just be clear and put it in a policy? And again, I think we should be as clear as possible in this policy when available, and so ICANN is now telling us their view. Let's just bake it into this and be done. 118 00:12:47.630 --> 00:12:49.180 ICANN - MTS - A/V: Thank you, Mark Volker. 119 00:12:50.830 --> 00:12:52.620 ICANN - MTS - A/V: Yes, I think, 120 00:12:53.030 --> 00:13:08.899 ICANN - MTS - A/V: we have been over this numerous times, and we had… I mean, this was one of the longer discussions that we had during the working group, and I think Reg is right when she puts in the chat that the working group intended what the working group proposed, and that was the… that was the intent, that was the language that we ultimately agreed on, and I think… I find it kind of… 121 00:13:09.270 --> 00:13:21.149 ICANN - MTS - A/V: Sad is the right word, it isn't the right word, but, curious that ICANN, who was in the room and who was asked to contribute and weigh in on the suggestions that we made during the time that we discussed them. 122 00:13:21.370 --> 00:13:39.079 ICANN - MTS - A/V: chose to wait with their feedback until now. I think that feedback would have been valuable and interesting at the time that we discussed it, and it could have been maybe even influenced the decision of the working group, but it was missing. Why did ICANN not make these comments? 123 00:13:39.200 --> 00:13:43.320 ICANN - MTS - A/V: And voice these concerns, or bring forth these issues. 124 00:13:43.470 --> 00:13:45.910 ICANN - MTS - A/V: At the time that we asked them to contribute them. 125 00:13:46.020 --> 00:13:52.279 ICANN - MTS - A/V: I think… That, to me, is sad and a break in the process that could have been avoided. 126 00:13:53.850 --> 00:13:56.150 ICANN - MTS - A/V: Thanks, Volker. I do want to say, however, that 127 00:13:57.030 --> 00:14:05.150 ICANN - MTS - A/V: that ICANN Org is also a member of the multi-stakeholder community, right? And under… 128 00:14:05.340 --> 00:14:11.250 ICANN - MTS - A/V: And under that theory, we could dismiss any public comment by anybody that had a representative around the table. 129 00:14:11.450 --> 00:14:17.710 ICANN - MTS - A/V: Right? So we don't… I don't think we want to do that, but I… but I will acknowledge your frustration. How's that? I can do that. 130 00:14:18.100 --> 00:14:20.159 ICANN - MTS - A/V: Reg, go ahead. 131 00:14:21.310 --> 00:14:27.770 Reg Levy – Tucows: Thanks, and… As has been said, this… the verbiage was… 132 00:14:27.930 --> 00:14:31.080 Reg Levy – Tucows: The result of a lot of backing and forcing. 133 00:14:31.580 --> 00:14:37.699 Reg Levy – Tucows: And… It feels very much like that has been tossed out the window. 134 00:14:37.930 --> 00:14:41.849 Reg Levy – Tucows: Information ordinarily accessible. 135 00:14:42.330 --> 00:14:47.009 Reg Levy – Tucows: Was put first, very specifically because… 136 00:14:47.120 --> 00:14:52.619 Reg Levy – Tucows: There is information that we are required to have that is not easily accessible. 137 00:14:53.220 --> 00:15:01.929 Reg Levy – Tucows: And so, although we have that under our contractual obligations, and when ICANN asks us for it, we can pull that data, that's very different 138 00:15:01.930 --> 00:15:13.990 Reg Levy – Tucows: From a, hopefully, reasonably quick and easy look at our files to say, okay, is there anything here that we can compare to something else that we have? 139 00:15:14.400 --> 00:15:23.749 Reg Levy – Tucows: And… For example, I'm gonna say the entire who is history of a domain. 140 00:15:24.140 --> 00:15:34.240 Reg Levy – Tucows: That may not be ordinarily accessible, and so I'm not going to compare all of the information that it used to have. 141 00:15:35.370 --> 00:15:38.110 Reg Levy – Tucows: I will compare what is currently available. 142 00:15:38.610 --> 00:15:39.710 Reg Levy – Tucows: And… 143 00:15:40.130 --> 00:15:56.619 Reg Levy – Tucows: Maybe that's… maybe that's an extreme lack, and we definitely want to make sure that a domain that transferred in that is very old, that we're still looking at every single piece of everything, but… but the point of putting information ordinarily accessible 144 00:15:56.840 --> 00:16:00.649 Reg Levy – Tucows: First was saying that that's the important piece. 145 00:16:00.920 --> 00:16:03.659 Reg Levy – Tucows: That we have systems. 146 00:16:04.200 --> 00:16:18.859 Reg Levy – Tucows: that allow us to access certain pieces of data, and that's what we're going to use, and that may differ based on what the registrar is. And as Volker said in the chat, this has been gotten over and over and over again. 147 00:16:18.940 --> 00:16:30.150 Reg Levy – Tucows: And so it is a little bit frustrating to do it again. I'm happy to continue to fight this, but again, I thought we had gotten to a place where everybody was a little bit unhappy. 148 00:16:31.300 --> 00:16:33.850 Reg Levy – Tucows: Which is the point of a true compromise. 149 00:16:34.680 --> 00:16:36.679 ICANN - MTS - A/V: Thank you, Reg. 150 00:16:37.130 --> 00:16:44.659 ICANN - MTS - A/V: Yeah, we did discuss it, for sure. Things are not thrown out the window. This is straw people text. We're… nobody is obligated 151 00:16:44.870 --> 00:16:48.980 ICANN - MTS - A/V: to accept what Nick and I did to try to bring the… 152 00:16:49.120 --> 00:16:52.590 ICANN - MTS - A/V: public comments in, so nothing's out the window. We're just… we're… 153 00:16:52.730 --> 00:16:58.449 ICANN - MTS - A/V: taking comments on the text and the temperature of the room about whether or not we want to adopt it, right? That's all. 154 00:16:58.740 --> 00:17:01.780 ICANN - MTS - A/V: Chris, go ahead. 155 00:17:03.050 --> 00:17:05.050 ICANN - MTS - A/V: Thank you, Paul. 156 00:17:07.599 --> 00:17:16.250 ICANN - MTS - A/V: I don't… I don't think it's particular… I understand the frustration, but I don't think it's particularly relevant to this discussion whether or not it should have been said in the room weeks ago. 157 00:17:16.700 --> 00:17:31.270 ICANN - MTS - A/V: But equally, I don't think that putting up the text without some clear explanation as to what's wrong with the existing text is actually a fair way of dealing with it. So if ICANN Org believes that the text that was originally there is unclear. 158 00:17:31.270 --> 00:17:39.500 ICANN - MTS - A/V: I would like an explanation of what it is that is unclear about it and why it is that their suggested text is better. 159 00:17:39.730 --> 00:17:41.990 ICANN - MTS - A/V: Given that they are being… given that… 160 00:17:42.340 --> 00:17:48.469 ICANN - MTS - A/V: Faced with a number of people in this room saying, It doesn't… it does… it… 161 00:17:48.580 --> 00:18:02.570 ICANN - MTS - A/V: It changes the import of the sentence. You're going to need to explain what the problem was with the wording you had and why you think your wording is better. I don't think it's enough to simply say this is what we think is better. You need to say why. 162 00:18:05.090 --> 00:18:08.700 ICANN - MTS - A/V: Thanks, Chris. So yeah, this is… 163 00:18:08.930 --> 00:18:12.819 ICANN - MTS - A/V: An attempt to respond to the public comment, if there is a champion. 164 00:18:13.200 --> 00:18:16.289 ICANN - MTS - A/V: For our straw person, happy to… 165 00:18:16.480 --> 00:18:19.759 ICANN - MTS - A/V: Hear from them. We've heard from people who, 166 00:18:20.340 --> 00:18:24.760 ICANN - MTS - A/V: Pointing back to how many times we've talked about this, and the fact that it was a subject of compromise. 167 00:18:25.000 --> 00:18:36.420 ICANN - MTS - A/V: So if we are going to change this, even though Nick and I proposed it, and you know, because we're trying to bring in the public's comment, right? This isn't just about what we've all said around the table. 168 00:18:36.550 --> 00:18:38.389 ICANN - MTS - A/V: I'm not married to this. 169 00:18:38.500 --> 00:18:55.560 ICANN - MTS - A/V: Right? But if somebody thinks this is better, or if they think if there's something even different than this that's better, great, let's hear. But Chris, I think that your request that somebody… that anybody that wants to make a change should be able to defend it, I think that's fair. We're gonna hear from Ching. 170 00:18:56.190 --> 00:18:59.919 ICANN - MTS - A/V: Thank you, Paul. Ching from the BC. So, I'd like to make a short point on 171 00:19:00.470 --> 00:19:07.020 ICANN - MTS - A/V: the information, right? So, I think… I'm just guessing that ICANN wants more information. 172 00:19:07.260 --> 00:19:25.499 ICANN - MTS - A/V: But at this particular case, more information is not necessarily useful. The right information is more useful, so I would rather, or the BC would probably rather to spend time on getting the right information instead of just more information. 173 00:19:25.750 --> 00:19:28.900 ICANN - MTS - A/V: This is what I'm trying to get at. Thank you. 174 00:19:29.280 --> 00:19:34.270 ICANN - MTS - A/V: Thanks, Ching. So, help me understand, is that support going back to the old, or… 175 00:19:34.630 --> 00:19:48.650 ICANN - MTS - A/V: What are you advocating for? At this point, I would rather to stick with the old one, so we don't go there. But if we're going to, for example, if the IRT want to talk about what information means, I'll be happy to. 176 00:19:48.900 --> 00:19:54.190 ICANN - MTS - A/V: Do it in terms of setting what's right for, you know, the information that we'd like to collect. 177 00:19:54.770 --> 00:19:55.839 ICANN - MTS - A/V: Thank you, Ching. 178 00:19:56.000 --> 00:19:57.510 ICANN - MTS - A/V: Back to you, Mark. 179 00:19:59.440 --> 00:20:01.230 ICANN - MTS - A/V: Mark Trachtenberg, the IPC. 180 00:20:02.030 --> 00:20:04.870 ICANN - MTS - A/V: If this is ICANN's view, Right? 181 00:20:05.290 --> 00:20:09.639 ICANN - MTS - A/V: why put it in an advisory and just not put it into the policy? Because ultimately. 182 00:20:10.100 --> 00:20:11.910 ICANN - MTS - A/V: If they put it into an advisory. 183 00:20:12.430 --> 00:20:19.529 ICANN - MTS - A/V: That's what's required anyway, but now you're just adding another level of another place that people have to look instead of just baking it into the policy itself. 184 00:20:19.870 --> 00:20:22.260 ICANN - MTS - A/V: So it just seems way more efficient if that's what they want. 185 00:20:22.560 --> 00:20:24.250 ICANN - MTS - A/V: Like, whether people agree with it or not. 186 00:20:24.500 --> 00:20:25.370 ICANN - MTS - A/V: you know. 187 00:20:26.490 --> 00:20:34.170 ICANN - MTS - A/V: Parties acknowledge that we have to go with what compliance says. We've said it a million times, what would align compliance? Well, now compliance and ICANN is telling you this is what we need, this is how we view it. 188 00:20:34.400 --> 00:20:39.880 ICANN - MTS - A/V: Why make people go to a different document, a different advisory, when it could just be in the policy itself? That seems inefficient to me. 189 00:20:41.290 --> 00:20:42.629 ICANN - MTS - A/V: And I think this language is fine. 190 00:20:44.450 --> 00:20:45.410 ICANN - MTS - A/V: Martina. 191 00:20:46.470 --> 00:20:55.340 ICANN - MTS - A/V: Thank you very much, Paul, and I hear all sides around this table, I understand the frustration, but again, from a policy perspective, government perspective. 192 00:20:55.600 --> 00:21:03.980 ICANN - MTS - A/V: We can be a bit concerned if ICANN Org does not feel like the text is adequate, but maybe I think ICANN Org initial interpretation of what we meant. 193 00:21:04.070 --> 00:21:12.779 ICANN - MTS - A/V: It's not what we meant, so now they… we have repeated what we meant, what we mean, so maybe there's a better phrasing that can be put on the table that 194 00:21:12.850 --> 00:21:24.599 ICANN - MTS - A/V: respects the compromise, the spirits of the compromise that we've reached without reopening the entire discussion, but it's not exactly the text that is here, so maybe I would put that in the hands of ICANNOR to 195 00:21:24.890 --> 00:21:30.050 ICANN - MTS - A/V: Briefly, you know, think about that. I think there would be something else textually could be. 196 00:21:30.350 --> 00:21:39.000 ICANN - MTS - A/V: played with to ensure that they're fine enough for implementing the policy, but as I said, we would like ICANN to tell us that it is fine. 197 00:21:41.190 --> 00:21:42.909 ICANN - MTS - A/V: Thanks, Martina. Reg. 198 00:21:45.060 --> 00:21:46.490 Reg Levy – Tucows: Thank you. 199 00:21:47.220 --> 00:21:57.379 Reg Levy – Tucows: Since this is something that had been discussed so often, and to Tomas's, point in the chat, that should be taken into account with public comments. 200 00:21:57.560 --> 00:22:06.139 Reg Levy – Tucows: The only way that I could live with this would be if it said, may include, but is not limited to. 201 00:22:12.130 --> 00:22:20.700 ICANN - MTS - A/V: So it would read, "Reasonably accessible to the registrar may include." But it's not limited to. 202 00:22:21.520 --> 00:22:23.390 ICANN - MTS - A/V: And then the rest of it stays. 203 00:22:23.790 --> 00:22:25.170 ICANN - MTS - A/V: The way it's written now? 204 00:22:26.410 --> 00:22:28.460 Reg Levy – Tucows: Don't love it, but I could live with it. 205 00:22:29.000 --> 00:22:37.009 Reg Levy – Tucows: I think, honestly, since we've done this so many times, that what we had before is preferable, but that seems to not be a popular position. 206 00:22:38.860 --> 00:22:39.680 ICANN - MTS - A/V: Thanks Reg. 207 00:22:40.450 --> 00:22:41.910 ICANN - MTS - A/V: Brian. 208 00:22:42.340 --> 00:23:01.460 ICANN - MTS - A/V: Thanks, Paul. Just to note, I think that what Reg proposed sounds reasonable. But I think it might be helpful, too, to understand the change that, you know, because I understand that this came from a comment maybe from ICANN Org, but there's obviously various parts of ICANN Org. And so, is this something that actually came from compliance 209 00:23:01.690 --> 00:23:05.120 ICANN - MTS - A/V: As far as a, they need this in order to 210 00:23:05.560 --> 00:23:08.489 ICANN - MTS - A/V: From an enforceability perspective, or is this… 211 00:23:08.910 --> 00:23:13.259 ICANN - MTS - A/V: somewhere else within ICANN organization as a preference, because those are two different 212 00:23:13.410 --> 00:23:27.459 ICANN - MTS - A/V: scenarios, one of which really gets to, if ICANN compliance believes it can't enforce the policy unless it has X, Y, and Z, that's a very different, different position than a preference from elsewhere in ICANN Org. 213 00:23:28.810 --> 00:23:42.899 ICANN - MTS - A/V: Thank you, Brian. We're gonna go to Jeff and ask that question, where to give us the history lesson of where the language came from. Was it compliance or someplace else? In the meantime, while you listen to him, I'd like for you to multitask and consider the Reg variant of May. 214 00:23:43.550 --> 00:23:46.680 ICANN - MTS - A/V: I'm so sorry, Peter. Sorry. Sorry, Jeff. Peter. 215 00:23:47.400 --> 00:23:52.719 ICANN - MTS - A/V: That's alright, I can live with Jeff. Peter Eakin from ICANN Org. Just to clarify, ICANN Org 216 00:23:52.880 --> 00:23:58.879 ICANN - MTS - A/V: Regularly, indeed, it's standard that we submit public, comments on PDPs. 217 00:23:59.370 --> 00:24:06.969 ICANN - MTS - A/V: And, this is the result of a cross-functional analysis that we undertake on the preliminary recommendations. 218 00:24:07.110 --> 00:24:10.470 ICANN - MTS - A/V: And that is a group that comprises representation from 219 00:24:10.890 --> 00:24:13.840 ICANN - MTS - A/V: lots of parts of ICANN Org, including compliance. 220 00:24:14.010 --> 00:24:17.390 ICANN - MTS - A/V: So, compliance were involved in this language. 221 00:24:18.770 --> 00:24:25.700 ICANN - MTS - A/V: For us, we… It is… we proposed this as a refinement suggestion. 222 00:24:26.430 --> 00:24:32.219 ICANN - MTS - A/V: Simply because we believe that the language as written 223 00:24:32.400 --> 00:24:38.910 ICANN - MTS - A/V: is potentially unclear as to exactly what, is intended. 224 00:24:39.540 --> 00:24:42.719 ICANN - MTS - A/V: So we really just posed this to the group. 225 00:24:43.540 --> 00:24:45.410 ICANN - MTS - A/V: To see, you know. 226 00:24:45.720 --> 00:24:51.719 ICANN - MTS - A/V: if there was a way of potentially unpacking it a little bit, as I saw in one of the Zoom calls. 227 00:24:51.850 --> 00:24:55.970 ICANN - MTS - A/V: comments that it was just much clearer of the intent. This is also with the. 228 00:24:56.190 --> 00:24:59.200 ICANN - MTS - A/V: With really just thinking ahead to implementation. 229 00:24:59.660 --> 00:25:06.310 ICANN - MTS - A/V: To sort of forestall, as someone says, a conversation that could happen in the IRT. 230 00:25:06.530 --> 00:25:08.570 ICANN - MTS - A/V: potentially… 231 00:25:08.950 --> 00:25:16.649 ICANN - MTS - A/V: It's better, we think, to, where possible, address these sorts of, sort of, ambiguities now, if possible, and if the working group agree. 232 00:25:19.730 --> 00:25:20.849 ICANN - MTS - A/V: Thank you, Peter. 233 00:25:21.720 --> 00:25:22.780 ICANN - MTS - A/V: Okay. 234 00:25:24.700 --> 00:25:26.460 ICANN - MTS - A/V: That's all the hands. 235 00:25:26.980 --> 00:25:33.900 ICANN - MTS - A/V: Let's open a queue on the Reg variant. Who could… who has a problem with the Reg variant? Who could live with it? 236 00:25:36.630 --> 00:25:39.800 ICANN - MTS - A/V: It would be… we would switch out the… 237 00:25:40.540 --> 00:25:45.210 ICANN - MTS - A/V: You would say, may include, but is not limited to. 238 00:25:46.980 --> 00:25:49.929 ICANN - MTS - A/V: And then we keep the rest of the straw person language. 239 00:25:51.510 --> 00:25:52.290 ICANN - MTS - A/V: Mark. 240 00:25:54.740 --> 00:25:59.060 ICANN - MTS - A/V: kind of like Mark Trachtenberg at the IPC, what I said in the chat, we just… I don't… 241 00:25:59.460 --> 00:26:09.780 ICANN - MTS - A/V: love Reddit's change, but we have to compromise here, and she's compromising by not loving the rest of the language, but being willing to live with that adjustment, so I… in the spirit of that. 242 00:26:10.450 --> 00:26:11.519 ICANN - MTS - A/V: you know, I think I could… 243 00:26:11.920 --> 00:26:18.129 ICANN - MTS - A/V: Or the IPC could maybe do the same, and, you know, if she's willing to get on board with that, then maybe that's a way to make this happen. 244 00:26:18.660 --> 00:26:23.750 ICANN - MTS - A/V: Thank you, Mark. Where everyone doesn't get exactly what they want, but we get closer to the… to what we think is best. 245 00:26:25.610 --> 00:26:26.710 ICANN - MTS - A/V: Thank you, Mark. 246 00:26:27.920 --> 00:26:30.800 ICANN - MTS - A/V: Any objections to the Reg variant? 247 00:26:33.330 --> 00:26:34.170 ICANN - MTS - A/V: Chris. 248 00:26:35.620 --> 00:26:43.939 ICANN - MTS - A/V: It's not an objection as such, it's a clarification, and I apologize profusely for having my lawyer's hat firmly screwed onto my head right now. 249 00:26:45.030 --> 00:26:48.940 ICANN - MTS - A/V: But irrespective of Reg's amendment, it seems to me that 250 00:26:49.340 --> 00:26:57.500 ICANN - MTS - A/V: The switch does make a difference because it says information the registrar is required to collect or maintain under its contractual obligations. 251 00:26:57.880 --> 00:26:58.680 ICANN - MTS - A/V: 1. 252 00:26:58.920 --> 00:27:05.000 ICANN - MTS - A/V: to information available through its technical systems and reasonably accessible. Now, what that means 253 00:27:05.250 --> 00:27:07.890 ICANN - MTS - A/V: Is that the information reasonably accessible. 254 00:27:08.720 --> 00:27:16.079 ICANN - MTS - A/V: if you parse it correctly, only applies to information available through its technical systems. Now, that may not matter, I'm not a registrar. 255 00:27:16.240 --> 00:27:30.910 ICANN - MTS - A/V: But it seems to me that having the information or where you say reasonably ordinarily at the beginning means it applies to everything. And as it's currently written, it only applies to information available through its technical systems. I have no idea if that makes any difference. 256 00:27:31.400 --> 00:27:38.410 ICANN - MTS - A/V: But it's a point, I think, it is a point of difference in the text that needs to be clear for people to understand. Thanks. 257 00:27:39.940 --> 00:27:41.030 ICANN - MTS - A/V: Thanks, Chris. 258 00:27:41.130 --> 00:27:47.139 ICANN - MTS - A/V: The way I was reading it is that the first reasonably accessible in the black font. 259 00:27:48.090 --> 00:27:52.569 ICANN - MTS - A/V: sort of takes care of that. We just use reasonably accessible again, which is 260 00:27:52.970 --> 00:27:56.649 ICANN - MTS - A/V: common in ICANN definitions, they tend to be a little bit circular. 261 00:27:56.770 --> 00:28:01.489 ICANN - MTS - A/V: I don't think because we use it later… That may be true. …that thing becomes unreasonably accessible, yeah. 262 00:28:01.980 --> 00:28:04.240 ICANN - MTS - A/V: So I think we're okay. I don't like it. 263 00:28:04.410 --> 00:28:07.500 ICANN - MTS - A/V: But… Ching. 264 00:28:08.290 --> 00:28:21.219 ICANN - MTS - A/V: Thank you, Paul. Ching from the BC. We have a short discussion, so the BC feels that the original test and the new text, pretty much, as Chris pointed out, is pretty much the same, except the reseller part, which, if… 265 00:28:21.410 --> 00:28:27.500 ICANN - MTS - A/V: If the group says, you know, the new text is better, we will actually support the new text. 266 00:28:27.820 --> 00:28:28.540 ICANN - MTS - A/V: Thanks. 267 00:28:29.010 --> 00:28:33.190 ICANN - MTS - A/V: ABC supports the Reg variant. Reg, do you support the Reg variant? 268 00:28:35.330 --> 00:28:36.210 Reg Levy – Tucows: I… 269 00:28:36.800 --> 00:28:46.160 Reg Levy – Tucows: I'm trying to make changes on the fly, and what I would really like to do is be able to type something into this so that I can read it, and… and that's not really possible right now. 270 00:28:46.410 --> 00:29:00.210 Reg Levy – Tucows: Again, my preferred is what we had agreed to before, because every single piece that is in the new proposed definition from ICANN is something that we considered and did not agree to. So… 271 00:29:00.540 --> 00:29:05.760 Reg Levy – Tucows: I'm trying to figure out how to make it be something close to what it was. 272 00:29:05.950 --> 00:29:16.200 Reg Levy – Tucows: And the maybe, but is not limited to, As… As Chris noted. 273 00:29:17.200 --> 00:29:29.300 Reg Levy – Tucows: There is a presumption in this definition as it stands that information that is reasonably accessible is not included in 274 00:29:30.490 --> 00:29:46.759 Reg Levy – Tucows: information that we're required to collect or maintain, like, that those are two different sets, and I agree with that. So as long as we say it's one or the other, great. Because it should not be both. If something is not reasonably accessible, even the… wow, I almost said a vault, but… 275 00:29:47.090 --> 00:30:01.849 Reg Levy – Tucows: Even though it exists, if it's not reasonably accessible, it ought not be reasonable for us to look at it, or to use it when we're considering our ADC. And again, that is what we got to at the end. 276 00:30:03.240 --> 00:30:20.599 Reg Levy – Tucows: And while it is interesting to note that ICANN staff thinks that all information that we are required to collect is necessarily reasonable, the way that it was written specifically said that the WG 277 00:30:20.740 --> 00:30:35.890 Reg Levy – Tucows: took that into consideration, and said that that wasn't true. And that gave us the opportunity to argue to ICANN compliance that something that we do have is not reasonably accessible. 278 00:30:36.250 --> 00:30:44.240 Reg Levy – Tucows: And that we would argue with ICANN compliance about the reasonability of that specific piece of information, and it didn't have to go through 279 00:30:44.680 --> 00:30:46.180 Reg Levy – Tucows: This whole process. 280 00:30:46.440 --> 00:30:50.270 Reg Levy – Tucows: And I'm trying to get us back to something close to that. 281 00:30:51.130 --> 00:30:55.040 Reg Levy – Tucows: So I don't know, I guess, is the answer to whether or not I still agree with my proposal. 282 00:30:56.710 --> 00:31:02.750 ICANN - MTS - A/V: Thank you, Reg. Okay, I'm asking for anybody else that wants to say something about this to get in behind Tomas. 283 00:31:02.880 --> 00:31:06.670 ICANN - MTS - A/V: Because I'm going to draw a line under it there. Martina, go ahead. 284 00:31:07.400 --> 00:31:16.090 ICANN - MTS - A/V: Thank you very much, Paul. I'm sorry to be the one more negative on Reg's proposal, but I we're not super super comfortable with May here. 285 00:31:16.560 --> 00:31:26.160 ICANN - MTS - A/V: We would prefer the ease. And I will reiterate that I think for us it's important that both registrars and ICANN are comfortable with what does this mean? 286 00:31:26.460 --> 00:31:33.950 ICANN - MTS - A/V: But maybe there's some drafting that they can do together that respects the spirits of the original sentence, and we keep the ease? 287 00:31:34.280 --> 00:31:38.349 ICANN - MTS - A/V: Because I think the May would open a bit of a Pandora box on our side. 288 00:31:40.690 --> 00:31:41.570 ICANN - MTS - A/V: Tomas. 289 00:31:42.460 --> 00:31:45.630 Thomas Rickert: Thanks so much. Hi, everybody. 290 00:31:46.110 --> 00:31:53.130 Thomas Rickert: I have a question. The way I read the original language… with, ordinarily. 291 00:31:53.310 --> 00:32:05.270 Thomas Rickert: Would not require a contracted party to pull data from systems that might not be part of the production system. 292 00:32:05.780 --> 00:32:07.919 Thomas Rickert: What do I mean by that? 293 00:32:08.080 --> 00:32:11.579 Thomas Rickert: I'm looking at this from a legal perspective, being a lawyer. 294 00:32:11.770 --> 00:32:17.349 Thomas Rickert: But you know that let's say there are invoices that you need to keep for 10 years. 295 00:32:17.770 --> 00:32:21.659 Thomas Rickert: But, the folks operating the abuse desk 296 00:32:22.030 --> 00:32:33.170 Thomas Rickert: may be blocked from access to that system, right? Because they don't need to see that data anymore, past a certain duration. So, what is the view of the… 297 00:32:33.750 --> 00:32:37.969 Thomas Rickert: Folks that, Better English speakers than me. 298 00:32:38.550 --> 00:32:42.510 Thomas Rickert: I think the… The proposed language would require 299 00:32:42.880 --> 00:32:49.390 Thomas Rickert: A contracted party to pull whatever data they have, even from systems that they may not 300 00:32:49.680 --> 00:32:54.829 Thomas Rickert: Have access to, you know, like, the bookkeeping requirements. 301 00:32:55.790 --> 00:33:01.209 Thomas Rickert: And if that were the case, then the question for the working group is, do we want contracted parties to 302 00:33:04.930 --> 00:33:21.499 Thomas Rickert: to tweak their processes counter to what GDPR would require them to do, and make data that can't ordinarily be part of a production system back to the production system. I hope that I'm making myself… Yeah, it's pretty early, so I'm not leaning one way or the other. 303 00:33:21.650 --> 00:33:27.380 Thomas Rickert: Just raising that, because I'm a little bit at loss with, Proposed new language. 304 00:33:28.690 --> 00:33:31.209 ICANN - MTS - A/V: Thanks Tomas. We have Marc and then Volker. Marc. 305 00:33:32.460 --> 00:33:34.240 ICANN - MTS - A/V: Marc Trachtenberg of the IPC. 306 00:33:35.940 --> 00:33:45.209 ICANN - MTS - A/V: I understand the argument that Reg wants to make to compliance about the things that aren't reasonably accessible because they're in different technical systems or something else, but I think that with her change, and actually even without it. 307 00:33:46.900 --> 00:33:54.700 ICANN - MTS - A/V: And going back to the language without Reg's change, as Martina says, I still think that Reg and registrars have the ability to still make that argument to compliance. 308 00:33:54.970 --> 00:33:58.180 ICANN - MTS - A/V: Compliance says you're not. You're not complying. You didn't do a reasonable investigation. 309 00:33:58.750 --> 00:34:09.100 ICANN - MTS - A/V: It's like, well, these are the things that we could look at, but we didn't look at these because they're not accessible for this reason. And then compliance could decide whether that's reasonable. So I think that argument is not precluded by this language. 310 00:34:09.250 --> 00:34:10.739 ICANN - MTS - A/V: With or without Regis Change. 311 00:34:11.010 --> 00:34:13.569 ICANN - MTS - A/V: It's still an argument that can be made to compliance. 312 00:34:13.739 --> 00:34:17.190 ICANN - MTS - A/V: Which, I think the compliance… Would be… would take into account. 313 00:34:17.440 --> 00:34:21.619 ICANN - MTS - A/V: They're not trying to unnecessarily punish the registrars, they're just trying to enforce the contracts. 314 00:34:23.620 --> 00:34:25.139 ICANN - MTS - A/V: Thanks, Mark Volker. 315 00:34:26.080 --> 00:34:32.050 ICANN - MTS - A/V: Yes, and… Parker Greiman for the record, for the RRSG. 316 00:34:32.350 --> 00:34:39.139 ICANN - MTS - A/V: We have discussed it during the working groups, but I think it bears just bringing it back for people to have it on the top of their minds. 317 00:34:39.989 --> 00:34:56.940 ICANN - MTS - A/V: when we deal with an abuse complaint, this is not a matter where we take an abuse complaint, then ruminate on that for a day or two, then we look at the data that we may have available in all the databases, and spend days and days on each abuse report to make sure that we find all the data that we have available to it. 318 00:34:57.510 --> 00:35:04.309 ICANN - MTS - A/V: And then we decide on that. Looking at an abuse complaint has to be done… doable in 5 to 10 minutes. 319 00:35:04.440 --> 00:35:13.739 ICANN - MTS - A/V: That is the time that we have available to us to, action… to review, action, and, notify. 320 00:35:14.010 --> 00:35:31.750 ICANN - MTS - A/V: that sounds like a little, because it is. However, that's the reality of how these reports have to be done, because of the volumes that we're receiving. If we are expected to look at non-production databases, reach out to resellers, what they… information they may have available, because that's in there as well. 321 00:35:31.790 --> 00:35:37.910 ICANN - MTS - A/V: That, for example, that we outsource to them, because they own the customer relationships. 322 00:35:38.020 --> 00:35:40.110 ICANN - MTS - A/V: And do all these extra steps. 323 00:35:40.440 --> 00:35:45.000 ICANN - MTS - A/V: For every abuse complaint that we receive that might warrant an ADC, 324 00:35:45.680 --> 00:35:55.700 ICANN - MTS - A/V: Do you want more abuse that we take care of less abuse? Is that the goal here? If that's the goal here, is that way we… if that is where we are, then that's what you can have, but… 325 00:35:55.920 --> 00:36:06.080 ICANN - MTS - A/V: I'm not sure that anyone will be satisfied with the result of that. The result should be a process that's workable, that's fast, expedient, and that produces results. 326 00:36:06.690 --> 00:36:10.550 ICANN - MTS - A/V: If that's not the goal, then I'm not sure why we're here. 327 00:36:12.310 --> 00:36:18.849 ICANN - MTS - A/V: Thanks, Volker. So… I said I would draw a line, after… 328 00:36:19.680 --> 00:36:22.520 ICANN - MTS - A/V: I forgot who it was. 329 00:36:22.640 --> 00:36:24.689 ICANN - MTS - A/V: And we've had 3 more pop up. 330 00:36:25.320 --> 00:36:32.780 ICANN - MTS - A/V: So, I'm gonna get criticized for this, because everybody will say I don't draw lines when I say I'll draw lines, but okay, we're almost done with the BDP. 331 00:36:32.960 --> 00:36:38.889 ICANN - MTS - A/V: So, we're gonna hear from… we're gonna hear from Mark again, then Chris again, and then Yao. 332 00:36:39.010 --> 00:36:43.710 ICANN - MTS - A/V: And then that'll be it, and then we'll have to decide what to do with this one. Mark, go ahead. 333 00:36:46.140 --> 00:36:47.860 ICANN - MTS - A/V: Marc Trachtenberg for the IPC. 334 00:36:49.470 --> 00:36:54.959 ICANN - MTS - A/V: I think the language that Fayo put in the chat is very helpful here, because it makes it extremely clear 335 00:36:55.170 --> 00:37:00.559 ICANN - MTS - A/V: that… A reasonable investigation does not require consideration of every category in every case. 336 00:37:00.790 --> 00:37:16.340 ICANN - MTS - A/V: And so this language, like, creates the universe for what's available, what could be reasonable, but then it's also limited by this implementation guidance, which makes clear that the registrar does not have to consider every one of these pieces of data. So I think that is a very helpful limitation and ensures 337 00:37:16.420 --> 00:37:22.169 ICANN - MTS - A/V: that Reg and, you know, Volker and anyone else who wants to make the argument that something was not reasonably accessible, and that's why they didn't look at it. 338 00:37:22.380 --> 00:37:23.659 ICANN - MTS - A/V: They're able to do that. 339 00:37:24.090 --> 00:37:29.530 ICANN - MTS - A/V: It's just… The language makes clear that all… the other language includes, like, what is the universe of what 340 00:37:29.930 --> 00:37:33.860 ICANN - MTS - A/V: you know, What is reasonably accessible? 341 00:37:34.340 --> 00:37:38.490 ICANN - MTS - A/V: But again, you don't have to look at every single thing. That's up to the discretion of the registrar. 342 00:37:39.850 --> 00:37:41.130 ICANN - MTS - A/V: Thanks, Mark. Chris? 343 00:37:42.110 --> 00:37:45.450 ICANN - MTS - A/V: Thank you, Paul, and I apologize for raising my hand again. 344 00:37:45.920 --> 00:37:48.329 ICANN - MTS - A/V: I may be slightly confused, and if I am. 345 00:37:48.570 --> 00:37:56.069 ICANN - MTS - A/V: I apologize again in advance. If I understand it correctly, the intent of this change is to clarify 346 00:37:56.330 --> 00:37:59.260 ICANN - MTS - A/V: What the original wording meant. Not to change it. 347 00:38:00.150 --> 00:38:03.359 ICANN - MTS - A/V: So, not to change the meaning of it. And so… 348 00:38:03.630 --> 00:38:11.919 ICANN - MTS - A/V: Arguments about the substance aren't really relevant. The question is, does this language change What was said before. 349 00:38:12.550 --> 00:38:30.849 ICANN - MTS - A/V: substantively, or is it merely a clarification? So, could I suggest that maybe the answer to… the way to deal with it might be to let the people who care about it think about it for a little while, consider the words properly, and maybe come… if it's at all possible, maybe come back to it? 350 00:38:31.130 --> 00:38:38.950 ICANN - MTS - A/V: Perhaps at the next session briefly to see whether or not they believe the wording means the same. 'Cause to ask, it's legal wording. 351 00:38:39.110 --> 00:38:43.230 ICANN - MTS - A/V: as it's currently written. I suspect it may well have been written by a lawyer, I could be wrong. 352 00:38:43.390 --> 00:38:50.169 ICANN - MTS - A/V: And therefore it may be helpful to let Volker and Reg and registrars look at it and see if, in fact. 353 00:38:50.470 --> 00:38:56.089 ICANN - MTS - A/V: They think it makes… it is simply a clarification, or it does make a… it makes a substantive difference. Thanks. 354 00:38:57.180 --> 00:39:03.109 ICANN - MTS - A/V: Thanks, Chris. The problem with kicking the can into the next session is we're not going to get done. 355 00:39:03.470 --> 00:39:10.430 ICANN - MTS - A/V: Right? And so, I hate to be that guy, but everybody had this for several days, and if we… 356 00:39:10.680 --> 00:39:16.269 ICANN - MTS - A/V: start kicking the hard stuff into the next session. We're going to end up kicking half the issues out on Thursday. 357 00:39:16.560 --> 00:39:19.510 ICANN - MTS - A/V: So, yeah. 358 00:39:20.290 --> 00:39:26.989 ICANN - MTS - A/V: Yeah, thank you. This is Yao for NPOC. Yeah, I agree with you, we need to make a decision today about this. 359 00:39:27.120 --> 00:39:32.120 ICANN - MTS - A/V: My concern is… Really, to… 360 00:39:32.410 --> 00:39:39.719 ICANN - MTS - A/V: try to understand why this, the agreed recommendation we already have for this addition is not. 361 00:39:40.280 --> 00:39:51.619 ICANN - MTS - A/V: supportive of the compliant task that ICANN or ICANN compliant will do if we maintain the recommendation as it is initial without any addition. 362 00:39:51.950 --> 00:40:04.290 ICANN - MTS - A/V: And even though with the… with the suggestion Reg made, which I'm not totally against, but I also think with the addition of wording, like resellers and other things, my… 363 00:40:04.600 --> 00:40:10.140 ICANN - MTS - A/V: We need to reconsider a role like, see what Other implication, this… 364 00:40:10.460 --> 00:40:22.589 ICANN - MTS - A/V: will imply, if we keep it like that. So, suggestion line here would be, why not keeping what we agreed on so far, and then the addition of the… for me, it's like a clarification. 365 00:40:22.880 --> 00:40:26.989 ICANN - MTS - A/V: Then we put it into into the implementation guideline. 366 00:40:27.290 --> 00:40:29.560 ICANN - MTS - A/V: So then we have a grinder. Okay. 367 00:40:30.380 --> 00:40:31.349 ICANN - MTS - A/V: Thanks, y'all. 368 00:40:32.460 --> 00:40:37.150 ICANN - MTS - A/V: Alright, so… That's a good… that's a good idea. 369 00:40:40.000 --> 00:40:47.630 ICANN - MTS - A/V: They're, they're… you know, if we're going to change something that was a subject of significant compromise, and history will record that this was 370 00:40:47.940 --> 00:40:55.559 ICANN - MTS - A/V: a significant disagreement between the IPC and the registrars, and it was resolved through the compromise language that appears in black font. 371 00:40:55.950 --> 00:41:02.659 ICANN - MTS - A/V: Folks, we need for that to be by wild acclaim, everybody claps and says we did a great job, right? So… 372 00:41:02.820 --> 00:41:11.149 ICANN - MTS - A/V: This will remain as it was. And we were gonna, you know, we have some implementation guidance to look at. 373 00:41:11.260 --> 00:41:15.090 ICANN - MTS - A/V: There's an IRT ahead. 374 00:41:15.210 --> 00:41:18.650 ICANN - MTS - A/V: There are advisories by compliance. 375 00:41:18.790 --> 00:41:22.950 ICANN - MTS - A/V: So we're gonna have to just trust the universe to unfold. 376 00:41:23.120 --> 00:41:24.890 ICANN - MTS - A/V: And we're moving on. 377 00:41:25.990 --> 00:41:27.460 ICANN - MTS - A/V: All right? 378 00:41:28.060 --> 00:41:32.740 ICANN - MTS - A/V: And I know that I probably made some people unhappy, but… Okay. 379 00:41:34.960 --> 00:41:37.339 ICANN - MTS - A/V: Let's go to the next item. 380 00:41:41.500 --> 00:41:43.419 ICANN - MTS - A/V: Record comment 4? 381 00:41:44.470 --> 00:41:45.170 ICANN - MTS - A/V: Okay. 382 00:41:49.020 --> 00:42:07.910 ICANN - MTS - A/V: Hi, everyone. So now we are seeing here, the main common clusters for Recommendation 4 and Implementation Guidance 4.1. There was one fairly editorial change that caused some confusion, the AND, OR, when we listed the non-exhaustive list. 383 00:42:08.090 --> 00:42:15.970 ICANN - MTS - A/V: Furthermore, many commenters suggested… suggested, sorry, to expand the list of indicators. 384 00:42:16.140 --> 00:42:27.740 ICANN - MTS - A/V: However, the working group noted that this is just a non-exhaustive list to take into consideration for various reasons, so we can provide some rationale or a clarification what the intent of this list is. 385 00:42:27.900 --> 00:42:36.109 ICANN - MTS - A/V: is Furthermore, there were some comments on, why this seems too flexible, why is not one 386 00:42:36.140 --> 00:42:49.699 ICANN - MTS - A/V: category mandatory. Also, we note that the working group discussed this before, and there were very clear reasons why the working group wanted to keep the list as is, because not all indicators result in the same. 387 00:42:50.630 --> 00:43:03.549 ICANN - MTS - A/V: or are connected to the same, so I think that is what the next two slides would want to clarify and just strengthen the working group rationale and intent with recommendation 4. 388 00:43:03.660 --> 00:43:06.439 ICANN - MTS - A/V: So I hand over to Paul to introduce those. 389 00:43:07.360 --> 00:43:16.659 ICANN - MTS - A/V: Thank you. There was a question in the chat, which I've just responded to from Jothan. That is correct. We are not adopting the red text, we are moving back to the black font text. 390 00:43:18.610 --> 00:43:22.059 ICANN - MTS - A/V: Okay, I need the next slide. Here we go. 391 00:43:25.490 --> 00:43:36.859 ICANN - MTS - A/V: So, here's the proposed update. Again, a straw person. This is just what leadership tried to do to incorporate public comment. It is not binding, and as we saw from the last 392 00:43:36.990 --> 00:43:41.860 ICANN - MTS - A/V: Rec. It is completely pushed back uponable. Is that a word pushed back uponable? 393 00:43:42.010 --> 00:43:54.720 ICANN - MTS - A/V: I just created a new phrase. Okay? So the proposed new language to determine whether association exists. A registrar must take into consideration reasonably accessible indicators. 394 00:43:55.060 --> 00:44:00.420 ICANN - MTS - A/V: That are relevant under the circumstances, and likely to yield useful information. 395 00:44:00.570 --> 00:44:04.000 ICANN - MTS - A/V: Such indicators may include, as applicable. 396 00:44:04.150 --> 00:44:07.559 ICANN - MTS - A/V: Registered name holder or account-related information. 397 00:44:07.850 --> 00:44:13.889 ICANN - MTS - A/V: technical indicators and indicators of coordinated activity or registration patterns. 398 00:44:14.190 --> 00:44:25.219 ICANN - MTS - A/V: When determining association, the specific elements considered in any given ADC, even within a single registrar, may vary depending upon the particular circumstances. 399 00:44:25.940 --> 00:44:33.000 ICANN - MTS - A/V: So, let us… I'm sorry. Oh, there's another slide. Okay, sorry. All that's Get to that. 400 00:44:34.060 --> 00:44:37.489 ICANN - MTS - A/V: And then the idea is to add to the implementation guidance. 401 00:44:37.790 --> 00:44:40.480 ICANN - MTS - A/V: After the current non-exhaustive list. 402 00:44:41.900 --> 00:44:49.050 ICANN - MTS - A/V: These indicators are illustrative and non-exhaustive, and their evidentiary weight may vary depending on the circumstances. 403 00:44:49.200 --> 00:44:59.370 ICANN - MTS - A/V: No single week or commonly shared infrastructure indicator necessarily establishes association or common control. In such… in such… 404 00:44:59.630 --> 00:45:02.109 ICANN - MTS - A/V: Apologies. In some circumstances. 405 00:45:02.280 --> 00:45:13.140 ICANN - MTS - A/V: One sufficiently specific indicator may support a reasonable determination of association. In other circumstances, multiple indicators may need to be considered together, okay? 406 00:45:13.590 --> 00:45:19.030 ICANN - MTS - A/V: All right, let's, open… Q on this, can I hear from Reg? 407 00:45:21.230 --> 00:45:39.320 Reg Levy – Tucows: Reg Levy from the Registrar Stakeholder Group. Strong support! I love it! Can we go back to the other slide? I have a slight quibble. Grammatically, there should not be a comma before the second AND. It should either be a colon and no AND, or simply no comma. Otherwise, love it! It's great! 408 00:45:41.640 --> 00:45:42.939 ICANN - MTS - A/V: Death to the comma. 409 00:45:44.200 --> 00:45:44.910 ICANN - MTS - A/V: All right. 410 00:45:45.990 --> 00:45:49.770 ICANN - MTS - A/V: Anyone else have anything to say about this one? 411 00:45:52.690 --> 00:45:53.640 ICANN - MTS - A/V: Jothan. 412 00:45:56.400 --> 00:46:01.389 ICANN - MTS - A/V: I… and… I'm, Jothan Frakes for the record, I'm here with my SAC hat on. 413 00:46:01.560 --> 00:46:09.980 ICANN - MTS - A/V: Really principally, it might be the case that, there may be signals that are… A. 414 00:46:10.320 --> 00:46:19.209 ICANN - MTS - A/V: Not relevant, as well. That could be, that may not be actually indicators that might, under other circumstances, show 415 00:46:19.740 --> 00:46:25.449 ICANN - MTS - A/V: association in other circumstances. So there's a… there's a larger fact pattern to look at on these. 416 00:46:25.960 --> 00:46:26.760 ICANN - MTS - A/V: Thank you. 417 00:46:28.890 --> 00:46:31.750 ICANN - MTS - A/V: Thanks, Jothan. Does that… 418 00:46:32.580 --> 00:46:36.300 ICANN - MTS - A/V: Do we need to consider a textual change for that, or is that a general comment? 419 00:46:36.550 --> 00:46:40.080 ICANN - MTS - A/V: I just take it as a general comment. I don't think that's additive. Thank you. 420 00:46:40.310 --> 00:46:41.360 ICANN - MTS - A/V: Thank you. 421 00:46:42.280 --> 00:46:45.590 ICANN - MTS - A/V: Any other hands? Anybody want to… 422 00:46:49.000 --> 00:46:51.390 ICANN - MTS - A/V: Anybody? Oh, Michaela, thank you. 423 00:46:52.470 --> 00:47:02.329 ICANN - MTS - A/V: Hi, Michaela, for the record. I'm… maybe this is just my brain, but I'm having a little trouble with the sufficiently specific indicator. 424 00:47:02.520 --> 00:47:17.260 ICANN - MTS - A/V: Like, that's not a criterion I recall us discussing, and that seems like that brings in significantly new language to consider, as an… I think that's just language I'm a little confused on. I don't know if we could provide some more clarity on that. 425 00:47:17.520 --> 00:47:35.380 ICANN - MTS - A/V: similarly, again, might just be a little jet-lagged, but I'm a little confused as to how… okay, so no singular… no single week or commonly shared indicator, la la la. But then, in some cases, one is sufficiently specific. It just seems, like, slightly logically confusing, but… 426 00:47:35.710 --> 00:47:43.550 ICANN - MTS - A/V: again, if others… if it makes sense to others, that I'll defer to the group consensus, but I think I'm a little confused about the logic of 427 00:47:43.700 --> 00:47:47.120 ICANN - MTS - A/V: No singular one, but then sometimes one singular is enough. 428 00:47:47.450 --> 00:47:49.580 ICANN - MTS - A/V: But maybe that's just the phrasing there. 429 00:47:50.380 --> 00:47:56.460 ICANN - MTS - A/V: Thanks, Michaela. I'll try to explain what we try to do with this. And I actually think the problem is that we… 430 00:47:56.950 --> 00:48:08.690 ICANN - MTS - A/V: We put sufficiently, right? That word is sort of redundant with the other thing, because if it does support a reasonable determination of association, it was therefore sufficient, right? 431 00:48:08.980 --> 00:48:20.909 ICANN - MTS - A/V: And so the idea behind no single weak or commonly shared infrastructure indicator necessarily establishes association or common control. Think about that in terms of, like. 432 00:48:21.140 --> 00:48:37.649 ICANN - MTS - A/V: DNS records, right? That, you know, if you… when you register your domain name, you sign up for your registrar's DNS, right? Well, my domain name for my law firm probably shares DNS records with, you know, a million other websites. 433 00:48:37.820 --> 00:48:40.059 ICANN - MTS - A/V: And so it wouldn't… 434 00:48:40.260 --> 00:48:58.319 ICANN - MTS - A/V: follow that, you know, that would be an indication that I'm associated with those domain names, right? So, that's an example of a weak infrastructure. association. But in some circumstances, one… and I scratched sufficient… I don't… sufficiently, I don't like it. 435 00:48:58.520 --> 00:49:07.729 ICANN - MTS - A/V: One… even though I… even though it's there. Okay, one specific indicator may support a reasonable determination of association. So, for example, if 436 00:49:08.010 --> 00:49:12.909 ICANN - MTS - A/V: There was a maliciously registered domain name. 437 00:49:13.120 --> 00:49:17.869 ICANN - MTS - A/V: by Fred Flintstone, who actually, I think I had a UDRP against at one point in my career. 438 00:49:18.030 --> 00:49:27.170 ICANN - MTS - A/V: And in that account is another maliciously registered domain name, also by Fred Flintstone. That would be an indication. 439 00:49:27.310 --> 00:49:31.950 ICANN - MTS - A/V: That's… that, to me, would be sufficient, right? And it's only one 440 00:49:32.130 --> 00:49:40.220 ICANN - MTS - A/V: one thing. So what we were trying to do with capturing this language is to explain how the sliding scale works, right? 441 00:49:40.250 --> 00:49:55.539 ICANN - MTS - A/V: And this is, this is something that, you know, Nick and I are both lawyers, so we're comfortable with because we're used to it, and especially in trademark law, we're extra used to this, right? Because no one indicator of the nine factors controls, you know, it's, you know. 442 00:49:55.540 --> 00:50:01.270 ICANN - MTS - A/V: Some can be weak, some can be strong. So that was the idea behind it, and it was actually meant to protect 443 00:50:01.830 --> 00:50:13.510 ICANN - MTS - A/V: Does that make sense? Instead of saying, oh, one info… oh, you have the same DNS because you're all reg… you're… you're all registered through Namecheap, well, then you're all guilty, right? We're trying to keep that from happening. 444 00:50:15.730 --> 00:50:34.980 ICANN - MTS - A/V: Okay? Yeah, Michaela, sorry, go ahead. Yeah, Michaela, just responding to that, so maybe this is more grammatical than anything, because it sounds like, okay, so no singular a lot, unless in some circumstances there is… like, sometimes there are cases where it's sufficient, where it's one indicator, if I understood correctly, and I think the way it's… 445 00:50:35.010 --> 00:50:47.460 ICANN - MTS - A/V: phrase now. Again, I'm not a lawyer, I'm not… specifically not a trademark lawyer, so maybe this is just language I'm not following, but I do want to make sure that it is comprehensible, because right now it just, again, seems logically confusing. 446 00:50:47.530 --> 00:50:52.530 ICANN - MTS - A/V: In some, it is sufficient, some… but not sometimes. 447 00:50:52.800 --> 00:51:02.389 ICANN - MTS - A/V: So I think if we could maybe try to play around with that language, just to make it a bit clearer, that would be appreciated. But again, if others… if it is understandable to others. 448 00:51:02.530 --> 00:51:10.469 ICANN - MTS - A/V: I'll defer my point, but I'm a bit confused still. Thanks. But I get the spirit of what you're trying to convey, just not the way it's framed now. 449 00:51:13.340 --> 00:51:20.739 ICANN - MTS - A/V: Thanks, Michaela. I guess what I'm going to do is to hit that pickleball back into your court and say, come up with the language that will make you comfortable. 450 00:51:21.030 --> 00:51:24.670 ICANN - MTS - A/V: And you can work on that while we talk to Reg Reg, go ahead. 451 00:51:25.370 --> 00:51:39.860 Reg Levy – Tucows: Don't change it. Reg Levy from the… from Tucows and the Registrar Stakeholder Group. Michaela, I do understand where you're coming from, but this makes total sense to me. And in our registrar back channel, many others. 452 00:51:40.060 --> 00:51:43.530 Reg Levy – Tucows: It's not just a single indicator. 453 00:51:44.190 --> 00:51:46.239 Reg Levy – Tucows: It's a single week indicator. 454 00:51:46.560 --> 00:51:50.809 Reg Levy – Tucows: Or it is a single, commonly shared infrastructure indicator. 455 00:51:50.920 --> 00:51:52.290 Reg Levy – Tucows: Versus… 456 00:51:52.570 --> 00:52:03.150 Reg Levy – Tucows: a sufficiently specific indicator. So, Volker put some stuff in the chat, but again, this makes total sense to me, and I'm absolutely on board with it. I can't just say. 457 00:52:03.730 --> 00:52:13.590 Reg Levy – Tucows: Well, it's using Cloudflare, so here's a million other domains with Cloudflare infrastructure, therefore there's no associated domains. 458 00:52:13.860 --> 00:52:20.070 Reg Levy – Tucows: That doesn't constitute a sufficient review because it's a weak indicator. 459 00:52:20.530 --> 00:52:29.900 Reg Levy – Tucows: What I have to do is look and see, oh, this is registered by Fred Flintstone. I've got 4 other remains registered by Fred Flintstone's. 460 00:52:30.060 --> 00:52:33.300 Reg Levy – Tucows: For some reason, that's a tongue twister for me. 461 00:52:33.440 --> 00:52:37.230 Reg Levy – Tucows: I've got 4 other domains registered by this person. 462 00:52:37.250 --> 00:52:56.619 Reg Levy – Tucows: So that is a sufficiently specific indicator. And… and it's going to be up to me to justify to ICANN which ones I used, and which… and whether or not they are considered weak or sufficiently specific. So I do understand where you're coming from, but I strongly… 463 00:52:56.620 --> 00:53:00.000 Reg Levy – Tucows: Hope that I've explained it well so that there are not changes. 464 00:53:01.790 --> 00:53:02.689 ICANN - MTS - A/V: Thanks Reg. 465 00:53:03.310 --> 00:53:04.110 ICANN - MTS - A/V: Mark? 466 00:53:07.020 --> 00:53:08.720 ICANN - MTS - A/V: or Trachtenberg for the IPC. 467 00:53:08.990 --> 00:53:14.879 ICANN - MTS - A/V: I'm generally… I think we're generally okay with all this language. I understand all the points raised, I agree with 468 00:53:15.010 --> 00:53:18.099 ICANN - MTS - A/V: Michaela's point about sufficiently specific. 469 00:53:18.290 --> 00:53:26.219 ICANN - MTS - A/V: I also understand and agree with what Reg is saying. I think maybe the solution to make it logically consistent is to replace sufficiently specific with strong. 470 00:53:26.790 --> 00:53:38.099 ICANN - MTS - A/V: Right, because you say, no single weak or commonly shared infrastructure indicator necessarily establishes association or common control, but in some circumstances, one strong, which is the opposite of the weak. 471 00:53:38.450 --> 00:53:46.889 ICANN - MTS - A/V: makes it logically consistent, and I think accomplishes the concerns that were raised by Reg and Michaela, and I think gets us to where we need to be, hopefully, if people are okay with that. 472 00:53:47.170 --> 00:53:48.780 ICANN - MTS - A/V: Maybe Reg could respond? 473 00:53:49.780 --> 00:53:54.169 ICANN - MTS - A/V: Thanks, Mark. Well, Michaela was next, but hopefully Reg can respond. Michaela? 474 00:53:55.160 --> 00:54:13.139 ICANN - MTS - A/V: I mean, I think from my side, I would have to triple check with the NCSG, but I think, to me, that sounds fine. I think that was the… I was confused about the comparison, single week versus sufficiently specific. So, to me, Mark, that's a great solution from my view, but I'll just triple check quickly and come back in the chat on that. Thanks. 475 00:54:14.400 --> 00:54:20.729 ICANN - MTS - A/V: Thank you, Michaela, and remember, Nick and I are not married to this text, we were just trying, so no one's hurting our feelings by changing 476 00:54:21.370 --> 00:54:23.530 ICANN - MTS - A/V: All right. Volker. 477 00:54:24.740 --> 00:54:33.430 ICANN - MTS - A/V: Thank you, Volker Greimann for the RRSG. I think this is necessary because it also matches our realities in how we deal with these things. 478 00:54:33.550 --> 00:54:35.570 ICANN - MTS - A/V: If… 479 00:54:35.710 --> 00:54:44.359 ICANN - MTS - A/V: We were nailed down to, always using the same indicators the same way, then we might be forced to, 480 00:54:44.850 --> 00:54:48.089 ICANN - MTS - A/V: have bad decision making in the process. 481 00:54:48.510 --> 00:55:00.749 ICANN - MTS - A/V: As an example, if we find certainly sequentially generated domains associated with a certain type of abuse, and can reasonably determine that they're all linked because of their naming conventions. 482 00:55:00.820 --> 00:55:16.819 ICANN - MTS - A/V: That doesn't mean that we have to treat all sequentially named domains that have been generated in the same manner by an algorithm, for example, the same way, because if we cannot link all of them to that kind of abuse, or they're used differently, then that might not be an indicator of abuse. 483 00:55:16.900 --> 00:55:22.079 ICANN - MTS - A/V: We must be able to treat similar. 484 00:55:22.220 --> 00:55:29.449 ICANN - MTS - A/V: topics differently, depending on the circumstances, and therefore certain circumstances that make us do something may not make us do something. In another case. 485 00:55:30.760 --> 00:55:31.969 ICANN - MTS - A/V: Thanks, Volker. 486 00:55:34.540 --> 00:55:38.960 ICANN - MTS - A/V: from my point of view, correct, right? We are trying to take the non-robotic 487 00:55:39.840 --> 00:55:43.780 ICANN - MTS - A/V: approach, right? We want humans looking at this and balancing factors. 488 00:55:44.600 --> 00:55:45.360 ICANN - MTS - A/V: Rod? 489 00:55:46.630 --> 00:55:49.180 ICANN - MTS - A/V: Yeah, Rod Rasmussen of the SSAC. 490 00:55:51.610 --> 00:55:59.979 ICANN - MTS - A/V: not on the topic that we've been talking about clarifying the language here, but I want to make sure to get in, since we're talking about the implementation guidance for 4. 491 00:56:00.210 --> 00:56:05.650 ICANN - MTS - A/V: I wanted to point out that the SSAC has published SSAC 1, or SAC 135. 492 00:56:06.210 --> 00:56:16.159 ICANN - MTS - A/V: That was… but that was noticed. It was… so we didn't have direct input on the particular language in the… in the worksheet, but we did publish 135. 493 00:56:16.310 --> 00:56:26.439 ICANN - MTS - A/V: That has been noted by others as well. In that SSAC document, we have a fairly… Comprehensive… 494 00:56:26.600 --> 00:56:33.230 ICANN - MTS - A/V: Analysis of different indicators, etc, that can be used, and how to combine them, etc. 495 00:56:33.460 --> 00:56:37.779 ICANN - MTS - A/V: And I would also note that several of the other public comments 496 00:56:38.010 --> 00:56:50.530 ICANN - MTS - A/V: got into some of these areas that I think were quite useful in many of them. Some approaches that were, unique that, were not covered by the SSAC document as well. 497 00:56:50.700 --> 00:56:59.100 ICANN - MTS - A/V: I bring this up because I think that we have a list in the implementation guidance right now. I know it's non-exhaustive. 498 00:56:59.420 --> 00:57:08.100 ICANN - MTS - A/V: It's also non-authoritative, and we now may have some authoritative resources we can point to, such as the SAC 135 document. 499 00:57:08.230 --> 00:57:10.379 ICANN - MTS - A/V: That might be worth adding. 500 00:57:10.560 --> 00:57:16.380 ICANN - MTS - A/V: A bit here to look for implementation guidance, to look towards authoritative 501 00:57:16.500 --> 00:57:23.190 ICANN - MTS - A/V: work in this topic area, and SAC 135 might be one of those to add. Thanks. 502 00:57:25.430 --> 00:57:27.360 ICANN - MTS - A/V: Thanks, Rod. Chris? 503 00:57:28.410 --> 00:57:47.970 ICANN - MTS - A/V: Thank you, Paul. Just in an attempt to clear up the misunderstandings on the wording or maybe make it a bit clearer. Part of the issue I think is that in the second sentence you say no single weak or commonly shared infrastructure indicator. I assume that in the next sentence where it says sufficiently specific indicator that you also mean infrastructure indicator, right? So that's the same thing. 504 00:57:49.610 --> 00:58:08.399 ICANN - MTS - A/V: Because you've referred to one sentence as indicator and another sentence infrastructure indicator. So I'm assuming they are intended to be the same thing. That's my… that's the first point. Second point is that in the second sentence, it doesn't actually describe the infrastructure indicator in any way, and I know that there's been use of the word strong has been… has been brought up, but it seems to me 505 00:58:08.580 --> 00:58:10.280 ICANN - MTS - A/V: That if we simply said. 506 00:58:10.490 --> 00:58:17.170 ICANN - MTS - A/V: In some circumstances, one sufficiently specific infrastructure indicator may support a reasonable determination of association. 507 00:58:17.400 --> 00:58:23.469 ICANN - MTS - A/V: In other circumstances, For example, where the indicator is weak. 508 00:58:24.540 --> 00:58:38.279 ICANN - MTS - A/V: multiple indicators may need to be considered together. In other words, string it, put it the other way around, make the clear statement about it is possible for it to be… for one indicator to be enough, but there are circumstances in which one indicator may not be enough, which includes where it's weak. 509 00:58:40.010 --> 00:58:45.019 ICANN - MTS - A/V: Thanks, Chris. I think that's significantly different than what we were trying to accomplish. We were not trying to 510 00:58:45.370 --> 00:58:53.069 ICANN - MTS - A/V: to limit the strong indicators to just infrastructure indicators, right? So the Fred Flintstone idea? Yeah. 511 00:58:53.250 --> 00:59:02.040 ICANN - MTS - A/V: So, but Chris, go ahead. Well, no, that's fine. If I've misunderstood, then I'm happy that it's not clear because I misunderstood it. 512 00:59:04.410 --> 00:59:10.369 ICANN - MTS - A/V: We're trying to call out the weakness of infrastructure indicators because they show up as a commonality. 513 00:59:10.760 --> 00:59:17.410 ICANN - MTS - A/V: As opposed to a very specific, or group of specific Or strong, under the… 514 00:59:17.660 --> 00:59:22.419 ICANN - MTS - A/V: Mark variant. Strong indicators, like Fred Flintstone. 515 00:59:22.910 --> 00:59:25.989 ICANN - MTS - A/V: Showing up as the registrant, like, for a handful. 516 00:59:27.340 --> 00:59:28.170 ICANN - MTS - A/V: Ching. 517 00:59:28.950 --> 00:59:42.370 ICANN - MTS - A/V: Thank you, Paul. Ching from the BC. So, the more I read it, the term of… the term of evidentiary weight start to pop up more. So I actually put my question there, but I'd like to… just to clarify. 518 00:59:42.370 --> 00:59:53.520 ICANN - MTS - A/V: So the example I'm giving now is, for example, there's five domains under one RNH, right? But only three resolved, right? 519 00:59:53.830 --> 01:00:08.289 ICANN - MTS - A/V: So two is not resolved. So three sharing you know one IP right. So in this text. So we're saying if registrar A has this thing this thing happening. So registrar B has the same thing happening. 520 01:00:08.430 --> 01:00:12.779 ICANN - MTS - A/V: So that means that we will be… this will be acceptable. 521 01:00:13.120 --> 01:00:29.720 ICANN - MTS - A/V: for ICANN that the ADC for Registrar A, for example, the end result is 5, and the Registrar B, the same scenario, but in Registrar B, they can only do, 3, to group 3 names, in one ADC group. 522 01:00:30.040 --> 01:00:37.040 ICANN - MTS - A/V: Does that mean that we are okay with this type of You know, evidentiary weight. 523 01:00:38.070 --> 01:00:40.279 ICANN - MTS - A/V: Just a question, to put it out there. 524 01:00:41.460 --> 01:00:56.640 ICANN - MTS - A/V: So, if I'm understanding the question, I think that answer, without the specific example, I think that answer is yes, right? Like, we want registrars thinking for themselves, right? So, because if we build out a very prescriptive policy. 525 01:00:56.660 --> 01:01:05.469 ICANN - MTS - A/V: it ages out as soon as we leave the room, because the bad guys thought of something else, right? Can I… yeah. So I'd just like to make sure the group understands this, so… 526 01:01:05.510 --> 01:01:10.310 ICANN - MTS - A/V: Even the scenario is the same. Once again, 5 names. 527 01:01:10.600 --> 01:01:13.030 ICANN - MTS - A/V: under different, ARNETCH 528 01:01:13.370 --> 01:01:26.179 ICANN - MTS - A/V: Three IP… three share one IP, the other registrar… I mean, the other RNH does the same, but the groove is fine that the end result from registrar A to registrar B could be different. 529 01:01:31.710 --> 01:01:33.190 ICANN - MTS - A/V: Okay, thanks, Ching. 530 01:01:33.380 --> 01:01:35.210 ICANN - MTS - A/V: Yeah, it could be. 531 01:01:39.040 --> 01:01:44.429 ICANN - MTS - A/V: And the only way to change that is to have a centralized whatever, and that's not what we did here. 532 01:01:45.740 --> 01:01:49.820 ICANN - MTS - A/V: For good reasons. Not the least of which is competition law. 533 01:01:50.480 --> 01:01:54.889 ICANN - MTS - A/V: Okay. Any other comments on this? 534 01:01:57.250 --> 01:01:58.299 ICANN - MTS - A/V: Michaela, go ahead. 535 01:01:58.960 --> 01:02:05.339 ICANN - MTS - A/V: Thanks, Michaela, for the record. I… I don't want to throw a wrench into this, but I think the NCSG is still… 536 01:02:05.450 --> 01:02:22.219 ICANN - MTS - A/V: confused about this language, and I promise it's not just me and my jet lag. So what we wanted to propose, perhaps to make it a bit clearer and easier, is we really like that first sentence. So these indicators are all the way to depending on the circumstances. 537 01:02:22.300 --> 01:02:26.789 ICANN - MTS - A/V: And we feel like that is more than sufficient, and we also have in… 538 01:02:26.880 --> 01:02:37.579 ICANN - MTS - A/V: the… in the rationale for 1 through 4, that no single data point will be determinative in all cases. So, from the NCSG's point of view. 539 01:02:37.730 --> 01:02:50.820 ICANN - MTS - A/V: I think we've already covered the fact that no singular one is a sufficient indicator, and I think it's pretty clear also that given the evidentiary weight may vary, and, like, the… just that first sentence should be sufficient 540 01:02:50.930 --> 01:02:53.999 ICANN - MTS - A/V: To cover everything else that's currently in red. 541 01:02:54.160 --> 01:03:03.789 ICANN - MTS - A/V: That's our view, and happy to hear what others think about that proposal. So striking everything after that first sentence, but still adding that first sentence. Thanks. 542 01:03:05.260 --> 01:03:07.639 ICANN - MTS - A/V: Thanks, Michaela. Martina. 543 01:03:09.380 --> 01:03:20.490 ICANN - MTS - A/V: I hear Michaela and I appreciate the suggestion and of course we can consider, but I do understand from reviewing all the comments indeed that there were people a bit confused about all this. 544 01:03:20.820 --> 01:03:36.810 ICANN - MTS - A/V: And I also appreciate that the Reg and Volker seem happy with this language because it does seem to reflect an operational reality, which is that if you have a very weak indicators, you need more to connect the assessment. If you have a very strong one, maybe that's sufficient. 545 01:03:37.180 --> 01:03:49.480 ICANN - MTS - A/V: in terms of clarification, and especially because people have expressed this need. I'm not sure we would need to delete everything. And I I think Reg's explanation was quite clear. So I I don't know. 546 01:03:49.680 --> 01:04:05.709 ICANN - MTS - A/V: how we could do to make it better, but striking it all together, I mean, we can consider, but I think there is a value in having these examples. Maybe you can take it up with the registrars and see if there is any language that would make it clear from your perspective. 547 01:04:06.050 --> 01:04:12.080 ICANN - MTS - A/V: which would maintain the examples, which I think were useful for the community. But it's just a suggestion. 548 01:04:14.430 --> 01:04:15.679 ICANN - MTS - A/V: Thank you, Martina. 549 01:04:17.190 --> 01:04:22.690 ICANN - MTS - A/V: All right, we have Mark. Anybody that wants to speak on this should get behind Mark, and… 550 01:04:22.810 --> 01:04:27.060 ICANN - MTS - A/V: Please don't jump in again and make me… you know. 551 01:04:27.390 --> 01:04:28.220 ICANN - MTS - A/V: Ruth. 552 01:04:28.870 --> 01:04:36.210 ICANN - MTS - A/V: make me have to, you know, extend the queue when I said I wouldn't. Otherwise, y'all are not gonna believe me. Mark, go ahead. 553 01:04:37.460 --> 01:04:39.250 ICANN - MTS - A/V: Mark Trachtenberg with the IPC. 554 01:04:40.390 --> 01:04:42.819 ICANN - MTS - A/V: I mean, I think I or we are okay with 555 01:04:43.220 --> 01:04:50.210 ICANN - MTS - A/V: either Martina's suggestion of striking all that other language, but I also see the value of having the examples in there, which is fine, too. I just… 556 01:04:50.840 --> 01:04:54.540 ICANN - MTS - A/V: Don't love specific, sufficiently specific. I think that 557 01:04:54.680 --> 01:05:00.779 ICANN - MTS - A/V: It's like you could say that you know the the name servers are sufficiently specific. They are. They're specific. It's one thing, I think. 558 01:05:01.010 --> 01:05:06.950 ICANN - MTS - A/V: Personally, strong seems to capture it better. I understand Reggie objects to it. I'm not really sure I understand the objection, but… 559 01:05:07.860 --> 01:05:18.400 ICANN - MTS - A/V: So, I'm good with just the first sentence, or the whole sentence, but just doing something that's sufficiently specific, and if strong's not good, maybe a different word could be picked to kind of capture what I think we all… everyone seems to agree on the concept. 560 01:05:18.600 --> 01:05:23.449 ICANN - MTS - A/V: Right? I don't think anyone seems to disagree, and everyone's trying to achieve the same thing. Maybe we could just… 561 01:05:24.060 --> 01:05:30.980 ICANN - MTS - A/V: Find a different word, or… Make people happy that we're… Saying what we mean. 562 01:05:34.030 --> 01:05:37.419 ICANN - MTS - A/V: Thank you, Mark. Okay. I don't see any other hands. 563 01:05:38.820 --> 01:05:44.739 ICANN - MTS - A/V: Trying to balance what I've heard, it sounds like… 564 01:05:45.480 --> 01:05:53.139 ICANN - MTS - A/V: Most of the people in the room are okay with this text, even if we don't change specific to strong. 565 01:05:53.510 --> 01:05:55.729 ICANN - MTS - A/V: I do think it conveys meaning. 566 01:05:56.110 --> 01:06:02.679 ICANN - MTS - A/V: And, we do have the NCSG wanting to strike the last two, but on the other hand. 567 01:06:03.070 --> 01:06:07.270 ICANN - MTS - A/V: This implementation guidance is to registrars, and they're happy with it. 568 01:06:07.830 --> 01:06:12.660 ICANN - MTS - A/V: And… Help that it, you know, they think it helps explain. 569 01:06:13.140 --> 01:06:21.119 ICANN - MTS - A/V: So… I think, you know, we may fiddle with the text a little bit and bring it back to you guys in the next reading, but… 570 01:06:21.290 --> 01:06:23.589 ICANN - MTS - A/V: I think the concepts are going to stay. 571 01:06:25.490 --> 01:06:26.160 ICANN - MTS - A/V: All right. 572 01:06:27.110 --> 01:06:30.370 ICANN - MTS - A/V: Let us… Is that it? 573 01:06:31.550 --> 01:06:32.520 ICANN - MTS - A/V: Okay. 574 01:06:33.610 --> 01:06:38.769 ICANN - MTS - A/V: All right. Is there anybody around the table or in the room that 575 01:06:39.630 --> 01:06:44.519 ICANN - MTS - A/V: Believes they did not get a chance to say anything they would like to say. As before. 576 01:06:44.730 --> 01:06:51.739 ICANN - MTS - A/V: This doesn't mean that you'll get your way, but if you've not had a chance to say it, let's hear it, and maybe you will get your way. Who knows? 577 01:06:52.180 --> 01:06:55.610 ICANN - MTS - A/V: Anybody did not feel heard. 578 01:06:59.770 --> 01:07:00.610 ICANN - MTS - A/V: Okay. 579 01:07:02.730 --> 01:07:09.629 ICANN - MTS - A/V: Great. Well, once again, guys, good job. And, tomorrow's our session. 580 01:07:10.030 --> 01:07:13.940 ICANN - MTS - A/V: Sunday morning at 1315. 581 01:07:14.210 --> 01:07:18.070 ICANN - MTS - A/V: And in the GNSO Council Room right here. 582 01:07:18.270 --> 01:07:24.290 ICANN - MTS - A/V: Everybody have a lovely time. I hope you get a few minutes to yourselves outside. It is beautiful. 583 01:07:24.450 --> 01:07:25.499 ICANN - MTS - A/V: Thanks very much. 584 01:07:28.290 --> 01:07:29.980 ICANN - MTS - A/V: And you can end the recording.