[07:32:29] Douglas Otis joins the room [07:43:20] Douglas Otis leaves the room [11:35:36] Doug_O joins the room [11:37:12] Chris Newman joins the room [11:40:23] Sound is good. [11:48:34] ESiegel joins the room [11:50:23] dcrocker joins the room [11:51:55] eliot.lear joins the room [11:51:57] thnetila joins the room [11:52:41] Greetings from West Dublin City! [11:52:44] frank joins the room [11:53:15] This is the DKIM meeting. [11:53:28] Jim Fenton joins the room [11:53:35] If you wish something spoken at the microphone, please preface it with "MIKE:" [11:54:12] You mean MIC: ? [11:54:57] sure [11:54:59] MIC [11:55:09] Good morning, Doug [11:57:32] jdfalk joins the room [11:57:47] good morning [11:58:11] sftcd joins the room [11:58:20] sftcd has set the subject to: Meeting starting in a sec [11:58:24] It has been a long night. Just move my data over to a new laptop after my other one died yesterday. Building code to lower down sensitive to adjust for increased bot net activity on larger networks, especially in Europe. We roll out the new service today. [11:59:25] meeting has been called to order [11:59:44] ogud: Olafur Gudmundsson joins the room [11:59:57] please remember the note well [12:00:03] kivinen joins the room [12:00:06] agenda bashing [12:00:08] ADSP [12:00:10] Overview [12:00:12] bash? [12:00:12] Alissa Cooper joins the room [12:00:35] PHB joins the room [12:00:46] pawal joins the room [12:01:02] chairs are looking for slides [12:01:25] document status [12:01:29] three rfcs [12:01:34] 4686 4871 5016 [12:01:37] kdz joins the room [12:01:39] three wg drafts [12:01:40] first up [12:01:42] dkim overview [12:01:44] lynch joins the room [12:02:42] Tony Hansen [12:03:06] EronenP joins the room [12:03:48] cyrus joins the room [12:04:03] semery joins the room [12:04:17] very many issues closed [12:04:35] polk.tim joins the room [12:06:17] 1563 number is correct. issue is verification failure not really a goal [12:06:40] sm joins the room [12:07:55] MIC: Is there something tracking: 4.5. Sub-Domain Assessment ... To permit assessments that are independent, one method is for an organization to use different sub-domains in the "d=" parameter, such as "transaction.example.com" versus "newsletter.example.com", or "productA.example.com" versus "productB.example.com". [These can be entirely separate from the rfc2822.From header field domain.] [12:08:09] This seem to be in conflict with ADSP. [12:08:48] sftcd has set the subject to: Meeting started [12:09:22] I posted a comment on the mailing list [12:09:23] tony: eliot: neither of us keep it in our head. [12:09:33] doug: did you mark it as "New Issue"? [12:09:37] Already did. [12:09:53] ok, you should have gotten an email with an issue # [12:10:05] sftcd leaves the room [12:10:06] Development and Deployment [12:10:09] thnetila leaves the room [12:10:12] Bill joins the room [12:10:16] we hope to have a new draft out soon [12:10:33] Stephen: expect WGLC to start soon [12:10:49] a single comment will not hold up the doc [12:10:52] Bill leaves the room [12:11:00] Jim Fenton, ADSP [12:11:14] http://www3.ietf.org/proceedings/08jul/slides/dkim-0.pdf [http://www3.ietf.org/proceedings/08jul/slides/dkim-0.pdf] [12:11:31] summary of changes can be found in -ssp-04 [12:11:52] key changes [12:11:56] ssp/asp -> adsp [12:12:04] parent domain check is gone [12:12:46] sftcd joins the room [12:12:47] testing flag is gone. no flags at all. registry removed [12:13:14] ABNF *WSP -> *FWS [12:13:17] abstract streamlined [12:13:22] wildcard discussion revised [12:13:50] whitespace [12:14:28] amorris joins the room [12:14:44] there was no need for leading space in DNS, only on email headers [12:14:47] it's early in the morning here, but I can't help thinking that perhaps we should remove all whitespace [12:15:03] so starting in SSP-01, changed to *WSP [12:15:06] JD: +1 [12:15:28] wlo joins the room [12:15:43] the earlier discussion about this topic noted that it might have been nice to do that at the time we did the signing spec, but now the goal should be to be compatible with the signing spec. [12:16:05] (itwasajoke) [12:16:11] in ssp-04, it's changed to *FWS, so it's also different from 4871 as well. [12:16:38] jd: one could argue a strict rule, which is what i thought you were arguing [12:16:52] (oh. you're not the only one a bit bleary eyed/mined. but for that matter, no one in the room seemed to see the humour...) [12:16:59] wlo leaves the room [12:17:02] oops, sorry, I wasn't intending to make any actual sense. *grin* [12:17:06] lynch leaves the room [12:17:07] Jim Galvin joins the room [12:17:15] you succeeded, but we didn't realize it. [12:17:34] presnick joins the room [12:17:34] presnick leaves the room [12:17:38] murray: make it *WSP and add an erata for 4871 [12:17:41] thnetila joins the room [12:17:43] frank? [12:18:00] Lisa joins the room [12:18:04] tlr joins the room [12:18:06] Phill: *WSP [12:18:13] Two parsers however. [12:19:02] Let's have a discussion on 4871 errata at the end of the meeting [12:19:46] spamfighter joins the room [12:20:20] spamfighter leaves the room [12:20:27] consensus to be confirmed: used *wSP [12:20:30] WSP [12:20:47] 1571: give some real examples [12:20:48] sftcd leaves the room [12:20:48] amorris leaves the room [12:20:49] to be added [12:20:49] thnetila leaves the room [12:20:57] spamfighter joins the room [12:20:58] thnetila joins the room [12:21:17] 1575: streamline abstract [12:21:43] sftcd joins the room [12:21:47] ellen siegel: [12:21:56] is this the issue that posted one for examples? [12:21:56] tonyhansen joins the room [12:22:34] please give viable examples of unknown [12:22:51] 1576 revise wildcard disucssion [12:23:06] this all has to do with wildcards in TXT records [12:23:11] bert joins the room [12:23:28] we are not in ADSP depending on the use of wildcard records in order to have ADSP operate [12:23:36] bert leaves the room [12:23:52] are there instances where we want to permit ADSP wildcard records, or do we want to tell people to just not do that? [12:23:54] MIC: Do we still need the "_domainkey" prefix. This record is to be place before all A records. [12:24:21] people are going to have wildcards whether we want 'em to or not, so we should tell 'em what the consequences will be [12:24:29] doug; did jim just cover you? [12:24:38] No. [12:25:27] distinction between 'allowing' vs. 'discussing'. Two different decisions for the wg [12:25:43] phill: [12:26:05] we can't tell people not to use wildcard TXT records, but we can say that it doesn't make sense for ADSP [12:26:08] Make wildcards work as good as possible, demand that ADSP records start with dkim= (or similar) [12:26:22] +frank [12:26:33] barry: the issue is the people not using ADSP [12:26:40] +1 to phill (as quoted by eliot) [12:26:47] sftcd leaves the room [12:27:07] thnetila leaves the room [12:27:14] jim: it's worth not using ADSP wildcards... [12:27:25] phill: server implementations for wildcards are not consistent [12:27:44] phill: why do we need two tags rather than one [12:27:59] sftcd joins the room [12:28:35] But that does not protect the rest of the domain. [12:28:38] in a large organization where email admin is separate from hostname admin, you want to provide a method to do a single delgation [12:28:55] not our job to tell people about general isuses of txt records [12:29:00] (dave crocker speaking) [12:29:12] Andrew Sullivan joins the room [12:30:07] a use of an ADSP format TXT should be invalid because they could appear in inappropriate places [12:30:37] MIC: As ADSP records are structured currently, for protection they must be place at any existing domain. Delegation can not be done for just DKIM signing and also protect the domain. [12:30:44] use case: i want to express ADSP for an entire domain, where the hostnames are not accessible via DNS [12:30:51] trjh joins the room [12:30:55] pete resnick: [12:31:10] eliot - I'll channel doug [12:32:17] there is a wildcard at TXT *.example.com and it will be returned to you when you do the ADSP lookup. you can look in there to determine it. But how do you know that the query was in response to a wildcard [12:32:25] dave crocker: [12:32:39] what does that imply in terms of a decision here [12:32:42] Pete: [12:33:36] ADSP implementations must handle the case, so why not have the tag [12:34:06] pete: and there's no way to enforce this from the query side [12:34:22] dave crocker: [12:34:43] Do not use TXT records ask for a new RR type :-) that uses the same syntax as TXT, Using TXT will cause infiite problems with sub-typing [12:34:44] if you put an ADSP wildcard in the right places, nobody will notice a problem. Dave's point is that it will also show up in the wrong place [12:34:54] RR types are registered already ... will be the response. [12:35:07] prefix with MIC if you want it spoken [12:35:12] barry: [12:35:19] (personal opinion) [12:35:31] MUST NOT put ADSP records where they don't belong [12:36:10] Phill: wildcards in DNS don't work the way we might want them to. This intersects DNSSEC. if you're not doing DNSSEC, wildcards are a server only thing. You can't tell the difference. [12:36:24] MIC: still seems like the only way to even begin to resolve this is to explain what the ramifications of wildcards will be for ADSP. a best practice can emerge later. [12:36:54] if you have _domainkey.example.com, then no wildcard at example.com [http://example.com] will propagate down. [12:37:03] @Olafur: No infinite problems for ADSP, it's strictly limited to known wildcard issues with UDP. Otherwise it uses _adsp labels [12:37:12] anything else is just battling edge cases & differing views of what is "right" for DNS [12:38:29] Barry: the issue is someone who doesn't implement any of this and gets a stray wildcard. [12:38:31] pete resnick: [12:38:35] j joins the room [12:38:37] i like what jd just said [12:38:48] We need a table with all the cases enumerated [12:39:05] I think that there are at least 3 x 3 cases to deal with [12:39:10] [caveat emptor] [12:39:19] dave crocker: [12:39:24] Set out the intended result for each and see what achieves that result [12:39:51] great idea [12:40:01] the spec should say what barry said: MUST NOT [12:40:10] and provide explanation as to why [12:40:34] actively creates misbehavior [12:40:49] explanation => reference "IAB choices", that's what it's for [12:41:20] eliot: echoing olafur - should we be reconsidering a new RR type? [12:41:58] phill: you can solve any of these cases by making a change in the text, but you have to be able to solve all of them. perhaps a table is useful here. [12:42:10] stephen: phill, are you volunteering? [12:42:15] phill: "I guess so" [12:42:22] jim fenton: [12:42:29] there are at least two classes of separate issues [12:42:40] 1. publication of WILDCARD _adsp record [12:42:51] PHB: thanks [12:42:53] 2. retrieval of a non-ADSP record as a result of a wildcard that is somewhere else [12:43:27] 2nd case is easier to deal with. at a minimum, remind people that you could get something other than an ADSP record, and you'd better be prepared. [12:43:31] MIC: Must start with dkim= would reduce the negative side-effects from TXT record. Since these records must be placed at every existing node, this also makes the "_domainkey" prefix wasted overhead. Due to this overhead, expect the use of wildcards as a result. [12:43:39] barry: and tell them how to be prepared [12:43:40] resnick joins the room [12:44:13] side issue: do we want to require that adsp have dkim= to identify ADSP records? [12:44:26] resnick leaves the room [12:45:06] tony hansen: DKIM DNS records have this same problem, and we do have a distinguishing mark on those. [12:45:27] ADSP should be no different [12:46:11] jim: sure. perhaps we need v=adsp1 [12:46:14] resnick joins the room [12:46:18] MIC: A version tag will never be used. [12:47:44] Hmmm. [12:48:02] Huh? [12:48:11] taking hmm [12:48:11] Eliot favors new RR type. [12:48:21] consensus is to use an adsp tag [12:48:37] I've no audio, was there a hum (about what) ? [12:48:40] no objection over here [12:48:48] the humm was about adding the adsp tag [12:48:55] to identify adsp records [12:49:00] hmmm :-) [12:49:00] and it passed according to the chair [12:49:24] proposal now is to add prescriptive text to limit ADSP records to the proper context [12:49:28] no objections [12:49:51] That suggestion does not make much sense. [12:49:53] please still do the matrix [12:50:08] A wildard will put it in the right and wrong place. [12:50:18] doug: adsp records are only to be found with _adsp._domainkey.... [12:50:25] 1579 [12:50:30] +1 to the matrix [12:50:37] And that would be the case. [12:50:40] Result Set/Status Codes [12:51:02] defining behavior of what happens with Dsicardable [12:51:18] Discardable v. Resent Headers [12:51:43] Does Discardable representa frontal assault on 2822upd Resent fields? [12:51:51] Doug_O: wildcards in the wrong place have no effect => cause no harm [12:51:58] barry: Discardable is least bad [12:52:07] pete resnick: [12:52:25] discardable is an assault on unauthorized resending, headers or no [12:52:39] MIC: discardable is about the worst term a committee could find [12:52:46] if you say that something is discardable and I resend it, and that somewhere else does the ADSP lookup, do we think that this is a problem? [12:53:10] Discardable is the wrong choice sense it implies an action that changes 2821 expectations. [12:53:17] MIC: re pete resnick; IIRC that's how it was designed [12:53:47] barry: problem occurs when from changes or signature breaks [12:54:06] so now it's discardable. i don't see a problem [12:54:52] now discussing the term [12:55:04] barry: but we've been too many times on this issue? [12:55:14] barry: is the 2nd bullet not an issue? [12:55:23] Frank, was there some other issue that I'm missing? [12:55:25] if there is an issue, someone needs to post [12:55:38] Barry: yes, too many times, but discardable was the worst so far [12:56:01] Pete: no, just resent-* is the issue [12:56:12] eliot: defer to extension? [12:56:14] eliot: a status code could be done later [12:56:24] MIC: ADSP is intended to protect From headers, however ADSP records may be missed due to DNS errors of an unknown nature. Accepting a message as signed having a key with a local-part restriction where the local-part is not found the From header invites abuse. Such use of the key is not controlled by the signing domain, and these keys are also more prone to theft. Not accepting these messages as signed is essential for security, irrespective of ADSP record existence, and should be mentioned in the ADSP. [12:56:42] yaron.sheffer joins the room [12:57:00] fujiwara joins the room [12:57:02] Sorry Frank, I wasn't clear: Is the Resent-* issue different than the "mail forwarded from a forwarding service" issue? Is there something else special about Resent-*? [12:57:17] kregan joins the room [12:57:45] ellen: an issue was lost [12:57:57] stephen: {we owe you a decision} [12:58:11] yaron.sheffer leaves the room [12:58:12] If the resender somehow breaks the signature his mail is "discradable", that's a bad name, IMHO [12:58:42] barry: you may fail to retrieve an ADSP record. [12:59:06] This leave open a security issue. [12:59:10] phill: [12:59:12] Frank: OK, just making sure that that's all there was. [12:59:14] Doug - comment during WGLC [12:59:17] X.509v3 Cert Pointer extension [12:59:30] resnick: Thanks [12:59:48] tonyhansen leaves the room [13:00:01] dkim provides lightweight pki [13:00:08] ietf has spent a lot of time developing pkix [13:00:13] and we have all of these CAs [13:00:29] and so we should have a bridge between x.509 cert and DKIM [13:00:52] tonyhansen joins the room [13:01:01] domain validated cert provides a bit of protection against dns/bgp attack [13:01:05] might be an EV cert [13:01:11] proof that party is accountable [13:01:27] additional attributes regardin logogtype [13:01:46] jim fenton: is there a draft? [13:02:02] http://www3.ietf.org/proceedings/08jul/slides/dkim-2.ppt [http://www3.ietf.org/proceedings/08jul/slides/dkim-2.ppt] [13:02:26] stephen: not much text in the current draft? [13:02:35] does it requirea new profile? [13:02:42] phill: prefer not to do it here [13:02:49] do it in a certificate forum [13:03:19] let's not have dkim become an x.509 forum [13:03:39] +1 to not becoming an x.509 forum [13:03:58] eliot: question about MUST bind to same key [13:04:13] Allegedly there are 700,000 v=spf1 -all policies, is yet another nullmx really what you want ? [13:04:34] PHB: yes, dkim key record and cert public key MUST be the same is the proposal [13:05:03] leif johannson: [13:05:23] those attributes include name to key binding and strict binding? [13:05:33] phill: [13:05:41] you have additional information that says that this key binds to this name [13:06:00] leif: we did a similar draft for a similar binding for DNSSEC [13:06:06] it wasn't favorably received [13:06:21] dlpartain joins the room [13:06:25] yaron.sheffer joins the room [13:06:29] phill: DNSSEC community seems to be focused on DNSSEC deployment [13:06:36] NOMAIL policy extension [13:06:44] dlpartain leaves the room [13:06:49] "i don't do email so checking dkim policy is not relevant: [13:06:58] simple statement for parked domains [13:07:48] Opt-out puts the burden on the wrong party. It should be an Opt-in. [13:07:49] Four simple solutions for nullmx is one too many, IMO [13:07:55] NULL Key [13:08:05] For large enterprises with many addresses [13:08:12] adding dkim signature may not be possible [13:08:14] dcrocker leaves the room [13:08:15] kdz leaves the room [13:08:18] addinga static header line is usually possible [13:08:42] no authentication value, but this key could only be used for this sender [13:08:55] allows to create holes in policy without negating policy as a hole [13:09:08] jim fenton: [13:09:11] MIC: Why not require the publication of MX records as an Opt-in scheme. This would protect the IPv6 power meters, for example. [13:09:25] what is the advantage of this over a subdomain of an unknown signing practice? [13:09:56] jim: this is a hole you could drive a truck through [13:11:07] discussion? [13:11:35] chair: none of this is chartered. [13:12:25] murray is now up [13:12:30] Drop NOMAIL, support Doug on the SMTP list (later) [13:12:54] lynch joins the room [13:13:21] murray: [13:13:35] other dkim-related drafts [13:13:50] draft-kucherawy-sender-auth-header [13:13:52] -15 [13:13:57] wouter joins the room [13:14:06] new draft has only minor edits [13:14:09] pk joins the room [13:14:15] along with secdir stuff [13:14:36] If Murray ever tackles EAI he will have *lots* of fun ;-) [13:14:54] if a verification fails, send a report to location X [13:15:14] "i'd like to know if my domain is being phished" [13:15:49] draft-shafranovich-feedback-report [13:15:51] AKA ARF [13:16:01] provide a dsn-like format [13:16:04] j leaves the room [13:16:11] add some fields for dkim forensics [13:16:38] easy to rework a dsn parser [13:17:11] that's it for murray [13:17:19] jim fenton: [13:18:02] there has been a lot of press about paypal having made agreements with gmail and yahoo to block messages from senders that purport to be from paypal that aren't [13:18:15] that arrangement does include getting feedback from yahoo and gmail [13:20:17] discussion now about whether docs should be wg docs [13:20:57] pasi; some set of relevant people sort of agree with it [13:21:00] Support AUTH-HEADER [13:21:15] but before rechartering anything i want the current documents completed [13:21:40] phillip's doc seems to contain things that should be separate documents, and not all of them receive equal agreement [13:21:43] tony hansen: [13:22:38] i've been helping to shepherd a document through that was not under a wg, and wound up being contentious - 2821upd - and the comment was made to me yesterday by an AD that it might have been better if there were a working group. it might have helped smooth the way within certain peoples minds [13:22:49] phb: [13:22:52] wouter leaves the room [13:23:38] consider using INCH [13:23:40] yaron.sheffer leaves the room [13:23:45] this should have been part of core [13:23:51] will it be reviewed by the right people? [13:24:31] Tony: +1, WG is simpler for stuff like 2821bis (2822upd went fine) [13:24:47] barry: [13:25:18] i agree that stuff gets reviewed by people in either case. working group brings organization and tracking and visibility [13:25:20] dave crocker: [13:25:24] MIC: it's being reviewed by implementors & users at MAAWG, but most of the folks at MAAWG aren't experienced in IETF process (most of the exceptions to that are in Dublin.) MAAWG doesn't do the same kind of tracking and visibility as the IETF. [13:25:34] going to the political: [13:25:43] lot's of maybes [13:26:06] let's not predict the future [13:26:13] yaron.sheffer joins the room [13:26:20] we know that the formalities make wg mechanics high overhead [13:26:37] rechartering is high overhead [13:27:11] if we're doing this for pr, my feeling is that the work is too far along [13:28:49] murray: i need a larger implementation base before agreeing that reporting is fully baked [13:29:27] dave: [13:29:40] auth results is really done [13:29:40] john.levine joins the room [13:30:57] barry: [13:31:20] do we have energy still as we finish up ADSP and overview and deployment to continue DKIM work or are we burning out? [13:31:43] dave crocker: do we have the work? [13:32:06] jim fenton: [13:32:09] spamfighter leaves the room [13:32:16] Andrew Sullivan leaves the room [13:32:17] some of this work is not strictly dkim-related [13:32:55] i think it might be appropriate to recharter, but if it's possible to do it, broaden the scope in order to permit these other proposals to be relevant [13:33:04] tony hansen: [13:33:15] i could see us moving toward reputation [13:33:29] it's a gaping hole in the scheme of things [13:33:31] vouch by reference [13:33:31] We need to help people implement the stuff we've got before inventing something else. [13:33:45] DNSBLs DNSWLs related [13:33:46] Jim: Auth-header is *waiting* for ADSP (otherwise it's near to ready) [13:33:50] If you want to take VBR as a WG draft, it's fine with me [13:34:02] john - if you want stuff said here preface it with MIC [13:34:22] no audio here, will wait for now [13:34:34] MIC: reputation seems too broad of a topic; the examples tony listed seem like they might be something more specific [13:34:42] murray: reputation work strikes me as too broad [13:35:26] drc: agrees with jd [13:35:30] Barry Leiba joins the room [13:35:33] (and murray) [13:35:50] we solve small stuff, not big hard topics [13:36:39] With respect to reputation: Unfortunately, the current Author Signature definition in ADSP prevents a practical use of the "on-behalf-of" i= identity as a method to convey _what_ had been authenticated. For large domains, the "on-behalf-of" identity will be blank when the provider is unwilling to affirm the From email-address. Allowing a practical means for these providers to assert what account or system was authenticated, even in an opaque manner, is vital for combating bot-net related abuse and would be more complaint with the current email infrastructure. Content filtering and malware filtering will soon be unable to keep pace with an exponentially increase in mutation rate, due to the "power of the bot". [13:36:48] AOB? [13:37:00] EronenP leaves the room [13:37:24] adjourned. [13:37:29] not adjourned [13:37:41] we have to figure out what to do with erata [13:37:54] pasi: iesg has been discussiing it. [13:38:02] eliot.lear: Thanks for scribing [13:38:06] there's been something posted [13:38:08] (welcomes0 [13:38:27] rfc-editor hasn't updated tools [13:38:36] waiting for tools to be updated before processing erata [13:39:28] tony: majority of erata came out of interop event last fall. [13:39:40] and things that were brought up at the november meeting [13:39:44] stephen: none were controversial [13:39:58] tlr leaves the room [13:40:02] tlr joins the room [13:40:17] erata can be done either by wg or by editors [13:40:34] When can 4871 go for DS ? [13:41:07] if you're going to move dkim to draft, it's a good time to update the rfcs. [13:41:21] dave points out that it doesn't require a wg to do the updates [13:41:28] the wg can exist but not meet [13:41:32] tony: [13:41:46] but doing a new draft of 4871 is a viable piece of work for recharter [13:41:46] kregan leaves the room [13:41:58] jim fenton: [13:42:19] have we gone past the timer? we have [13:42:23] AOB? [13:42:27] adjourned (for real). [13:42:29] ESiegel leaves the room [13:42:34] sm leaves the room [13:42:35] kivinen leaves the room [13:42:38] frank leaves the room [13:42:42] PHB leaves the room [13:42:51] Doug_O leaves the room [13:43:03] eliot.lear leaves the room [13:43:03] Lisa leaves the room [13:43:04] thanks again, eliot [13:43:12] Alissa Cooper leaves the room [13:43:20] jdfalk leaves the room [13:43:29] tonyhansen leaves the room [13:43:38] resnick leaves the room [13:43:49] john.levine leaves the room [13:43:50] cyrus leaves the room [13:45:20] Jim Fenton leaves the room [13:46:18] Alissa Cooper joins the room [13:46:29] Alissa Cooper leaves the room [13:46:58] sftcd has set the subject to: Meeting ended [13:48:55] semery leaves the room [13:51:55] tlr leaves the room [13:57:13] ESiegel joins the room [13:57:25] ESiegel leaves the room [13:57:47] Jim Galvin leaves the room [13:59:43] Chris Newman leaves the room [14:00:55] Barry Leiba leaves the room [14:02:11] yaron.sheffer leaves the room [14:08:31] polk.tim leaves the room [14:10:09] pk leaves the room [14:18:30] sftcd leaves the room [14:18:41] Lisa joins the room [14:18:43] Lisa leaves the room [14:19:56] ogud: Olafur Gudmundsson leaves the room: Replaced by new connection [14:20:18] tlr joins the room [14:25:29] PHB joins the room [14:28:02] lynch leaves the room [14:34:22] tlr leaves the room [14:48:45] pk joins the room [14:48:57] pk leaves the room [15:27:16] pawal leaves the room [16:22:58] PHB leaves the room [16:59:23] abelyang joins the room [18:16:47] abelyang leaves the room [19:28:22] fujiwara leaves the room [19:28:22] trjh leaves the room [22:21:05] PHB joins the room [22:43:43] PHB leaves the room