WEBVTT

1
00:00:02.580 --> 00:00:07.569
ICANN - MTS - A/V: Hello, and welcome to the NCSG Policy Committee Work Session 1 of 2.

2
00:00:07.730 --> 00:00:21.569
ICANN - MTS - A/V: Please note that this session is being recorded and is governed by the ICANN Expected Standards of Behavior, the ICANN Community Anti-Harassment Policy, and the ICANN Community Participant Code of Conduct concerning statements of interest.

3
00:00:21.870 --> 00:00:28.429
ICANN - MTS - A/V: Please observe the following guidelines to participate in this session. I will also post them in the chat for your reference.

4
00:00:28.680 --> 00:00:39.329
ICANN - MTS - A/V: Only questions posted in the Zoom chat identified as a question will be read aloud during this session, as time permits, and when directed by the chair of this session.

5
00:00:39.680 --> 00:00:44.510
ICANN - MTS - A/V: If you wish to speak, please raise your hand in Zoom, or otherwise as directed.

6
00:00:44.960 --> 00:00:50.359
ICANN - MTS - A/V: When speaking, please state your name for the record, and speak clearly at a moderate pace.

7
00:00:50.560 --> 00:00:54.090
ICANN - MTS - A/V: I will now hand the floor over to Rafiq Damak. You may begin.

8
00:00:56.110 --> 00:01:04.989
ICANN - MTS - A/V: Thanks, Andrea. Thanks to everyone for joining today for our first NCSE session of ICANN 87 in Bali.

9
00:01:05.110 --> 00:01:12.089
ICANN - MTS - A/V: Yesterday we had the day 0 with for the non-contract party house. But this is our official

10
00:01:12.380 --> 00:01:18.730
ICANN - MTS - A/V: First official meeting here, and starting with the Policy Committee session.

11
00:01:19.840 --> 00:01:28.780
ICANN - MTS - A/V: Where we, hopefully will set our priorities and plan for the next days in this ICANN meeting.

12
00:01:29.140 --> 00:01:35.759
ICANN - MTS - A/V: And this session will be chaired by Farisan Abadiri, who is our Policy Committee Chair.

13
00:01:36.250 --> 00:01:37.839
ICANN - MTS - A/V: So, Ferdinand, over to you.

14
00:01:38.670 --> 00:01:43.700
ICANN - MTS - A/V: Thank you, Rafiq. I thought that, we should

15
00:01:43.940 --> 00:01:56.739
ICANN - MTS - A/V: because of the, good meetings that we had yesterday, and also, the, SSAT SRT meeting, and generally the past 6 months, many

16
00:01:57.110 --> 00:02:10.859
ICANN - MTS - A/V: topic areas that we care about have sprung up, like, remedy for domain name registrant, like, transparency and stuff like that. I thought that maybe, as well as talking about our priorities for the week.

17
00:02:10.860 --> 00:02:26.120
ICANN - MTS - A/V: We should, talk about top, topics that we want to advocate for and, have, like, potentially a policy, development.

18
00:02:26.620 --> 00:02:28.329
ICANN - MTS - A/V: process for them.

19
00:02:28.510 --> 00:02:31.180
ICANN - MTS - A/V: And next slide, Andrew.

20
00:02:33.920 --> 00:02:46.580
ICANN - MTS - A/V: So, and also I go a little bit over the, council agenda, and we can also talk about the GNSO Council meeting with the board.

21
00:02:46.910 --> 00:02:49.370
ICANN - MTS - A/V: Next slide.

22
00:02:50.500 --> 00:02:55.710
ICANN - MTS - A/V: So these are the priorities that…

23
00:02:56.140 --> 00:03:10.979
ICANN - MTS - A/V: We have identified throughout our engagement at the moment with DNS abuse, mitigation, PDP, and also with the, SRT.

24
00:03:11.310 --> 00:03:21.320
ICANN - MTS - A/V: group. Srt group is the is the group that discusses the disclosure of domain name registrant, private personal data to 3rd parties.

25
00:03:21.850 --> 00:03:32.059
ICANN - MTS - A/V: One thing that we really care about is the matter of remedy, because, today actually is the DNS Abuse PDP Day.

26
00:03:32.270 --> 00:03:41.289
ICANN - MTS - A/V: And, and if you, and I encourage all of you to attend those meetings, even if you are not a member.

27
00:03:41.350 --> 00:04:01.160
ICANN - MTS - A/V: Because you will see where we have lost, and what we have gained. We actually managed to, to put a lot of human rights respecting language about, like, proportionality of, mitigation and associated domain check.

28
00:04:01.360 --> 00:04:16.010
ICANN - MTS - A/V: And, also, like, excluding compromised domains from the, from the scope of the, of the policy. But at the end of the day, we did not really get.

29
00:04:16.269 --> 00:04:27.460
ICANN - MTS - A/V: Like, for example, privacy protection, language in the, policy recommendation. And, and…

30
00:04:27.670 --> 00:04:42.359
ICANN - MTS - A/V: So, there were some issues that we did not get, and one of the most important one was that… was the matter of remedy. So, what would happen if things go wrong? If you do the associated domain check.

31
00:04:42.670 --> 00:04:52.359
ICANN - MTS - A/V: And then, you see that, like, the registrar would take action against an account that would

32
00:04:52.410 --> 00:05:08.270
ICANN - MTS - A/V: hamper like that is wrongly accused of DNS abuse. How can they retrieve it? How can they, complain about it? These are the things that we don't have. We don't have them in the, policy development process.

33
00:05:08.410 --> 00:05:14.450
ICANN - MTS - A/V: at the moment in the DNS abuse mitigation. So, when we were talking to the community about all this.

34
00:05:15.520 --> 00:05:34.600
ICANN - MTS - A/V: They are of the opinion that remedy should have its own PDP. Now, one of the things that I don't personally agree with, because I think that when you come up with any kind of policy, of course, I agree that we need to have a remedy as a

35
00:05:34.760 --> 00:05:43.480
ICANN - MTS - A/V: as a, overarching structure, but I think every PDP needs to answer this one question.

36
00:05:43.650 --> 00:05:45.310
ICANN - MTS - A/V: If things go wrong.

37
00:05:45.470 --> 00:05:50.399
ICANN - MTS - A/V: What sort of recourse the domain name registrant has?

38
00:05:50.730 --> 00:06:04.430
ICANN - MTS - A/V: Is there already a recourse? Can they go and complain? Is it effective or not? But, the community wants to, the community has been talking about, like, doing, like, a separate PDP.

39
00:06:04.840 --> 00:06:20.990
ICANN - MTS - A/V: that, talks about remedy, but it's not only remedy for DNS abuse mitigation, it's a remedy for, like, you know, it's kind of, like, overarching remedy for… so that domain name registering can go and conflict.

40
00:06:21.230 --> 00:06:34.219
ICANN - MTS - A/V: Now, we have a session, a cross-community session on Monday that talks about remedy, and I am going to pass it on to my colleague Michaela

41
00:06:34.290 --> 00:06:46.179
ICANN - MTS - A/V: To, tell us a little bit about, this, topic of remedy, and, what we want to cover, and what are the… and also, like.

42
00:06:46.490 --> 00:07:00.080
ICANN - MTS - A/V: I don't think we can get remedy language in the DNS abuse mitigation PDP1, but what can we do in the next iterations of PDPs?

43
00:07:02.840 --> 00:07:17.770
ICANN - MTS - A/V: Thank you so much, Farzi. Michaela, for the record. I think what would be helpful to draw attention to is, you know, since we've been discussing this so much in the community, what I think is a pretty good win is that we do have a dedicated session later this week.

44
00:07:17.880 --> 00:07:31.750
ICANN - MTS - A/V: On Thursday, with the contracted party's house, we'll be discussing exactly this. We have about 30 minutes on the agenda to discuss what could be options for moving forward as a community, and specifically for our two houses.

45
00:07:31.750 --> 00:07:41.659
ICANN - MTS - A/V: to come together, or two groups, the NCSG and the CPH, on this topic, and I agree, Farzi, I'm not sure how far we'll get within the PDP itself.

46
00:07:41.690 --> 00:07:48.589
ICANN - MTS - A/V: That being said, I was pretty heartened when I went through the public comments that came in. There were a number of people who pointed to that gap.

47
00:07:48.650 --> 00:08:04.419
ICANN - MTS - A/V: in remedy, and I think there might be some room for… a little bit of wiggle room there, potentially, to try to put in something like a requirement to notify the affected registrant when a registrar takes action against an associated domain. I might be a little too optimistic.

48
00:08:04.420 --> 00:08:13.519
ICANN - MTS - A/V: But I think there is plenty of discussion there. And similarly, perhaps a requirement to have a process.

49
00:08:13.520 --> 00:08:33.119
ICANN - MTS - A/V: for restoration of domain name, maybe without going to the same level of specifics that we would want in a separate PDP or whatever process we end up going with within ICANN. But just a few kind of more… to get into the details of what we would want to see, which is more likely going to be outside of the policy development process.

50
00:08:33.120 --> 00:08:45.830
ICANN - MTS - A/V: This would be something along the lines of, you know, when mitigation action has been taken on a registrant's domain name, a registrant should be entitled to things like appropriate notice on the mitigation decision.

51
00:08:45.830 --> 00:08:54.139
ICANN - MTS - A/V: A general explanation of the relevance of the action. Information concerning where remediation could be available and where that's applicable.

52
00:08:54.140 --> 00:09:03.299
ICANN - MTS - A/V: and access to a reasonable mechanism to review reconsideration. So this is, you know, very typical and standard due process procedures, and

53
00:09:03.300 --> 00:09:16.470
ICANN - MTS - A/V: that would be something that we would want to see, ideally standardized, at least as a baseline, as a requirement from the contractual agreements that contracted parties have with ICANN. And ideally, we'd want this to go further, so this is also perhaps

54
00:09:16.510 --> 00:09:22.850
ICANN - MTS - A/V: We could bookmark this to also discuss with folks in other constituency groups like the CCTLDs or the GAC.

55
00:09:23.430 --> 00:09:29.289
ICANN - MTS - A/V: Similarly, where there's mitigation action that has led to something erroneous.

56
00:09:29.370 --> 00:09:41.170
ICANN - MTS - A/V: We would want to see registrars and registries have processes capable of correcting or reversing this. So it's not enough just to have an option to appeal. We want to actually have the ability to rectify whatever went wrong.

57
00:09:41.170 --> 00:09:50.559
ICANN - MTS - A/V: So this could be something like an independent appeal process, a contact form with a clear procedure, or an accessible process for reversal and reinstatement.

58
00:09:50.560 --> 00:10:03.449
ICANN - MTS - A/V: But those are just some initial ideas that Farzi and I have been tossing around, among others in the group. Don't know if anyone has questions, or if I went too quickly, or if the coffee hasn't kicked in, but I'll stop there for the moment. Thanks.

59
00:10:03.660 --> 00:10:10.649
ICANN - MTS - A/V: Yeah, thank you so much, Michaela, and I just want to, take this, opportunity to ask.

60
00:10:10.690 --> 00:10:23.990
ICANN - MTS - A/V: other, like, the NCSG representatives that were active on the DNS abuse, working group, what sort of issues they thought that were not addressed.

61
00:10:24.080 --> 00:10:31.470
ICANN - MTS - A/V: coherently and completely, other than remedy. I think.

62
00:10:31.700 --> 00:10:39.909
ICANN - MTS - A/V: Christabel made the point during the, DNS Abuse Mitigation PDP about compromised domains.

63
00:10:40.030 --> 00:10:46.930
ICANN - MTS - A/V: And that there should be, like, a clear, definition of, compromised domains.

64
00:10:47.100 --> 00:10:52.670
ICANN - MTS - A/V: And, Christabel, can I ask you, to give us a little bit of background? Yeah.

65
00:10:53.110 --> 00:11:02.490
ICANN - MTS - A/V: Yeah, sure, okay. So, I… I've been part of this PDP as an alternate, so, although I do share my ideas with the group.

66
00:11:02.630 --> 00:11:17.560
ICANN - MTS - A/V: with the rest of the group, and one of my concerns that I don't think that the working group as a whole actually addressed sufficiently was the concept of compromised domain. I think after the long, very, very long and painful

67
00:11:17.730 --> 00:11:37.589
ICANN - MTS - A/V: deliberations which we had. We did come to a kind of baseline definition for how, or I would say, what triggers ADC as a whole, but I think that the trigger itself might be a little risky towards… the agreed trigger itself might be a little risky towards compromised domains.

68
00:11:37.590 --> 00:11:49.989
ICANN - MTS - A/V: which, are simply described to be out of scope for ADC, but, I feel like the implementation… the implementation of that trigger might not sufficiently

69
00:11:49.990 --> 00:12:00.510
ICANN - MTS - A/V: safeguard compromised domains. So I think that there should be a little more… I don't know if the upcoming work that the working group has would look into this, but…

70
00:12:00.710 --> 00:12:13.240
ICANN - MTS - A/V: I feel like if there is… there can be some extra work done on, defining exactly how, compromised domains are out of scope, given the agreed trigger, which is basically

71
00:12:13.240 --> 00:12:25.370
ICANN - MTS - A/V: all domains. So, if we're going to check all… if we're going to check every single, every single, reported case of abuse, how exactly are abuse, compromised domains being

72
00:12:25.370 --> 00:12:35.509
ICANN - MTS - A/V: being safeguarded, I don't really see that's explicit enough. I think that that needs some extra work, and I think that we would all benefit from giving this a little more thought.

73
00:12:37.520 --> 00:12:47.280
ICANN - MTS - A/V: Thank you, thank you, Christabel. Yeah, that is, very important. Another, issue was that we wanted some

74
00:12:48.790 --> 00:12:54.769
ICANN - MTS - A/V: We wanted some stronger language for data protection and privacy.

75
00:12:54.970 --> 00:12:59.270
ICANN - MTS - A/V: which the group decided not to

76
00:12:59.390 --> 00:13:08.189
ICANN - MTS - A/V: Not to add, and the thing is that if you go through it, it does say that

77
00:13:08.310 --> 00:13:22.499
ICANN - MTS - A/V: data, like, they should not, according to applicable law, the registrar should not, violate, data, protection. The thing is that it does not have any kind of enforcement power.

78
00:13:22.560 --> 00:13:30.389
ICANN - MTS - A/V: If you just say that according to applicable law, like, and when there is no remedy, the registrant can't go

79
00:13:30.620 --> 00:13:37.750
ICANN - MTS - A/V: Can go to, like, a process and say that my privacy was violated.

80
00:13:38.160 --> 00:13:46.750
ICANN - MTS - A/V: So that was another problem as well. But… and another thing that I think we should, focus on, especially during this

81
00:13:46.960 --> 00:13:55.260
ICANN - MTS - A/V: day, that is DNS abuse mitigation day, is to see what's the result of the, human rights impact assessment.

82
00:13:55.320 --> 00:14:09.759
ICANN - MTS - A/V: Because in human rights impact assessment, of course, when staff, do it, it's really, really comprehensive. So, I don't think that the group work got high…

83
00:14:09.960 --> 00:14:33.420
ICANN - MTS - A/V: high, score on, providing remedy for the domain name registrant, and also, when it comes to their, privacy. But of course, that scoring, we have always said that this is just guiding the group's work, it's not… and it's nothing that, they… it has to be binding, but of course, it should inform

84
00:14:33.420 --> 00:14:35.230
ICANN - MTS - A/V: or the work…

85
00:14:35.260 --> 00:14:47.680
ICANN - MTS - A/V: If it's not possible to, inform it now, we need to come up with next steps on when the policy actually goes into force. Tapani, did you want to… yeah. Barsi, you have two hands up.

86
00:14:49.770 --> 00:15:07.670
ICANN - MTS - A/V: Tapani, and then Michaela. Just a little observation about remedy, that it's a little different in the case of when your registrant loses their domain, remedies, you get it back. But if your data is improperly disclosed, it cannot be undisclosed, and it can be literally fatal.

87
00:15:08.440 --> 00:15:12.470
ICANN - MTS - A/V: So, what's the remedy if you're already dead? So, you have to be much more

88
00:15:13.430 --> 00:15:17.990
ICANN - MTS - A/V: Careful about disclosure than about suspending a domain.

89
00:15:20.500 --> 00:15:27.430
ICANN - MTS - A/V: I totally agree, Tapaniya. Another thing, the problem with remedies that it's always after the fact.

90
00:15:27.610 --> 00:15:31.389
ICANN - MTS - A/V: So, we wanted to…

91
00:15:31.440 --> 00:15:48.829
ICANN - MTS - A/V: of course, we keep, like, advocating for measures that before, bad things happen, we want the registrar to be careful in their investigation. This is why we kept talking about, like, investigative, threshold. It should be high, and it should be based on.

92
00:15:48.830 --> 00:15:51.730
ICANN - MTS - A/V: Evidence, it should be proportionate, so…

93
00:15:51.730 --> 00:15:57.490
ICANN - MTS - A/V: But I totally agree with you that remedy we should also like.

94
00:15:57.780 --> 00:16:14.459
ICANN - MTS - A/V: maybe we can frame remedy in a way that it's not just exposed and after the fact. It's, like, people can complain about, like, I don't know, privacy practices or data protection, practices.

95
00:16:14.520 --> 00:16:20.589
ICANN - MTS - A/V: But that's a really good point that we have to consider in our work throughout. Go ahead, Michaela.

96
00:16:21.910 --> 00:16:37.750
ICANN - MTS - A/V: Thank you. No, I… and kind of following up on Tapani's point as well, I think that's where having ideally tighter language on the safeguards would help, because that's the upfront. So trying to say, okay, well, when you are applying, for example, the definition of

97
00:16:37.970 --> 00:16:56.989
ICANN - MTS - A/V: association, let's try to keep that, you know, more… let's make sure that we have in there that it must… that you must do that in a way that's reasonable and proportionate. So that way, ideally, you're curbing that… you're limiting the scope of association, so that you don't have to worry as much about remedy, but it's not a perfect solution.

98
00:16:57.000 --> 00:17:02.540
ICANN - MTS - A/V: I hear you, and that doesn't apply, again, as well as we would like when it comes to the data protection element.

99
00:17:02.680 --> 00:17:20.560
ICANN - MTS - A/V: I do want… I did want to just bounce, though, off of… I know Christabel was talking about the compromised domain definition, and there is a slight opening in the slides that the ICANN staff prepared for… about clarifying the compromised domain definition. There were other folks who mentioned that they wanted more clarity on that definition.

100
00:17:20.700 --> 00:17:37.009
ICANN - MTS - A/V: ICANN staff didn't really propose what I think is a much more substantive definition, so maybe there's room if you wanted to propose something, like, tighter language. There is a slide dedicated to discussing that topic, so we could take advantage of that space. It's… I think it's under slide…

101
00:17:37.150 --> 00:17:43.260
ICANN - MTS - A/V: 17 of the slideshow that they shared. So that's an option as well. Thanks.

102
00:17:44.640 --> 00:17:46.680
ICANN - MTS - A/V: Great.

103
00:17:46.880 --> 00:17:56.740
ICANN - MTS - A/V: Yeah. So We should Yeah. So today we have, I think, around 2

104
00:17:56.760 --> 00:18:13.919
ICANN - MTS - A/V: is it two, like, NCAB sessions that, I invite you all to attend, and if you see anything that is alarming, and, you think that it's going… nothing is… I mean, of course, we have come up with these recommendations, and this

105
00:18:14.880 --> 00:18:28.469
ICANN - MTS - A/V: And going through the public comments and stuff is a good exercise, but I… we don't think that there is a possibility to change things drastically, but if you see something that…

106
00:18:28.660 --> 00:18:43.499
ICANN - MTS - A/V: is really concerning, there's always a… there… we can always raise it, and it can always be considered in the next, iterations of the… of the policy. Or we can come up with our own.

107
00:18:43.770 --> 00:18:46.910
ICANN - MTS - A/V: Kind of like a group that discusses the issue.

108
00:18:47.150 --> 00:18:58.180
ICANN - MTS - A/V: And so let's go to. So this is the other priority that we have is the common data protection baseline. There was

109
00:18:58.210 --> 00:19:03.380
ICANN - MTS - A/V: for a while, when we were asking ICANN to

110
00:19:03.390 --> 00:19:18.910
ICANN - MTS - A/V: enforce data, like, basic data protection for every registrant in the world, even if those that don't have data protection laws in their jurisdiction. There was quite a lot of, pushback.

111
00:19:19.790 --> 00:19:28.359
ICANN - MTS - A/V: And, and for good reasons, because, you know, we want to keep ICANN's, mission, limited.

112
00:19:28.460 --> 00:19:42.570
ICANN - MTS - A/V: And, if we if we open that door, then there will be requests for like ICANN enforcing, for example, content moderation issues. So.

113
00:19:42.730 --> 00:19:54.759
ICANN - MTS - A/V: But but what we argue is that ICANN is already doing are already obligating the registrars to

114
00:19:55.220 --> 00:20:03.029
ICANN - MTS - A/V: To decide whether they should disclose domain and registrant private information to the third parties.

115
00:20:03.290 --> 00:20:04.370
ICANN - MTS - A/V: So.

116
00:20:04.570 --> 00:20:13.879
ICANN - MTS - A/V: Since they are doing that, the implications of that is they need to also make sure that when they are when this is happening.

117
00:20:14.140 --> 00:20:20.889
ICANN - MTS - A/V: The registrar, protects the data, notifies the domain name registrant.

118
00:20:21.390 --> 00:20:25.560
ICANN - MTS - A/V: and other other issues that they need to consider.

119
00:20:25.880 --> 00:20:28.240
ICANN - MTS - A/V: And, so…

120
00:20:28.980 --> 00:20:40.140
ICANN - MTS - A/V: For a while, the community felt that we should, we should not have a data, protection that ICANN data protection principle that ICANN enforces actively.

121
00:20:40.450 --> 00:20:47.060
ICANN - MTS - A/V: But The other day, during Sand meeting, there was an opening.

122
00:20:47.270 --> 00:21:01.470
ICANN - MTS - A/V: that somebody suggested that they finally might agree with us that we should have a conversation about whether we want ICANN to have a data protection policy that it enforces.

123
00:21:02.660 --> 00:21:08.479
ICANN - MTS - A/V: That can be, like, adopting OECD principles, or, like, something like that.

124
00:21:08.960 --> 00:21:14.070
ICANN - MTS - A/V: So this is another… this is a conversation that we can have with the community.

125
00:21:14.280 --> 00:21:22.770
ICANN - MTS - A/V: And see if there is interest, and convince the community that this is something that we should look after.

126
00:21:25.590 --> 00:21:29.970
ICANN - MTS - A/V: Well, I think we should just congratulate ourselves for

127
00:21:30.210 --> 00:21:37.290
ICANN - MTS - A/V: For creating that opportunity for us to, protect

128
00:21:37.440 --> 00:21:40.909
ICANN - MTS - A/V: domain name registrant data wherever they are.

129
00:21:45.090 --> 00:21:48.009
ICANN - MTS - A/V: You are all so excited about this.

130
00:21:49.520 --> 00:21:50.760
ICANN - MTS - A/V: What is this?

131
00:21:50.950 --> 00:22:02.430
ICANN - MTS - A/V: Wake up! Okay, so… Now, there's another issue of transparency. We said this, during the… during the

132
00:22:02.710 --> 00:22:12.889
ICANN - MTS - A/V: DNS abuse, PDP as well. We want transparency on how many domains, have they… have the registrar

133
00:22:12.890 --> 00:22:25.689
ICANN - MTS - A/V: done this ADC, what has been the result, how many domains they have taken down, and as always, transparency has its good things, and it also can have

134
00:22:25.810 --> 00:22:32.939
ICANN - MTS - A/V: that can create problems. Like, people can go and look at the data and say, oh, this registrar does not do enough ADC.

135
00:22:33.330 --> 00:22:48.590
ICANN - MTS - A/V: And, so we have to consider those, but generally, transparency is a good thing, because we can see if there are, like, false positives, we can… we can see if the domain name registrar is careless about doing ADC.

136
00:22:49.000 --> 00:23:05.799
ICANN - MTS - A/V: And, so transparency is something that we care about, and we want to put that in every PDP. We want to have a question in every charter about the transparency, like, what elements that should… that is needed.

137
00:23:08.080 --> 00:23:09.659
ICANN - MTS - A/V: And

138
00:23:10.590 --> 00:23:14.270
ICANN - MTS - A/V: And one thing that… A.

139
00:23:14.980 --> 00:23:27.609
ICANN - MTS - A/V: we can discuss is… so I had, I am of the opinion that we can bring transparency language to the… when we are chartering a PDP.

140
00:23:27.860 --> 00:23:37.169
ICANN - MTS - A/V: And I ask that question, but at some point, we can also, talk about, like, transparency principles.

141
00:23:37.240 --> 00:23:56.190
ICANN - MTS - A/V: And, whether we want to have, like, some kind of transparency reporting by the registrars, or if ICANN come… if it's a good idea for ICANN compliance to provide certain data, aggregate data on, different elements that we want to see.

142
00:24:00.100 --> 00:24:09.150
ICANN - MTS - A/V: And, so that's another thing that, we care about, and I think we should, make it one of our priorities.

143
00:24:09.530 --> 00:24:18.199
ICANN - MTS - A/V: The other thing is the accessibility and access to domain names. We live in a highly.

144
00:24:19.250 --> 00:24:37.040
ICANN - MTS - A/V: like, the geopolitical tensions are affecting people's access to DNS and digital infrastructure. We have discussed this on the mailing list at NCSG, the recent event that happened that.

145
00:24:37.160 --> 00:24:53.150
ICANN - MTS - A/V: that a domain name, was… that an organization was put on a terrorist list, and that affected, third-party access to, to the services that they provided. They… because they also, like, lost their, domain name.

146
00:24:53.380 --> 00:25:05.630
ICANN - MTS - A/V: And, we… we don't only see that in the matter of, like, sanctions or geopolitical issues, we also see that there is this, very much a shift in

147
00:25:06.020 --> 00:25:12.839
ICANN - MTS - A/V: People's approach that they don't want to provide more access.

148
00:25:13.090 --> 00:25:21.999
ICANN - MTS - A/V: to people to, for infrastructure. I know that we have a plenary on access, but, it's…

149
00:25:22.480 --> 00:25:36.480
ICANN - MTS - A/V: I'm sorry, I think it's more of a show and theater than, like, addressing the real, the real issues that people have when, they want to register a domain name and they want to access it.

150
00:25:36.580 --> 00:25:51.439
ICANN - MTS - A/V: So, that's another thing that I think should be our priority, moving forward. Look at what sort of barriers we have, in access, and what… what can ICANN do

151
00:25:51.440 --> 00:26:04.840
ICANN - MTS - A/V: what is within remit of ICANN… it can be nothing, but, you know, we talk to other stakeholders, and they might be, operating in spaces that they might be able to do something about.

152
00:26:05.270 --> 00:26:11.390
ICANN - MTS - A/V: Like, coming up with solutions for facilitating access.

153
00:26:13.770 --> 00:26:20.280
ICANN - MTS - A/V: So, these are, like, the four priorities, and Yeah,

154
00:26:20.670 --> 00:26:23.289
ICANN - MTS - A/V: Michaela has her hand up. Go ahead.

155
00:26:24.270 --> 00:26:31.140
ICANN - MTS - A/V: Thanks, Michaela, for the record. No, just following on about that, the AI collective incident that you mentioned, I think one…

156
00:26:31.450 --> 00:26:40.209
ICANN - MTS - A/V: area, it's hard to say to what extent it's within ICANN's remit, right? I don't know if we necessarily want to place ICANN in the role of arbiter of what's

157
00:26:40.260 --> 00:26:56.920
ICANN - MTS - A/V: Correct or not. That being said, I think it is a slippery slope into that distinction between what's action at the infrastructure level versus what is content, and also how terrorism designations can be weaponized. And this is not a new topic for those of us working in the human rights space.

158
00:26:56.970 --> 00:27:15.059
ICANN - MTS - A/V: But what could be useful, and I think we mentioned this in the statement that the NCSG sent to PIR, is that we could ask registries and their respective service providers to publish transparent information about how they respond to these kind of requests. I know in our letter we talked about

159
00:27:15.090 --> 00:27:20.619
ICANN - MTS - A/V: In theory, there was supposed… or not in theory, there was supposed to be a 30-day wind-down period in which

160
00:27:20.670 --> 00:27:27.629
ICANN - MTS - A/V: to implement the terrorism designation. So, for example, for service providers to withdraw their service.

161
00:27:27.670 --> 00:27:42.840
ICANN - MTS - A/V: provision, but a lot of them acted immediately. So why is that? What was the logic? Was there pressure from the Trump administration? You know, what was the reasoning behind it? All those things are things that could potentially be published if they so wished.

162
00:27:42.880 --> 00:27:55.480
ICANN - MTS - A/V: So again, that's one thing we can ask for, but I also don't know if that's something we'd want ICANN to require. So that's a separate question, but one that we should definitely discuss and put forward to the registries and registrars. Thanks.

163
00:27:58.080 --> 00:28:08.069
ICANN - MTS - A/V: Yeah, thank you, Michaela. Those are, like, real concerns that we need to address. This is why we want to have a town hall. We have a town hall.

164
00:28:08.440 --> 00:28:15.830
ICANN - MTS - A/V: We always have human rights, town hall at ICANN meetings. So on Thursday.

165
00:28:16.090 --> 00:28:18.559
ICANN - MTS - A/V: On Thursday we are going to

166
00:28:19.490 --> 00:28:24.069
ICANN - MTS - A/V: We are going to have the, meeting about sanctions.

167
00:28:24.400 --> 00:28:35.379
ICANN - MTS - A/V: and access. So, but we are going to talk about, like, the overarching access issue, and we are going to frame it as access to infrastructure.

168
00:28:35.680 --> 00:28:44.070
ICANN - MTS - A/V: because it's not just this incident. These days people

169
00:28:44.500 --> 00:28:51.140
ICANN - MTS - A/V: Like, you know, in the past, there was always the, resistance against

170
00:28:52.070 --> 00:29:11.049
ICANN - MTS - A/V: attacking infrastructure, even if, like, it's the enemy, even if it's this, perpetrator, like, attacking general purpose technology and infrastructure that civilians rely on to access services and digital services and.

171
00:29:11.260 --> 00:29:13.789
ICANN - MTS - A/V: and sometimes essential services.

172
00:29:13.890 --> 00:29:26.419
ICANN - MTS - A/V: is just a no-go in any kind of conflict. But… and we… but we see that, around the world, that kind of principle is being watered down.

173
00:29:26.630 --> 00:29:35.250
ICANN - MTS - A/V: And we need to like have a conversation about this. How can we Still, like.

174
00:29:35.480 --> 00:29:39.969
ICANN - MTS - A/V: How can we still defend access to infrastructure?

175
00:29:40.310 --> 00:29:48.200
ICANN - MTS - A/V: even for our enemies, because that infrastructure is Used by the civilians.

176
00:29:48.780 --> 00:29:50.580
ICANN - MTS - A/V: And,

177
00:29:51.580 --> 00:29:57.500
ICANN - MTS - A/V: So we need to like have a chat about this for that meeting.

178
00:29:57.590 --> 00:30:16.290
ICANN - MTS - A/V: there's gonna be the community members there, but of course, there are not… not many people are gonna be that forthcoming about issues, because it's a very, sensitive issue. So what we need to do is that we need to, present the issue, and then try to get community feedback.

179
00:30:16.500 --> 00:30:25.980
ICANN - MTS - A/V: I am going to. I I'm going to invite Internet society. Internet society has also issued the like the

180
00:30:26.030 --> 00:30:45.359
ICANN - MTS - A/V: CEO wrote a blog about this, so I'm going to, invite Internet Society to that session as well, but be very active, because we might actually… I mean, I don't know how the community is going to react or, like, make interventions.

181
00:30:45.960 --> 00:30:50.130
ICANN - MTS - A/V: Okay, let's go to the next slide. Andrew.

182
00:30:51.710 --> 00:30:59.229
ICANN - MTS - A/V: Okay, so For now, we are moving on from

183
00:30:59.480 --> 00:31:05.040
ICANN - MTS - A/V: the DNS abuse PDP1, which was about associated domain check.

184
00:31:07.190 --> 00:31:17.420
ICANN - MTS - A/V: and The second Pdp. That they want to do is about domain name registration at scale.

185
00:31:19.500 --> 00:31:32.009
ICANN - MTS - A/V: What… one of the problems is that with the domain name registration at scale, it just means that, like, you know, bulk access, like, domain name registrant, registers, like, 50

186
00:31:32.010 --> 00:31:46.360
ICANN - MTS - A/V: domains, or a thousand domains. Now, that's one of the problems. We don't… we don't know how to define scale. And also, they say that at scale and speed. So, at the moment, the Council is coming up with the

187
00:31:46.360 --> 00:31:47.620
ICANN - MTS - A/V: Charter.

188
00:31:47.770 --> 00:31:51.529
ICANN - MTS - A/V: of the, of this PDP, and

189
00:31:51.840 --> 00:31:59.680
ICANN - MTS - A/V: We are trying, and we are having so many arguments over the charter language. It's it's not.

190
00:31:59.930 --> 00:32:04.440
ICANN - MTS - A/V: it's not going smoothly. One of the problems is that

191
00:32:04.820 --> 00:32:22.650
ICANN - MTS - A/V: like, you know, I believe that the Charter is being too prescriptive on how do you want to… they… it says that we need to, like, we need to come up with methods to restrict access to domain registration at scale.

192
00:32:22.810 --> 00:32:42.460
ICANN - MTS - A/V: And I think that that is too prescriptive, and we don't… we are telling the working group to come up with the mechanisms already. And it's even… it wanted to go further than that, and say that, like, you know, you need to look at, like, behavioral indicators, but also identity.

193
00:32:43.000 --> 00:32:49.640
ICANN - MTS - A/V: which we try to remove, but in a very unprecedented act, a gag

194
00:32:49.860 --> 00:32:56.219
ICANN - MTS - A/V: sent an input to the Gnso Council. This is fun.

195
00:32:56.220 --> 00:33:10.620
ICANN - MTS - A/V: to the GNSO Council and said that I think that you need to consider my input. One of… one of their, comments was that identity should be considered by, the working group.

196
00:33:13.000 --> 00:33:16.699
ICANN - MTS - A/V: I I yes, so

197
00:33:16.810 --> 00:33:24.339
ICANN - MTS - A/V: And, you know, I'm just gonna quite respectfully tell GAC that, we are going to push back on that.

198
00:33:24.770 --> 00:33:41.479
ICANN - MTS - A/V: If the working group wants to discuss identity, they can, but I think that we need a strong language that the mechanisms that they come up with should not, prescribe that.

199
00:33:41.830 --> 00:33:51.370
ICANN - MTS - A/V: that the registrar have, like, ID requirements in order for the domain name registrant to, to register domains at scale.

200
00:33:51.650 --> 00:33:59.199
ICANN - MTS - A/V: They can do that if they want in their best practice, but I don't think it should be a contractual obligation by ICANN.

201
00:33:59.360 --> 00:34:02.240
ICANN - MTS - A/V: because that would open a can of worms.

202
00:34:03.370 --> 00:34:09.200
ICANN - MTS - A/V: And so that's and that can be like that can have a human rights impact.

203
00:34:09.820 --> 00:34:29.140
ICANN - MTS - A/V: if I can, if I can obligate the registrar. So that's one thing, and the other thing that the GAC said was that, we are going to talk about recourse and remedy elsewhere, we don't have to discuss it during PDP2.

204
00:34:29.429 --> 00:34:33.989
ICANN - MTS - A/V: So just… Peter has his hand up.

205
00:34:34.570 --> 00:34:50.559
ICANN - MTS - A/V: But I haven't finished, Andrea. Thank you, though. I will give you time, Peter, don't worry. So, and so what I want to say, what… I will finish this now. So, in this

206
00:34:50.790 --> 00:35:01.029
ICANN - MTS - A/V: these HRIA sessions that we do, they are really good, because we get the community to come in and talk about the human rights impact.

207
00:35:01.120 --> 00:35:11.759
ICANN - MTS - A/V: And I have been talking to the community, and some people are of the opinion that there is no human rights impact. Domain name registrant has no.

208
00:35:11.870 --> 00:35:12.990
ICANN - MTS - A/V: Right.

209
00:35:13.070 --> 00:35:28.570
ICANN - MTS - A/V: to, like, register domain at scale, and that's, like, a feature. But then, I have argued that, but then don't let people that go and want to do censorship circumvention, don't they, like.

210
00:35:28.600 --> 00:35:46.049
ICANN - MTS - A/V: do, like, domain name registration at scale in order to do, like, the hopover and not to be blocked, and they say that, well, no, they can just use the subdomain. So, we need to… we need to really suss this out and see what sort of human rights impact it could potentially

211
00:35:46.050 --> 00:36:01.329
ICANN - MTS - A/V: Huh. And even if it's not in the technical issues and the feature in the mitigation mechanisms, there could be a human rights impact in the mitigation mechanism that the group wants to come up with.

212
00:36:03.250 --> 00:36:06.310
ICANN - MTS - A/V: Pete. Oh, Peter, your hand went down.

213
00:36:08.840 --> 00:36:17.900
ICANN - MTS - A/V: Oh, oh, sorry, Peter. It was about the priority. Okay, so how about

214
00:36:19.940 --> 00:36:25.549
ICANN - MTS - A/V: How about how about we go to Tapani who wants to comment on this issue, and then we can go to you, Peter.

215
00:36:27.070 --> 00:36:30.679
ICANN - MTS - A/V: Tapani for the record. Just a quick observation on this.

216
00:36:31.030 --> 00:36:41.710
ICANN - MTS - A/V: Censorship circumvention thing using subdomains does not work against situations where your whole domain is being cut down, just like in that recent .org case.

217
00:36:44.580 --> 00:36:51.050
ICANN - MTS - A/V: That's a really good point, Tapani. Peter, go ahead.

218
00:36:54.450 --> 00:36:57.389
Taiwo Peter Akinremi: Thanks, Percy. Am I coming through?

219
00:36:58.360 --> 00:37:15.059
Taiwo Peter Akinremi: Yes, yes. Yeah, thank you. So I, I was, wanted to speak on the first, slide that, you were talking about, because one of, one of the, observations that.

220
00:37:15.280 --> 00:37:24.880
Taiwo Peter Akinremi: In policy development now is that, oh, narrow scoping and,

221
00:37:25.030 --> 00:37:39.599
Taiwo Peter Akinremi: trim it down, and trying to, you know, fixate on one particular area, and trying to solve that, and we could see that NCSG is fighting for remedies to be discussed about things.

222
00:37:39.600 --> 00:37:45.460
Taiwo Peter Akinremi: I guess this is… this is high time for us to, find a way to say that

223
00:37:45.460 --> 00:37:50.929
Taiwo Peter Akinremi: Despite narrow scopings of any policy development, there are still some

224
00:37:50.930 --> 00:38:15.449
Taiwo Peter Akinremi: elements that, should not be traded, with, especially on the four priorities that, we, we, we, we think that it's, it's, it's, it's, it's, it's, it's, it's a priority for, for NCSG. We should find a way that this is non-negotiable in any policy development, despite of any narrow scopings or, whatever that, you know, we

225
00:38:15.450 --> 00:38:23.300
Taiwo Peter Akinremi: want to do. We know that we want to, move very fast, but that should not be at the cost of,

226
00:38:23.470 --> 00:38:41.289
Taiwo Peter Akinremi: are discussing remedies and, transparency and accountability. I would recommend… I know that, you know, Farsi and other, colleagues have been, fighting for that, you know, to discuss that. I guess we need to move

227
00:38:41.290 --> 00:38:45.269
Taiwo Peter Akinremi: Passed that and started looking at how we can push for

228
00:38:45.270 --> 00:38:51.399
Taiwo Peter Akinremi: forward and recommendations to the GNSO at large, and how they can adopt that in any

229
00:38:51.400 --> 00:39:13.690
Taiwo Peter Akinremi: policy they want to talk about, then this element needs to be, in, in that, as we have done for the human right. I know that there's still, you know, fight around that, but we need to move past, coming, you know, like, after PDP has been formed, and we started talking about this, now we need to push forward and, and, and, and…

230
00:39:13.690 --> 00:39:16.210
Taiwo Peter Akinremi: And be proactive on how to.

231
00:39:16.210 --> 00:39:24.520
Taiwo Peter Akinremi: make this a standard, a baseline that will be part of any PDP activity. So, wanted to touch on that. Thank you.

232
00:39:26.510 --> 00:39:30.689
ICANN - MTS - A/V: Thank you, Peter. Actually, that's a really great point.

233
00:39:31.030 --> 00:39:47.929
ICANN - MTS - A/V: one thing that we repeatedly saw that the group, the DNS Abuse Working Group, did to us was that, oh, that's out of scope. They kept saying, well, like, we were talking about remedy, they said, no, that's out of scope, and we were talking about

234
00:39:47.930 --> 00:39:53.410
ICANN - MTS - A/V: All these things that should be a part and parcel of a PDP.

235
00:39:53.410 --> 00:40:09.240
ICANN - MTS - A/V: And, they would just say, no, that's out of scope. And we have to push back on this out of scope argument in the PDP as long as, yes, of course it's out of scope. If you want to, ICANN to become a content moderator.

236
00:40:09.240 --> 00:40:14.369
ICANN - MTS - A/V: Yes, that is out of scope. But if you want, if you…

237
00:40:14.390 --> 00:40:26.179
ICANN - MTS - A/V: want to have like remedy mechanism not to be addressed in the working group, not even to be addressed there, just to say, do you have remedy if things go wrong?

238
00:40:26.460 --> 00:40:32.030
ICANN - MTS - A/V: Just for the group to consider, and say, what is the next step if you don't have remedy?

239
00:40:33.070 --> 00:40:37.809
ICANN - MTS - A/V: and but they kept saying, like, it's out of scope. So we need to like, really.

240
00:40:37.850 --> 00:40:55.910
ICANN - MTS - A/V: push back on this out-of-scope thing. And I'm glad that it wasn't, like, the language wasn't used, in one of the presentations that I saw. I see Christabel's hand up, and then we, move on. Oh, Christabel? Oh, no, it's not.

241
00:40:55.970 --> 00:40:58.090
ICANN - MTS - A/V: Okay, great.

242
00:40:59.410 --> 00:41:13.619
ICANN - MTS - A/V: Okay, so for this, for this PDP, I will come to you, and I will ask you to volunteer to discuss the issue.

243
00:41:13.950 --> 00:41:30.339
ICANN - MTS - A/V: And, also. Yeah. Yo, I'm looking at you. And also. And, and Tapani and, you know, we should all be there and discuss the human rights impact assessment because it's also very useful for.

244
00:41:30.340 --> 00:41:35.370
ICANN - MTS - A/V: later on, when they do the human rights impact assessments for the Pdp.

245
00:41:35.550 --> 00:41:41.119
ICANN - MTS - A/V: And we will invite the rest of the community as well to discuss.

246
00:41:42.220 --> 00:41:45.480
ICANN - MTS - A/V: Next slide.

247
00:41:51.990 --> 00:42:11.579
ICANN - MTS - A/V: Oh, that's the town hall that, we discussed, a human rights town hall. It's gonna happen on Thursday. You know, there's the impact of registrants in sanctioned countries, but also when sanctions happen at individual level, and…

248
00:42:11.620 --> 00:42:15.660
ICANN - MTS - A/V: And, what are the solutions?

249
00:42:15.660 --> 00:42:34.280
ICANN - MTS - A/V: What are the solutions? What can be done about it? And we can, like, think about speakers, as I, as I was, saying, so we are talking to, different people if they, if they want to speak on the issue, but generally, we need to set the scene. I think Michaela, if.

250
00:42:34.280 --> 00:42:44.840
ICANN - MTS - A/V: You can also like go through the article 19 statement, and also like Bruna can also set the scene.

251
00:42:44.910 --> 00:42:47.090
ICANN - MTS - A/V: on the

252
00:42:47.280 --> 00:42:56.060
ICANN - MTS - A/V: infrastructure access issue, and then we take it from there, and I'm sure the community, will weigh in.

253
00:42:56.310 --> 00:43:03.970
ICANN - MTS - A/V: But what do we want out of this? We need to think about ICANN Org role.

254
00:43:04.630 --> 00:43:16.189
ICANN - MTS - A/V: what sort of role ICANN Org has, and what sort of role registries and registrars have, and what sort of role, like, we have as digital rights advocates and researchers.

255
00:43:17.000 --> 00:43:18.430
ICANN - MTS - A/V: Next slide.

256
00:43:21.680 --> 00:43:26.510
ICANN - MTS - A/V: Okay, well, I think so. I have been talking about this for a long time.

257
00:43:28.480 --> 00:43:40.759
ICANN - MTS - A/V: This is about SAT. We all know what SAT is, the, disclosure of… the triage of, information, a request for disclosure of domain name register and private personal information.

258
00:43:41.250 --> 00:43:50.099
ICANN - MTS - A/V: SSAT is going to finalize the… the SRT is going to finalize the recommendations.

259
00:43:50.640 --> 00:44:05.059
ICANN - MTS - A/V: This week, they're going to have a few other sessions. There are things that we've… we've won, which is great, and there are things that were really essential, and we still… we still didn't get.

260
00:44:05.240 --> 00:44:12.869
ICANN - MTS - A/V: One was that notifying domain registrants about a disclosure, and then remedy in case of wrongful disclosure.

261
00:44:13.210 --> 00:44:32.309
ICANN - MTS - A/V: So these are the two things that, yes, like, on Thursday, we had a whole day meeting, and we want the domain name registrant, when their data is disclosed by the registrar, we want them to be notified.

262
00:44:32.830 --> 00:44:37.449
ICANN - MTS - A/V: And there was some support in the room for that, but it was…

263
00:44:37.830 --> 00:44:44.930
ICANN - MTS - A/V: overwhelmingly. They didn't. They didn't want to have that. The other thing is that remedy

264
00:44:45.320 --> 00:44:56.120
ICANN - MTS - A/V: in case of wrongful disclosure. When we looked at the human rights impact assessment that they had done, they hadn't like considered

265
00:44:56.330 --> 00:45:12.070
ICANN - MTS - A/V: like, the remedy that they considered for, for that was that, oh, we are not disclosing the data. It's the registrar that will decide. But that is not really a strong argument or a safeguard.

266
00:45:12.260 --> 00:45:16.160
ICANN - MTS - A/V: If you're obligating the domain and registrar to

267
00:45:16.640 --> 00:45:21.909
ICANN - MTS - A/V: Disclose after certain criteria are met.

268
00:45:22.080 --> 00:45:28.110
ICANN - MTS - A/V: Then, you need to provide the registrant with some sort of remedy.

269
00:45:28.410 --> 00:45:48.039
ICANN - MTS - A/V: In case things go wrong. And that's other, also, we didn't get. But for, of course, for the requester, you know, they have all sorts of complaint mechanisms, and they can go to ICANN, and they can complain if they don't get the data, but for the domain name registrant, at the moment, there's nothing.

270
00:45:48.960 --> 00:46:01.309
ICANN - MTS - A/V: Also, GAC was really, cares really about, cares strongly about requester's privacy, and they asked.

271
00:46:01.500 --> 00:46:12.020
ICANN - MTS - A/V: To add a few bullet points about how the requester privacy should be protected.

272
00:46:12.610 --> 00:46:28.640
ICANN - MTS - A/V: Because, like, if there are individuals and organizations, but, you know, Bruno made a really good point. She didn't go on the record, but, she also said that, sorry, Bruno, am I… I… can I…

273
00:46:28.810 --> 00:46:44.860
ICANN - MTS - A/V: So, basically, she said that, well, this is… sure, for, like, individuals, but this is, like, if we want some sort of transparency later on, on, like, organizations, and how many

274
00:46:45.170 --> 00:46:50.700
ICANN - MTS - A/V: disclosure request they want and stuff, then that would, make it difficult.

275
00:46:50.830 --> 00:46:58.609
ICANN - MTS - A/V: So it is really interesting to see where GAC's interests are and who they are protecting and defending.

276
00:46:59.290 --> 00:47:07.469
ICANN - MTS - A/V: Anyway, So we are gonna also have a… we have an authentication,

277
00:47:07.640 --> 00:47:26.380
ICANN - MTS - A/V: meeting here as well, which is interesting. And if you care about privacy, if you care about disclosure of private information. This is the issue that is going on. And we are going to talk about authentication.

278
00:47:27.970 --> 00:47:39.889
ICANN - MTS - A/V: and ICANN might work on in the future. They might start working on with authentication agreements that they can have with different law enforcement agencies.

279
00:47:40.060 --> 00:47:45.349
ICANN - MTS - A/V: And that's like a framework that we need to be very much involved with.

280
00:47:45.740 --> 00:47:50.790
ICANN - MTS - A/V: And that's about it. Let's go to the next slide, Andrea. I think I'm doing well.

281
00:47:51.790 --> 00:48:03.209
ICANN - MTS - A/V: Okay, so alright. So this is like the Council that we are. Gonna so these are the discussions at the Council. Latin diacritics vote Latin diacritics

282
00:48:03.540 --> 00:48:10.950
ICANN - MTS - A/V: It's this group that came up with some sort of policy on Latin direct critics.

283
00:48:11.240 --> 00:48:15.469
ICANN - MTS - A/V: For, like, and, yeah, Tapani, do you want to…

284
00:48:15.930 --> 00:48:26.260
ICANN - MTS - A/V: Yeah, just, Latin diacritics PDP was perhaps the, let's say, most convivial, most friendly PDP since forever. Very little disagreement.

285
00:48:26.700 --> 00:48:34.279
ICANN - MTS - A/V: I pushed for mainly expanding the set of character sets that are available and some other things and mostly got it.

286
00:48:34.850 --> 00:48:49.729
ICANN - MTS - A/V: There were some things that were left out because the charter would not really allow for them, and I might suggest a follow-up PDP one day, but it's not really important or urgent, and the outcome is, I guess, just about as good as possible, given the charter, so I'm happy to vote for it.

287
00:48:50.730 --> 00:48:54.229
ICANN - MTS - A/V: Okay, great. Well, counselors, we are going to vote. Yes.

288
00:48:54.840 --> 00:48:57.800
ICANN - MTS - A/V: Unless you strongly object to something.

289
00:48:58.630 --> 00:49:00.670
ICANN - MTS - A/V: Okay.

290
00:49:01.080 --> 00:49:04.460
ICANN - MTS - A/V: So for accuracy,

291
00:49:05.010 --> 00:49:09.499
ICANN - MTS - A/V: I have been saying this for a while now. So GAAC

292
00:49:09.900 --> 00:49:22.010
ICANN - MTS - A/V: Decided to send a letter and say that we need to have a dialogue about verification of domain name registrant.

293
00:49:22.360 --> 00:49:29.320
ICANN - MTS - A/V: Like, you know, that domain register and keep their data updated and accurate.

294
00:49:29.440 --> 00:49:38.220
ICANN - MTS - A/V: And we, and there was this small team that had decided that… that had suggested that, okay, well, maybe we can…

295
00:49:38.490 --> 00:49:48.119
ICANN - MTS - A/V: We can shorten the time that the domain name registrant should update their their data.

296
00:49:48.380 --> 00:50:06.860
ICANN - MTS - A/V: And, GAC has taken that suggestion and keeps coming to the Council and keeps saying that, yeah, we need to… we need to enforce that in a way, we need to implement it. And the more we say that we don't work like that, we need to go to a policy development process.

297
00:50:07.060 --> 00:50:12.329
ICANN - MTS - A/V: The less there is, like, this kind of understanding of the process.

298
00:50:12.770 --> 00:50:15.730
ICANN - MTS - A/V: So, but…

299
00:50:15.770 --> 00:50:29.390
ICANN - MTS - A/V: But for us, our position is that accuracy means contactability. We also have concerns about shortening, shortening the period that, domain name registrant is given in order to, verify their data.

300
00:50:29.390 --> 00:50:36.080
ICANN - MTS - A/V: when they register domain, because, Kathy at some point said, what if it's, like, a small

301
00:50:36.420 --> 00:50:50.170
ICANN - MTS - A/V: hospital that, like… like, the IT guy has registered the domain, and they don't have time, and they don't… they don't… they don't update it within 2 weeks, and then what are… what's gonna happen? Are they gonna lose their…

302
00:50:50.340 --> 00:51:07.630
ICANN - MTS - A/V: lose their domain, and then people will have access to the domain name of the hospital. So, these are… these are the things that we need to consider, but also, like, the more crucial problem with this is that GAC being so proactive.

303
00:51:07.950 --> 00:51:16.019
ICANN - MTS - A/V: And telling us what to do, and wanting us, in a way, to circumvent our policy development processes.

304
00:51:17.550 --> 00:51:33.310
ICANN - MTS - A/V: PPSAI updates. There will be a PPSAI update. We care about that because it's about privacy proxy. Privacy proxy is used by vulnerable communities and communities that want to stay… remain anonymous for.

305
00:51:33.310 --> 00:51:45.069
ICANN - MTS - A/V: Like, you know, because of freedom of speech, because of the fear of persecution. And we need to be very careful when we come up with, disclosure mechanisms for, for privacy proxy.

306
00:51:45.390 --> 00:51:49.819
ICANN - MTS - A/V: And, there will be an update. This is an implementation stage.

307
00:51:50.750 --> 00:51:52.430
ICANN - MTS - A/V: And

308
00:51:53.340 --> 00:51:57.970
ICANN - MTS - A/V: And I need somebody to volunteer to monitor this.

309
00:51:58.310 --> 00:52:01.200
ICANN - MTS - A/V: Who wants to do that? No? Yes.

310
00:52:01.960 --> 00:52:02.700
ICANN - MTS - A/V: Okay.

311
00:52:03.290 --> 00:52:11.859
ICANN - MTS - A/V: Iona, IPR transfer, there are concerns on the list. I don't know if you have followed it. It's very interesting.

312
00:52:12.200 --> 00:52:20.380
ICANN - MTS - A/V: ALAC made a point about it, but we don't have much time, we can, like.

313
00:52:20.560 --> 00:52:24.070
ICANN - MTS - A/V: Talk to me off-list, to discuss what the issue is.

314
00:52:24.230 --> 00:52:26.659
ICANN - MTS - A/V: And we have chair election.

315
00:52:26.890 --> 00:52:29.119
ICANN - MTS - A/V: Fort Agena. So a council.

316
00:52:30.360 --> 00:52:36.009
ICANN - MTS - A/V: and my colleague Rafiq has organized

317
00:52:36.510 --> 00:52:44.950
ICANN - MTS - A/V: 2 meetings with the with the candidates for the Genesis Council. Rafi, do you want to?

318
00:52:46.620 --> 00:52:53.370
ICANN - MTS - A/V: Yes, so we invited two candidates, Vivek and Samantha, to join us.

319
00:52:53.540 --> 00:52:56.459
ICANN - MTS - A/V: during the NCAG membership session.

320
00:52:56.760 --> 00:53:04.209
ICANN - MTS - A/V: To have interview interaction with them, and based on that, we will make a decision about the vote.

321
00:53:04.510 --> 00:53:06.780
ICANN - MTS - A/V: Again.

322
00:53:07.100 --> 00:53:12.870
ICANN - MTS - A/V: When discussing with CAG in particular, we… I clarified that

323
00:53:13.260 --> 00:53:23.260
ICANN - MTS - A/V: The nomination process is separate from the voting, so we did nominate Vivek as candidate from the NCPH.

324
00:53:23.640 --> 00:53:38.439
ICANN - MTS - A/V: As usual, I mean, we have no issue on that, but when it comes to the vote for the UNESCO chair, we, we have two, two volunteers, so we'll interview them, ask them some questions to see who.

325
00:53:39.070 --> 00:53:51.099
ICANN - MTS - A/V: will fit as, the next, GNSO… GNSO chair. Yeah, we'll… so that we think what we will, when we will make decision on Tuesday at the end.

326
00:53:52.190 --> 00:54:00.439
ICANN - MTS - A/V: Thank you, Rafiq. So, this is a… like, we can also, like, have a conversation about that if you want to know more about the candidates.

327
00:54:00.560 --> 00:54:08.909
ICANN - MTS - A/V: And also, if you want to know about, how the council… our council members, I want to go.

328
00:54:09.640 --> 00:54:16.979
ICANN - MTS - A/V: about the voting. So, and we have only… oh, yes, great. And also, like, Bruno, if…

329
00:54:17.320 --> 00:54:22.829
ICANN - MTS - A/V: When you're added, like, can you also, like, cover the board meeting with, GNSO? Yes, thank you.

330
00:54:23.620 --> 00:54:26.750
ICANN - MTS - A/V: I put my hand up to talk about the elections, but I can do both.

331
00:54:26.950 --> 00:54:33.600
ICANN - MTS - A/V: So no, just as an outgoing. I'm I'm outgoing counselor, and so on. And I just wanted to

332
00:54:33.970 --> 00:54:40.140
ICANN - MTS - A/V: perhaps suggest for all incoming councillors that vote to really look at the profiles and

333
00:54:40.680 --> 00:54:49.349
ICANN - MTS - A/V: think about who you're voting for. Council is challenging. I think some of the things we have advocating… advocated over the past years was

334
00:54:49.500 --> 00:55:06.390
ICANN - MTS - A/V: for more structure into the council work, for more transparency into the council work. And, you know, it really depends on the chair and how this person steps into this role, and whether this person has been willing to listen to NCSG's claims and requests, and…

335
00:55:06.500 --> 00:55:15.100
ICANN - MTS - A/V: perhaps I can say that, but sadly, that was not quite the case this year. You know, we were… weren't quite listened to, at least I don't feel like we were.

336
00:55:15.130 --> 00:55:32.850
ICANN - MTS - A/V: So, just maybe asking that incoming councilors do take a look at the candidates and think about that, and I also wanted to put on the record that, the NCPH does not have a… has a candidate for the vice chair role. We asked CSG yesterday for a candidate, they don't have a name yet.

337
00:55:32.890 --> 00:55:45.570
ICANN - MTS - A/V: So, maybe just putting that on the record for all of us to know that if a new name appears on the day of the voting, it was not a name that was agreed, at the intersessional at Day Zero yesterday.

338
00:55:45.730 --> 00:55:55.760
ICANN - MTS - A/V: So yeah. Next topic. Yesterday we had a quick meeting between the NCPA, the No Contracted Party House and the board.

339
00:55:55.960 --> 00:56:14.779
ICANN - MTS - A/V: Where we addressed, some of the priorities for the two sides of the house. So the CSG presented, some of their priorities around the review of reviews, accuracy, and a third topic that I'm forgetting, in AI. And we did, bring some, some priorities on our side as well.

340
00:56:14.780 --> 00:56:32.779
ICANN - MTS - A/V: That being the discussion on abuse, some of the points on privacy and protecting the identity of registrants and also AI for that matter. So the meeting was an interesting one. I'm not sure we're gonna have any recordings on that note, right?

341
00:56:32.830 --> 00:56:37.599
ICANN - MTS - A/V: We did have some some interesting points about some interesting

342
00:56:37.690 --> 00:56:44.650
ICANN - MTS - A/V: kind of feedback from the board. Let's put it as feedback that on the point that we try to argue for

343
00:56:45.600 --> 00:57:02.210
ICANN - MTS - A/V: privacy of registrants, the board was rather too punitive, in my opinion, kind of trying to claim that this would not be possible because they… some of them were far more interested in fighting crime as opposed to ensuring privacy for domain name registrants.

344
00:57:02.330 --> 00:57:08.560
ICANN - MTS - A/V: Something that, in our opinion, could be balanced, but, you know, some of them were not quite willing to.

345
00:57:08.700 --> 00:57:14.269
ICANN - MTS - A/V: But we did have interesting support in the room, so board members like Sarah, Wes.

346
00:57:14.500 --> 00:57:35.470
ICANN - MTS - A/V: James Gavin, they did, show some support for NCSG's point on… at least on the point of transparency and freedom of expression. That was really interesting to see. So, yeah, I think… anything else to add on that note? So, yeah. Yeah, thank you. And it was recorded. I think it was a very interesting session. Have a look. And I see that, Peter's…

347
00:57:35.470 --> 00:57:37.740
ICANN - MTS - A/V: Hand is up, Peter. Sorry. Go ahead.

348
00:57:39.190 --> 00:57:47.859
Taiwo Peter Akinremi: Thanks, Fazi. Just wanted to touch on the chair election, so that we have clarity on.

349
00:57:48.190 --> 00:57:54.540
Taiwo Peter Akinremi: How this should go… Like, I keep hearing that We…

350
00:57:54.790 --> 00:58:02.950
Taiwo Peter Akinremi: a separate nomination from who to vote for. I believe that, So, we'll take…

351
00:58:03.040 --> 00:58:21.030
Taiwo Peter Akinremi: listening and, you know, hears and listen to both the candidate and… and, what I want to, encourage the councillors to do is listen beyond the world that has been spoken, and be able to understand

352
00:58:21.090 --> 00:58:25.509
Taiwo Peter Akinremi: Who aligns with, our values, and also

353
00:58:25.650 --> 00:58:36.990
Taiwo Peter Akinremi: what would be, a good fit for, for, for, for the GNSO chair. Sometimes, we might need to actually, like, take away sentiment.

354
00:58:36.990 --> 00:58:47.510
Taiwo Peter Akinremi: And, and try to do what is right. So I believe that, we have a good, you know, two good candidates that will be pitching their interest and, how they…

355
00:58:47.510 --> 00:59:00.519
Taiwo Peter Akinremi: can align, and they can, they can, they can serve well. I just want to encourage folks to, listen beyond words, and what has been spoken, not because somebody says that.

356
00:59:00.800 --> 00:59:11.459
Taiwo Peter Akinremi: they are going to… they are aligned with transparency, or NCSG values, and that's what they're going to do, but we should just, listen beyond the words.

357
00:59:11.460 --> 00:59:14.399
Taiwo Peter Akinremi: And be able to, like, vote for the right person.

358
00:59:14.400 --> 00:59:37.489
Taiwo Peter Akinremi: So that's just what I want to encourage. I'm taking away… sentiment away from whatever things, and I will encourage other… also to do the same thing. And I also, like, want to put on the record, not because, we should look past, I'm not advocating for any candidate. We vote for who we think that is best, but we should, look towards the…

359
00:59:37.650 --> 00:59:56.770
Taiwo Peter Akinremi: the role of the GNSO chair, and how we can actually make better policy, because we, represent the interest of the, of, of, of public interest, and not because of not personal agenda or whatever. We should vote for somebody that can lead

360
00:59:56.770 --> 01:00:05.959
Taiwo Peter Akinremi: the policy that can help us to manage the policy well, and also steer conversation is the right way. So, I just want to put that on the record. Thank you.

361
01:00:05.960 --> 01:00:06.880
ICANN - MTS - A/V: Thank you, Peter.

362
01:00:06.880 --> 01:00:07.610
Taiwo Peter Akinremi: Yeah.

363
01:00:07.610 --> 01:00:12.230
ICANN - MTS - A/V: Sorry, I'm sure Andrea is very pissed off with me now. I will have to.

364
01:00:12.400 --> 01:00:26.189
ICANN - MTS - A/V: We have to leave. So I see you during DNS abuse mitigation PDP today. And don't forget about the human rights impact assessment on Monday.

365
01:00:26.380 --> 01:00:34.120
ICANN - MTS - A/V: We really need you there. And also Thursday. And also, of course, a host of NCSG meeting that Rafiq is running.

366
01:00:34.260 --> 01:00:36.250
ICANN - MTS - A/V: Thank you very much.

367
01:00:37.770 --> 01:00:39.789
ICANN - MTS - A/V: Thank you, you can stop the recording.