WEBVTT

1
00:00:03.670 --> 00:00:20.570
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.

2
00:00:20.570 --> 00:00:28.459
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.

3
00:00:29.630 --> 00:00:36.629
ICANN - MTS - A/V: Only questions, please log into Zoom, as we'll be using that to ask questions and raise your hand.

4
00:00:37.680 --> 00:00:41.809
ICANN - MTS - A/V: If you wish to speak, Please wait for the chair.

5
00:00:42.000 --> 00:00:51.679
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.

6
00:00:52.770 --> 00:00:54.080
ICANN - MTS - A/V: Thank you, Terry.

7
00:00:54.330 --> 00:01:11.980
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.

8
00:01:12.100 --> 00:01:15.070
ICANN - MTS - A/V: And to socialize what we've done.

9
00:01:15.300 --> 00:01:20.870
ICANN - MTS - A/V: And then we will finish up, with two last recommendations on Thursday.

10
00:01:21.260 --> 00:01:25.329
ICANN - MTS - A/V: The sessions are broken into a recommendation each.

11
00:01:25.460 --> 00:01:32.300
ICANN - MTS - A/V: With each recommendation, we'll also be looking at questions raised in the public comment regarding implementation guidance.

12
00:01:32.470 --> 00:01:36.529
ICANN - MTS - A/V: So, that is how we will do it.

13
00:01:36.670 --> 00:01:42.699
ICANN - MTS - A/V: Want to, just spend a few minutes, doing a generalized update for everyone in the room.

14
00:01:42.990 --> 00:01:45.239
ICANN - MTS - A/V: And we'll go on to the next slide for that.

15
00:01:46.680 --> 00:01:52.600
ICANN - MTS - A/V: So today, and tomorrow and Thursday are about public comments.

16
00:01:52.710 --> 00:01:59.490
ICANN - MTS - A/V: We, put out the draft report for public comments, and the point of that is to test

17
00:01:59.750 --> 00:02:08.489
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.

18
00:02:08.630 --> 00:02:20.469
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

19
00:02:20.500 --> 00:02:33.870
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

20
00:02:33.960 --> 00:02:37.479
ICANN - MTS - A/V: doing a lot of wordsmithing, so… but, staff will be grabbing that.

21
00:02:39.060 --> 00:02:54.760
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.

22
00:02:54.970 --> 00:03:10.210
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

23
00:03:10.330 --> 00:03:23.329
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

24
00:03:23.580 --> 00:03:39.650
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.

25
00:03:39.780 --> 00:03:48.379
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

26
00:03:48.570 --> 00:03:53.330
ICANN - MTS - A/V: to Council in December for their, consideration. So that is the…

27
00:03:53.480 --> 00:03:55.880
ICANN - MTS - A/V: That is the goal. Hopefully, we make that goal.

28
00:03:56.150 --> 00:04:06.800
ICANN - MTS - A/V: So… We will, after this and after Bali 87, we will continue to meet, on Mondays.

29
00:04:06.970 --> 00:04:15.939
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.

30
00:04:16.660 --> 00:04:19.860
ICANN - MTS - A/V: All right, let's dive into the public comment review.

31
00:04:20.070 --> 00:04:23.879
ICANN - MTS - A/V: And, I'll just.

32
00:04:24.160 --> 00:04:34.799
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.

33
00:04:34.910 --> 00:04:41.299
ICANN - MTS - A/V: And, you know, this is, nearly focused, nearly chartered, niche policy directed to do

34
00:04:41.400 --> 00:04:56.920
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.

35
00:04:57.030 --> 00:05:06.790
ICANN - MTS - A/V: About 3% requested significant changes. 12% were like other comments or no position taken.

36
00:05:06.990 --> 00:05:17.210
ICANN - MTS - A/V: And, we had, 8 preliminary recommendations that were, affected by the Public Comment 5 implementation guidance.

37
00:05:17.400 --> 00:05:21.109
ICANN - MTS - A/V: were hit. So overall broad support for the ADC framework.

38
00:05:21.220 --> 00:05:31.030
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.

39
00:05:31.130 --> 00:05:50.970
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.

40
00:05:51.060 --> 00:05:56.779
ICANN - MTS - A/V: It's good to see the level of support, support with changes.

41
00:05:56.900 --> 00:06:03.839
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.

42
00:06:04.090 --> 00:06:09.230
ICANN - MTS - A/V: And down the implementation guidance that were affected, so… Good chart.

43
00:06:09.370 --> 00:06:11.600
ICANN - MTS - A/V: I like charts. So…

44
00:06:12.390 --> 00:06:20.880
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?

45
00:06:24.230 --> 00:06:31.210
ICANN - MTS - A/V: Hi, everyone. This Feodora from ICANN Org. Just similar to what Paul just introduced.

46
00:06:31.260 --> 00:06:36.249
ICANN - MTS - A/V: This is on a high level in words that many comments support the overall ADC framework.

47
00:06:36.260 --> 00:06:52.470
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.

48
00:06:52.610 --> 00:07:00.040
ICANN - MTS - A/V: However, nonetheless, as discussed with Paul, there are still opportunities to clarify and strengthen the current language.

49
00:07:00.380 --> 00:07:09.460
ICANN - MTS - A/V: As noted, some of the comments provide substantive input on drafting ambiguities, gaps, or potential unintended consequences.

50
00:07:09.660 --> 00:07:15.179
ICANN - MTS - A/V: And those will be the ones that will be discussed during these sessions.

51
00:07:15.690 --> 00:07:24.560
ICANN - MTS - A/V: Another point to consider is that a smaller set of comments raises more More, let's say, substantive concerns.

52
00:07:24.590 --> 00:07:39.580
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…

53
00:07:39.580 --> 00:07:49.829
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

54
00:07:49.890 --> 00:08:05.039
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

55
00:08:05.230 --> 00:08:19.659
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.

56
00:08:21.290 --> 00:08:26.709
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.

57
00:08:27.590 --> 00:08:36.669
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.

58
00:08:36.909 --> 00:08:39.610
ICANN - MTS - A/V: Comment by comment, everybody can read.

59
00:08:39.770 --> 00:08:55.249
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.

60
00:08:55.300 --> 00:09:07.879
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.

61
00:09:08.040 --> 00:09:22.650
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.

62
00:09:22.810 --> 00:09:26.009
ICANN - MTS - A/V: And settled, during the process.

63
00:09:26.110 --> 00:09:32.070
ICANN - MTS - A/V: And then lastly, in terms of paths forward.

64
00:09:32.790 --> 00:09:45.570
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…

65
00:09:45.800 --> 00:09:46.760
ICANN - MTS - A/V: people.

66
00:09:47.200 --> 00:09:53.350
ICANN - MTS - A/V: Right? These are not… This is not something that, if the working group

67
00:09:54.100 --> 00:09:56.050
ICANN - MTS - A/V: You know, if y'all don't like them.

68
00:09:56.170 --> 00:10:09.059
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

69
00:10:09.120 --> 00:10:18.380
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?

70
00:10:19.120 --> 00:10:28.769
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.

71
00:10:30.410 --> 00:10:33.950
ICANN - MTS - A/V: Thank you, Paul. This is Feodora from ICANN Org again.

72
00:10:34.260 --> 00:10:50.369
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.

73
00:10:50.560 --> 00:11:04.030
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.

74
00:11:04.240 --> 00:11:14.050
ICANN - MTS - A/V: Yeah, problems when… when operating this definition or exclusion. So there will be some path forward proposed on this.

75
00:11:14.200 --> 00:11:19.500
ICANN - MTS - A/V: Furthermore, there was also many comments considering actionable evidence and clarify

76
00:11:19.580 --> 00:11:35.739
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.

77
00:11:35.850 --> 00:11:46.549
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

78
00:11:46.660 --> 00:11:50.140
ICANN - MTS - A/V: type of Dns abuse should clarify

79
00:11:50.810 --> 00:12:06.699
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

80
00:12:06.740 --> 00:12:25.469
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.

81
00:12:25.540 --> 00:12:26.780
ICANN - MTS - A/V: However.

82
00:12:27.310 --> 00:12:35.379
ICANN - MTS - A/V: The comments note that discussing primary use or purpose of use that was also A long discussion within the

83
00:12:35.530 --> 00:12:45.280
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.

84
00:12:45.290 --> 00:13:01.680
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.

85
00:13:03.580 --> 00:13:04.630
ICANN - MTS - A/V: Thank you.

86
00:13:04.770 --> 00:13:08.330
ICANN - MTS - A/V: So, this is where the fun starts, right?

87
00:13:08.540 --> 00:13:26.200
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.

88
00:13:26.460 --> 00:13:42.580
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.

89
00:13:42.810 --> 00:13:51.839
ICANN - MTS - A/V: The registrar shall reasonably determine based on the information accessible to it and the circumstances applicable to the case.

90
00:13:51.950 --> 00:13:55.170
ICANN - MTS - A/V: If the registered name is a compromised domain.

91
00:13:55.510 --> 00:14:11.639
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.

92
00:14:12.620 --> 00:14:13.370
ICANN - MTS - A/V: All right.

93
00:14:13.660 --> 00:14:24.429
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.

94
00:14:24.530 --> 00:14:39.369
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

95
00:14:39.370 --> 00:14:44.799
ICANN - MTS - A/V: maybe don't know everybody. We all know, but everybody else may not know, so appreciate that. Mark, your turn.

96
00:14:45.310 --> 00:14:49.759
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.

97
00:14:51.130 --> 00:14:55.609
ICANN - MTS - A/V: So two, I think, questions or issues here. One, I think.

98
00:14:55.840 --> 00:15:00.400
ICANN - MTS - A/V: Like, what does legitimate or benign mean? That's not necessary. I think you could just say a domain name.

99
00:15:00.670 --> 00:15:12.440
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.

100
00:15:12.640 --> 00:15:23.869
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…

101
00:15:24.080 --> 00:15:39.650
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…

102
00:15:39.860 --> 00:15:46.300
ICANN - MTS - A/V: To take into account that practical reality to address the knowledge of the ultimate

103
00:15:46.610 --> 00:15:49.390
ICANN - MTS - A/V: you know, end user or customer, and, you know, we kind of, I think.

104
00:15:49.550 --> 00:15:55.539
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.

105
00:15:56.780 --> 00:15:57.850
ICANN - MTS - A/V: Thank you, Mark.

106
00:15:58.370 --> 00:15:59.430
ICANN - MTS - A/V: Michaela

107
00:16:01.540 --> 00:16:21.520
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

108
00:16:21.630 --> 00:16:31.709
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.

109
00:16:33.190 --> 00:16:43.580
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

110
00:16:43.610 --> 00:16:53.320
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?

111
00:16:53.390 --> 00:17:01.109
ICANN - MTS - A/V: And if it is abusive, did the abuse occur with or without the knowledge of the beneficial owner?

112
00:17:01.250 --> 00:17:03.999
ICANN - MTS - A/V: That's, I think, an easier binary test.

113
00:17:04.690 --> 00:17:07.110
ICANN - MTS - A/V: And we should try to simplify and avoid.

114
00:17:07.670 --> 00:17:10.030
ICANN - MTS - A/V: Ambiguity or additional tests that aren't necessary.

115
00:17:10.310 --> 00:17:23.949
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.

116
00:17:24.030 --> 00:17:34.180
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.

117
00:17:34.320 --> 00:17:39.169
ICANN - MTS - A/V: But that being said, I don't want to harp on that point too much, but

118
00:17:39.350 --> 00:17:48.130
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…

119
00:17:48.290 --> 00:18:01.110
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.

120
00:18:01.600 --> 00:18:04.009
ICANN - MTS - A/V: Thanks, Michaela. Next up is Ching.

121
00:18:05.060 --> 00:18:10.699
ICANN - MTS - A/V: Thank you, Paul. Ching from the BC. So, I'd like to also make this clarifying question.

122
00:18:10.760 --> 00:18:28.630
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.

123
00:18:28.780 --> 00:18:38.649
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…

124
00:18:38.880 --> 00:18:43.330
ICANN - MTS - A/V: That's something that we also need to come… consider, and also to clarify.

125
00:18:43.720 --> 00:18:44.480
ICANN - MTS - A/V: Thanks.

126
00:18:45.530 --> 00:18:46.580
ICANN - MTS - A/V: Thanks, Ching.

127
00:18:46.770 --> 00:18:47.590
ICANN - MTS - A/V: Mark?

128
00:18:49.000 --> 00:18:53.569
ICANN - MTS - A/V: Mark Trachtenberg from the IPC, just to respond to Michaela's point, I think.

129
00:18:53.920 --> 00:19:04.949
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.

130
00:19:06.200 --> 00:19:08.360
ICANN - MTS - A/V: Thanks, Mark. We have Gabriel.

131
00:19:22.200 --> 00:19:24.250
ICANN - MTS - A/V: I can run a remote mic.

132
00:19:41.230 --> 00:19:42.369
ICANN - MTS - A/V: They're working on it.

133
00:19:43.400 --> 00:19:45.030
ICANN - MTS - A/V: Oh.

134
00:19:45.250 --> 00:19:47.639
ICANN - MTS - A/V: Okay, we have, we have live.

135
00:19:47.890 --> 00:19:50.820
ICANN - MTS - A/V: Sorry, you were 5 feet away. I, I…

136
00:19:51.880 --> 00:19:54.330
ICANN - MTS - A/V: It's important to get exercise after long flights.

137
00:19:55.590 --> 00:20:14.319
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.

138
00:20:14.370 --> 00:20:31.979
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

139
00:20:32.060 --> 00:20:55.789
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.

140
00:20:56.060 --> 00:21:09.530
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.

141
00:21:09.690 --> 00:21:14.220
ICANN - MTS - A/V: And lastly, with regards to legitimate or benign domain.

142
00:21:14.440 --> 00:21:19.829
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.

143
00:21:19.910 --> 00:21:24.929
ICANN - MTS - A/V: Sometimes bad guys will compromise the sites of… or accounts of other bad guys.

144
00:21:24.980 --> 00:21:40.160
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.

145
00:21:40.350 --> 00:21:41.120
ICANN - MTS - A/V: over.

146
00:21:47.210 --> 00:21:48.380
ICANN - MTS - A/V: We're checking it.

147
00:22:10.880 --> 00:22:14.239
ICANN - MTS - A/V: Hello? Okay, this is great. This is better anyways.

148
00:22:14.730 --> 00:22:21.710
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.

149
00:22:22.080 --> 00:22:25.060
ICANN - MTS - A/V: So Gabriel.

150
00:22:25.390 --> 00:22:31.679
ICANN - MTS - A/V: I think that you briefly touched on trigger, right? Because this is an exception to the trigger.

151
00:22:31.840 --> 00:22:35.600
ICANN - MTS - A/V: Right, so I don't think that… By not…

152
00:22:35.950 --> 00:22:41.130
ICANN - MTS - A/V: Saying again that the triggers triggered here in the implementation guidance that we've

153
00:22:41.380 --> 00:22:57.960
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.

154
00:23:11.200 --> 00:23:18.480
ICANN - MTS - A/V: Thank you, Farzan Badi, Non-Commercial Stakeholder Group. I just want to remind the group why we, are…

155
00:23:18.900 --> 00:23:25.809
ICANN - MTS - A/V: emphasizing in the clear definition of compromised domain. Every time we

156
00:23:26.080 --> 00:23:44.880
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.

157
00:23:44.920 --> 00:23:48.019
ICANN - MTS - A/V: have their, to be profiled.

158
00:23:48.100 --> 00:23:54.520
ICANN - MTS - A/V: And every time, we were told that compromised domains are not

159
00:23:54.630 --> 00:24:11.039
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

160
00:24:11.330 --> 00:24:21.900
ICANN - MTS - A/V: way of defining compromised domains, and not entangle them in this ADC, policy.

161
00:24:22.120 --> 00:24:33.889
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.

162
00:24:34.770 --> 00:24:35.839
ICANN - MTS - A/V: That's her thing.

163
00:24:38.910 --> 00:24:42.729
ICANN - MTS - A/V: Thank you. All right, we have Brian Cymbolic next.

164
00:24:58.640 --> 00:25:04.510
ICANN - MTS - A/V: Thank you. Thanks, everyone. Hi, Brian Cimbolic with PIR, but here for the registries.

165
00:25:04.550 --> 00:25:19.860
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.

166
00:25:19.960 --> 00:25:30.309
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…

167
00:25:30.460 --> 00:25:42.930
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

168
00:25:43.040 --> 00:26:06.620
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

169
00:26:06.620 --> 00:26:10.559
ICANN - MTS - A/V: the way to address that, and it's ICANN contractual compliance. So.

170
00:26:10.560 --> 00:26:22.689
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.

171
00:26:22.690 --> 00:26:38.780
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.

172
00:26:40.210 --> 00:26:42.249
ICANN - MTS - A/V: And where should I bring this microphone?

173
00:26:43.130 --> 00:26:44.700
ICANN - MTS - A/V: Terry's behind you.

174
00:26:44.820 --> 00:26:45.810
ICANN - MTS - A/V: Thank you.

175
00:26:48.240 --> 00:26:51.360
ICANN - MTS - A/V: All right, we have, Volker.

176
00:26:55.020 --> 00:26:56.380
ICANN - MTS - A/V: Terry's coming to you.

177
00:26:57.020 --> 00:26:59.560
ICANN - MTS - A/V: Thank you, Paul. Interesting.

178
00:26:59.730 --> 00:27:04.150
ICANN - MTS - A/V: the microphones. Volker Greimann RSG,

179
00:27:04.340 --> 00:27:19.169
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.

180
00:27:19.170 --> 00:27:34.820
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,

181
00:27:35.040 --> 00:27:49.909
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.

182
00:27:49.910 --> 00:27:59.850
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.

183
00:28:00.070 --> 00:28:02.800
ICANN - MTS - A/V: Yeah.

184
00:28:03.110 --> 00:28:06.160
ICANN - MTS - A/V: So I don't see how we need an additional,

185
00:28:06.610 --> 00:28:24.219
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.

186
00:28:24.460 --> 00:28:26.510
ICANN - MTS - A/V: Thanks, Volker. We have Mark.

187
00:28:28.700 --> 00:28:30.439
ICANN - MTS - A/V: Marc Trachtenberg, IPC.

188
00:28:30.610 --> 00:28:44.659
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.

189
00:28:45.360 --> 00:29:01.459
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.

190
00:29:02.340 --> 00:29:07.139
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.

191
00:29:07.580 --> 00:29:09.990
ICANN - MTS - A/V: the better off… work that…

192
00:29:10.270 --> 00:29:16.420
ICANN - MTS - A/V: Innocent registrants will have… will be. And also, the better off the policy will be.

193
00:29:16.560 --> 00:29:17.720
ICANN - MTS - A/V: in its purpose.

194
00:29:18.960 --> 00:29:21.540
ICANN - MTS - A/V: Thanks, Mark. We have Michaela.

195
00:29:23.110 --> 00:29:42.300
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

196
00:29:42.300 --> 00:29:49.199
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.

197
00:29:49.240 --> 00:30:00.150
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.

198
00:30:00.340 --> 00:30:11.359
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.

199
00:30:15.090 --> 00:30:19.669
Feodora Hamza - ICANN Org: Sorry. Hi, everyone.

200
00:30:20.380 --> 00:30:21.320
Feodora Hamza - ICANN Org: Awesome.

201
00:30:21.760 --> 00:30:22.950
Feodora Hamza - ICANN Org: This makes sense.

202
00:30:25.680 --> 00:30:27.450
Feodora Hamza - ICANN Org: Hello.

203
00:30:29.960 --> 00:30:31.340
ICANN - MTS - A/V: Okay, now it's better.

204
00:30:31.520 --> 00:30:45.359
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.

205
00:30:45.410 --> 00:31:02.959
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

206
00:31:03.310 --> 00:31:05.009
ICANN - MTS - A/V: everybody's,

207
00:31:05.820 --> 00:31:10.920
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.

208
00:31:11.050 --> 00:31:15.690
ICANN - MTS - A/V: But we are here again, as it seems to not provide the needed information.

209
00:31:17.000 --> 00:31:20.430
ICANN - MTS - A/V: Thanks, Fayo. Okay, we have Martina.

210
00:31:21.240 --> 00:31:22.010
ICANN - MTS - A/V: Test.

211
00:31:22.440 --> 00:31:36.510
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.

212
00:31:36.650 --> 00:31:53.850
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.

213
00:31:53.890 --> 00:31:59.300
ICANN - MTS - A/V: Which gave a number of scenarios and people help, and that helped with the implementation of the amendments.

214
00:31:59.370 --> 00:32:11.889
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.

215
00:32:11.890 --> 00:32:19.570
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.

216
00:32:19.570 --> 00:32:24.559
ICANN - MTS - A/V: I think that was a trend that emerged not only in relation to this recommendation, but for also other recommendations.

217
00:32:24.560 --> 00:32:32.940
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.

218
00:32:34.790 --> 00:32:36.160
ICANN - MTS - A/V: Thank you, Martina.

219
00:32:38.230 --> 00:32:44.379
ICANN - MTS - A/V: All right. Well, so here are the issues identified by our round robin. Okay.

220
00:32:44.620 --> 00:32:48.589
ICANN - MTS - A/V: So, we have whether or not to keep legitimate or benign.

221
00:32:49.710 --> 00:32:59.619
ICANN - MTS - A/V: How to or not adjust registered name holder to talk more about the… Underlying beneficial registrant.

222
00:33:00.770 --> 00:33:02.770
ICANN - MTS - A/V: And I thought there was a third thing.

223
00:33:03.110 --> 00:33:04.729
ICANN - MTS - A/V: But it's escaping me.

224
00:33:04.990 --> 00:33:08.209
ICANN - MTS - A/V: If you are the champion of the third thing, please let me know.

225
00:33:08.590 --> 00:33:11.489
ICANN - MTS - A/V: I will kick off discussion.

226
00:33:11.700 --> 00:33:16.480
ICANN - MTS - A/V: Want another walkthrough on legitimate and benign, let's just focus on that, okay?

227
00:33:16.840 --> 00:33:21.939
ICANN - MTS - A/V: My concern about legitimate and benign is the exact opposite of Mark's concern.

228
00:33:22.090 --> 00:33:39.960
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.

229
00:33:40.270 --> 00:33:48.379
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?

230
00:33:48.640 --> 00:33:55.090
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.

231
00:33:55.450 --> 00:33:58.230
ICANN - MTS - A/V: Right? It used to be that

232
00:33:58.450 --> 00:34:12.580
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.

233
00:34:12.940 --> 00:34:15.780
ICANN - MTS - A/V: adds a qualitative level on this.

234
00:34:15.900 --> 00:34:18.269
ICANN - MTS - A/V: That, I think, is going to be hard

235
00:34:18.560 --> 00:34:27.390
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…

236
00:34:27.550 --> 00:34:32.779
ICANN - MTS - A/V: To address that concern, and let me know if you still want to keep legitimate and benign, or…

237
00:34:33.120 --> 00:34:34.779
ICANN - MTS - A/V: Yeah, thank you.

238
00:34:36.920 --> 00:34:41.610
ICANN - MTS - A/V: Thank you. I mean, I… you know, I'm not necessarily tied to

239
00:34:42.020 --> 00:34:53.680
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.

240
00:34:54.120 --> 00:35:05.339
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.

241
00:35:06.390 --> 00:35:11.030
ICANN - MTS - A/V: Thank you, Michaela, and I think that that's… that there's appetite around this table for a definition.

242
00:35:11.250 --> 00:35:18.049
ICANN - MTS - A/V: Right? We have heard, well, we can just… from Martina, if we can't get there, we can revert back.

243
00:35:18.200 --> 00:35:37.059
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.

244
00:35:37.220 --> 00:35:42.069
ICANN - MTS - A/V: And, I have a hand from Reg. Reg, go ahead.

245
00:35:44.250 --> 00:35:58.530
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…

246
00:35:59.580 --> 00:36:18.159
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

247
00:36:18.870 --> 00:36:22.530
Reg Levy – Tucows: An indication that the domain itself.

248
00:36:23.540 --> 00:36:27.299
Reg Levy – Tucows: Is legitimate or benign, and rather that it's use.

249
00:36:27.510 --> 00:36:33.630
Reg Levy – Tucows: is legitimate or benign. So, a compromised domain means a domain name

250
00:36:33.850 --> 00:36:36.899
Reg Levy – Tucows: That is registered for a legitimate or benign.

251
00:36:37.080 --> 00:36:38.100
Reg Levy – Tucows: use.

252
00:36:38.290 --> 00:36:55.419
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.

253
00:36:57.130 --> 00:36:58.110
ICANN - MTS - A/V: Thank you, Reg.

254
00:36:59.440 --> 00:37:02.430
ICANN - MTS - A/V: Any other comments on legitimate or benign?

255
00:37:04.350 --> 00:37:09.719
ICANN - MTS - A/V: anybody… Deeply opposed to scratching legitimate or benign.

256
00:37:11.500 --> 00:37:16.810
ICANN - MTS - A/V: And just relying on the knowledge of the Domain…

257
00:37:16.930 --> 00:37:18.809
ICANN - MTS - A/V: Registrant, whoever that turns out to be.

258
00:37:20.730 --> 00:37:23.920
ICANN - MTS - A/V: Okay, off goes legitimate or benign.

259
00:37:24.320 --> 00:37:36.820
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.

260
00:37:37.970 --> 00:37:40.230
ICANN - MTS - A/V: Sure. Mark Trachtenberg, the Ipc.

261
00:37:40.450 --> 00:37:56.159
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.

262
00:37:56.330 --> 00:38:04.739
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…

263
00:38:04.980 --> 00:38:10.509
ICANN - MTS - A/V: This is a gigantic hole, because that's not really the intent. The intent is the beneficial owner.

264
00:38:10.810 --> 00:38:11.940
ICANN - MTS - A/V: Of the domain name.

265
00:38:12.240 --> 00:38:18.159
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…

266
00:38:18.300 --> 00:38:25.929
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.

267
00:38:26.910 --> 00:38:29.809
ICANN - MTS - A/V: Thank you, Mark Eberhardt.

268
00:38:31.260 --> 00:38:46.709
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.

269
00:38:46.940 --> 00:38:53.629
ICANN - MTS - A/V: The registered name holder is defined in the registrar agreement, if I'm not mistaken.

270
00:38:53.800 --> 00:38:58.479
ICANN - MTS - A/V: Traditionally, you contracted with a registrar.

271
00:38:59.110 --> 00:39:18.579
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.

272
00:39:18.710 --> 00:39:35.040
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.

273
00:39:35.210 --> 00:39:41.629
ICANN - MTS - A/V: The privacy provider is only there to hide this in the WHOIS and in the RDAP.

274
00:39:43.770 --> 00:39:46.910
ICANN - MTS - A/V: Thanks, Eberhard. Reg, go ahead.

275
00:39:48.760 --> 00:39:52.559
Reg Levy – Tucows: Thanks, Reg Levy from Tucos again. I…

276
00:39:53.220 --> 00:39:55.450
Reg Levy – Tucows: I understand where Marc is coming from.

277
00:39:55.590 --> 00:40:07.369
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.

278
00:40:07.370 --> 00:40:17.469
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…

279
00:40:18.070 --> 00:40:20.139
Reg Levy – Tucows: On our plate for today.

280
00:40:20.360 --> 00:40:23.560
Reg Levy – Tucows: Or for as long as this PDP lasts.

281
00:40:24.090 --> 00:40:33.019
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.

282
00:40:36.010 --> 00:40:38.289
ICANN - MTS - A/V: Thanks, Reg. Martina.

283
00:40:39.600 --> 00:40:44.149
ICANN - MTS - A/V: Thank you very much, Paul Martina, for representing the GAC for the records.

284
00:40:44.360 --> 00:40:51.719
ICANN - MTS - A/V: I think that I tend to agree with Reg and also with Brian. I think

285
00:40:51.720 --> 00:41:09.349
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.

286
00:41:09.400 --> 00:41:16.700
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.

287
00:41:16.810 --> 00:41:30.269
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.

288
00:41:30.930 --> 00:41:38.570
ICANN - MTS - A/V: which I'm not sure it's the most constructive for managing the expectation, especially because, as Reg said.

289
00:41:39.090 --> 00:41:51.010
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

290
00:41:51.160 --> 00:42:05.560
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.

291
00:42:07.300 --> 00:42:08.709
ICANN - MTS - A/V: Thank you, Martina.

292
00:42:09.210 --> 00:42:10.410
ICANN - MTS - A/V: We have Mark.

293
00:42:11.360 --> 00:42:13.209
ICANN - MTS - A/V: Mark Trachtenberg from the IPC.

294
00:42:13.640 --> 00:42:28.850
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.

295
00:42:29.220 --> 00:42:30.980
ICANN - MTS - A/V: and on the registered name holder issue.

296
00:42:31.130 --> 00:42:43.530
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.

297
00:42:43.650 --> 00:43:00.280
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.

298
00:43:00.890 --> 00:43:06.220
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.

299
00:43:06.490 --> 00:43:21.050
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.

300
00:43:21.770 --> 00:43:30.689
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.

301
00:43:32.560 --> 00:43:34.299
ICANN - MTS - A/V: Thank you, Mark.

302
00:43:34.860 --> 00:43:45.079
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.

303
00:43:45.860 --> 00:43:48.470
ICANN - MTS - A/V: Right? Is it… is that right?

304
00:43:48.770 --> 00:43:50.440
ICANN - MTS - A/V: One of the registrars can help me.

305
00:43:50.660 --> 00:44:02.470
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.

306
00:44:02.870 --> 00:44:06.749
ICANN - MTS - A/V: And so, wouldn't we just plop in account holder?

307
00:44:09.100 --> 00:44:22.860
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?

308
00:44:22.890 --> 00:44:32.239
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.

309
00:44:33.200 --> 00:44:47.470
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.

310
00:44:47.470 --> 00:44:53.939
ICANN - MTS - A/V: You know, the issue of the registrant as it relates to compromise, that exists under 3.18 today.

311
00:44:53.940 --> 00:45:18.389
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.

312
00:45:18.390 --> 00:45:22.969
ICANN - MTS - A/V: or ultimate underlying beneficial registrant. But it sounds to me as though if we say

313
00:45:22.970 --> 00:45:36.070
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

314
00:45:36.070 --> 00:45:43.719
ICANN - MTS - A/V: associated domain check that, in theory, also exists for 3.18.2 that we are all living under today.

315
00:45:45.430 --> 00:45:48.140
ICANN - MTS - A/V: Thank you, Brian. We have Yao

316
00:45:49.250 --> 00:46:02.590
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…

317
00:46:02.720 --> 00:46:03.710
ICANN - MTS - A/V: Other…

318
00:46:03.970 --> 00:46:13.100
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.

319
00:46:13.520 --> 00:46:27.230
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

320
00:46:27.360 --> 00:46:32.329
ICANN - MTS - A/V: having sort of, I don't think glossary word is used here, but

321
00:46:33.320 --> 00:46:39.959
ICANN - MTS - A/V: having a way to link all the time you've already been using to the actual document. For example.

322
00:46:40.280 --> 00:46:43.780
ICANN - MTS - A/V: A lot of terms from the Raa document.

323
00:46:43.910 --> 00:46:48.660
ICANN - MTS - A/V: I've been using the recommendations and… I.

324
00:46:50.110 --> 00:47:07.749
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…

325
00:47:08.000 --> 00:47:08.979
ICANN - MTS - A/V: Thank you.

326
00:47:09.730 --> 00:47:10.910
ICANN - MTS - A/V: Okay.

327
00:47:11.110 --> 00:47:15.130
ICANN - MTS - A/V: We have, reg.

328
00:47:17.160 --> 00:47:22.399
Reg Levy – Tucows: I'm so surprised. Reg Levy from Tucas and the Registrars.

329
00:47:23.570 --> 00:47:33.000
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.

330
00:47:33.130 --> 00:47:40.249
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.

331
00:47:40.760 --> 00:47:46.440
Reg Levy – Tucows: Because sometimes that is the relevant piece for certain types of registrars.

332
00:47:48.010 --> 00:47:55.969
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

333
00:47:56.440 --> 00:47:59.559
Reg Levy – Tucows: It's not really the account holder's consent.

334
00:47:59.790 --> 00:48:05.110
Reg Levy – Tucows: that is relevant for the use of a domain, right? When…

335
00:48:05.280 --> 00:48:24.840
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.

336
00:48:28.520 --> 00:48:30.569
ICANN - MTS - A/V: Okay, we have Volker and then Mark.

337
00:48:31.610 --> 00:48:36.989
ICANN - MTS - A/V: Yeah, just oh it works for the record RRSG.

338
00:48:37.710 --> 00:48:49.320
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,

339
00:48:49.560 --> 00:49:08.019
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.

340
00:49:08.220 --> 00:49:24.579
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.

341
00:49:24.580 --> 00:49:29.780
ICANN - MTS - A/V: This is not the entity that we would be looking at when it comes to.

342
00:49:29.800 --> 00:49:33.020
ICANN - MTS - A/V: the, use of the domain name. This is

343
00:49:33.070 --> 00:49:37.849
ICANN - MTS - A/V: The payer, this is the payment trail that we have to follow and have to,

344
00:49:37.970 --> 00:49:44.339
ICANN - MTS - A/V: keep data off, not the use trail, and therefore I would urge not to use that here.

345
00:49:46.450 --> 00:49:54.020
ICANN - MTS - A/V: Thanks, Volker. Registered name holder, by the way, the definition means the holder Of a registered name.

346
00:49:54.650 --> 00:49:57.990
ICANN - MTS - A/V: So, that's very, very clear. Thank you, everybody.

347
00:49:58.160 --> 00:50:00.970
ICANN - MTS - A/V: Yeah, so we got that taken care of.

348
00:50:01.370 --> 00:50:10.429
ICANN - MTS - A/V: All right, we're gonna go to Mark, but I will say this, we have the IPC and the NCSG.

349
00:50:10.600 --> 00:50:18.740
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.

350
00:50:19.110 --> 00:50:20.800
ICANN - MTS - A/V: So, Mark, go ahead.

351
00:50:23.110 --> 00:50:32.549
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.

352
00:50:32.820 --> 00:50:34.520
ICANN - MTS - A/V: I…

353
00:50:34.910 --> 00:50:42.429
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.

354
00:50:42.470 --> 00:50:47.949
ICANN - MTS - A/V: But, you know, there has to be some term, and the fact that other previous agreements made before our policies

355
00:50:47.960 --> 00:51:04.639
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

356
00:51:04.640 --> 00:51:12.550
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.

357
00:51:12.810 --> 00:51:27.399
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.

358
00:51:28.690 --> 00:51:47.199
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.

359
00:51:47.370 --> 00:51:53.440
ICANN - MTS - A/V: So, hop in now, otherwise I'm gonna draw the line, after Gabriel. Gabriel, go ahead.

360
00:51:54.400 --> 00:52:06.409
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

361
00:52:06.850 --> 00:52:16.189
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.

362
00:52:16.190 --> 00:52:29.570
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.

363
00:52:29.680 --> 00:52:38.590
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.

364
00:52:38.590 --> 00:52:52.210
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.

365
00:52:52.240 --> 00:53:02.189
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.

366
00:53:02.450 --> 00:53:09.590
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.

367
00:53:10.620 --> 00:53:12.279
ICANN - MTS - A/V: Or a third party.

368
00:53:16.010 --> 00:53:17.350
ICANN - MTS - A/V: Okay, interesting.

369
00:53:17.740 --> 00:53:26.759
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,

370
00:53:28.510 --> 00:53:36.329
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.

371
00:53:36.630 --> 00:53:46.009
ICANN - MTS - A/V: Okay, we have, a couple more things. They fall in the category of non-substantive comments on.

372
00:53:46.320 --> 00:53:51.740
ICANN - MTS - A/V: Implementation Guidance 1.1 related to actionable evidence and recurring intermittent DNS abuse.

373
00:53:51.860 --> 00:53:58.580
ICANN - MTS - A/V: and potential language to clarify the working group intent. So here's the proposed language from leadership.

374
00:53:58.840 --> 00:54:05.840
ICANN - MTS - A/V: Actionable evidence may be identified through the registrar's own analysis or received from an external source.

375
00:54:06.090 --> 00:54:09.440
ICANN - MTS - A/V: Consistent with existing contractual obligations.

376
00:54:09.640 --> 00:54:26.069
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.

377
00:54:26.280 --> 00:54:39.490
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.

378
00:54:43.420 --> 00:54:47.130
ICANN - MTS - A/V: Any, any concerns about this language? Volker?

379
00:54:48.160 --> 00:54:56.619
ICANN - MTS - A/V: Yeah, I still feel that this basically creates, definitions and obligations that govern the entire.

380
00:54:57.110 --> 00:55:05.239
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.

381
00:55:05.570 --> 00:55:07.419
ICANN - MTS - A/V: This shouldn't be in here.

382
00:55:10.140 --> 00:55:16.329
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

383
00:55:17.050 --> 00:55:19.019
ICANN - MTS - A/V: The dates, if you want.

384
00:55:19.200 --> 00:55:20.630
ICANN - MTS - A/V: So, okay.

385
00:55:23.180 --> 00:55:27.070
ICANN - MTS - A/V: Anybody else have anything to say about this? This is all good.

386
00:55:29.990 --> 00:55:31.430
ICANN - MTS - A/V: going once.

387
00:55:32.070 --> 00:55:38.549
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.

388
00:55:43.190 --> 00:55:49.279
ICANN - MTS - A/V: Okay, we're into, public comment, on Rec number 2. Fayo.

389
00:55:50.630 --> 00:56:09.769
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.

390
00:56:10.160 --> 00:56:16.269
ICANN - MTS - A/V: And we used… is being used, even though it doesn't fit the grammar, so that was the most…

391
00:56:16.620 --> 00:56:20.550
ICANN - MTS - A/V: Important part, and dr. Paul?

392
00:56:21.210 --> 00:56:26.829
ICANN - MTS - A/V: Thanks, Fayo. So this is what the tweak looks like from leadership.

393
00:56:27.290 --> 00:56:46.239
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.

394
00:56:46.340 --> 00:56:53.140
ICANN - MTS - A/V: Consistent with Recommendation 1, referring back to the trigger, as well as Recommendations 3 through 8.

395
00:56:56.480 --> 00:56:58.720
ICANN - MTS - A/V: Any concerns about this?

396
00:56:59.630 --> 00:57:00.910
ICANN - MTS - A/V: opening a queue.

397
00:57:06.380 --> 00:57:07.430
ICANN - MTS - A/V: Okay.

398
00:57:08.910 --> 00:57:10.500
ICANN - MTS - A/V: Town of Portsmouth, I'm seeing no hands.

399
00:57:12.260 --> 00:57:15.079
ICANN - MTS - A/V: Groovy, as they say. Okay.

400
00:57:18.580 --> 00:57:19.440
ICANN - MTS - A/V: Okay.

401
00:57:19.850 --> 00:57:23.119
ICANN - MTS - A/V: So… Is that it for this session?

402
00:57:27.470 --> 00:57:28.870
ICANN - MTS - A/V: Okay, Gabriel.

403
00:57:29.930 --> 00:57:41.539
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.

404
00:57:41.750 --> 00:57:45.629
ICANN - MTS - A/V: That they generally align with the agreement that they

405
00:57:45.910 --> 00:57:49.660
ICANN - MTS - A/V: I don't know if you want me to read it. I can read it for reference here.

406
00:57:50.260 --> 00:57:58.849
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.

407
00:57:58.850 --> 00:58:12.780
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.

408
00:58:12.780 --> 00:58:16.860
ICANN - MTS - A/V: And under the operational control, their operational control.

409
00:58:16.860 --> 00:58:34.480
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.

410
00:58:34.710 --> 00:58:35.519
ICANN - MTS - A/V: Over.

411
00:58:37.780 --> 00:58:43.860
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…

412
00:58:44.370 --> 00:58:59.180
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.

413
00:59:00.540 --> 00:59:08.520
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…

414
00:59:08.730 --> 00:59:10.590
ICANN - MTS - A/V: I think what the…

415
00:59:10.900 --> 00:59:27.270
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.

416
00:59:27.850 --> 00:59:31.030
ICANN - MTS - A/V: Thanks, Gabriel. Let's hear from Reg and Volker.

417
00:59:31.350 --> 00:59:32.290
ICANN - MTS - A/V: Reg first.

418
00:59:32.840 --> 00:59:36.900
Reg Levy – Tucows: Thank you. Rach Levy from Tucas and the Registrar Stakeholder Group.

419
00:59:37.570 --> 00:59:54.499
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.

420
00:59:54.620 --> 01:00:10.589
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.

421
01:00:10.960 --> 01:00:23.549
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.

422
01:00:24.080 --> 01:00:41.360
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.

423
01:00:41.590 --> 01:00:51.100
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.

424
01:00:51.330 --> 01:00:54.310
Reg Levy – Tucows: It's… it's a baffling suggestion.

425
01:00:56.720 --> 01:00:58.220
ICANN - MTS - A/V: Thanks, Reg. Volker?

426
01:00:59.990 --> 01:01:03.660
ICANN - MTS - A/V: Thank you all for the amendment for the RSD.

427
01:01:04.310 --> 01:01:23.439
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

428
01:01:23.500 --> 01:01:27.489
ICANN - MTS - A/V: TLDs across registrars, whether they're affiliated or not.

429
01:01:27.690 --> 01:01:33.169
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.

430
01:01:33.220 --> 01:01:45.110
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.

431
01:01:45.160 --> 01:01:59.100
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,

432
01:01:59.100 --> 01:02:11.819
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.

433
01:02:11.850 --> 01:02:19.010
ICANN - MTS - A/V: The same way that is currently being envisioned for, inside one registrar accreditation.

434
01:02:19.150 --> 01:02:26.959
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.

435
01:02:27.980 --> 01:02:34.080
ICANN - MTS - A/V: just as the cross registry and cross registrar for unaffiliated registrars would be.

436
01:02:35.410 --> 01:02:37.739
ICANN - MTS - A/V: Thanks, Volker. We have Mark.

437
01:02:39.000 --> 01:02:40.670
ICANN - MTS - A/V: Arch Trachtenberg, Ipc.

438
01:02:41.150 --> 01:02:47.440
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.

439
01:02:47.640 --> 01:02:56.109
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…

440
01:02:56.240 --> 01:03:00.939
ICANN - MTS - A/V: recognize and acknowledge that we have to take into account different business models, and I understand Volker's point.

441
01:03:01.510 --> 01:03:16.169
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.

442
01:03:16.370 --> 01:03:19.630
ICANN - MTS - A/V: Just like in the same way that if you have resellers, you ask the resellers.

443
01:03:19.740 --> 01:03:36.910
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.

444
01:03:37.240 --> 01:03:41.840
ICANN - MTS - A/V: So, that seems to be a simple solution for this problem that already exists, like, with the reseller model.

445
01:03:43.670 --> 01:03:45.349
ICANN - MTS - A/V: Thanks, Mark. We have Rod.

446
01:03:46.200 --> 01:03:51.149
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.

447
01:03:51.260 --> 01:03:54.500
ICANN - MTS - A/V: Points that we brought up in our feedback as well.

448
01:03:54.750 --> 01:04:08.490
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…

449
01:04:08.530 --> 01:04:09.820
ICANN - MTS - A/V: address that.

450
01:04:09.840 --> 01:04:24.909
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.

451
01:04:24.910 --> 01:04:37.339
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.

452
01:04:37.450 --> 01:04:40.870
ICANN - MTS - A/V: In that latter case, we thought that that would…

453
01:04:41.020 --> 01:04:47.609
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.

454
01:04:48.040 --> 01:04:52.849
ICANN - MTS - A/V: You know, then another domain that they already have the ability to go and examine.

455
01:04:52.990 --> 01:04:58.150
ICANN - MTS - A/V: So in that… in this case, it was more a matter of you already… you're looking across

456
01:04:58.350 --> 01:05:01.490
ICANN - MTS - A/V: the portfolio anyways.

457
01:05:01.620 --> 01:05:04.349
ICANN - MTS - A/V: Don't use this as a loophole. Thanks.

458
01:05:05.820 --> 01:05:16.439
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…

459
01:05:16.960 --> 01:05:19.170
ICANN - MTS - A/V: This is… this issue raised by Gabriel.

460
01:05:19.290 --> 01:05:29.930
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…

461
01:05:30.020 --> 01:05:43.749
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.

462
01:05:44.050 --> 01:05:53.299
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.

463
01:05:54.010 --> 01:06:02.830
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.

464
01:06:03.000 --> 01:06:06.229
ICANN - MTS - A/V: So, perfect. Ry, do you want to respond to that? Yeah.

465
01:06:06.410 --> 01:06:09.050
ICANN - MTS - A/V: just on that last point.

466
01:06:09.280 --> 01:06:17.990
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

467
01:06:18.200 --> 01:06:26.110
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.

468
01:06:26.200 --> 01:06:42.990
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.

469
01:06:43.000 --> 01:06:47.660
ICANN - MTS - A/V: And you know, and we'll we'll we'll address it, even if it's just to say.

470
01:06:47.830 --> 01:06:56.290
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?

471
01:06:56.500 --> 01:06:58.410
ICANN - MTS - A/V: Brian.

472
01:06:58.690 --> 01:06:59.710
ICANN - MTS - A/V: Thanks, Paul.

473
01:06:59.710 --> 01:07:20.740
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

474
01:07:20.740 --> 01:07:32.500
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.

475
01:07:32.560 --> 01:07:40.129
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.

476
01:07:40.190 --> 01:07:50.060
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.

477
01:07:50.060 --> 01:08:11.229
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.

478
01:08:11.230 --> 01:08:16.839
ICANN - MTS - A/V: all under the same corporate umbrella that have really different operational structures. So.

479
01:08:16.850 --> 01:08:31.239
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.

480
01:08:31.359 --> 01:08:40.090
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.

481
01:08:40.140 --> 01:09:04.290
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.

482
01:09:06.710 --> 01:09:09.730
ICANN - MTS - A/V: Thanks, Brian, that may be the solution that everybody's looking for.

483
01:09:10.109 --> 01:09:11.810
ICANN - MTS - A/V: Ching.

484
01:09:12.200 --> 01:09:20.680
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.

485
01:09:20.960 --> 01:09:24.050
ICANN - MTS - A/V: Sharing, just across…

486
01:09:24.180 --> 01:09:35.690
ICANN - MTS - A/V: Not just the registrar under common control, but interregistrar. But understand that interregistrar topics out of scope.

487
01:09:35.920 --> 01:09:52.059
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…

488
01:09:52.260 --> 01:10:05.130
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.

489
01:10:06.830 --> 01:10:08.250
ICANN - MTS - A/V: Thanks, Ching. Somebody…

490
01:10:08.520 --> 01:10:13.029
ICANN - MTS - A/V: mentioned, and I don't know if it was Volker or somebody else, the concept that you are…

491
01:10:13.470 --> 01:10:19.970
ICANN - MTS - A/V: Perhaps sitting at a dashboard, right? Because you are a registrar with multiple registrars, right?

492
01:10:20.250 --> 01:10:30.679
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

493
01:10:30.920 --> 01:10:43.190
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.

494
01:10:43.420 --> 01:10:47.759
ICANN - MTS - A/V: And you are overseeing, essentially, multiple affiliated registrars.

495
01:10:47.960 --> 01:11:04.510
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

496
01:11:04.720 --> 01:11:10.170
ICANN - MTS - A/V: We may be getting what some people want, but we can keep poking at it if we want to.

497
01:11:10.360 --> 01:11:14.280
ICANN - MTS - A/V: I'm gonna open this up to Mark. Go ahead.

498
01:11:15.260 --> 01:11:19.839
ICANN - MTS - A/V: Mark Tragenberg from the IPC poking at it slightly.

499
01:11:20.190 --> 01:11:29.890
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.

500
01:11:30.140 --> 01:11:35.680
ICANN - MTS - A/V: So that's… while on the surface, logically, it makes sense, I think there's a practical issue with that.

501
01:11:38.800 --> 01:11:41.769
ICANN - MTS - A/V: There's also sort of a really big old downside

502
01:11:42.050 --> 01:11:49.010
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…

503
01:11:49.300 --> 01:11:53.569
ICANN - MTS - A/V: Internal motivation to get to your accessible information?

504
01:11:54.370 --> 01:11:55.120
ICANN - MTS - A/V: Right?

505
01:11:56.560 --> 01:12:03.950
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.

506
01:12:04.190 --> 01:12:05.619
ICANN - MTS - A/V: But, anybody else?

507
01:12:08.700 --> 01:12:09.690
ICANN - MTS - A/V: Okay.

508
01:12:11.020 --> 01:12:13.829
ICANN - MTS - A/V: So… Is that it?

509
01:12:14.210 --> 01:12:20.419
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.

510
01:12:21.080 --> 01:12:23.689
ICANN - MTS - A/V: For recommendations 1 and 2, and…

511
01:12:24.150 --> 01:12:31.029
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?

512
01:12:32.160 --> 01:12:36.190
ICANN - MTS - A/V: Right? Not… not that you got your way, that's not the question, but…

513
01:12:36.390 --> 01:12:41.990
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…

514
01:12:42.250 --> 01:12:46.600
ICANN - MTS - A/V: Given a chance to talk. So, let's… Anybody else? Open mic.

515
01:12:49.200 --> 01:12:50.190
ICANN - MTS - A/V: Okay.

516
01:12:52.500 --> 01:12:55.150
ICANN - MTS - A/V: Great. We have… how many minutes?

517
01:12:55.980 --> 01:12:57.220
ICANN - MTS - A/V: We have 15.

518
01:12:57.890 --> 01:12:58.730
ICANN - MTS - A/V: What's that?

519
01:13:00.990 --> 01:13:01.870
ICANN - MTS - A/V: Okay.

520
01:13:02.210 --> 01:13:07.969
ICANN - MTS - A/V: So, we're, we're early. Is there anybody in the room, since this is an ICANN public meeting?

521
01:13:08.420 --> 01:13:12.110
ICANN - MTS - A/V: That has anything that they would like to say about recommendations 1 and 2?

522
01:13:15.870 --> 01:13:18.169
ICANN - MTS - A/V: Gabe, you're not in the room. Go ahead, buddy.

523
01:13:18.880 --> 01:13:31.999
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.

524
01:13:32.270 --> 01:13:41.280
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

525
01:13:41.630 --> 01:13:52.749
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

526
01:13:52.750 --> 01:14:02.570
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?

527
01:14:02.680 --> 01:14:20.689
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

528
01:14:20.770 --> 01:14:27.600
ICANN - MTS - A/V: Maliciously acquired, or acquired for malicious purposes, to incorporate that feedback that it's both

529
01:14:27.780 --> 01:14:32.530
ICANN - MTS - A/V: The situations in which the bad guys register the domain, or if they acquire it later after the fact.

530
01:14:33.040 --> 01:14:34.990
ICANN - MTS - A/V: But, throwing that out there.

531
01:14:36.750 --> 01:14:38.619
ICANN - MTS - A/V: Thank you, Gabriel. Jothan.

532
01:14:39.410 --> 01:14:44.590
ICANN - MTS - A/V: I'd kind of like to build on Gabe's wisdom. There, there are systems and and

533
01:14:44.790 --> 01:14:48.070
ICANN - MTS - A/V: Services out there where you can lease a domain.

534
01:14:48.190 --> 01:14:54.400
ICANN - MTS - A/V: And You know, you could have a, you know, a party who owns a very valuable domain name.

535
01:14:54.560 --> 01:15:09.830
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.

536
01:15:10.180 --> 01:15:14.470
ICANN - MTS - A/V: potentially an innocent party in the the person who's leasing the name.

537
01:15:14.740 --> 01:15:23.219
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.

538
01:15:23.770 --> 01:15:26.979
ICANN - MTS - A/V: Thank you, Jothan. Now we did it. We got Chris involved.

539
01:15:28.350 --> 01:15:30.839
ICANN - MTS - A/V: Yeah, thanks. Thanks, Paul.

540
01:15:32.950 --> 01:15:37.570
ICANN - MTS - A/V: I'm very wary of over-defining things. I think that…

541
01:15:37.940 --> 01:15:46.820
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.

542
01:15:47.310 --> 01:16:03.689
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…

543
01:16:03.870 --> 01:16:10.909
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.

544
01:16:12.460 --> 01:16:13.600
ICANN - MTS - A/V: Thanks, Chris.

545
01:16:15.930 --> 01:16:18.230
ICANN - MTS - A/V: Anyone else? Oh, Mark, go ahead.

546
01:16:18.810 --> 01:16:29.460
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.

547
01:16:29.620 --> 01:16:31.819
ICANN - MTS - A/V: Because they would have acquired the domain name, and I think…

548
01:16:31.980 --> 01:16:44.130
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.

549
01:16:44.170 --> 01:16:55.719
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.

550
01:16:58.930 --> 01:16:59.959
ICANN - MTS - A/V: Thanks, Mark.

551
01:17:00.600 --> 01:17:02.640
ICANN - MTS - A/V: Michaela

552
01:17:04.750 --> 01:17:24.039
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.

553
01:17:25.170 --> 01:17:33.320
ICANN - MTS - A/V: Music to your chair's ears. Okay. Chris, back to you. Yeah, I agree. I think it can be addressed.

554
01:17:33.880 --> 01:17:38.800
ICANN - MTS - A/V: Otherwise, I think what we're saying is that We think that.

555
01:17:40.330 --> 01:17:45.540
ICANN - MTS - A/V: Compliance would look at a domain that's being used badly and say.

556
01:17:45.660 --> 01:17:54.280
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…

557
01:17:54.490 --> 01:17:55.920
ICANN - MTS - A/V: We can pick up that point.

558
01:17:56.710 --> 01:17:57.500
ICANN - MTS - A/V: implementation.

559
01:17:59.400 --> 01:18:02.400
ICANN - MTS - A/V: Thank you. All right, we're going back to Mark.

560
01:18:04.200 --> 01:18:05.860
ICANN - MTS - A/V: Mark Trachtenberg, IPC.

561
01:18:06.430 --> 01:18:18.169
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…

562
01:18:18.170 --> 01:18:26.519
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…

563
01:18:26.860 --> 01:18:32.070
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.

564
01:18:33.350 --> 01:18:35.999
ICANN - MTS - A/V: Now, Mark, that was my very first punt of the day.

565
01:18:38.510 --> 01:18:40.609
ICANN - MTS - A/V: All right. Oh, Brian.

566
01:18:40.910 --> 01:18:54.949
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.

567
01:18:54.950 --> 01:19:04.589
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.

568
01:19:04.590 --> 01:19:14.749
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.

569
01:19:15.060 --> 01:19:15.950
ICANN - MTS - A/V: here.

570
01:19:18.290 --> 01:19:19.860
ICANN - MTS - A/V: Thanks, Brian. Back to Mark.

571
01:19:20.370 --> 01:19:22.700
ICANN - MTS - A/V: Mark Trachtenberg for the IPC.

572
01:19:22.760 --> 01:19:39.770
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…

573
01:19:39.790 --> 01:19:57.269
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.

574
01:19:57.320 --> 01:20:02.930
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.

575
01:20:03.720 --> 01:20:07.860
ICANN - MTS - A/V: Leave it for later, but let's try to be the edge case and not the default.

576
01:20:09.090 --> 01:20:10.719
ICANN - MTS - A/V: Thanks, Mark. We're here from Fayetteville.

577
01:20:12.170 --> 01:20:12.680
Feodora Hamza - ICANN Org: No.

578
01:20:14.080 --> 01:20:15.679
ICANN - MTS - A/V: Hi everyone, just…

579
01:20:15.710 --> 01:20:26.499
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

580
01:20:26.510 --> 01:20:44.849
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.

581
01:20:44.940 --> 01:20:46.130
ICANN - MTS - A/V: This helps a bit.

582
01:20:46.790 --> 01:20:47.640
ICANN - MTS - A/V: Thank you.

583
01:20:49.000 --> 01:20:50.740
ICANN - MTS - A/V: Any other comments on this?

584
01:20:54.560 --> 01:20:58.950
ICANN - MTS - A/V: All right, leadership will take that back and give that some pondering.

585
01:21:01.440 --> 01:21:02.370
ICANN - MTS - A/V: All right.

586
01:21:04.060 --> 01:21:09.869
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.

587
01:21:10.100 --> 01:21:10.880
ICANN - MTS - A/V: Where is it?

588
01:21:13.780 --> 01:21:17.240
ICANN - MTS - A/V: Is this working? Oh, it is working, Farzad Abadi.

589
01:21:17.880 --> 01:21:26.470
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.

590
01:21:26.720 --> 01:21:32.640
ICANN - MTS - A/V: Of how you display and tell us, what sorts of support.

591
01:21:33.310 --> 01:21:41.770
ICANN - MTS - A/V: The PDP recommendations have had… I, advise against saying that…

592
01:21:42.360 --> 01:21:51.140
ICANN - MTS - A/V: 83% of the public comments supported the recommendations, so we are on the right track.

593
01:21:51.390 --> 01:22:10.210
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

594
01:22:10.380 --> 01:22:14.950
ICANN - MTS - A/V: Talk about the public comments and how we, assess the…

595
01:22:15.120 --> 01:22:23.040
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.

596
01:22:23.190 --> 01:22:25.960
ICANN - MTS - A/V: And we take people's concerns into account.

597
01:22:26.350 --> 01:22:27.039
ICANN - MTS - A/V: Thank you.

598
01:22:30.280 --> 01:22:31.120
ICANN - MTS - A/V: Thank you.

599
01:22:32.040 --> 01:22:33.080
ICANN - MTS - A/V: Anyone else?

600
01:22:37.220 --> 01:22:39.900
ICANN - MTS - A/V: Okay, well, let's not.

601
01:22:40.290 --> 01:22:50.159
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

602
01:22:50.330 --> 01:23:00.139
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.

603
01:23:04.240 --> 01:23:05.780
ICANN - MTS - A/V: You can stop the recording.