WEBVTT

1
00:00:03.450 --> 00:00:20.570
ICANN - MTS - A/V: Hello, and welcome to the SSAD SRT session 1 of 3. Please note that this session is being recorded and is governed by the ICANN Expected Standards of Behavior, the ICANN Community Anti-Harassment Policy, and the ICANN Community Participant Code of Conduct concerning statements of interest.

2
00:00:20.570 --> 00:00:35.000
ICANN - MTS - A/V: I will also post them in the chat for your reference. If you wish to speak, please raise your hand in Zoom or otherwise as directed. When speaking, please state your name for the record and speak clearly at a moderate pace. With that, I'll turn the floor over to Mark Anderson. Please begin.

3
00:00:36.250 --> 00:00:41.270
ICANN - MTS - A/V: Thank you, Terry. This is Mark Anderson, chair of the SSAT SRT Working Group.

4
00:00:41.380 --> 00:00:47.239
ICANN - MTS - A/V: Welcome, everybody, to this first of three meetings of the SAD SRT.

5
00:00:47.410 --> 00:00:59.930
ICANN - MTS - A/V: Note for people in the room, this is a working session of the SRT, so we ask that unless you're, a member of the SRT, you refrain from.

6
00:01:00.030 --> 00:01:10.779
ICANN - MTS - A/V: refrain from, coming to the microphone. We're happy to have observers here and, and welcome you, but, just to note that this is a working session of the SRT.

7
00:01:12.150 --> 00:01:20.870
ICANN - MTS - A/V: We have an agenda up on the screen. The agenda flows from the work we did during Thursday's full-day session.

8
00:01:20.950 --> 00:01:36.100
ICANN - MTS - A/V: So we have some outstanding items on, privacy proxy related to recommendations 3 and 8, but mostly in Rec 8, so we'll dedicate the majority of the time for today's meeting to talking through that.

9
00:01:36.360 --> 00:01:53.860
ICANN - MTS - A/V: We also have some time for, REC 1. We have new language proposed around authentication, again, based on the discussion that happened during Thursday's full-day meeting. And so we'll spend the, or plan to spend the remainder of our time, on that.

10
00:01:54.470 --> 00:01:55.839
ICANN - MTS - A/V: Next slide, please.

11
00:01:58.760 --> 00:02:12.389
ICANN - MTS - A/V: Before we get into the substance of our work, I'd like to ask Feodora to give a little bit of a readout of what happened during our full-day face-to-face meeting. So, Feodora, over to you.

12
00:02:13.210 --> 00:02:14.530
ICANN - MTS - A/V: Hi, everyone.

13
00:02:14.760 --> 00:02:31.340
ICANN - MTS - A/V: This Feodora from ICANN Org, and we just wanted to… you've seen the notes and action items, and also the updated control sheet, and you can see here, as a high-level outcome from the Thursday meeting, that we don't necessarily have any red items anymore, because the group left

14
00:02:31.530 --> 00:02:40.399
ICANN - MTS - A/V: on those items with an idea to resolution. However, targeted discussions remain on authentication, privacy proxy.

15
00:02:41.010 --> 00:02:56.710
ICANN - MTS - A/V: And recommendation six that was considered green before, but some concerns were raised and it's also up for targeted discussion and some items remain open regarding recommendation 13. However, progress has been made because now you see more.

16
00:02:56.960 --> 00:02:57.900
ICANN - MTS - A/V: Apologies.

17
00:02:58.030 --> 00:03:01.059
ICANN - MTS - A/V: Recommendations in green as stable.

18
00:03:01.170 --> 00:03:09.219
ICANN - MTS - A/V: Of course, they can pop up if any material concern is identified. However, based on the SRT discussion on the 15th of October.

19
00:03:09.370 --> 00:03:18.360
ICANN - MTS - A/V: These seem at a very stable stage. We know that on REC 16, there was a comment that might need some attention, what overall.

20
00:03:18.520 --> 00:03:21.750
ICANN - MTS - A/V: These seem, good for public comment.

21
00:03:22.280 --> 00:03:31.799
ICANN - MTS - A/V: And on the next slide, just to note for the working groups, sorry, SRT's awareness, we will update the language as we go.

22
00:03:32.190 --> 00:03:34.809
ICANN - MTS - A/V: Throughout these sessions, and what has been agreed.

23
00:03:35.200 --> 00:03:47.740
ICANN - MTS - A/V: And we will share everything with the group along the way, but also ultimately after ICANN 87, so that the SRT can look at it from a complete perspective, and then we can take follow-up.

24
00:03:47.880 --> 00:03:51.869
ICANN - MTS - A/V: after ICANN 87 in the normal working group calls.

25
00:03:52.840 --> 00:03:54.830
ICANN - MTS - A/V: Back to… Mark, thank you.

26
00:03:56.010 --> 00:03:58.199
ICANN - MTS - A/V: Thank you, Fedor. Next slide.

27
00:04:00.560 --> 00:04:10.430
ICANN - MTS - A/V: All right. So our first topic for today will be the follow-up discussions on REC 3 and 8, specifically related to privacy proxy.

28
00:04:10.720 --> 00:04:29.130
ICANN - MTS - A/V: And if you're following along on the mailing list, you'll note that we heard from, from David. David has, proposed some, GAC language as well. So as, as we go through this, I'll, give David an opportunity to speak to the language that he spent… sent to the mailing list.

29
00:04:29.350 --> 00:04:32.850
ICANN - MTS - A/V: But in the meantime, I want to.

30
00:04:33.270 --> 00:04:41.570
ICANN - MTS - A/V: I want to go through, sort of, what we heard during Thursday's call, as a, as a background to the new proposed language.

31
00:04:41.730 --> 00:04:55.949
ICANN - MTS - A/V: And so we have, input from the GAC, and, during Thursday's call, I think, or during Thursday's in-person meeting, David, proposed the, the same language he went around to the mailing list.

32
00:04:56.050 --> 00:05:04.270
ICANN - MTS - A/V: And so we've tried to incorporate that GAC feedback into the language leadership team is proposing.

33
00:05:04.560 --> 00:05:10.389
ICANN - MTS - A/V: We heard from IPC regarding access to the underlying data.

34
00:05:10.740 --> 00:05:20.110
ICANN - MTS - A/V: We heard concerns from registrars and NCSG about legal and operational limits, as well as data subject safeguards.

35
00:05:20.250 --> 00:05:39.590
ICANN - MTS - A/V: And so, given, given all the input we received and the different, perspectives, we've taken in all that feedback and input and proposed a compromise language that we think incorporates elements to the best of our ability.

36
00:05:39.720 --> 00:05:41.350
ICANN - MTS - A/V: So, next slide, please.

37
00:05:45.400 --> 00:05:51.580
ICANN - MTS - A/V: As I said, the leadership proposed language proposes a middle ground.

38
00:05:51.750 --> 00:06:09.950
ICANN - MTS - A/V: For, when the contracted party has access to the data, it should disclose the data. Just note that, that should is a change from, previous, May language. Should disclose if the contracted party determines that disclosure is permitted under applicable law, contracts, and policy.

39
00:06:13.040 --> 00:06:18.150
ICANN - MTS - A/V: We also have language in the recommendations.

40
00:06:18.310 --> 00:06:26.440
ICANN - MTS - A/V: Where the contracted party can indicate if the, in REC 3.11,

41
00:06:26.470 --> 00:06:46.170
ICANN - MTS - A/V: where they will… where they're willing to handle disclosure requests via the SSAD. This was feedback from RDRS. We know that some registrars are willing to handle disclosure requests via the RDRS, and want to be able to do so via the SSAD as well.

42
00:06:46.500 --> 00:06:56.460
ICANN - MTS - A/V: And, where the contract party does not have access to the data, they're expected to clearly indicate that, and where possible.

43
00:06:57.050 --> 00:07:05.930
ICANN - MTS - A/V: Provide in the response the path, or the channel where the requester, can go in order to submit the request.

44
00:07:06.650 --> 00:07:15.160
ICANN - MTS - A/V: So we've tried to take into account all the feedback and input we've received so far.

45
00:07:15.550 --> 00:07:17.759
ICANN - MTS - A/V: And if we go to the next slide, please.

46
00:07:20.510 --> 00:07:34.900
ICANN - MTS - A/V: I think this gets us to the, the proposed, leadership language. Don't worry, I'm not gonna read all this out, to everybody. We did send this language out previously, and hopefully everybody's had a chance to review it.

47
00:07:35.340 --> 00:07:42.250
ICANN - MTS - A/V: What I'd like to do, to start with is just, throw it out to the, to the SRT.

48
00:07:43.920 --> 00:07:48.179
ICANN - MTS - A/V: Are there questions, feedback, support, objections?

49
00:07:48.340 --> 00:07:53.389
ICANN - MTS - A/V: And, John, looks like you're up first, so please, go ahead.

50
00:07:54.550 --> 00:08:07.550
ICANN - MTS - A/V: Thanks, John McAwin, for the record. So the IPC was discussing this in the… actually in this room right before this, and we liked the language. I see that it incorporates the GACS language in that second paragraph.

51
00:08:07.720 --> 00:08:14.129
ICANN - MTS - A/V: The big question we have, and I think, you know, our support really determines on

52
00:08:14.240 --> 00:08:16.199
ICANN - MTS - A/V: What is the meaning of should?

53
00:08:18.430 --> 00:08:19.240
ICANN - MTS - A/V: Thanks.

54
00:08:22.830 --> 00:08:23.910
ICANN - MTS - A/V: Thanks, John.

55
00:08:25.910 --> 00:08:35.329
ICANN - MTS - A/V: Any other… so I'm not sure I'm in a position to answer that question. I know should generally has very specific meaning.

56
00:08:35.490 --> 00:08:41.870
ICANN - MTS - A/V: But I'm going to, Pass the mic over to Volker. Volker, go ahead.

57
00:08:42.010 --> 00:08:45.500
ICANN - MTS - A/V: Hello, Volker Greimer for the RSEG.

58
00:08:46.100 --> 00:09:02.680
ICANN - MTS - A/V: As a contracted party, when interpreting contracts, we would usually interpret the word should as a presumption of a certain outcome, without, final determination that it has to be that outcome. So there's a strong indication that this.

59
00:09:03.330 --> 00:09:08.719
ICANN - MTS - A/V: This would be the outcome, but there might be factors that exclude that, so that's how we would interpret should.

60
00:09:12.430 --> 00:09:14.649
ICANN - MTS - A/V: Thanks, Volker. John, go ahead.

61
00:09:15.850 --> 00:09:21.090
ICANN - MTS - A/V: So, I'm glad to hear that, because I think that's trending in the right direction.

62
00:09:21.970 --> 00:09:23.420
ICANN - MTS - A/V: you know, we…

63
00:09:23.720 --> 00:09:33.609
ICANN - MTS - A/V: have some proposed definitions of should. There's been others that have been used, I think, like, subsequent procedures had… didn't define should, but it really, in the…

64
00:09:33.870 --> 00:09:39.760
ICANN - MTS - A/V: Preamble, getting to the, implementation guidance, had some

65
00:09:40.050 --> 00:09:49.989
ICANN - MTS - A/V: similar language to what Volker just said. I mean, I could, drop something into an email or the chat with some ideas. With respect to this.

66
00:09:51.830 --> 00:09:58.899
ICANN - MTS - A/V: Again, getting along the same lines as what you see in the, subsequent procedures, discussion of this.

67
00:09:59.280 --> 00:10:01.899
ICANN - MTS - A/V: To me, it's looking at, like, using,

68
00:10:01.970 --> 00:10:21.059
ICANN - MTS - A/V: best efforts to, you know, follow through with the policy, unless there is another, you know, compelling reason not to, is, I mean, again, trying to get what Volker was getting at, which is not objectionable to us. But we just need to… we need to see that, and again, I'm happy to… to…

69
00:10:21.190 --> 00:10:25.830
ICANN - MTS - A/V: Take a shot at drafting something, no pride of authorship for people to look at.

70
00:10:29.580 --> 00:10:33.430
ICANN - MTS - A/V: Thanks, John. I'll note Sarah's pointing out, I think it should is…

71
00:10:33.700 --> 00:10:40.659
ICANN - MTS - A/V: I think the use of capital should here is intended to have meaning as defined in a specific RFC.

72
00:10:40.810 --> 00:10:48.339
ICANN - MTS - A/V: And I don't… Know that language off the top of my head, but, that…

73
00:10:48.670 --> 00:11:01.369
ICANN - MTS - A/V: Or to the extent that that's specifically applicable, but just calling that out, as, as capital should, generally has, has meaning and as, as defined, and Sam's helpfully put a link.

74
00:11:01.480 --> 00:11:03.859
ICANN - MTS - A/V: And RFC 2119.

75
00:11:04.260 --> 00:11:06.869
ICANN - MTS - A/V: Greg, go ahead.

76
00:11:08.980 --> 00:11:14.450
ICANN - MTS - A/V: Thanks, Greg Shatton for the record, and I was actually going to point out the same thing.

77
00:11:14.560 --> 00:11:34.089
ICANN - MTS - A/V: And, RFC 2119 says this word, or the adjective recommended, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

78
00:11:34.180 --> 00:11:35.749
ICANN - MTS - A/V: I'll put that into the chat.

79
00:11:37.840 --> 00:11:40.000
ICANN - MTS - A/V: Thanks, Greg. Becky, go ahead.

80
00:11:40.720 --> 00:11:46.320
ICANN - MTS - A/V: Apologies if I'm missing something, but I'm now a little confused because

81
00:11:46.700 --> 00:12:06.000
ICANN - MTS - A/V: David had circulated some language for 573, that basically says, where a disclosure request regards a domain registered through a privacy or proxy service, the contracted party must ensure the request is evaluated and responded to in line with the requirements of the consensus policy on privacy proxy registrations.

82
00:12:06.220 --> 00:12:13.490
ICANN - MTS - A/V: I guess I'm confused as to why we're not considering that Same approach.

83
00:12:14.060 --> 00:12:16.700
ICANN - MTS - A/V: Consistently, all the way through.

84
00:12:16.900 --> 00:12:26.849
ICANN - MTS - A/V: I mean, I understand the language that was circulated was about 573, but… This suggests that… different standard than

85
00:12:27.370 --> 00:12:31.350
ICANN - MTS - A/V: would be suggested by the language that GAC has come up with.

86
00:12:33.510 --> 00:12:36.440
ICANN - MTS - A/V: Thanks, Becky. I'll note there's two pages.

87
00:12:36.630 --> 00:12:48.710
ICANN - MTS - A/V: To the language, and the second… and so I just had the first page up. I think the second page, refers to what you were talking about, referencing the privacy proxy, policy.

88
00:12:54.660 --> 00:12:56.410
ICANN - MTS - A/V: Theodore, do you want to jump in there?

89
00:12:58.660 --> 00:13:15.590
ICANN - MTS - A/V: Hi, everyone, Feodora. Just to note, regarding this language, and based on the path that the SRT had already discussed and established, we understood that the group wants more than a may, but a must might not be possible, so that's where, we…

90
00:13:15.740 --> 00:13:33.690
ICANN - MTS - A/V: thought it should… could help, taking into consideration various factors. However, we were also referencing that, this relates to what is already accessible and can be provided. However, in the language that is in black and was already in the recommendation,

91
00:13:33.750 --> 00:13:41.850
ICANN - MTS - A/V: What is not accessible and cannot be provided would be subject to, the policy on privacy proxy, and also to 8.5, where

92
00:13:41.900 --> 00:13:56.940
ICANN - MTS - A/V: we would need to provide a rationale or next steps to the requester where possible. So, it was kind of to see the two steps or different situations. I hope that clarifies. Otherwise, yeah.

93
00:13:57.030 --> 00:13:59.010
ICANN - MTS - A/V: Happy to adjust. Thank you, Mark.

94
00:14:00.350 --> 00:14:05.420
ICANN - MTS - A/V: Thanks, Feodora. Greg, is that, old hand, or… Both.

95
00:14:05.740 --> 00:14:08.249
ICANN - MTS - A/V: Okay. Your mic's on, also.

96
00:14:09.170 --> 00:14:10.960
ICANN - MTS - A/V: Becky, new hand?

97
00:14:12.490 --> 00:14:13.890
ICANN - MTS - A/V: So I.

98
00:14:14.350 --> 00:14:21.469
ICANN - MTS - A/V: I understand that, I understand the explanation, but I guess my question is.

99
00:14:21.630 --> 00:14:25.559
ICANN - MTS - A/V: Doesn't it make sense to say.

100
00:14:25.870 --> 00:14:43.019
ICANN - MTS - A/V: this… the… how you… how you… your obligations with respect to disclosure of privacy and proxy data should be decided in one place, and we're saying it's the PPSAI. I mean, I'm interested in what David has to say about that. I just…

101
00:14:43.120 --> 00:14:55.799
ICANN - MTS - A/V: Seems like I do understand, but I guess I want to have the previous question of, doesn't it make more sense just to say it's going to be decided in one place, and that's going to be what the policy is?

102
00:14:57.260 --> 00:15:12.140
ICANN - MTS - A/V: Thanks, Becky. I see David's raised his hand in the queue, and why don't I just turn the floor over to him to present his proposal, which I think is basically what you're asking, right? So, so David, floor is yours, go ahead.

103
00:15:13.650 --> 00:15:24.190
ICANN - MTS - A/V: Thanks, Mark. Yes, and thanks, folks, for, considering the proposal that we circulated earlier today. So basically, the proposed text.

104
00:15:24.250 --> 00:15:35.229
ICANN - MTS - A/V: is… sort of gets at the… the idea that, you know, it's very important for the GAC, first of all, that the SSAD provide meaningful consideration when a requester submits the request through the SSAD.

105
00:15:35.320 --> 00:15:45.280
ICANN - MTS - A/V: So this language, we believe, is a compromised solution that recognizes, as Becky sort of points out, the ongoing policy work that's happening simultaneously through the PPSAI.

106
00:15:45.320 --> 00:16:03.430
ICANN - MTS - A/V: So I think the language avoids the result of having different requirements based on whether the request comes through the SSAT or not. So, we were really hoping that we could get support for the language here today, acknowledging that, you know, we had that conversation yesterday.

107
00:16:03.430 --> 00:16:15.470
ICANN - MTS - A/V: Around… or on Thursday, I suppose, around the policy requirements articulated in the RDP versus what's in the SAT, and some confusion that may arise from that, and trying to…

108
00:16:15.470 --> 00:16:30.429
ICANN - MTS - A/V: trying to, marry those two things. So, we think that, sort of pointing to the policy work that's happening in the PPSAI, and that could be the policy that, that sort of articulates how that privacy proxy data would be managed would be helpful.

109
00:16:30.960 --> 00:16:41.590
ICANN - MTS - A/V: Thank you. Happy to connect, offline, but, would, would, appreciate, any support if, folks do support the language. Thank you.

110
00:16:43.380 --> 00:16:54.960
ICANN - MTS - A/V: Thanks, David, and we have, we have that language up on the screen now, and just, just to clarify, this, this language would, replace the language that we just looked at, right?

111
00:16:56.680 --> 00:17:02.400
ICANN - MTS - A/V: And David's nodding his head for those not in the room. All right, Susan, please go ahead.

112
00:17:05.390 --> 00:17:11.180
ICANN - MTS - A/V: So, although I would like to agree with that, the thing that's troubling me is that the PPSAI is…

113
00:17:11.440 --> 00:17:18.409
ICANN - MTS - A/V: Is an implementation review team implementing a policy… some policy recommendations that already exist?

114
00:17:18.520 --> 00:17:20.250
ICANN - MTS - A/V: But they don't deal with this.

115
00:17:20.569 --> 00:17:29.459
ICANN - MTS - A/V: They deal with, you know, kind of accreditation of privacy proxy service providers and so on. They don't deal with obligations on disclosure.

116
00:17:29.570 --> 00:17:32.160
ICANN - MTS - A/V: And so that's my concern, is we've…

117
00:17:32.310 --> 00:17:34.580
ICANN - MTS - A/V: We're referring to a policy that isn't there.

118
00:17:38.560 --> 00:17:45.770
ICANN - MTS - A/V: Thanks, Susan. David, do you want to respond to that, or I can go to Ashley, who's next in queue? Sure, just…

119
00:17:46.040 --> 00:17:55.870
ICANN - MTS - A/V: Very quickly, I believe that the latest text may actually, resolve some of the questions that you might have, Susan, but I believe it does actually speak to that.

120
00:17:58.050 --> 00:18:00.219
ICANN - MTS - A/V: Thanks, David. Ashley, go ahead.

121
00:18:01.000 --> 00:18:02.590
ICANN - MTS - A/V: Thank you, Ashley Heineman.

122
00:18:02.710 --> 00:18:11.740
ICANN - MTS - A/V: representing registrars. And just to agree with what David said, there is text in the draft policy that does look at.

123
00:18:12.010 --> 00:18:21.710
ICANN - MTS - A/V: disclosure, and the PPSAI draft. But that being said, that's still under discussion. And… In terms of text.

124
00:18:21.820 --> 00:18:25.919
ICANN - MTS - A/V: I just wanted to say that I think what the GAC puts forward.

125
00:18:26.420 --> 00:18:27.319
ICANN - MTS - A/V: Or David.

126
00:18:27.460 --> 00:18:31.430
ICANN - MTS - A/V: It's actually much clearer, much more simple.

127
00:18:31.670 --> 00:18:34.969
ICANN - MTS - A/V: And I think the other text just adds a bit of.

128
00:18:35.090 --> 00:18:43.409
ICANN - MTS - A/V: confusion and complication. And in this instance, the way it is drafted, the registrars are okay with the word must here.

129
00:18:47.730 --> 00:18:49.870
ICANN - MTS - A/V: Okay, thanks, Ashley.

130
00:18:50.320 --> 00:18:52.120
ICANN - MTS - A/V: To…

131
00:18:52.690 --> 00:19:01.750
ICANN - MTS - A/V: level set for everybody else. What we're looking for here is to be able to finalize language for going out to public comment.

132
00:19:01.930 --> 00:19:14.050
ICANN - MTS - A/V: And we have, sort of two proposals. We have the leadership… leadership team's proposed compromise based on our discussion, Thursday, which.

133
00:19:14.250 --> 00:19:20.999
ICANN - MTS - A/V: John, said, potentially, he's supportive of, depending on interpretation of the word should.

134
00:19:21.160 --> 00:19:27.730
ICANN - MTS - A/V: And then we have, David's, GAC proposed language, which.

135
00:19:28.130 --> 00:19:38.519
ICANN - MTS - A/V: Ashley, on behalf of the registrars, are willing to support. Noting that, Tomas in chat is also on board with the GAC proposed language.

136
00:19:38.660 --> 00:19:52.070
ICANN - MTS - A/V: What I'd like to ask, is for… I need a… I'm looking for a strong mandate for which version of the language should go into the version that goes for public comment.

137
00:19:52.250 --> 00:20:07.940
ICANN - MTS - A/V: You know, so… you know, and if we're not able to agree on language, we'd revert to the previous version that we discussed on Thursday. So I do have some support for both.

138
00:20:08.010 --> 00:20:18.970
ICANN - MTS - A/V: And so, I'd like to… like to ask the group to weigh in, help give me clearer direction on what version should go into the, the public comment version.

139
00:20:19.130 --> 00:20:22.310
ICANN - MTS - A/V: So, Susan, you're, first up. Go ahead.

140
00:20:23.010 --> 00:20:32.749
ICANN - MTS - A/V: We were just gonna say, could we have, like, a short pause to talk it over, if you're trying to reach a decision, like, as we speak? Could we… could we take a short break?

141
00:20:33.570 --> 00:20:48.719
ICANN - MTS - A/V: Absolutely. Public comment isn't until November 10th, so we don't necessarily need to decide this moment. So, I mean, if we can come back on, you know, in a subsequent one of our meetings, that's fine. I thought you were trying to shut this off.

142
00:20:48.720 --> 00:20:58.560
ICANN - MTS - A/V: But, yeah, but yes, I would love to have this closed today, if at all possible. So if a short break would be helpful, we can do that.

143
00:21:03.120 --> 00:21:12.479
ICANN - MTS - A/V: Okay, then let's, let's take 5 to caucus, and, we'll pick back up. I see we have a queue. We'll, pick back up, in 5 minutes.

144
00:21:12.930 --> 00:21:20.529
ICANN - MTS - A/V: I'm sorry, Mark, I just wanted to clarify, are we having 3 options now, or 2 options? 3 options means one is…

145
00:21:20.650 --> 00:21:23.940
ICANN - MTS - A/V: We don't change anything. It was the original language.

146
00:21:24.100 --> 00:21:36.130
ICANN - MTS - A/V: Second option is whatever was proposed by the leadership team. Third option is the GAC language. Is that the three we're discussing? Essentially, yes.

147
00:21:36.310 --> 00:21:42.710
ICANN - MTS - A/V: you know, I'm asking… I'm asking the group to indicate, you know, is there support, for…

148
00:21:43.080 --> 00:21:47.669
ICANN - MTS - A/V: either of the two new options. If there's not support, we would… we would…

149
00:21:48.170 --> 00:21:57.590
ICANN - MTS - A/V: stick with the existing… the existing language. I suppose if you wanted to weigh in and support the existing language, that's… that's fine, too. So, I think…

150
00:21:57.710 --> 00:22:02.709
ICANN - MTS - A/V: Essentially, the answer is yes. I'm asking the group to weigh in on the three different options.

151
00:22:03.750 --> 00:22:10.440
ICANN - MTS - A/V: Anne, did you want to jump in before? Very quickly, I mean, is there some sort of prohibition in…

152
00:22:10.760 --> 00:22:19.079
ICANN - MTS - A/V: a final report against asking for public comment on two different options? I mean, why can't you ask

153
00:22:19.360 --> 00:22:20.600
ICANN - MTS - A/V: the community.

154
00:22:21.110 --> 00:22:27.949
ICANN - MTS - A/V: Here are the two things we… Said, you know, we haven't… And we want your input.

155
00:22:28.710 --> 00:22:37.479
ICANN - MTS - A/V: We absolutely could. I'm not… sure that that's necessary in this case. Certainly that is an option, and if

156
00:22:37.720 --> 00:22:42.830
ICANN - MTS - A/V: You all tell me you can't decide between the two, then we could do that.

157
00:22:42.980 --> 00:22:49.149
ICANN - MTS - A/V: But I think I would prefer to go to public comment with a proposed path forward.

158
00:22:52.900 --> 00:22:57.440
ICANN - MTS - A/V: All right, so 5-minute break to caucus, and we'll pick back up shortly.

159
00:22:58.090 --> 00:23:01.189
ICANN - MTS - A/V: Thank you. We'll pause the recording for the 5 min break.

160
00:23:04.730 --> 00:23:05.790
ICANN - MTS - A/V: Please begin.

161
00:23:06.020 --> 00:23:25.799
ICANN - MTS - A/V: All right, thank you everybody for bearing with us while we had a, informal breakout session. I think, before we, before we pick back up the discussion, I would, like, to invite Wes to, say a few words at the mic. Wes, go ahead.

162
00:23:26.070 --> 00:23:29.899
ICANN - MTS - A/V: Thanks, Mark. This is Wes Hardaker, the board liaison to this group.

163
00:23:30.190 --> 00:23:32.510
ICANN - MTS - A/V: Or one of two, I should say.

164
00:23:32.850 --> 00:23:42.459
ICANN - MTS - A/V: I want to revisit sort of what I said on Thursday with respect to how to consider some of these, you know, more complex decisions, right?

165
00:23:42.610 --> 00:23:45.080
ICANN - MTS - A/V: You recall on Thursday, I talked about

166
00:23:45.720 --> 00:23:48.560
ICANN - MTS - A/V: Thinking about things from a bigger picture, right?

167
00:23:49.440 --> 00:23:52.239
ICANN - MTS - A/V: What is the system usability gonna look like?

168
00:23:53.000 --> 00:24:02.930
ICANN - MTS - A/V: And when you're thinking about weighting these different types of things, right, I don't mean just the usability from one user, I mean the usability of the entire system to all parties.

169
00:24:03.650 --> 00:24:13.509
ICANN - MTS - A/V: What is the implementation going to look like? What's the complexity of that gonna look like? And what's it gonna look like for all parties that are gonna be interacting with this system?

170
00:24:14.260 --> 00:24:26.789
ICANN - MTS - A/V: And as I said on Thursday, what does the cost look like? And as I indicated on Thursday, cost is not just in dollars, right? There's a number of ways that cost has to be considered, of which, you know, certainly dollars is part of it.

171
00:24:26.790 --> 00:24:38.219
ICANN - MTS - A/V: But it's not even cost to ICANN, which is what I said the other day, right? There's a cost to the registrars, there's a cost to the privacy proxy services, there's a cost to the users and their ability to use the system.

172
00:24:39.110 --> 00:24:46.410
ICANN - MTS - A/V: And then, you know, finally, a lot of this comes down to… What's the simple solution?

173
00:24:47.250 --> 00:24:49.099
ICANN - MTS - A/V: Right? Really complex…

174
00:24:49.600 --> 00:24:57.709
ICANN - MTS - A/V: you know, systems with a lot of parties that need to communicate end up to be fairly expensive in terms of all of the things I just listed.

175
00:24:58.020 --> 00:24:58.920
ICANN - MTS - A/V: So…

176
00:24:59.120 --> 00:25:07.229
ICANN - MTS - A/V: a lot of times, the right approach is often the simplest, right? It's the simplest for everybody, it's the simplest in cost, it's the simplest in implementation, so…

177
00:25:07.370 --> 00:25:22.949
ICANN - MTS - A/V: This, to me, you know, everything I just said seems to focus a lot on the choices between these. Obviously, the board will, you know, consider anything that this group has to put forward, but from our perspective, that's, you know, that would be sort of the major concerns we have.

178
00:25:25.780 --> 00:25:40.380
ICANN - MTS - A/V: Thanks, Wes, and thanks for jumping in there. I do want to reiterate that this is not the absolute last word on this. This is a decision about what version of the text we would like to send to public comment. You know, of course, we'll have.

179
00:25:40.490 --> 00:25:43.570
ICANN - MTS - A/V: The ability and the option to evaluate public comments.

180
00:25:43.750 --> 00:25:47.959
ICANN - MTS - A/V: And, and adjust the language as, as appropriate.

181
00:25:48.150 --> 00:26:06.739
ICANN - MTS - A/V: But, I would like us to put our best possible version out to public comment as possible. So I appreciate… I know that privacy proxy has proven to be one of the most challenging topics for us to deal with, and so I appreciate everybody's time and attention to this one.

182
00:26:07.430 --> 00:26:13.040
ICANN - MTS - A/V: All right, with that, having had time to caucus, who would like to weigh in?

183
00:26:15.780 --> 00:26:17.540
ICANN - MTS - A/V: All right, John, thank you.

184
00:26:18.360 --> 00:26:36.060
ICANN - MTS - A/V: Yeah, so John Macklin, for the record, and speaking with the GAC representatives, the IPC can support their proposal. We think it does pretty much capture what the group has been talking about. It does require, for

185
00:26:36.090 --> 00:26:49.609
ICANN - MTS - A/V: the IRT working on the PPSAI to implement what is currently in place there, but provided that happens, I think it accomplishes everything that we want to have happen. Thanks.

186
00:26:51.190 --> 00:26:53.139
ICANN - MTS - A/V: Thanks, John. Anyone else?

187
00:26:55.030 --> 00:26:55.850
ICANN - MTS - A/V: Becky.

188
00:26:56.210 --> 00:27:01.419
ICANN - MTS - A/V: Oh, sorry. Yeah, Becky, please go ahead. The registries support the GAC language.

189
00:27:03.760 --> 00:27:05.100
ICANN - MTS - A/V: Thanks, Becky.

190
00:27:05.650 --> 00:27:08.850
ICANN - MTS - A/V: Anyone else want to jump in or object?

191
00:27:11.040 --> 00:27:20.510
ICANN - MTS - A/V: Steve, go ahead. Thank you. I finally found the, place to raise my hand there. Support the GAC. Same as… same as IPC.

192
00:27:21.000 --> 00:27:22.450
ICANN - MTS - A/V: Speaking for BC.

193
00:27:23.290 --> 00:27:25.670
ICANN - MTS - A/V: Thank you, Steve. Farsnet, go ahead.

194
00:27:29.460 --> 00:27:31.250
ICANN - MTS - A/V: We support.

195
00:27:31.590 --> 00:27:33.170
ICANN - MTS - A/V: GAC language.

196
00:27:33.620 --> 00:27:36.080
ICANN - MTS - A/V: as non-commercial stakeholder group.

197
00:27:37.060 --> 00:27:39.709
ICANN - MTS - A/V: And this is a moment of celebration.

198
00:27:40.070 --> 00:27:40.780
ICANN - MTS - A/V: Yeah.

199
00:27:43.870 --> 00:28:00.040
ICANN - MTS - A/V: Wow, thank you. I'll second that, and thank you, everybody, for weighing in on this. I'll take that as consensus to proceed with the GACS language on this. Thank you, David, for presenting this and proposing it to the group.

200
00:28:00.160 --> 00:28:10.210
ICANN - MTS - A/V: So we'll use, use that as the… so we'll replace the GAC's proposed language for 5.7.3 as the, proposed path forward.

201
00:28:10.330 --> 00:28:12.260
ICANN - MTS - A/V: And… Feodora, please.

202
00:28:12.260 --> 00:28:15.310
Feodora Hamza - ICANN Org: Go ahead. I just have a clap.

203
00:28:18.400 --> 00:28:25.310
ICANN - MTS - A/V: I think it's 8.7.3 or is it 5.7.3? Can we just clarify where you would like?

204
00:28:30.000 --> 00:28:35.490
ICANN - MTS - A/V: I think… I think it's… the new number is 5.7.3, but I think it was the old 8.7.3.

205
00:28:36.950 --> 00:28:43.859
ICANN - MTS - A/V: Sorry, because we were… Mark announced that we would use the old numbering, so that's why I was just confused, but thank you.

206
00:28:46.190 --> 00:28:52.079
ICANN - MTS - A/V: Okay, I think we're all set on this one, and I think, John and Steve, those are, old hands.

207
00:28:54.400 --> 00:29:00.080
ICANN - MTS - A/V: So, with that, I think we can go back to our slides and, pick up…

208
00:29:04.160 --> 00:29:07.510
ICANN - MTS - A/V: So we'll continue, so that, that wraps up.

209
00:29:08.530 --> 00:29:17.740
ICANN - MTS - A/V: That wraps up our discussion on privacy proxy, which I know we already had a round of applause, but, another one might be in order.

210
00:29:17.760 --> 00:29:32.680
ICANN - MTS - A/V: So, that's, that wraps up our discussion on privacy proxy, through, through to, through public comment. So, again, privacy proxy has been, been quite a challenge, so I, I thank everybody for their, their…

211
00:29:32.760 --> 00:29:41.580
ICANN - MTS - A/V: Good faith discussions on this and contributions, and, look forward to seeing how the public comments play out.

212
00:29:42.110 --> 00:29:46.850
ICANN - MTS - A/V: With that, we're gonna shift gears and talk about Recommendation 1.

213
00:29:46.960 --> 00:29:57.139
ICANN - MTS - A/V: Similar to the privacy proxy discussion, we have new language from leadership team based on the discussion that happened during our Thursday face-to-face.

214
00:29:57.220 --> 00:30:07.349
ICANN - MTS - A/V: And we're looking for confirmation that the new language is fit for purpose to go into the public comment version.

215
00:30:07.470 --> 00:30:08.760
ICANN - MTS - A/V: Next slide, please.

216
00:30:10.860 --> 00:30:15.130
ICANN - MTS - A/V: I think, Theodore, do you wanna… Ts up, please.

217
00:30:18.220 --> 00:30:37.710
ICANN - MTS - A/V: Hi, everyone. So, based on the SRT discussion on Thursday, we've heard different suggestions and comments on how, recommendation 1 can be adjusted. This was specifically to, REC 1.3, to make clear that the requirements, administrative and technical and so on, will be.

218
00:30:37.740 --> 00:30:45.730
ICANN - MTS - A/V: done in consultation with the IRT, and later on, also, if changes need to happen with the Standing Committee, so, that is something we…

219
00:30:45.840 --> 00:30:47.919
ICANN - MTS - A/V: We have tried to address.

220
00:30:48.230 --> 00:30:55.269
ICANN - MTS - A/V: Furthermore, there was also a comment that the list of authentication providers should be made transparent and public.

221
00:30:55.470 --> 00:31:05.930
ICANN - MTS - A/V: and the communities they serve, so that is also language that we proposed can be added there. And, furthermore, one last change on this slide deck would be

222
00:31:06.650 --> 00:31:16.629
ICANN - MTS - A/V: the language on 1.4, just to make clear that ICANN Org would be responsible to manage the application process once all the requirements are set and published.

223
00:31:16.870 --> 00:31:18.859
ICANN - MTS - A/V: On the next slide.

224
00:31:21.960 --> 00:31:25.739
ICANN - MTS - A/V: Yes, I just talked to this. So this is just a

225
00:31:28.090 --> 00:31:30.429
ICANN - MTS - A/V: The language that Mark will introduce now.

226
00:31:32.690 --> 00:31:50.089
ICANN - MTS - A/V: Thanks, Feodora. If I could just highlight a couple items. The first is that we're making clear that during implementation, ICANN Org should consult with the implementation review team in establishing the framework

227
00:31:50.090 --> 00:31:55.130
ICANN - MTS - A/V: for authentication entities to become accredited.

228
00:31:55.210 --> 00:32:03.250
ICANN - MTS - A/V: So the framework, including administrative, technical, and security requirements, to become a recognized authentication provider.

229
00:32:03.650 --> 00:32:21.380
ICANN - MTS - A/V: Likewise, we've made it clear following implementation, if there are need… if there's a need to make changes to that framework, ICANN Org should consult with the Standing Committee, which will take over from the IRT. Next slide, please.

230
00:32:22.420 --> 00:32:24.810
ICANN - MTS - A/V: And then, lastly…

231
00:32:32.380 --> 00:32:43.689
ICANN - MTS - A/V: Sorry. And then, we've, added clarification, to 1.9, that the list of, recognized authentication providers

232
00:32:43.690 --> 00:32:52.540
ICANN - MTS - A/V: should be published and maintained for each category of requesters.

233
00:32:52.780 --> 00:32:59.980
ICANN - MTS - A/V: So hopefully that language, reflects Oh, sorry, one more slide.

234
00:33:01.550 --> 00:33:18.069
ICANN - MTS - A/V: On 1.4, we've also made a change, to clarify that it's ICANN's, ICANN Org's sole responsibility for determining if an authentication provider meets the criteria to become recognized.

235
00:33:18.190 --> 00:33:32.920
ICANN - MTS - A/V: And so, I think there was some question during our discussion on Thursday whether that would be ICANN Org's responsibility or ICANN Org in association with the Standing Committee or IRT.

236
00:33:32.990 --> 00:33:38.900
ICANN - MTS - A/V: So we added language in 1.4 to clarify that it's ICANN Org's responsibility.

237
00:33:39.750 --> 00:33:47.300
ICANN - MTS - A/V: And so I think that is… yes, that's the proposed language, or the proposed edits.

238
00:33:47.470 --> 00:33:50.870
ICANN - MTS - A/V: to, to REC 1.

239
00:33:51.110 --> 00:33:54.449
ICANN - MTS - A/V: Now, before I close this out, I do want to note.

240
00:33:55.010 --> 00:34:10.570
ICANN - MTS - A/V: We heard from the GAC. The GAC has additional feedback, I think specifically on Section 1.3. Unfortunately, that came in after we had prepared the material, for, today's meeting.

241
00:34:10.670 --> 00:34:20.090
ICANN - MTS - A/V: So similarly to the language on REC 8, I'll invite the GAC to speak to those proposed changes.

242
00:34:20.090 --> 00:34:32.960
ICANN - MTS - A/V: But before they do, I'd like to, ask the, group if they can weigh in on, the proposed changes to, to REC 1. And Steve, you're up first. Go ahead.

243
00:34:33.290 --> 00:34:35.129
ICANN - MTS - A/V: Thank you.

244
00:34:36.330 --> 00:34:55.089
ICANN - MTS - A/V: Even with all those words there, it's not 100% clear to me whether the following… what the status of the following is. Are we anticipating that there could be different requirements for authentication providers serving different communities, or is this a single standard to be applied to all authentication providers?

245
00:34:55.120 --> 00:35:08.400
ICANN - MTS - A/V: So that's a question. And let me now add a comment. This is a service, the way this is written, this is a service performed by ICANN Org on behalf of the registrars.

246
00:35:09.650 --> 00:35:21.710
ICANN - MTS - A/V: the criterion for appropriateness is, does this meet the needs of the registrars? So, ultimately, the consultation has to reflect

247
00:35:21.760 --> 00:35:33.260
ICANN - MTS - A/V: that the registrar's needs and their processes are being supported here, ICANN

248
00:35:33.790 --> 00:35:44.030
ICANN - MTS - A/V: If ICANN were operating entirely on its own and saying, well, we decided the following, then that's imposing the answers on the

249
00:35:44.030 --> 00:35:59.269
ICANN - MTS - A/V: data holders, but in fact, that doesn't do any good if the data holders don't, want to use… I mean, don't trust or find that satisfactory, so there has to be a connection between what the registrars actually need and what ICANN does on their behalf.

250
00:35:59.480 --> 00:36:01.460
ICANN - MTS - A/V: I'm not sure that's adequately…

251
00:36:01.690 --> 00:36:10.059
ICANN - MTS - A/V: It's partially but not adequately in my mind nailed down that ICANN Org in this is operating.

252
00:36:10.350 --> 00:36:14.629
ICANN - MTS - A/V: On behalf of the registrars, as opposed to imposing on the registrars.

253
00:36:16.450 --> 00:36:18.689
ICANN - MTS - A/V: Thanks, Steve. Farshnate, go ahead.

254
00:36:20.730 --> 00:36:22.350
ICANN - MTS - A/V: Fires anybody.

255
00:36:22.520 --> 00:36:26.600
ICANN - MTS - A/V: So, my question on the first one is.

256
00:36:26.890 --> 00:36:34.070
ICANN - MTS - A/V: And I have asked this before, so what do we mean by designee? ICANN Org or its designee?

257
00:36:34.150 --> 00:36:51.310
ICANN - MTS - A/V: how does ICANN choose a designee? Are we talking about, like, the firms that provide the service? So that's one, question. The other thing is that after, in the red, line, the second one.

258
00:36:51.470 --> 00:36:55.109
ICANN - MTS - A/V: I don't like that there's, if warranted there.

259
00:36:55.240 --> 00:36:59.419
ICANN - MTS - A/V: I mean, I… I feel like it's, kind of…

260
00:36:59.720 --> 00:37:09.500
ICANN - MTS - A/V: Like, we need more clarity, maybe we get rid of, if warranted. For the second one, I think it's on the second… on the next slide.

261
00:37:11.940 --> 00:37:22.040
ICANN - MTS - A/V: I think, we like that kind of transparency and accountability. It's not… Can you… yeah. So.

262
00:37:22.280 --> 00:37:27.610
ICANN - MTS - A/V: Yeah, I think… I think this is good. It addresses our concern.

263
00:37:27.900 --> 00:37:34.470
ICANN - MTS - A/V: And for the last one, if we can pull it up, sorry.

264
00:37:34.650 --> 00:37:46.840
ICANN - MTS - A/V: So we, again, we have this designee here, and how does the… how does ICANN choose this designee? That's important for us to know. Another thing is that

265
00:37:47.100 --> 00:37:49.310
ICANN - MTS - A/V: That.

266
00:37:49.510 --> 00:38:01.139
ICANN - MTS - A/V: So we are saying that ICANN is the only responsible party for authentication of these providers, and they don't have to do it in consultation with the community.

267
00:38:02.620 --> 00:38:08.380
ICANN - MTS - A/V: That… the African, the published current. So of

268
00:38:08.550 --> 00:38:20.970
ICANN - MTS - A/V: that I think that it was very useful when we talked to LEA in the LEA group, we talked to like FBI and Interpol, and they told us.

269
00:38:20.970 --> 00:38:36.210
ICANN - MTS - A/V: what sort of protocols they have for, like, holding themselves accountable, and I just think that we should have those conversations, we should have those conversations with the future and potential authenticated providers.

270
00:38:36.400 --> 00:38:47.430
ICANN - MTS - A/V: And maybe that way it can help also ICANN Org to make the decision of authenticating certain providers.

271
00:38:47.580 --> 00:39:00.510
ICANN - MTS - A/V: And I just think that this paragraph, we might be able to say that, like, for the onboarding and stuff, the community should be consulted, or something like that.

272
00:39:02.620 --> 00:39:05.570
ICANN - MTS - A/V: Okay, thanks, Farshney.

273
00:39:05.840 --> 00:39:08.540
ICANN - MTS - A/V: What I'd like to do real quick is.

274
00:39:08.900 --> 00:39:14.989
ICANN - MTS - A/V: If I could put, Lisa on the spot to answer Farzaneh's question about, designees.

275
00:39:15.220 --> 00:39:30.929
ICANN - MTS - A/V: And then, I have Anne in the queue, I'll go to you. And then in the interest of time, I want to give David time to speak to the GAC proposal. So we'll go Lisa, Anne, and then David, if you're…

276
00:39:30.960 --> 00:39:35.770
ICANN - MTS - A/V: ready, I'll ask you to speak to your proposal. So, Lisa, please go ahead.

277
00:39:36.050 --> 00:39:46.460
ICANN - MTS - A/V: Thanks, Mark. This is Lisa Carter for the record. In terms of what is meant by designee, that would mean maybe a third party that ICANN might

278
00:39:46.730 --> 00:39:49.099
ICANN - MTS - A/V: Assigned to do this?

279
00:39:49.470 --> 00:40:01.170
ICANN - MTS - A/V: We don't have a final way that this system is going to be handled yet, so this kind of allows the flexibility if ICANN wants to outsource something for us to do that. That's what the designee language means.

280
00:40:03.440 --> 00:40:05.309
ICANN - MTS - A/V: Thanks, Lisa. Anne, go ahead.

281
00:40:06.700 --> 00:40:13.060
ICANN - MTS - A/V: Thanks, appreciate the changes to the language, and, on the topic of.

282
00:40:13.800 --> 00:40:30.150
ICANN - MTS - A/V: you know, how this standards get… framework further gets developed. I think the intent we discussed in the all-day meeting was that there would be a, you know, direct consultation with the IRT, and the IRT,

283
00:40:30.530 --> 00:40:34.730
ICANN - MTS - A/V: It does sort of raise the question of how a designee.

284
00:40:35.480 --> 00:40:40.410
ICANN - MTS - A/V: consults with the IRT. I mean, I assume that it would be…

285
00:40:40.520 --> 00:40:50.070
ICANN - MTS - A/V: you know, ICANN working with the IRT first, and then… issuing an RFP or whatever.

286
00:40:50.320 --> 00:40:53.600
ICANN - MTS - A/V: That seems to be a little bit awkward, because the…

287
00:40:54.720 --> 00:41:04.620
ICANN - MTS - A/V: are we saying the third-party designee would be consulting with the IRT? I'm not… I'm not too sure about that part. And then.

288
00:41:06.180 --> 00:41:12.530
ICANN - MTS - A/V: Actually, on the slide… Yeah, the first… this slide here.

289
00:41:12.990 --> 00:41:19.610
ICANN - MTS - A/V: I didn't notice it before, but when Farsanae brings up If warranted…

290
00:41:20.020 --> 00:41:28.739
ICANN - MTS - A/V: Yeah, again, I'm not quite too sure about that either, and maybe we don't need, if warranted, maybe it should just be

291
00:41:29.500 --> 00:41:30.330
ICANN - MTS - A/V: you know.

292
00:41:31.510 --> 00:41:34.000
ICANN - MTS - A/V: If you're proposing to change the framework.

293
00:41:34.690 --> 00:41:37.469
ICANN - MTS - A/V: Go ahead, consult with the Standing Committee.

294
00:41:40.340 --> 00:41:45.080
ICANN - MTS - A/V: Okay, thank you. Steve, I think that's an old hand.

295
00:41:45.390 --> 00:41:56.460
ICANN - MTS - A/V: Yeah. Okay. And, David, I'd like to turn the floor over to you to speak to the GAC's feedback on, I think, 1.3 specifically. David, the floor is yours.

296
00:41:56.720 --> 00:41:57.730
ICANN - MTS - A/V: Thanks, Mark.

297
00:41:57.950 --> 00:42:17.389
ICANN - MTS - A/V: Yeah. So, thanks everybody. I know that we submitted this, we sort of table-dropped it last minute, so I really do appreciate the group's, consideration of the request, and certainly this is a conversation that we'll have to, that will certainly be ongoing. And thanks for leadership for their proposed edits that they've circulated as well. Really appreciate it.

298
00:42:17.590 --> 00:42:32.159
ICANN - MTS - A/V: So, we've provided a rationale for each change in the document, so I won't go through each red line change, but, I'm happy to talk about the change, the changes that we've made or are proposing offline if, folks have questions.

299
00:42:32.380 --> 00:42:40.790
ICANN - MTS - A/V: But, just in a broad sense, firstly, there's sort of a set of edits that provides more flexibility to accommodate different approaches to authentication.

300
00:42:40.900 --> 00:42:55.380
ICANN - MTS - A/V: So, for instance, the current language assumes that every authentication provider will take the exact same approach, or fixed term renewals, specifically to its users, but there are, or there probably will be cases that.

301
00:42:55.510 --> 00:42:58.150
ICANN - MTS - A/V: Won't take that same approach.

302
00:42:58.500 --> 00:43:11.529
ICANN - MTS - A/V: Also, the requirement for authentication providers to enter into a contract with ICANN would be challenging for governments and government entities. I think I've flagged this, when we first… one of our previous calls.

303
00:43:11.670 --> 00:43:16.130
ICANN - MTS - A/V: So the GAC is really looking for flexibility on this, requirement.

304
00:43:16.590 --> 00:43:33.339
ICANN - MTS - A/V: So, basically, it may be challenging for a government entity to enter into a binding contract with ICANN, specifically if they want to set up their own authentication provider, and we really don't want the recommendations to

305
00:43:33.340 --> 00:43:46.420
ICANN - MTS - A/V: preemptively exclude governments from participating as an authentication provider or setting up an authentication provider should they be in the position that they are not able to actually sign a binding contract with ICANN.

306
00:43:46.420 --> 00:44:05.680
ICANN - MTS - A/V: So we're looking for a little bit of flexibility in that, in that language as well. But, and then I think, we've also included some changes to the authentication tokens and some of the, the, edits that we've provided here in this document, I think reflect previous comments that we've had.

307
00:44:05.680 --> 00:44:20.819
ICANN - MTS - A/V: And Feodora, I apologize, but I think maybe on Thursday you had, said that there were still waiting for, subsequent edits that might take these into consideration. So these are just edits that, we've provided in, in, previous.

308
00:44:20.820 --> 00:44:26.650
ICANN - MTS - A/V: discussions as well, but they pretty much mirror the changes that we're looking for in 1.3.

309
00:44:26.920 --> 00:44:32.909
ICANN - MTS - A/V: But yes, thank you again for the group and thank you to leadership for accommodating the edits.

310
00:44:34.630 --> 00:44:40.799
ICANN - MTS - A/V: Great, thank you, David, and thank you for your, your feedback and, and explanation on this one.

311
00:44:40.920 --> 00:44:47.970
ICANN - MTS - A/V: We're, running low on time for our session, and we have a little bit of a queue. I'll get to the queue in a second, but…

312
00:44:48.060 --> 00:44:57.839
ICANN - MTS - A/V: I want to say, on… on this language, I think what leadership is proposing, we've gotten great feedback, Ann, Farsnay, Steve, thank you.

313
00:44:57.840 --> 00:45:11.869
ICANN - MTS - A/V: We've got the, the GAC proposal. What we'd like to do is propose, that, leadership team take all of this, into account and turn a new version for the, the SRT to review.

314
00:45:12.060 --> 00:45:27.720
ICANN - MTS - A/V: Again, happy to get to the queue here, but I think based on all the feedback we've heard, as much as I'd like to close out this REC today, I think clearly that's not going to happen, and so we'll need a new version that we can review.

315
00:45:27.880 --> 00:45:32.209
ICANN - MTS - A/V: But in the meantime, let's get to the queue. Sarah, you're up.

316
00:45:32.930 --> 00:45:40.019
Sarah Wyld (RrSG / Tucows): Good afternoon, this is Sarah. I hope I sound normal. I'm feeling shockingly okay.

317
00:45:40.210 --> 00:45:44.489
Sarah Wyld (RrSG / Tucows): I really appreciate the GAC team working on moving us forward through this section.

318
00:45:44.930 --> 00:45:59.299
Sarah Wyld (RrSG / Tucows): That said, I'm concerned that the proposal weakens the binding obligations on authentication providers to a degree that makes contracted parties unable to rely on those authentication outcomes.

319
00:45:59.680 --> 00:46:06.020
Sarah Wyld (RrSG / Tucows): The way I see it, if we get investigated by a data processing or data protection authority.

320
00:46:06.100 --> 00:46:19.680
Sarah Wyld (RrSG / Tucows): And we have to explain why we trusted the authentication and disclosed personal data. If we can't show that there's a contract governing how requesters are authenticated, then I think it would be hard to defend

321
00:46:19.680 --> 00:46:27.529
Sarah Wyld (RrSG / Tucows): trusting that authentication. So that puts us right back to the original problem with knowing who is submitting these requests.

322
00:46:27.850 --> 00:46:41.329
Sarah Wyld (RrSG / Tucows): I do think this is a great starting place, and we could consider maybe lighter weight options rather than a full-blown formal contract, which is where we were trying to get to with the binding language in the original text.

323
00:46:41.400 --> 00:47:00.150
Sarah Wyld (RrSG / Tucows): Now, I know David mentioned flexibility for authentication providers or governments, and I'm really sympathetic to that, but when the contracted party has a very inflexible deadline for response to urgent requests, it becomes really important, and that's why we're looking for that legal assurance. Thank you.

324
00:47:02.540 --> 00:47:07.680
ICANN - MTS - A/V: Thanks, Sarah. I have Farshne and then David. Farshne, go ahead.

325
00:47:08.560 --> 00:47:20.959
ICANN - MTS - A/V: So, we've been, talking about and insisting on, authentication provider accountability, and governments is one of the stakeholders that we are really

326
00:47:21.070 --> 00:47:39.989
ICANN - MTS - A/V: really, it's very important for us to hold them accountable, especially as, we have mentioned before, that some of, the, law enforcement agencies in different, governments, they abuse, different, systems to have access to data. So.

327
00:47:40.020 --> 00:47:57.849
ICANN - MTS - A/V: I… we can't agree that, that the authentication provider, especially if they're the government, should not have an agreement with ICANN, but if you have other… if you have other proposals as to how we can

328
00:47:57.950 --> 00:48:03.869
ICANN - MTS - A/V: hold them accountable, without the agreement, we are all ears, David.

329
00:48:06.060 --> 00:48:08.130
ICANN - MTS - A/V: Thank you, Farsney. David, go ahead.

330
00:48:09.020 --> 00:48:28.210
ICANN - MTS - A/V: So first off, I just want to thank, Sarah for her comments, and Farzaneh for her comments as well. I really appreciate, the openness to work together towards a workable solution, especially introducing some sort of flexible or some sort of accountability mechanism that might suit, suit us here, so I really do appreciate that.

331
00:48:28.290 --> 00:48:40.309
ICANN - MTS - A/V: And just for full transparency, and I forgot to mention it in my previous intervention when I was, introducing the, the changes, we've also introduced, new implementation.

332
00:48:40.310 --> 00:48:48.830
ICANN - MTS - A/V: guidance, and the GAC just wants an explicit reference to the understanding that once the SSAD recommendations are approved by the board and implemented.

333
00:48:48.830 --> 00:48:53.619
ICANN - MTS - A/V: And implemented, the urgent request policy will be operationalized.

334
00:48:53.790 --> 00:49:12.500
ICANN - MTS - A/V: I think that was a, from my understanding, a mutual understanding amongst the group, but I think that the GAC would be comfortable with a… or more comfortable with a explicit reference in the document. But, certainly happy to work with folks on language around, the changes that we've made to number one, so.

335
00:49:12.980 --> 00:49:14.839
ICANN - MTS - A/V: So, happy to touch base. Thanks.

336
00:49:16.150 --> 00:49:22.699
ICANN - MTS - A/V: Thanks, David. On that, implementation note, given where we are on time, I'll…

337
00:49:22.870 --> 00:49:29.099
ICANN - MTS - A/V: propose that we table that until one of our later sessions. Maybe we can get to that during Monday's session.

338
00:49:29.590 --> 00:49:33.589
ICANN - MTS - A/V: We're at the, we have about 5 minutes left.

339
00:49:34.710 --> 00:49:37.069
ICANN - MTS - A/V: If we go back to the slides.

340
00:49:40.010 --> 00:49:58.899
ICANN - MTS - A/V: So I thank everybody for a good discussion. I think this has, given the leadership team a bit to think about as far as new language. Thank you for the feedback. I think we can address some of it. On the point about needing

341
00:49:59.670 --> 00:50:17.300
ICANN - MTS - A/V: needing binding language for, for authentication entities, versus, maximum flexibility. I'm not exactly sure how to thread that needle, so we, we may need, additional… additional consideration on that one. I'm, I'm…

342
00:50:17.570 --> 00:50:19.260
ICANN - MTS - A/V: I think.

343
00:50:20.050 --> 00:50:35.810
ICANN - MTS - A/V: I'll say, you know, if we… if we don't have agreed-to language on that one, we'll go with our current language for public comments, but we do have a little bit of runway still until we get to public comments, so we can

344
00:50:35.810 --> 00:50:42.090
ICANN - MTS - A/V: Try and come to, to language that threads that particular needle.

345
00:50:42.350 --> 00:50:43.909
ICANN - MTS - A/V: So I think I'm…

346
00:50:44.300 --> 00:50:55.400
ICANN - MTS - A/V: Hearing a, you know, a clear and conflicting need for accountability, yet flexibility, which are difficult to check both boxes, but we'll do that as best we can.

347
00:50:57.070 --> 00:50:58.579
ICANN - MTS - A/V: Next slide, please.

348
00:51:02.250 --> 00:51:12.320
ICANN - MTS - A/V: All right, so our next SRT meeting will be, 19 October. It's, during the 3 p.m. local time slot.

349
00:51:14.720 --> 00:51:34.689
ICANN - MTS - A/V: to, to prepare for the meeting, we'll, we'll be looking for, outstanding, REC 6 and REC 13 items that are in the control sheet. So please, please review those and come prepared to, to discuss and, and find resolution. I think… are these our last AMBER items?

350
00:51:36.920 --> 00:51:52.829
ICANN - MTS - A/V: I think so. I think, I think these are the last, last items that we have marked as amber, on the control sheet. So it would be great if we could close those out during Monday's meeting. If not, we do have additional runway to try and do that.

351
00:51:53.170 --> 00:51:57.909
ICANN - MTS - A/V: So, as, as, and then…

352
00:51:58.770 --> 00:52:11.769
ICANN - MTS - A/V: Just sort of recap where we, where we landed on today. We have agreement on privacy proxy language, so we'll see that, reflected in our draft public comments, version.

353
00:52:11.900 --> 00:52:18.110
ICANN - MTS - A/V: And we'll work on updating the, the REC1 language.

354
00:52:18.410 --> 00:52:26.860
ICANN - MTS - A/V: And, we'll get that out to the, the full SRT as soon as we have, language available.

355
00:52:27.390 --> 00:52:28.600
ICANN - MTS - A/V: Next slide.

356
00:52:31.060 --> 00:52:35.850
ICANN - MTS - A/V: Any other… any other business? Any, questions, comments?

357
00:52:39.700 --> 00:52:54.899
ICANN - MTS - A/V: Not seeing any hands, it looks like we can, oh, Anne, sneaking in under the wire. Go ahead, Anne. Sorry, just a question whether, we will be able to hear from finance, from ICANN Finance, this week?

358
00:52:56.050 --> 00:53:05.740
ICANN - MTS - A/V: Thanks, Anne, good question. Yes, I've asked, for them to come to our Wednesday, our Wednesday meeting, and I've also…

359
00:53:05.930 --> 00:53:19.340
ICANN - MTS - A/V: I've also indicated that, there's a desire to have a better, to have a better understanding of the cost breakdown. I understand that they might not be far along… enough along that they'll be able to provide that.

360
00:53:19.340 --> 00:53:29.110
ICANN - MTS - A/V: But I've indicated that that is, that is what we want to talk about on Wednesday, is, better understanding of the costing and what the cost drivers are.

361
00:53:33.120 --> 00:53:36.649
ICANN - MTS - A/V: initial development and ongoing operational costs.

362
00:53:36.910 --> 00:53:40.870
ICANN - MTS - A/V: You know, and I, I, you know, to… I don't, you know, I can't…

363
00:53:41.060 --> 00:53:50.499
ICANN - MTS - A/V: I can't promise that they'll have that available for us on Friday, but I think they, you know, I've indicated that that's what we want to talk about on… er, sorry, Wednesday, during the Wednesday session.

364
00:53:52.270 --> 00:53:59.700
ICANN - MTS - A/V: Farzaneh, go ahead. Thank you for the incredible job of taking into account our feedback. We very much appreciate it.

365
00:54:03.630 --> 00:54:11.630
ICANN - MTS - A/V: Thank you, Farsnay, and with that, I think we can adjourn. Thank you very much for an excellent meeting, and we can end the recording.

366
00:54:13.740 --> 00:54:15.260
ICANN - MTS - A/V: And stop the recording.