00:02:13 #startmeeting S55 weekly meeting 00:02:13 Meeting started Thu Jan 30 00:02:13 2020 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:02:13 Useful Commands: #action #agreed #help #info #idea #link #topic. 00:02:31 hi there! I think it's just me and teor, but we're logging so that ahf and gaba can see the backlog 00:03:14 So I guess I should start with a status update 00:03:18 teor: Thanks for revising 311; I'm sorry I haven't read 312 yet, but I think I can get to it tomorrow 00:03:25 go for it! 00:04:05 After doing a draft roadmap on the pad, my next task was to write tor change proposals for each of the tasks in the sponsored work 00:04:16 I split the work up in to 3 different proposals 00:04:53 I've done first drafts for #24404 and #33073, the third proposal is about statistics and monitoring, it doesn't have a ticket or any drafts yet 00:05:14 The first two proposals are proposal 311 and 312 00:05:32 nickm and I have done a review and revisions on proposal 311 00:06:07 I've also made some minor revisions to proposal 312, the latest version is at https://github.com/torproject/torspec/pull/105 00:06:12 (done) 00:06:34 ok. I've reviewed 311 and plan to review 312 tomorrow. 00:06:38 311 lgtm 00:07:01 IMO you should merge it into torspec.git if you don't mind doing so 00:07:34 I'd like to do an initial review and squash, merge to tor-dev, and then send out an updated version to the list 00:07:39 ok 00:07:47 s7r has written a reply to proposal 312 about IPv6 address privacy 00:07:50 I have no other current to-do items here as far as I know, other than to stand ready for more stuff to review. 00:07:53 (done with my status) 00:08:10 anything we should discuss this week? Where do we want to be this time next week? 00:08:23 apparently IPv6 address privacy is off by default in debian, so I think we should try without any changes, and see how it works 00:08:45 (s7r is also going to try and see how tor works with IPv6 address privacy over the next week or so) 00:09:06 "IPv6 exit privacy" means "don't put your MAC in your IPv6 address"? 00:09:44 I don't know, I haven't had time to read the RFC yet. But I think it uses a seni-random value instead. 00:09:47 * semi-random 00:10:06 We had an ancient patch for detecting a lack of ipv6 privacy in #4806 00:10:15 but that's client-side 00:10:35 or rather, the need for ipv6 privacy is mostly client-side 00:12:41 Yes, I think on relays we'd want to avoid it 00:13:00 If possible, and if the IPv6 address changes frequently 00:13:39 I don't have much else to discuss this week 00:14:12 Next week, I'd like to have first drafts for all 3 proposals, be very close to final drafts, and open all the tickets (as gaba has asked me to do) 00:14:29 Or at least, open all the required tickets 00:15:18 I think we should avoid opening tickets for optional items, unless they are obviously faster to implement than the default 00:15:25 (I think there's only one of those) 00:15:46 We can decide how many optional items we have time for, when the basic functionality is working 00:15:49 (done) 00:17:22 nickm seems to have lost connection... 00:19:24 ok, that was annoying 00:19:49 There was a netsplit? About 5-10 users on one IRC host seem to have lost connection 00:20:04 What was the last thing you saw? 00:21:00 nickm ? 00:21:03 I saw you say "* 00:10 <+teor> * semi-random 00:21:13 oh my 00:21:38 i'll read http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-01-30-00.02.log.txt 00:21:51 that appears to be the meetbot log so far... 00:22:11 ok, I'm caught up. 00:22:24 Yes, meetbot saw everything I said 00:22:48 great 00:23:03 I expect that you and karsten will review the statistics and monitoring proposal 00:23:06 Was there anything you wanted to discuss, nickm? 00:23:09 I said a few things after that, but they were all "are you still there" and "is there a netsplit" 00:23:28 sounds good to me. 00:23:34 i'm done. 00:23:41 any objection to ending the meeting? 00:24:01 One more thing 00:24:34 I feel like we could spend ages trying to work out the correct amount of noise to add to the IPv4/IPv6 and client/relay connection and bandwidth statistics 00:24:54 agreed 00:25:00 I think noise should be optional, and we should get a basic stats implementation working first 00:25:21 I also think the right way to do noise is to do it consistently, something like privcount, rather than stat by stat 00:25:42 this would be "number of ipv6 connections, number of ipv4 connections"? 00:25:51 or somethign more specific, like number of bytes? 00:25:54 or ...? 00:26:22 we promised connections and bandwidth in the proposal, so it should be "number of connections" and "number of bytes" 00:26:44 I want to avoid circuit counts, and bridge statistics, because they are more sensitive (and out of scope) 00:27:14 karsten will also do some once-off queries for "number of IPv6 relays" and "number of IPv6 relays supporting IPv6 extends" 00:27:29 but they don't need any code from us 00:27:31 ok 00:28:10 I generally think those are safe. Maybe before we deploy we just use whatever mechanism we're using for connection counts and bandwidths now, but the proposal can say "we leave the noise unspecified" 00:28:34 Yes, I wanted to tweak the current implementation, rather than rewriting everything. 00:28:43 sounds fine 00:29:00 I also need to ask karsten if we need a migration period, where we include combined IPv4+IPv6, and also count them separately 00:29:01 So I think that's it, that's all the questions and status that I had. 00:29:34 sounds good. let's be in touch, and meet in a week! 00:29:35 #endmeeting