[03:45:31] gclark-ohiou leaves the room
[05:33:51] somaya joins the room
[05:34:34] somaya leaves the room: offline
[06:58:25] anssi joins the room
[06:59:08] jlcjohn joins the room
[06:59:11] astaikos joins the room
[07:01:29] jsimbol joins the room
[07:02:02] <jlcjohn> I'm getting no audio feed.
[07:10:05] beroset joins the room
[07:11:03] fomula joins the room
[07:14:17] Joseph Ishac joins the room
[07:17:19] <Joseph Ishac> Who's remote?
[07:17:32] gclark-ohiou joins the room
[07:20:17] sftcd joins the room
[07:20:37] Joseph Ishac polls for remote participants
[07:21:53] <ikogan> hello
[07:21:56] gclark-ohiou waves.
[07:23:16] ikogan leaves the room
[07:23:31] <sftcd> hI all there, can we get someone to scribe? Sorry for asking late;-)
[07:23:35] ikogan joins the room
[07:24:27] <Joseph Ishac> I can jabber scribe - which basically means I'll type up questions and responses
[07:24:37] <Joseph Ishac> but who here is remote?
[07:25:01] <ikogan> I am listening to the feed from Athens
[07:25:13] <Joseph Ishac> ah good
[07:25:16] <gclark-ohiou> same here
[07:26:01] <Joseph Ishac> any questions for the mic, put MIC: out in front
[07:26:10] <Joseph Ishac> and I'll relay them.
[07:27:10] <ikogan> Sure, thanks
[07:27:11] <Joseph Ishac> I was able to get SBP stuff to compile, but didn't get a chance to play with it
[07:27:17] gclark-ohiou nods.
[07:28:13] <sftcd> Thanks Joe
[07:28:46] Andrew Sullivan joins the room
[07:29:52] PasiS joins the room
[07:30:59] <ikogan> afaik, all of our clocks were synced to the minute
[07:31:36] <gclark-ohiou> 5MB is right
[07:31:43] <ikogan> Initially, only 5mb of shared memory was allocated
[07:31:44] <sftcd> Starting to put slides up now;-) At https://datatracker.ietf.org/meeting/75/materials.html and search down for dtnrg
[07:31:52] <ikogan> It worked a lot better when we bumped it up to about 30
[07:32:04] <gclark-ohiou> we upped it to 25 or 30MB
[07:32:48] <ikogan> We suspected that the older dtn2 implementation that kept expecting acks contributed fairly heavily to that problem (as Ion was holding all of those bundles in memory until expiration)
[07:33:31] <gclark-ohiou> note: the API isn't production ready!
[07:33:56] <Joseph Ishac> gclark-ohiou: want me to take that to the Mic?
[07:34:50] <gclark-ohiou> Joseph: I think it's all right
[07:35:14] <gclark-ohiou> Joseph: anybody who downloads the API and sees a python script in place of autotools should have an idea, at least :)
[07:35:56] <Joseph Ishac> the newest dtn2 has some sort of issue reading deferred bundles... the old version on Unit017 seemed to work better
[07:37:18] <Joseph Ishac> gclark-ohiou: :)
[07:39:04] PasiS leaves the room
[07:39:19] <ikogan> sshfs-fuse mounted over admin links
[07:39:22] <sftcd> These slides: http://www.ietf.org/proceedings/75/slides/DTNRG-5.ppt
[07:42:55] <Joseph Ishac> heh, I say it was 70% of the headaches
[07:43:30] <Joseph Ishac> quite a few people couldn't talk to unit017, simply b/c they overlooked the non-standard port
[07:43:34] <sftcd> then we should do something different next time I guess
[07:48:00] <sftcd> someone get pritwish to send a link to the dtn-interest list
[07:55:01] alexmcmahon joins the room
[07:56:07] PasiS joins the room
[07:56:41] <Joseph Ishac> Show of hands for reading and commenting on documents: about 8-9
[07:57:08] <Joseph Ishac> Q @mic: Any preference out of the long list?
[07:57:34] <Joseph Ishac> A: All, save security
[07:59:30] <Andrew Sullivan> ISTR in Mtn. View the Chairs suggested it'd be dangerous to publish prophet without other routing documents, for fear that prophet would become the Ont True DTN Routingi
[08:00:00] <Andrew Sullivan> does anyone else remember that discussion too, or did I imagine it?
[08:00:47] <Joseph Ishac> I vaguely remember something to that effect
[08:02:38] <Joseph Ishac> Kevin F: Vote for DTNRG meeting in Japan at next IETF?   2/3 of room... about 10 ppl?
[08:02:50] <sftcd> These slides are on their way to the meeting materials site
[08:03:50] <Joseph Ishac> Nikolaols Laoutaris presenting next
[08:04:28] <sftcd> turns out I need to get the slides from Kevin and post them afterwards, sorry
[08:08:55] <sftcd> go fedex!
[08:12:52] <Andrew Sullivan> This is pretty cool, but won't the transit providers change their billing practices the next time the contract is open, so that "free" valley doesn't happen any more?
[08:14:32] alexmcmahon leaves the room
[08:22:44] Armando Caro joins the room
[08:23:21] Daniel Ellard joins the room
[08:23:30] <Daniel Ellard> Anyone here?
[08:23:45] <gclark-ohiou> hi
[08:24:04] <Armando Caro> hi Dan
[08:24:17] <Daniel Ellard> Just wondering if anyone else was awake stateside.  
[08:25:00] <ikogan> I am, for the moment, awake
[08:25:05] <Armando Caro> gclark: are you listening to the audo feed
[08:25:13] <Armando Caro> same question to ikogan
[08:25:15] <gclark-ohiou> yes
[08:25:17] <ikogan> yes
[08:25:26] <Armando Caro> how's the sound? Dan is complaining about low gain
[08:26:21] <ikogan> It seems no worse than any other internet audio that I've heard
[08:26:41] <ikogan> Though, I do have to have all of my volumes up as high as possible to hear this adequately
[08:26:53] <Armando Caro> hmm
[08:27:05] <Daniel Ellard> I'm only getting it through the left channel, and it's quiet.  When I crank it up all the way I can hear it, but when I get any other kind of alert, it wakes up the neighbors.
[08:27:07] <gclark-ohiou> seems a little soft to me as well, but I just turned it up and it seems fine
[08:27:12] <gclark-ohiou> hah
[08:27:15] <ikogan> That's true, I am only getting a left channel
[08:27:18] <ikogan> I assumed that was normal
[08:27:38] <ikogan> If you guys plan on fixing it, could someone warn us?
[08:28:11] <gclark-ohiou> yeah, I'm wearing headphones + high volume.  increasing gain all of a sudden wouldn't be pretty.
[08:28:25] <Armando Caro> i'll warn. i'll bring it up as soon as this Q&A session ends
[08:28:40] <Andrew Sullivan> there's no AV tech in the room & I think therefore the chances of it changing much in the next hour is therefore pretty small
[08:28:55] <Armando Caro> ok
[08:28:58] <Andrew Sullivan> oops, too many therefores
[08:29:35] <Joseph Ishac> I don't think fiddling with hardware is a good idea given their technical difficulties with the projector
[08:29:55] <Armando Caro> so maybe i shouldn't bring it up, since we are behind schedule a bit
[08:30:03] <Andrew Sullivan> the projectors in the two theatres down here have been troublesome all week
[08:30:06] <sftcd> yep let's live with the current setup
[08:30:21] <Armando Caro> sorry guys.. 
[08:30:43] <Armando Caro> i'll try to pay attention to this room... so ask , and i can try to repeat/relay anything that was unclear to you
[08:31:48] <Joseph Ishac> hopefully no one drops a microphone ;)
[08:31:54] <Armando Caro> :-)
[08:33:07] <Daniel Ellard> Yes we only have an hour or so left and we seem to have been bogged down in the weight of bits.  Which is cool, but we have more agenda items to hit!
[08:35:20] Will Ivancic joins the room
[08:35:35] <sftcd> Nice Telefonica presentation; http://www.ietf.org/proceedings/75/slides/DTNRG-6.ppt
[08:43:14] <Joseph Ishac> Will Leland presenting on Bundle Extensions
[08:43:30] <sftcd> These slides: http://www.ietf.org/proceedings/75/slides/DTNRG-7.ppt
[08:43:33] <Armando Caro> yes, telefonica's talk was interesting... 
[08:43:45] <Daniel Ellard> Extensions to the bundle protocol, not extension blocks :-)
[08:44:05] <sftcd> Why not extension blocks? Could be or not.
[08:45:08] <Daniel Ellard> I predict that Will will argue that they should not.
[08:45:21] PasiS leaves the room
[08:45:51] <sftcd> Sure. But that doesn't mean he's correct or has consensus of course. We'll see I guess
[08:47:32] <Joseph Ishac> SF: Noted only one time in the interop
[08:47:43] <Joseph Ishac> ... where this was an issue
[08:47:46] PasiS joins the room
[08:48:23] <Joseph Ishac> Will I: Notes that it is a common troubleshooting issue
[08:49:06] <sftcd> rather that I only saw one node that had a wrong clock (wrong TZ) and one who's clock had to be set (mine:-)
[08:49:10] <Joseph Ishac> A: Notes that it's a heavy dependency
[08:49:46] <Armando Caro> sftcd: no there's no consensus yet on anything... that's why Will L is presenting this now... to get feedback and drive towards consensus
[08:50:01] <Joseph Ishac> Kevin Fall: Original concept had scheduled contacts, and that requires absolute time
[08:50:17] <Daniel Ellard> That was then; this is now.  Relatively speaking.
[08:51:35] <Joseph Ishac> Will Ivancic: Clarifying that absolute time is somewhat more of a convenience for scheduled links
[08:51:46] <Joseph Ishac> (although I think he didn't do a good job saying it)
[08:52:44] <Joseph Ishac> (Basically I don't see why you NEED absolute time in *DTN* to do scheduled contacts)
[08:53:33] <sftcd> I think saying "convenience" is overstated 
[08:53:53] <Joseph Ishac> yeah, I was trying to paraphrase
[08:54:28] <beroset> One can only derive an approximation to absolute time from a crystal timebase, but that assumes that such a clock is continuously running.
[08:55:14] <beroset> For power savings, devices often turn off high speed clocks and only run on low speed clocks during quiescent periods.
[08:55:25] <Daniel Ellard> Motes and similar low-power systems need to power down whenever possible.
[08:55:35] <Daniel Ellard> Whoops; what Beroset said.
[08:57:24] <Armando Caro> exactly
[08:57:36] <Armando Caro> plus cell phones have centralized infrastructure
[08:57:38] <gclark-ohiou> agreed
[08:57:41] <Armando Caro> and 1-hop wireless
[08:57:57] <beroset> It might be nice to actually see the rest of the presentation...
[08:58:30] <sftcd> its been posted to the list already so discussing now while we've time is IMO better
[08:59:02] <Armando Caro> yes, but we sort of knew that time sync was the more controversial topic
[08:59:13] fomula leaves the room
[08:59:25] <Andrew Sullivan> The argument at the mic right now sure sounded like "that's what the RFC says"
[08:59:48] <Daniel Ellard> I think discussion is good but there are other points in the presentation besides relative time, and they might merit discussion.
[08:59:51] <Andrew Sullivan> which has got to be the wrong argument from an IRTF working group
[09:00:05] <sftcd> or...that's what the research group said in those RFCs...we don't have to redo everything we do
[09:00:25] <Daniel Ellard> Andrew: agreed.  
[09:01:00] <Andrew Sullivan> of course not.  But it's pretty clear that there's lots of use cases where "and you have a clock that keeps good time" is not a true statement
[09:01:26] <Andrew Sullivan> therefore, what the RG assumed in its RFC turns out to be false. This is why we do research, no?
[09:01:59] <Joseph Ishac> Andrew Sullivan: agreed
[09:02:01] <sftcd> @Andrew: I agree (check the mailing list archive from some years ago) but I don't agree with overstating issues and some folks IMO are doing that some(times:-)
[09:02:20] <Andrew Sullivan> Really?  At an IETF/IRTF meeting?
[09:02:24] <Andrew Sullivan> :)
[09:03:04] <Joseph Ishac> I think Armando Caro comments at the mic were spot on
[09:04:03] teemu joins the room
[09:04:29] <Andrew Sullivan> yes, pretty much every system I've ever laid hands on does indeed have a lame oscillator!
[09:04:30] <Joseph Ishac> Well to me, "every systems got one" is an overstatement ;)
[09:04:55] <Joseph Ishac> my phone still doesn't even autosync :)
[09:05:29] badamson joins the room
[09:06:15] <sftcd> @joe: I agree, all sides of this discussion overstate (except me of course:-)
[09:06:29] <Joseph Ishac> sftcd: of course
[09:06:31] <astaikos> he did make reference to army systems, and many have very expensive and accurate oscillators, which contradicts his point that he has heard from army/marines folks that they have poor access to timing
[09:06:58] <beroset> don't relativistic effects make all time relative time?  :)
[09:07:11] <Andrew Sullivan> @astaikos: I think his point isn't perfectly clear from the preso and discussion
[09:07:12] <Armando Caro> military wants to move away from expensive systems... the programs bbn is working on is develop $500 radios to give every soldier
[09:07:19] teemu leaves the room
[09:07:21] <Daniel Ellard> Some army systems do, some don't.  And the one's that don't are the cheap ones that are in the field and would benefit most from DTN
[09:07:25] teemu joins the room
[09:07:31] <Armando Caro> their end goal is to have systems that are as cheap and disposable as cell phones
[09:08:01] Jeff Ward joins the room
[09:08:03] <Andrew Sullivan> but if you have multiple agencies all showing up together at a disaster site, the thing you want to do as step 1 is _not_ "now everyone reconfigure their systems"
[09:08:12] <Andrew Sullivan> (that's quite apart from the other points people just made)
[09:08:12] <Armando Caro> exactly
[09:08:23] <Armando Caro> configuration is the other thing that EVERYONE wants to avoid as much as possible
[09:09:39] <Joseph Ishac> I'd like to see someone show me what I lose by removing absolute time
[09:09:56] <Joseph Ishac> or point 5 on the slide
[09:10:20] <Joseph Ishac> that argument is what needs to be part of that document
[09:10:25] <Andrew Sullivan> I think that's the right question
[09:10:47] <Joseph Ishac> or what Will just said... what is the problem at hand, the property and how does each approach solve it
[09:10:51] <Daniel Ellard> which slide?  (slide 3?)
[09:11:06] <teemu> I guess you couldn't define the lifetime of a bundle in real time
[09:11:07] <Joseph Ishac> the one with timing... I don't see #'s 
[09:11:12] <sftcd> @dan (with the LARGE font) slide 4
[09:11:17] <Andrew Sullivan> yeah, the previous one (it's now slide 4 -- bottom left corner)
[09:11:26] <teemu> since in general you have no idea how long a bundle has lived while being sent over a link
[09:11:27] <Joseph Ishac> ah yes, it was 3 then
[09:11:37] alexmcmahon joins the room
[09:11:55] <Daniel Ellard> thx
[09:12:00] <gclark-ohiou> maybe this is a silly question, but wouldn't not having absolute clocks interfere with a node's access to certain systems (e.g. things that use certificates with expiration dates)?
[09:12:33] <Andrew Sullivan> yes, there are lots of applications where you need absolute time
[09:12:52] <Andrew Sullivan> that doesn't mean it should be part of the transport proto
[09:13:01] <gclark-ohiou> true enough
[09:13:33] <Andrew Sullivan> (heck, we even need abso time for DNS w/ DNSSEC now!)
[09:14:12] <sftcd> hop count arguments are IMO weaker
[09:14:42] <badamson> @teemuk: there are some protocols that can tell you how long a bundle has lived while being sent over a link - e.g., the NORM protocol has this information although I don't think that aspect has yet been leveraged in its use as a DTN convergence layer use
[09:14:57] <Joseph Ishac> it's to stop loops
[09:15:08] <Joseph Ishac> hop counts are very useful
[09:15:14] <sftcd> loops are explicitly allowed and sometimes optimal
[09:16:20] <teemu> Yes some protocols can tell you how long the bundle has lived on the wire, but that's not necessarily true for every protocol. I'm just thinking of a sneakernet scenario.
[09:16:37] <ikogan> Is reporting bundle transport time something that should be required of a convergence layer?
[09:17:17] <Daniel Ellard> That's devilishly hard for some link types.
[09:18:00] <sftcd> wonrgly
[09:18:13] <sftcd> wrongly, he retyped:-)
[09:18:20] <Will Ivancic> hop counts are also a very good debug tool.
[09:18:36] <Will Ivancic> and I can control resource utilization
[09:18:41] <Daniel Ellard> The customer is always right, at least if you want them to keep being your customer.
[09:18:41] <Andrew Sullivan> [rteyped, surely?]
[09:18:42] <Armando Caro> yes
[09:18:48] <Armando Caro> hop count limit is hard to get right
[09:19:03] <Armando Caro> but routing loops are hard to avoid too... but that's arguable worse to experience
[09:19:19] <gclark-ohiou> in DTN, a routing loop could be pretty bad with a hop count, though. . .
[09:19:31] <gclark-ohiou> *only using a hop count
[09:19:37] <teemu> In DTNs you sometimes _want_ routing loops
[09:19:47] <teemu> e.g., with data stores
[09:20:15] <teemu> where you want to drop off your bundle and pick it up later, which would look like a routing loop
[09:20:27] <astaikos> there has been a lot of work over the last few years to avoiding loops in link state routing
[09:20:31] <Joseph Ishac> right, so it's not to stop routing loops
[09:22:06] <Will Ivancic> teemu.  I agree that you may want to store and get back so you have a loop once or maybe three times or 5 times, but when it hits 10000 maybe something is wrong.
[09:22:19] <Joseph Ishac> err... not to stop them completely... it can't do that.  Rather it's to stop say, a bundle from quickly being passed around in error.  Just like it can happen now on the net.
[09:22:24] <Will Ivancic> I have seen such in manets and hop count is a very useful debug tool
[09:22:31] <sftcd> @will: how do you know what number is ok?
[09:22:42] <Armando Caro> it's not to STOP loops.. it's to prevent resource waste when loops were not properly avoided
[09:22:55] <Will Ivancic> it depends on you network.
[09:22:58] <Armando Caro> transient loops are always possible as far as i know
[09:23:07] <Joseph Ishac> sftcd: if you put a conter up on a bundle instead (just as a theory experiment)
[09:23:20] <Joseph Ishac> sftcd: and saw a number of 1000, would that be OK?
[09:23:27] <sftcd> @Will: so the answer is "it depends" which is as difficult as figuring out expiry
[09:23:36] <Armando Caro> yes it is
[09:23:38] <Will Ivancic> experience will probably result in a default but if you know something more about your network, you can set hop count appropriately.
[09:23:51] <Armando Caro> hard to set limits... but doesn't mean we should have a limit
[09:24:01] <sftcd> @will: s/hops/expiry/ and the argument is all the same
[09:24:12] <Will Ivancic> no
[09:24:24] <Armando Caro> i meant: doesn't mean we shouldn't have a limit
[09:24:26] <Will Ivancic> hop and expiration are not the same
[09:24:45] <Armando Caro> not the same.... just similar in difficulty of seting limit
[09:24:49] <sftcd> I said the form of the arguments is the same and the difficulty in picking values is the same
[09:25:01] <Joseph Ishac> Armando Caro: yeah I think that was sftcd point
[09:25:12] <Will Ivancic> expiration is  easy for many applications.
[09:25:13] <Armando Caro> expiration is a little easier maybe cause app can decide on relevance... but app may say it is relevant for 10 years! should that be allowed
[09:25:24] <Armando Caro> ?
[09:25:28] <Will Ivancic> I may have information that is only useful for a certain period of time.
[09:25:39] <Joseph Ishac> Should we maybe be paying attention to this presenter :)
[09:25:49] <Armando Caro> yes
[09:26:12] <Will Ivancic> If I send you a weather prediction for the next three days, getting it on day four is worthless.
[09:26:18] <Daniel Ellard> I would guess that the network radius of the world is probably some nameable number.  1,000?  10,000?  
[09:26:38] <sftcd> radius != path length if loops happen
[09:27:00] <Will Ivancic> now, if I am a node that sees that bundle 50 times and passes it off, I may conclude this is goning nowhere and just drop it or not accept it anymore.
[09:27:25] <sftcd> one can recognise the same bundle without a hop count
[09:27:32] <Daniel Ellard> Right. If path length > radius then there's a loop.  If you don't want to loop, drop it
[09:30:42] Andrew Sullivan leaves the room
[09:31:55] <Joseph Ishac> take a hum on wg?
[09:32:03] <Joseph Ishac> or rather bof?
[09:32:36] alexmcmahon leaves the room
[09:32:36] badamson leaves the room
[09:32:39] PasiS leaves the room
[09:32:39] astaikos leaves the room
[09:32:39] Jeff Ward leaves the room
[09:32:42] teemu leaves the room
[09:32:45] jsimbol leaves the room
[09:32:45] beroset leaves the room
[09:32:54] Joseph Ishac leaves the room
[09:33:02] Joseph Ishac joins the room
[09:33:11] <Joseph Ishac> Thanks to remote participants
[09:33:15] Armando Caro leaves the room
[09:33:18] <Joseph Ishac> it's over
[09:33:19] anssi leaves the room: Computer went to sleep
[09:33:30] Joseph Ishac leaves the room
[09:33:35] <ikogan> Alright, thanks Joseph and everyone else. I think it's finally time to sleep.
[09:33:45] <gclark-ohiou> oh, sleep is overrated :)
[09:33:52] gclark-ohiou leaves the room
[09:36:05] <Daniel Ellard> thanks!
[09:36:10] Daniel Ellard leaves the room
[09:41:23] ikogan leaves the room
[09:50:09] sftcd leaves the room
[09:53:00] Will Ivancic leaves the room: Computer went to sleep
[11:03:54] jlcjohn leaves the room
[11:30:58] Kevin Fall joins the room
[11:31:43] <Kevin Fall> hello there..
[11:31:50] <Kevin Fall> anybody there?
[11:36:51] sftcd joins the room
[11:42:15] <Kevin Fall> hello?
[11:42:26] <sftcd> Or perhaps goodbye?
[11:42:36] <Kevin Fall> where RU?
[11:42:45] <sftcd> @ TLS room 307
[11:42:50] <Kevin Fall> (been trying to call you).
[11:42:54] <Kevin Fall> TLS?
[11:42:57] <Kevin Fall> (conf ctr?)
[11:43:16] <sftcd> no sign of missed calls? ah well
[11:43:27] <Kevin Fall> is Alex there?  Want to get him the bottle!
[11:43:27] <sftcd> I'm meeting Pete at the front door at 2pm
[11:43:34] <Kevin Fall> Pete ?
[11:43:39] <sftcd> offspring
[11:43:44] <Kevin Fall> front door of hotel?
[11:43:49] <sftcd> conf centre
[11:43:51] <Kevin Fall> oh
[11:43:58] <Kevin Fall> Alex there somewhere?
[11:44:36] <sftcd> left him in a coffee shop, his phone # is ...
[11:44:38] <Kevin Fall> your cell ends in 0597, right?
[11:44:45] <Kevin Fall> yah, what's his cell..
[11:44:46] <Kevin Fall> thx
[11:45:03] <sftcd> +353-87-901-7524 = alex
[11:45:04] <Kevin Fall> when do u go2 airport?
[11:45:18] <sftcd> my flight's at 8pm
[11:45:48] <Kevin Fall> ru coming to hotel?
[11:46:16] <sftcd> gotta collect bags sometime, probably 'bout 5pmish
[11:46:36] <Kevin Fall> ok, so you're playing tourist... [?]
[11:47:01] <sftcd> yep gotta shop for smaller kids etc you're welcome to come along if you've time to kill
[11:47:29] <Kevin Fall> i gotta check outta here in ~10 min and I want to make sure this bottle gets to a safe place...
[11:47:37] <Kevin Fall> (also got a big mess to pack up :( )
[11:50:13] <Kevin Fall> you wanna walk by hotel on your way shopping?  I should be down there in 15 min or so hopefully.
[11:50:15] <Kevin Fall> gotta run now.
[11:50:47] <sftcd> ok later so
[11:50:50] sftcd leaves the room
[11:55:38] Kevin Fall leaves the room
[12:16:51] Kevin Fall joins the room
[12:35:39] Kevin Fall leaves the room
[13:30:34] Kevin Fall joins the room
[13:51:32] Daniel Ellard joins the room
[15:07:48] hkruse joins the room
[15:07:54] hkruse leaves the room
[15:22:42] josh leaves the room: Replaced by new connection
[16:06:14] Kevin Fall leaves the room
[16:06:17] Kevin Fall joins the room
[17:43:19] ikogan joins the room
[18:02:54] Kevin Fall leaves the room
[18:38:08] Kevin Fall joins the room
[19:09:14] Kevin Fall leaves the room
[19:48:07] Kevin Fall joins the room
[19:48:07] Daniel Ellard leaves the room
[20:33:23] Kevin Fall leaves the room
[20:36:18] Kevin Fall joins the room
[21:06:22] Kevin Fall leaves the room
[21:21:09] ikogan leaves the room
[22:31:22] ikogan joins the room