[09:30:38] --- bhstark has joined
[09:30:44] --- bhstark has left
[09:59:39] --- hardie@jabber.psg.com has joined
[10:00:05] <hardie@jabber.psg.com> Session will be starting soon; intro slides are on.
[10:01:16] --- spencerdawkins has joined
[10:01:27] <hardie@jabber.psg.com> Marc and Hannes introduce themselves
[10:01:35] <hardie@jabber.psg.com> This is the only session
[10:02:09] <hardie@jabber.psg.com> Review of interim meeting; minutes are linked from www.ietf-ecrit.org
[10:02:49] --- bhstark has joined
[10:02:55] <hardie@jabber.psg.com> Interim meeting Summary requirements
[10:03:07] <hardie@jabber.psg.com> ready for last call, whichd 14th march
[10:03:14] --- jr111 has joined
[10:03:24] <hardie@jabber.psg.com> Comments recieved; more mods expected. Issue tracker will be updated
[10:04:02] <hardie@jabber.psg.com> Emergency Identifier: sos-02 stopped; sipping-servicice adopted
[10:04:27] --- martin.thomson has joined
[10:04:32] <hardie@jabber.psg.com> Mapping protocol: Lump & Econ-IRIS merged to LoST; DNS-SOS work stopped
[10:04:36] --- HannesTschofenig has joined
[10:04:41] <hardie@jabber.psg.com> Review of milestones
[10:04:51] <hardie@jabber.psg.com> All are red, in the past
[10:04:56] --- Shida_Schubert has joined
[10:05:06] --- anabolism@jabber.org has joined
[10:05:07] <hardie@jabber.psg.com> New milestones are presented
[10:05:25] <hardie@jabber.psg.com> (please see website)
[10:05:54] <hardie@jabber.psg.com> oops--not yet on charter page, but should be in list archives
[10:06:09] <hardie@jabber.psg.com> Dates are WGLC
[10:06:34] <hardie@jabber.psg.com> Agenda for today: oopen issues in requirements; open issues in security threates
[10:06:50] <hardie@jabber.psg.com> Henning will present on URN
[10:07:11] <hardie@jabber.psg.com> Lost presentation, Discussion on Future work
[10:07:24] <hardie@jabber.psg.com> Discussion of Emergency Authority to Citizen, architecture and phone bcp
[10:07:27] <hardie@jabber.psg.com> Any bashes?
[10:07:39] <hardie@jabber.psg.com> Hearing none....
[10:07:43] <hardie@jabber.psg.com> Over to Roger
[10:08:26] <hardie@jabber.psg.com> No open issues currently logged against requirements drafts in issue tracker
[10:08:43] <hardie@jabber.psg.com> Post them directly or send them to hannes/roger if you have new issues
[10:09:09] <hardie@jabber.psg.com> Since the interim significant amounts of rearranging/rewording
[10:09:32] <hardie@jabber.psg.com> comments recieved text messaging-->text communication
[10:09:42] <hardie@jabber.psg.com> "identifier" vs. dial string clarifications.
[10:10:00] <hardie@jabber.psg.com> Shida raised issues related to MUST usage
[10:10:33] <hardie@jabber.psg.com> new qualifying language added
[10:10:49] <hardie@jabber.psg.com> e.g. MUST support vs. MUST implment
[10:11:08] <hardie@jabber.psg.com> clarification of VSP as an instance of ASP
[10:12:09] <hardie@jabber.psg.com> Henning raises two issues: VSP could be used with a qualifier that it may mean more than voice; he believes ASP is too much a term of art external to that
[10:12:28] <hardie@jabber.psg.com> So qualifying VSP may be more appropriate
[10:13:58] <hardie@jabber.psg.com> 2nd point: 2119 MUSTs make the text a bit more awkward; he suggests that since these are requirements for protocols rather than for implementations, that a general introduction rather than doing it at every MUST would be easier
[10:14:33] <hardie@jabber.psg.com> Tom mentions that this is what he did with the Security requirements.
[10:15:07] <hardie@jabber.psg.com> James says "must implement vs. must deploy" are the critical distinctions. Implement into the protocol design?
[10:15:22] <hardie@jabber.psg.com> James says "has to be there" is the real underlying requirement
[10:15:56] <hardie@jabber.psg.com> Roger says that he will add a paragraph to create an overview, and that he will go on
[10:16:11] <hardie@jabber.psg.com> Tom says that there are three levels: design, implementation, use.
[10:16:48] --- anewton has joined
[10:17:23] <hardie@jabber.psg.com> Steve Kent says there are only two cases here: you are writing requirements for a protocol which will later design
[10:17:29] <hardie@jabber.psg.com> or you are writing a protocol
[10:17:44] <hardie@jabber.psg.com> The IETF uses an "implementation compliance" model for the latter.
[10:17:44] --- miki_h has joined
[10:18:22] <hardie@jabber.psg.com> This does not mean all are turned on; knobs simply must be present to be compliant
[10:18:45] <hardie@jabber.psg.com> Tom Taylor comes up for issues in the Security Considerations document.
[10:19:34] <hardie@jabber.psg.com> Status: accepted as WG work item, resubmitted as draft-ietf-ecrit-security-threats-00
[10:19:40] <hardie@jabber.psg.com> Should arrive today-ish
[10:20:03] <hardie@jabber.psg.com> small changes since draft-taylor: deleted asp/vsp term, small wording changes
[10:20:31] <hardie@jabber.psg.com> Summary of threats: threat of fraud, further threat of probte to identify other entities to attack
[10:21:11] <hardie@jabber.psg.com> First item moved to security considreations for emergency identifier draft
[10:22:02] <hardie@jabber.psg.com> James at mic: location conveyance document will mandate carrying location header when it carries location
[10:22:17] <hardie@jabber.psg.com> Tom asks will it always be present?
[10:22:41] <hardie@jabber.psg.com> James responds that no, not always (e.g. non emergency calls will not)
[10:22:54] <hardie@jabber.psg.com> But header will be present whenever location is.
[10:24:00] <hardie@jabber.psg.com> Jonathan notes that there is an issue about who is doing the expansion
[10:24:25] <hardie@jabber.psg.com> If that happens, the terminal may not provide location
[10:25:11] <hardie@jabber.psg.com> Jonathan says a better model may be the psap-uri is a route rather than a destination
[10:25:28] <hardie@jabber.psg.com> Henning notes that he has a whole section on this and deferring this to there may be more appropriate
[10:26:07] <hardie@jabber.psg.com> There are number of issues with identification, but they should be discussed in later drafts
[10:26:25] <hardie@jabber.psg.com> Thrates to mapping: DoS, impersonation, corruption, reflection, breach of confidentiality
[10:28:10] <hardie@jabber.psg.com> Note that some of these may be location of mapping server rather than within the mapping protocol itself. There still may be ways to use the mapping protocol to hellp
[10:28:29] <hardie@jabber.psg.com> Recommendations: some requirements proposed (see draft)
[10:28:58] <hardie@jabber.psg.com> Major issues; strength of requirements: are these MUST provide authentiaction, confidentiality or MUST allow
[10:30:02] <hardie@jabber.psg.com> Henning asks who is authenticating to whom
[10:30:21] <hardie@jabber.psg.com> Server to client authentication
[10:31:04] <hardie@jabber.psg.com> Andy believes that it must be possible, but not require from day one.
[10:33:32] <hardie@jabber.psg.com> Jonathan notes that in some proxy cases (proxy talking to existing mapping server) some authentication in a mutual tls type will be likely
[10:34:13] <hardie@jabber.psg.com> Steve Kent notes that these are actually system requirements: must be used in an environment where some service is available
[10:34:36] <hardie@jabber.psg.com> (e.g. to achieve confidentiality, ipsec or tls might be possible in specific deployments)
[10:35:15] <hardie@jabber.psg.com> if the protocol will provide it, in contrast, then a description of how that works is required
[10:36:21] <hardie@jabber.psg.com> Continues discussion of what the system must provide.
[10:37:05] <hardie@jabber.psg.com> Andy says that he would be happy to re-use something that already had it and say that up front
[10:38:17] <hardie@jabber.psg.com> Jonathan says that there are several roles here; he's not interested in the phone to mapping server, but if there is a vsp, that its proxy has a mutual tls connection to the mapping server
[10:38:37] <hardie@jabber.psg.com> Tom asks if this isnt' a billing driven requirement
[10:39:29] --- anewton has left
[10:39:31] <hardie@jabber.psg.com> Andy says that Jonathan raised as a protocol requirement--does the protocol need up to handle a nailed up connection (e.g. proxy to mapping server)
[10:40:10] <hardie@jabber.psg.com> Future of document: this information should be taken up into Security Considerations of specific documents
[10:40:27] <hardie@jabber.psg.com> Other future: working group item as a specific document
[10:41:40] <hardie@jabber.psg.com> Hannes review why this is commonly a working group strategy
[10:41:54] <hardie@jabber.psg.com> Jon says that Hannes spoken for him well
[10:42:31] <hardie@jabber.psg.com> Henning is concerned about dependencies--that it will end up holding specific drafts which might otherwise be ready
[10:42:52] <hardie@jabber.psg.com> So we should finish it quickly, so it is referencable, or we agree that some documents cut and paste from it into there.
[10:43:15] <hardie@jabber.psg.com> Tom takes it as settled that it is published as standalone
[10:44:21] <hardie@jabber.psg.com> Hannes says that we saw plenty of feedback for previous version, encourage everyone to read new version, and we will start WGLC inone or two weeks
[10:44:27] <hardie@jabber.psg.com> After IETF
[10:44:53] <hardie@jabber.psg.com> Rohan would like to make sure that mapping protocol document references this document
[10:45:46] <hardie@jabber.psg.com> Jonathan says that this would work by the security considerations would describe how it meets the issues raised by this documents
[10:46:32] <hardie@jabber.psg.com> Rohan agrees with this assessment, but not the conclusion--this contains guidance to LoST
[10:47:21] <hardie@jabber.psg.com> Yes, says Jonathan says that the LoST authors must read this and do the work, but that the readers of LoST should not need access to it to make sense of it
[10:47:26] <hardie@jabber.psg.com> Tom summarizes
[10:48:03] <hardie@jabber.psg.com> He will make sure that system requirements are described as such, and that authentication issues is handled.
[10:48:15] <hardie@jabber.psg.com> Roger and Tom will work on the authentication issue
[10:48:27] <hardie@jabber.psg.com> NOTE! Will be heading for WGLC shortly
[10:48:46] <hardie@jabber.psg.com> Can someone scribe for a moment?
[10:49:04] <hardie@jabber.psg.com> Starting Henning's presentation
[10:49:05] --- anewton has joined
[10:49:51] <anewton> Henning giving URN presentation
[10:50:47] <anewton> will attempt to incorporate Jonathans comments inline.
[10:51:54] <anewton> ua recoginition and resolution
[10:52:07] <anewton> ua recognition and proxy resolution
[10:52:32] <anewton> ua recognition and proxy location determination
[10:52:42] <anewton> proxy recognition and proxy resolution
[10:53:24] <anewton> jr: problematic because proxy can determine location
[10:53:48] <anewton> henning: a phone that recognizes 911 and has location will insert it
[10:54:37] <anewton> jr: did you consider ua knows about 911 but not location
[10:54:50] <anewton> henning: end system knows location but knows emergency
[10:55:04] <anewton> henning: but it won't insert location information in every call except emergency calls
[10:55:24] --- dcrocker has joined
[10:55:46] <hardie@jabber.psg.com> Discussion of the 302 security implementations
[10:55:59] <anewton> henning: security issue with end system demanding location fraudulaently
[10:56:08] <hardie@jabber.psg.com> "my phone is too dumb" needs to evaporate over time
[10:56:41] <hardie@jabber.psg.com> Keith Drage asks if this slide is the last example
[10:57:14] <hardie@jabber.psg.com> There is a case in 3gpp where the phone does not recognize that it is an emergency call, because it does not know the local dial string
[10:57:30] <hardie@jabber.psg.com> The proxy does recognize it and wants to insert the urn
[10:58:01] <hardie@jabber.psg.com> and the location information
[10:58:11] <hardie@jabber.psg.com> Henning agrees and says that this a generalization of the basic model
[10:58:34] <hardie@jabber.psg.com> Where someone along the path recognizes that it is an emergency call and inserts the appropriate info
[10:58:43] --- anewton has left
[10:59:18] <hardie@jabber.psg.com> Keith says that some operators want to recognize that it is an emergency call, then shift it to an existing to uri (e.g. tel 112)
[10:59:50] <hardie@jabber.psg.com> Hannes asks that these operators should raises these requirements tot he list
[11:00:25] --- anewton has joined
[11:00:30] <hardie@jabber.psg.com> Henning says that the ideal is that the closer to the phone that the recognition occurs, the better--ideal at the phone
[11:01:05] --- sunakichiwide has joined
[11:01:42] <hardie@jabber.psg.com> Keith says that in the roaming case, you don't necessarily have a complete set of digit strings that the user might dial believing that they are asking for emergency services
[11:02:03] <hardie@jabber.psg.com> Dynamic update of those is the current direction, but doesn't work 100%
[11:02:50] <hardie@jabber.psg.com> James W. says that there this model looks like other situations where the proxy must recognize that this is an emergency call
[11:03:10] <hardie@jabber.psg.com> Henning says that this should be a fail-safe, not recommended operating practice.
[11:03:28] <hardie@jabber.psg.com> The ends system providers will do this believing that someone else will handle it.
[11:04:24] <hardie@jabber.psg.com> Steve Norris starts a discussion of details of location conveyance and is asked to wait til the later discussion
[11:05:04] <hardie@jabber.psg.com> Paul notes that there is another problem if the end system doesn't know that this is an emergency call: the route headers may be inappropriate in an emergency call.
[11:05:37] <hardie@jabber.psg.com> Henning says that this is a "don't do this and drive" brittle case
[11:05:49] <hardie@jabber.psg.com> Jonathan asks to rant
[11:06:53] <hardie@jabber.psg.com> He wants dial string recognition to be trivial--so that it works in wifi cases trivially
[11:07:16] <hardie@jabber.psg.com> Jonathan thinks the 3gpp architecture is fatally flawed, and he means will kill people, and the IETF should say that.
[11:07:29] <hardie@jabber.psg.com> Put rant off to the phone bcp discussion
[11:08:15] <hardie@jabber.psg.com> Chair of 3ggp ct: it actually works the way you hope
[11:08:28] <hardie@jabber.psg.com> Two things to separate: user identification of emergency calls
[11:09:18] <hardie@jabber.psg.com> Critical for 3gpp: single identification for the protocol, so that the device implementors don't do this for themselves.
[11:10:03] <hardie@jabber.psg.com> Keith has 3 words: proxy case is not what he asked for. We are discussing corner cases
[11:10:32] <hardie@jabber.psg.com> Problems with approach
[11:11:53] <hardie@jabber.psg.com> Alternatives to call identification
[11:12:58] <hardie@jabber.psg.com> only trust accept-contact from same trust domain, creating a new header likely to have similar issues, re-do mapping and ensure that URL mataches check external source that URL is indeed a psap, (joking) new tld for psaps only
[11:14:08] --- anabolism@jabber.org has left: Logged out
[11:14:59] --- Dan Mongrain has joined
[11:15:27] <hardie@jabber.psg.com> Jonathan adds another option: a call is an emergency services call when the request uri is the urn
[11:15:52] <hardie@jabber.psg.com> Henning asks what does the first hop proxy do when the call is so marked but the route header takes it somewhere else?
[11:16:34] <hardie@jabber.psg.com> Jonathan agrees that this is a problem
[11:17:28] <hardie@jabber.psg.com> Jonathan discusses a variation of "re-do the mapping"
[11:18:02] <hardie@jabber.psg.com> Pen asks what happens when identification fails?
[11:18:34] <hardie@jabber.psg.com> Henning says you route it to that URL, but treat it as a normal call (e.g. no priority and no billing relief)
[11:19:05] <hardie@jabber.psg.com> Pen says that he would prefer anything that purports to be an emergency call is treated as such
[11:19:17] <hardie@jabber.psg.com> Paul: accept-contact has become the new "info"
[11:20:50] <hardie@jabber.psg.com> Henning reinforces that you do not want to have two different ways of doing the same things.
[11:21:22] <hardie@jabber.psg.com> Andy newton: you need to have a sixth bullet--reserved IP space for PSAPS
[11:21:28] <hardie@jabber.psg.com> (joke) much laughter
[11:22:13] <hardie@jabber.psg.com> Confirm that this is not a problem for situations where you have a relationship between UA and proxy
[11:22:30] <hardie@jabber.psg.com> Only the simless case applies
[11:23:49] <hardie@jabber.psg.com> Hans describes the exisitng pstn network and cellular entwork
[11:24:26] <hardie@jabber.psg.com> dramatic solution: message call set up in place to invite. invented a whole new message/method
[11:24:58] <hardie@jabber.psg.com> Not suggesting "Emergency-Invite" here.
[11:25:40] <hardie@jabber.psg.com> But the same thing happens here
[11:25:54] <hardie@jabber.psg.com> Jonathan discusses how to handle the route-set, and suggests a flag
[11:27:12] <hardie@jabber.psg.com> Jonathan goes back to re-do the mapping.
[11:27:51] <hardie@jabber.psg.com> "only re-do it in the malicious case"
[11:28:08] <hardie@jabber.psg.com> Brian says " if you don't care about this punt, but if you do care, re-do the mapping"
[11:28:18] <hardie@jabber.psg.com> Henning says that is the only thing that will work
[11:29:25] <hardie@jabber.psg.com> Keith says that when this is tagged as an emergency call, and that tagging will overwhelm any "normal" routing to special mapping
[11:30:51] <hardie@jabber.psg.com> Henning asks for consensus on "redo the mapping" as the basis for Security Considerations write-up on this?
[11:31:35] <hardie@jabber.psg.com> Jonathan suggests a fix: split the draft so that there are two problems. Move out the contention issue to a sip use of URN document
[11:31:59] <hardie@jabber.psg.com> Henning if there is a better idea later, we can update the RFC.
[11:32:22] <hardie@jabber.psg.com> Rohan supports split the document
[11:32:49] <hardie@jabber.psg.com> Jonathan asks for clarification on what "redo" means
[11:35:06] <hardie@jabber.psg.com> Hannes asks Henning to put together text summarizes the approach, and sends it to the list.
[11:35:15] <hardie@jabber.psg.com> Henning will try to draft later this week.
[11:37:37] <hardie@jabber.psg.com> Next issues: resolution mechanism for URN
[11:38:47] --- anewton has left
[11:39:10] <hardie@jabber.psg.com> NAPTR/DDDS described
[11:39:42] <hardie@jabber.psg.com> Martin has another suggestion: RFC 3958 (s/naptr) which is a different flavor of DDDS
[11:40:12] <hardie@jabber.psg.com> It would require a small update to 3958, but that is agreeable to the authors.
[11:41:35] <hardie@jabber.psg.com> Andy says 3958 agree to update 3958 to include the u flag.
[11:46:11] <hardie@jabber.psg.com> Henning review open issues:
[11:46:18] <hardie@jabber.psg.com> marking, ddds (or s/naptr)
[11:46:49] <hardie@jabber.psg.com> Andy present LoST
[11:46:55] <hardie@jabber.psg.com> History slide
[11:48:55] <hardie@jabber.psg.com> Features & things not to do reviewed
[11:49:04] <hardie@jabber.psg.com> Example presented
[11:49:47] <hardie@jabber.psg.com> Discusses when it might be run (short answer--whenever")
[11:51:04] <hardie@jabber.psg.com> Discuss who might--derived from henning's architecture document
[11:51:46] <hardie@jabber.psg.com> TBD: complete schemea, error conditions, transport mechanism resolution, dialstring discovery?, security considerations, iana considerations, internationalization, describe load balancing.
[11:51:58] <hardie@jabber.psg.com> Jonathan said it looks pretty good, largely on target
[11:52:24] <hardie@jabber.psg.com> He wants to makes sure that TLS mutual auth mode must be possible
[11:52:33] <hardie@jabber.psg.com> Dial string question discussed now?
[11:52:59] <hardie@jabber.psg.com> Brian asks when much more meat version is coming?
[11:53:24] <hardie@jabber.psg.com> Henning says schema is essentially done, there is a working schema, that needs to get copied in.
[11:53:41] <hardie@jabber.psg.com> Error conditions do need work, especially for validation.
[11:55:28] <hardie@jabber.psg.com> There was some discussion on list, and consensus, probably needs to be reflected in the draft
[11:55:47] <hardie@jabber.psg.com> Is LoST now a working group item?
[11:56:00] <hardie@jabber.psg.com> Marc asks for hum
[11:56:08] <hardie@jabber.psg.com> none opposed
[11:56:29] <hardie@jabber.psg.com> Jonathan loves the name, asks not to change
[11:57:22] <hardie@jabber.psg.com> Now one to the mapping architecture draft
[11:59:51] <hardie@jabber.psg.com> Henning reviews the forest and trees
[12:01:53] <hardie@jabber.psg.com> Notes that the description of protocol to share data among trees not done; replication among tree guides and copies of authoritative servers are protocol pieces that aren't done
[12:02:40] <hardie@jabber.psg.com> Notes the mSLP might be reasonably similar
[12:03:12] <hardie@jabber.psg.com> Jonathan believes that this does need to be solved, but that this can be targetted fairly late
[12:03:15] --- Dan Mongrain has left
[12:03:24] --- Dan Mongrain has joined
[12:03:39] <hardie@jabber.psg.com> Andy Newton thinks this should be a working group document
[12:04:01] <hardie@jabber.psg.com> Brian says "this should explain how it works, and the BCP mechanizes it"
[12:04:25] <hardie@jabber.psg.com> Shall we ask to add this to charter?
[12:04:40] <hardie@jabber.psg.com> no objections to suggested charter change.
[12:04:58] <hardie@jabber.psg.com> Brian comes up for draft-rosen-ecrit-phonebcp
[12:07:27] <hardie@jabber.psg.com> guidance to phone and first hop proxy on what to implement, and guidance to operators on what to deploy
[12:07:33] <hardie@jabber.psg.com> no normative text
[12:07:46] <hardie@jabber.psg.com> how to put the pieces together
[12:08:37] <hardie@jabber.psg.com> List comments
[12:08:47] <hardie@jabber.psg.com> UA-when does it redo?
[12:09:10] <hardie@jabber.psg.com> agreed on changes suggested
[12:09:22] <hardie@jabber.psg.com> mobile devices need more text, including shape types
[12:09:51] <hardie@jabber.psg.com> suggestions new term "location indication"
[12:14:00] <hardie@jabber.psg.com> discussion of mandatory to implement location qacquisition
[12:14:27] --- mnvakil has joined
[12:14:51] <hardie@jabber.psg.com> Andy suggests that a balance might be "must be done at network attachment"
[12:15:53] <hardie@jabber.psg.com> Steve Kent asks if the psap wants to verify the source, having proprietary methods makes it difficult to verify, does it not?
[12:22:57] --- dcrocker has left
[12:23:18] <hardie@jabber.psg.com> Steve goes through Emergency Authority to citizen notifcations draft at breakneck speed
[12:24:00] <hardie@jabber.psg.com> ETSI work
[12:24:03] --- Dan Mongrain has left: Disconnected
[12:24:17] <hardie@jabber.psg.com> where emergency workers want to inform people of emergencies
[12:24:25] <hardie@jabber.psg.com> known emergencies: flood, hurricane
[12:24:31] <hardie@jabber.psg.com> unknown: explosion, gas leak
[12:25:38] <mnvakil> testing please ignore...
[12:25:50] <hardie@jabber.psg.com> Methods of delivery
[12:26:14] <hardie@jabber.psg.com> media, sirens, etas, mobiles, amateur radio, email, web, bulk sms
[12:26:19] <hardie@jabber.psg.com> Web?
[12:26:23] <hardie@jabber.psg.com> huh?
[12:26:53] <hardie@jabber.psg.com> tr-102182
[12:27:02] <hardie@jabber.psg.com> is the document identifier
[12:27:20] <hardie@jabber.psg.com> James goes three minutes on mapping-events
[12:29:30] <hardie@jabber.psg.com> "Euphoric recovery from mapping failure"
[12:29:38] <hardie@jabber.psg.com> Fallback route
[12:30:27] <hardie@jabber.psg.com> Andy asks "what do you mean by failure" if the mapping says "no idea where you are, here's a default" and the mapping server does not respond
[12:32:05] <hardie@jabber.psg.com> Pointer to draft where dhc returns a psap uri, having done lost itself.
[12:33:37] --- Shida_Schubert has left: Logged out
[12:33:55] --- sunakichiwide has left
[12:34:05] --- jr111 has left
[12:34:18] --- mnvakil has left
[12:34:22] --- bhstark has left
[12:34:30] --- martin.thomson has left
[12:35:03] --- hardie@jabber.psg.com has left
[12:37:26] --- spencerdawkins has left
[12:48:25] --- HannesTschofenig has left
[12:55:18] --- miki_h has left
[13:58:58] --- spencerdawkins has joined
[14:05:14] --- spencerdawkins has left
[14:07:06] --- dcrocker has joined
[14:14:24] --- dcrocker has left
[14:18:53] --- mnvakil has joined
[14:19:30] --- mnvakil has left
[14:44:59] --- dcrocker has joined
[14:54:13] --- mnvakil has joined
[14:58:32] --- mnvakil has left
[16:16:53] --- dcrocker has left
[16:41:22] --- dcrocker has joined
[16:43:53] --- dcrocker has left
[18:42:34] --- shidaschubert has joined
[18:42:37] --- shidaschubert has left
[20:47:03] --- sunakichiwide has joined
[20:51:07] --- sunakichiwide has left