[09:29:36] --- tomkri has joined
[09:29:47] --- tomkri has left
[09:49:17] --- tomkri has joined
[09:49:20] --- tomkri has left
[09:56:46] --- nm has joined
[09:57:18] --- tetsu1 has joined
[09:59:57] --- agallant has joined
[10:03:24] --- richard.barnes has joined
[10:03:34] --- dumdidum has joined
[10:03:43] <richard.barnes> (chair) interest in an interim?
[10:03:46] --- andrewm has joined
[10:03:55] --- alfredh has joined
[10:03:56] --- spencerdawkins has joined
[10:04:22] <richard.barnes> show of hands:
[10:04:30] <richard.barnes> several in favor, no serious objections
[10:04:43] <richard.barnes> [Dean Willis taking the mic....]
[10:04:44] --- bhoeneis has joined
[10:05:07] <richard.barnes> http://www3.ietf.org/proceedings/07jul/slides/p2psip-13.pdf
[10:05:29] --- ltn22@jabber.org has joined
[10:05:36] <richard.barnes> This is an update on the concepts/terminology draft
[10:05:56] --- csp has joined
[10:06:13] <richard.barnes> (slide 2)
[10:06:19] <richard.barnes> (slide 3)
[10:06:52] --- cullenfluffyjennings@jabber.org has joined
[10:06:54] --- Jukka has joined
[10:07:10] <richard.barnes> function = something done by the overlay
[10:07:13] --- jfr937 has joined
[10:07:15] <richard.barnes> service = something done by a peer
[10:07:18] <richard.barnes> (slide 4)
[10:07:32] <richard.barnes> This is just a sample of what peers might offer
[10:07:54] <richard.barnes> Must a peer provide any of these?
[10:08:17] <richard.barnes> [ If anyone has something they want said in the room, please preface with ROOM: ]
[10:08:49] <richard.barnes> (Hardie) To clarify: HTTP caching vs arbitrary object storage means that in the former case, it would do standard http caching?
[10:09:02] <richard.barnes> (Willis) Not expected to do anything in particular
[10:09:22] <richard.barnes> (Hardie) One thing people are suggesting is that the overlay provide application semantics as well as storage
[10:09:35] <richard.barnes> (Sinnreich) Why is presence missing from these services?
[10:09:43] <richard.barnes> (Willis) This is just a sample
[10:10:00] <richard.barnes> Presence might be a "function" of the overlay
[10:10:37] --- ttfr has joined
[10:11:23] <richard.barnes> (Q) another model for p2p is where everything is routable, no NATs, VPNs, etc
[10:11:47] <richard.barnes> concerned that we approach this e2e model, not put too much emphasis on things like STUN
[10:12:13] <richard.barnes> overlays are not the only way to deal with the realities of Internet routing
[10:12:36] <richard.barnes> (Rosen) Think we understand, but don't think this group is trying to build anything that won't work in the open Internet
[10:12:43] <richard.barnes> Also want them to work in the real world
[10:13:31] <richard.barnes> (Willis) This document works from consensus reached at earlier points in the discussion, which says we do have an overlay
[10:13:46] <richard.barnes> (Peterson) That's also in the charter, so non-overlay solutions are out of scope of the WG
[10:14:05] <richard.barnes> (next slide: Client/Peer divide)
[10:14:06] <cullenfluffyjennings@jabber.org> Link to charter http://ietf.org/html.charters/p2psip-charter.html
[10:14:21] --- Jabber-Wile has joined
[10:14:49] --- sureshk has joined
[10:15:15] <spencerdawkins> What I didn't say, because it didn't seem helpful, was that the overlay functions looked a lot like what Jim was hoping for, but that some services might be required in some deployments to accommodate NATs, etc - but having these as services, and not as functions, means they aren't at the core of P2PSIP
[10:15:39] <richard.barnes> (next slide: Things I've heard)
[10:16:09] --- ja has joined
[10:16:44] <richard.barnes> (Matthews) Clearly, peers can run out of storage. If you *just* put contact info, then it might be reasonable that you'll never practically hit the limit
[10:17:10] <richard.barnes> We do need to keep this in mind
[10:17:38] <richard.barnes> (ekr) Current DHTs deal with this badly, only option is to "soft fail"
[10:17:56] <richard.barnes> Our design will have to notify peers of how much capacity it's expected to have
[10:18:33] <richard.barnes> (next slide: Peer review)
[10:19:43] <richard.barnes> (Dawkins) Do we think we need answers to these in order to move forward? Or could the answers change as we progress?
[10:20:36] <richard.barnes> (ekr) ISTM that there are four categories of entities
[10:20:39] <richard.barnes> (1) SIP UAs
[10:20:52] <richard.barnes> (2) Things that can read/write data with the DHT, but don't participate
[10:21:01] <richard.barnes> (3) Things that route traffic, but don't store
[10:21:12] <richard.barnes> (4) Things that do all of the above, plus storage
[10:21:41] <richard.barnes> Don't see a fundamental difference between storing contacts and storing other stuff
[10:21:58] <richard.barnes> But may need different policies for different types of data
[10:22:32] <richard.barnes> Nobody will have to store >N*1000 contacts, or >N*10 voicemail messages
[10:22:54] --- brian.minard@gmail.com has joined
[10:23:00] <richard.barnes> If you're a peer and you run out of storage, you have to leave the overlay
[10:23:32] <richard.barnes> (Matthews) Intrigued by Spencer's suggesting. No current proposal explicitly supports a non-SIP UA, but all could probably add one.
[10:24:08] <richard.barnes> Two ideas why one might want a client: (1) might want to do something other than SIP (maybe not in scope), (2) wireless/low power devices
[10:24:34] <richard.barnes> Maybe let's go forward just looking at the P2P stuff, then deal with clients later when we have a better idea what we want it to do
[10:24:50] <richard.barnes> How we bring clients into the picture might become more obvious as we go along
[10:25:20] --- sureshk has left
[10:25:21] <richard.barnes> (Willis) If we have the concept of clients, we could add protocols later, but need client concept in order to guide questions about services
[10:26:32] <richard.barnes> (Matthews) My view of "client" is similar to a "SIP UA" in terms of DHT interactions. If we have a model of a node that talks to one peer and does its interaction with the overlay via that peer, and that peer roughly resembles a SIP proxy, that's what I'm thinking
[10:27:05] <richard.barnes> (back mic) different data types also have different "TTL" values
[10:27:12] --- Qian has joined
[10:27:52] <richard.barnes> (Stucker) Also need to account for the "symmetry" of what you're storing, e.g., contact info added when I join, deleted when I leave
[10:28:28] <richard.barnes> Also need to be able to interrogate overlay about how data will be handled
[10:28:56] <richard.barnes> (back mic) always will have devices that can't participate in dht. need to support these.
[10:30:11] <richard.barnes> (Dawkins) Experimental vs. Standards track? We need a PS by December of last year. Maybe we can move forward faster if we focus on the core functions of the overlay
[10:30:22] <richard.barnes> Let's do service later
[10:30:24] --- sureshk has joined
[10:30:53] <richard.barnes> (next slide: Peer services)
[10:31:25] --- tomkri has joined
[10:31:44] <richard.barnes> (next slide: Client Quirks)
[10:33:37] <richard.barnes> (Matthews) That last point might fit well with the question of what happens when a peer tries to join, but doesn't support the DHT being used
[10:33:58] --- csp has left: Replaced by new connection
[10:34:42] --- sureshk has left
[10:34:51] <richard.barnes> (front mic -- name?) Second bullet is an important question, especially when it comes to low-power devices
[10:36:06] <richard.barnes> (JDR) It will be hard to make a decision about this without some empirical information
[10:36:08] --- kafka-j31415927 has joined
[10:36:26] --- kafka-j31415927 has left: Logged out
[10:36:32] <richard.barnes> What exactly are the constraints that prevent clients from participating more fully? Storage? Power? IP reachability?
[10:36:48] --- kafka-j31415927 has joined
[10:38:08] <richard.barnes> (Dawkins) Worried we'll continue to add complexity to an already complicated system
[10:39:04] <richard.barnes> (Willis) As we're talking about proposals, keep these questions in mind. Maybe we can work backwards from example protocols to concepts/requirements
[10:39:39] <richard.barnes> [ Changing speakers, Marcin Matuszewski taking the mic ]
[10:39:51] <richard.barnes> http://www3.ietf.org/proceedings/07jul/slides/p2psip-15.pdf
[10:39:57] <richard.barnes> (title slide)
[10:40:08] <richard.barnes> (next slide: An orderly approach)
[10:41:27] <richard.barnes> (next slide: Overlay requirements)
[10:43:31] --- sureshk has joined
[10:46:15] <richard.barnes> (ekr) I agree that it's a bad idea to base Peer ID on IP, but not for this reason. You can always leave/rejoin. This is a trade-off (churn vs. other mobility overhead), not a requirement.
[10:46:38] <richard.barnes> (next slide: SIP-Overlay Interface)
[10:47:08] <richard.barnes> (next slide: client protocol)
[10:50:01] <richard.barnes> (next slide: Selecting a DHT)
[10:51:35] <richard.barnes> (Bryan) Opening discussion on DHT issues
[10:51:45] <richard.barnes> (Matthews) Want to do that now?
[10:51:52] <richard.barnes> (Bryan) Good point, let's put that off
[10:51:57] <ja> .nsvgoki,99
[10:52:35] <richard.barnes> (slide 8 now, Attacks)
[10:53:58] <richard.barnes> (next slide: P2PSIP Security)
[10:55:50] <richard.barnes> (Matthews) Seems that you're suggesting we consider "good enough" security. We need to consider all the attacks and think about which are practical to mitigate.
[10:56:12] <richard.barnes> Don't want to rule things out initially -- start out trying to do everything, and rule out things later
[10:56:53] <richard.barnes> We don't know at this point what will be practical to do
[10:57:31] <richard.barnes> (back mic) would help to classify attacks
[10:57:32] <spencerdawkins> spencer was at the mike to agree with philip...
[10:57:43] --- csp has joined
[10:58:10] --- dwillis@jabber.org has joined
[10:58:29] <richard.barnes> (JDR) Have to consider security constantly, at every step of the design. E.g., Peer ID selection has security implications
[10:59:31] --- bhoeneis has left
[10:59:48] <richard.barnes> (next slide: OPEN ISSUES)
[11:00:40] <richard.barnes> (Bryan) Charter rules out distributed enrollment, since it's not well understood
[11:01:00] <richard.barnes> (ekr) DHTs without credentials are very open to attack, so you need to have credentials for peers
[11:01:09] <richard.barnes> [ next presenter ]
[11:01:49] <richard.barnes> [ Philip Matthews presenting on behalf of all proposals: http://www3.ietf.org/proceedings/07jul/slides/p2psip-17.pdf ]
[11:02:26] <richard.barnes> (Bryan) Philip will present common lessons learned, then we'll give each proposal 5min to present, 5min discussion
[11:02:33] --- sureshk has left
[11:02:35] <richard.barnes> (first slide: Title slide)
[11:03:08] <richard.barnes> (next slide: Intro)
[11:04:28] <richard.barnes> (next slide: Should the P2P layer be distinct from the SIP layer?)
[11:05:49] <richard.barnes> (Rosen) Our intent is to discuss this at the mic here, then have some hums
[11:05:56] --- ltn22@jabber.org has left
[11:06:02] <richard.barnes> (Hardie) Prefer left side of slide to right side
[11:06:13] --- ltn22@jabber.org has joined
[11:06:26] <richard.barnes> "P2P layer" covers things which might themselves be pluggable, e.g. with different DHTs
[11:06:28] --- brian.minard@gmail.com has left
[11:07:18] --- dumdidum has left
[11:07:23] <richard.barnes> (Shepherd) Does SIP need to be modified to work on top of the P2P layer? Is it "SIP+something" instead of just "SIP"?
[11:07:44] --- ja has left
[11:08:08] <richard.barnes> (JDR) Surely, there needs to be work to define how SIP uses the P2P service. P2P layer provides get/put, replaces 3263. We'll need to describe how to use the DHT (e.g., for GRUU).
[11:08:29] <richard.barnes> Agreement that there will be mods to SIP
[11:08:46] <richard.barnes> HUM 1: In favor of separate P2P layer
[11:09:07] --- ja has joined
[11:09:07] <richard.barnes> HUM 2: In favor of maintaining integrated P2P + SIP layer
[11:09:25] <richard.barnes> In room, strong support for 1, no support for 2.
[11:09:33] <richard.barnes> (Rosen) Will confirm on mailing list)
[11:09:44] <richard.barnes> (next slide: Support multiple DHTs?)
[11:12:29] <richard.barnes> (Lowenkamp) If we have a mandatory DHT, then clients will probably have to use that DHT until the market forces another one to the fore
[11:12:49] <richard.barnes> If we don't, then if you have 20 nodes that want to form a network, the probably won't have a common DHT
[11:13:11] <richard.barnes> Only difference without a mandatory DHT is that ad-hoc is harder
[11:13:48] <richard.barnes> (Dawkins) How do we get any real interoperability without a mandatory to implement?
[11:14:38] <richard.barnes> (Hardie) Need to distinguish mandatory-to-implement vs. mandatory-to-deploy.
[11:15:14] <richard.barnes> Probably don't want to pick just one. Our history of selecting a winner has been really poor, e.g. OSI protocol stack.
[11:16:25] <spencerdawkins> ... "IAB selection of OSI protocol stack as basis for IPng"
[11:16:53] <richard.barnes> (Matthews) Many current proposals are quite open, but there may be exotic things that show up in the future
[11:17:14] <richard.barnes> Should we keep modifying the proposal to maintain support for the latest and greatest?
[11:17:35] <richard.barnes> (Hardie) Try to make this sufficiently well layered so that impacts are limited as new things come along
[11:20:14] <richard.barnes> (Garcia) Agree with Ted. One thing SIP is good at is negotiating support for different features.
[11:20:27] <richard.barnes> (Matthews) Can't do that here. Overlay will have a particular DHT.
[11:20:41] <richard.barnes> (Bryan) Analogy is joining a conference and trying to use a different codec
[11:21:18] <richard.barnes> (Rosen) Hogwash! Pick one!
[11:22:02] <richard.barnes> We pick things like ciphersuites that stay fixed for a long time, and that's not a big deal
[11:22:42] <richard.barnes> [ Brian Rosen came out into the room to make that comment, so it was made as a technical contributor, not as a co-chair ]
[11:22:50] <richard.barnes> [ Holding remaining discussion to the end ]
[11:23:00] <richard.barnes> (next slide: DD Record Types)
[11:24:46] <richard.barnes> (next slide: DD: Soft state or hard state?)
[11:27:06] <richard.barnes> (next slide: Security)
[11:28:46] <ltn22@jabber.org> voila
[11:28:57] <richard.barnes> (next slide: High-level NAT traversal approach)
[11:29:00] <ltn22@jabber.org> je vais aller faire un tour a la restroom tu surveilles mon mac
[11:29:06] <spencerdawkins> Nat traversal - I'm confused. Isn't the question whether there are a few peers with IP addresses that are reachable without traversing NATs?
[11:29:06] <richard.barnes> (next slide: Transport protocol)
[11:29:07] <ltn22@jabber.org> si qqun s'apporche tu cries
[11:29:35] --- ltn22@jabber.org has left
[11:29:51] --- apn has joined
[11:30:00] <richard.barnes> [ is someone watching ltn22's mac? ]
[11:30:07] <richard.barnes> (next slide: Diagnostics)
[11:31:04] <richard.barnes> [ Philip has finished ]
[11:31:29] <richard.barnes> (Perkins) You listed 3 transport protocols, there are actually 4 -- DCCP missing
[11:31:44] <richard.barnes> (Matthews) Thought it wasn't appropriate, and no current proposal calls for it
[11:32:24] <richard.barnes> (back mic) Want to keep this simpler than SIP itself.
[11:33:46] <richard.barnes> (Johnston) Nearly all of the examples show services being done p2p, don't require a lot of SIP machinery
[11:33:58] --- csp has left
[11:34:10] <richard.barnes> (Dawkins) Future-proofing will be driven by use cases.
[11:34:41] <richard.barnes> (JDR) Flag day? Doesn't work. If you don't future-proof first, before you deploy, then you're screwed
[11:35:00] --- hb47713 has joined
[11:35:03] <richard.barnes> Need to have adaptation mechanisms before it's deployed
[11:35:14] <richard.barnes> [ JDR is first proposal presentation ]
[11:35:29] <richard.barnes> [ http://www3.ietf.org/proceedings/07jul/slides/p2psip-10.pdf ]
[11:36:01] <richard.barnes> [ sorry, use consolidated slides from here: http://www3.ietf.org/proceedings/07jul/slides/p2psip-19.pdf ]
[11:36:42] <dwillis@jabber.org> ASP key issues, JDR presenting
[11:37:20] <dwillis@jabber.org> Using peers as SIP proxies is bad, all bad.
[11:37:57] <dwillis@jabber.org> Rough outline of live DHT swapout included. Might take months of parallel running.
[11:38:23] <dwillis@jabber.org> Tried to characterize usage, data structure, access control, etc.
[11:38:59] <dwillis@jabber.org> Modeled DHT API for plugability.
[11:39:28] <dwillis@jabber.org> Differentiated "forwarding" nodes from nodes that actually have to process the requests.
[11:40:03] <richard.barnes> (Sinnreich) Are there IPR claims here?
[11:40:24] <richard.barnes> (JDR) Not that I'm aware of.
[11:40:48] <richard.barnes> (front mic -- name?) Sounds like you're integrating the lookup with the SIP layer? Can you support really dumb clients?
[11:41:04] <richard.barnes> (JDR) No integration between SIP layer and overlay layer. Document talks about how SIP uses DHT.
[11:41:51] <richard.barnes> (Bryan -- participant hat on) Some people are confused that "using ICE" entails "using SIP"
[11:42:10] <richard.barnes> (JDR) This spec says how you use ICE without all the extra baggage of SIP/SDP
[11:42:38] <richard.barnes> ICE used to be written that way, as a meta-protocol in XML
[11:43:02] <richard.barnes> This layer made ICE incomprehensible, so we got rid of it, but we're effectively re-doing it here
[11:43:22] <richard.barnes> [ next presentation: HIPHOP, presented by Philip Matthews ]
[11:43:32] <richard.barnes> (next slide: HIP-HOP)
[11:44:18] <richard.barnes> Critical distinction here is that HIP-HOP has a separate distributed forwarding layer, based on HIP
[11:45:57] --- ttfr has left
[11:46:24] <richard.barnes> This low-layer approach allows for re-use of standard socket API
[11:48:43] <richard.barnes> (back mic -- name?) This approach (enabling changes with just a re-compile) has been done in the past?
[11:48:56] <richard.barnes> (Sinnreich) Any IPR? (Matthews) No.
[11:49:19] <richard.barnes> (Audet) The recompile idea assumes that what you're recompiling is an IPv6 app, so you may be overselling this.
[11:49:19] --- ttfr has joined
[11:49:31] <richard.barnes> (Matthews) Recent SIPit had 20% IPv6 implementation
[11:49:38] <dwillis@jabber.org> Of course, there are thousands of underlying patents, but none from the authors of this draft required to implement the draft.
[11:49:41] <richard.barnes> Other approaches entail even more work
[11:50:39] <richard.barnes> (Audet) This will be more of a benefit once there's more deployment of v6
[11:51:22] <richard.barnes> (JDR) Want to be clear that for SIP, there are changes to be made (even if it is v6), unclear how this varies from other proposals.
[11:51:55] <richard.barnes> Intriguing idea, good for HIP. DHT has good properties for translating HIT to IP address, ICE good for establishing connections.
[11:52:18] <richard.barnes> Direction is wrong: Not "HIP is helpful for doing DHTs"; rather, "DHTs are good for implementing HIP"
[11:52:40] <richard.barnes> Worried that this low-layer approach introduces a lot of intermediate-layer issues that could complicate life
[11:52:48] <richard.barnes> Maybe this sort of work belongs someplace else
[11:53:15] <richard.barnes> (Matthews) Don't understand why this might not be an appropriate approach for p2psip
[11:53:53] <richard.barnes> (Camarillo) Thinking about doing a HIP tutorial soon. We've been using HIP with recompiled applications successfully.
[11:54:30] <richard.barnes> [ next presentation: P2PP, presented by Salman Baset ]
[11:54:36] <richard.barnes> (next slide: P2PP)
[11:59:10] <richard.barnes> (ekr) What's the security story?
[11:59:55] <richard.barnes> (Baset) TBD. We intend to provide mechanisms for the 2 types of security that Philip identified
[12:00:06] <richard.barnes> [oops, sorry, the 3 types ]
[12:00:23] <richard.barnes> (ekr) Encourage you to flesh out what you're actually going to do
[12:00:51] <richard.barnes> [ next presentation: RELOAD, presented by Bruce Loewenkamp ]
[12:00:56] <richard.barnes> (next slide: RELOAD)
[12:01:09] <richard.barnes> RELOAD has a base doc and a security doc
[12:02:48] <richard.barnes> no security for pure ad-hoc networks, HMAC and certs supported when available
[12:03:24] <richard.barnes> signatures on individual elements avoid transitive trust
[12:04:46] <richard.barnes> No patents on this draft
[12:05:16] <richard.barnes> [ next presentation: LOCSER+HIP, presented by Jani Hautakorpi ]
[12:05:22] <richard.barnes> (next slide: LOCSER+HIP)
[12:05:35] <richard.barnes> (next slide: Overview)
[12:06:18] <richard.barnes> Different use of HIP than HIP-HOP
[12:06:35] <richard.barnes> Uses HIP as-is, and doesn't do overlay routing at the HIP layer
[12:07:47] <richard.barnes> (next slide: Highlights)
[12:08:22] --- Jukka has left
[12:08:25] <richard.barnes> No known patents
[12:08:43] <richard.barnes> (Sinnreich) Any IPR? (Hautakorpi) None known.
[12:08:51] <richard.barnes> (ekr) Could you talk about the security model?
[12:09:14] <richard.barnes> (Hautakorpi) Peer protocol would have security protocol, we're just proposing use of HIP as a base protocol
[12:09:26] <richard.barnes> (ekr) There are some security services necessary at the "HIP layer"
[12:09:43] <richard.barnes> (Hautakorpi) Depends on how the peer protocol uses HIP
[12:10:01] <richard.barnes> (Audet) Does this also rely on using IPv6 addressing for NAT traversal?
[12:10:26] <richard.barnes> (Hautakorpi) No, not for NAT traversal.
[12:10:56] <richard.barnes> (Matthews) In this context, the HIT is just used as an identifier to higher layers
[12:11:56] <richard.barnes> (JDR) The advantage of using HIP is that you don't need to do things like restart ICE when you move, right?
[12:12:57] <richard.barnes> [ next presntation: XPP, presented by Emil Ivov ]
[12:13:02] --- agallant has left
[12:15:53] --- isudo has joined
[12:16:59] <richard.barnes> [ moving to general discussion ]
[12:17:22] <richard.barnes> (Matthews) What's interesting about these drafts is that each one contributes different, useful ideas
[12:18:04] <richard.barnes> (Rosen) Do you think this merging needs WG/chair help, or are the individual author teams going to do it on their own?
[12:18:35] <richard.barnes> (Matthews) I've been talking with other authors. Seeing what we can bring from RELOAD into HIP-HOP
[12:19:00] <richard.barnes> There's some debate on how fast we want to try to do things. Probably won't be able to make a choice in Vancouver.
[12:19:14] <richard.barnes> (Rosen) Agreed, we've got other things to worry about, don't need a full answer in Vancouver
[12:19:59] <richard.barnes> (Bryan) Procedural comment: Materials page seems to be screwing up files. Working on it.
[12:20:17] <richard.barnes> (Rosen) We're going to let this work percolate for a while.
[12:20:33] --- tetsu1 has left
[12:20:34] <richard.barnes> [ Adjourned. Have a nice day! ]
[12:20:49] --- dwillis@jabber.org has left
[12:21:00] --- tomkri has left: Logged out
[12:21:12] --- ja has left
[12:21:36] --- ttfr has left
[12:21:37] --- alfredh has left
[12:21:59] --- richard.barnes has left
[12:22:18] --- spencerdawkins has left
[12:23:36] --- nm has left
[12:24:55] --- isudo has left
[12:25:58] --- hb47713 has left
[12:27:39] --- Jabber-Wile has left
[12:28:29] --- andrewm has left
[12:34:16] --- cullenfluffyjennings@jabber.org has left
[12:36:21] --- apn has left
[12:38:11] --- jfr937 has left
[12:39:21] --- kafka-j31415927 has left
[12:42:58] --- Qian has left
[13:26:25] --- isudo has joined
[13:53:21] --- spencerdawkins has joined
[13:58:41] --- jfr937 has joined
[14:02:38] --- spencerdawkins has left
[14:02:39] --- jfr937 has left
[14:28:35] --- nm has joined
[15:34:37] --- nm has left: Replaced by new connection
[15:34:37] --- nm has joined
[15:34:38] --- nm has left
[16:42:25] --- isudo has left: Replaced by new connection