[17:58:22] --- jhutz has joined
[17:59:05] --- raeburn has joined
[18:00:11] --- nico has joined
[18:04:00] --- ietf-meeting has joined
[18:04:05] --- mrex has joined
[18:10:43] --- tlyu@jis.mit.edu has joined
[18:11:36] --- jaltman has joined
[18:11:45] <jaltman> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
[18:12:11] <jaltman> Audio stream http://videolab.uoregon.edu/events/ietf/ietf672.m3u
[18:20:45] --- Matt has joined
[18:25:19] <nico> just did
[18:25:21] <nico> hold on
[18:25:29] <jaltman> yes
[18:25:38] <jaltman> we hear you
[18:25:42] <nico> but I hung up
[18:25:43] <jaltman> one two three
[18:27:48] --- hartmans2 has joined
[18:27:53] --- lha has joined
[18:28:10] --- hartmans has joined
[18:28:26] <jhutz> Nico, are you using the proxy, or the mp3 directly?
[18:28:35] <hartmans> Nico, there is an on-site server with much les lag.
[18:28:37] <nico> directly now
[18:28:40] <hartmans> Do you want me to try to give you that address?
[18:28:45] <nico> I went through a proxy for the krb-wg one
[18:28:54] <nico> yes
[18:28:57] <nico> give me the address
[18:29:37] <nico> nobody does
[18:29:48] <nico> I looked at the OID registries I could find
[18:30:07] <hartmans> That doesn't make sense
[18:30:19] <nico> {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss- domain-based(5)}
[18:30:34] <nico> there are registries online that are not authoritative
[18:31:42] <jhutz> nico, until you have the lag fixed, you should comment via jabber
[18:31:48] <nico> yes
[18:32:06] <jhutz> sound is csma, and lag breaks carrier sense
[18:32:19] <nico> indeed
[18:32:25] <nico> backoff worked though
[18:32:29] <nico> :)
[18:32:47] <jhutz> I am muting you for now...
[18:32:58] <nico> I'm muted already
[18:33:15] <nico> we had a thread on this
[18:33:18] --- rlbob has joined
[18:33:28] <nico> I forget why we ended up using the SRV name
[18:33:44] <mrex> that OID (arc) is in fact administrated by IANA. There is a (deprecated) alternative nametype for hostbased service names issued by IANA on this arc
[18:34:03] <nico> and there are two other arcs in there as well
[18:34:08] <mrex> in the gssapi v2 standard documents
[18:34:08] <nico> all from RFC2743
[18:34:45] <nico> ¡ we'll remove that from the example
[18:34:52] <nico> ¡ move on :)
[18:35:37] <nico> ¡ note Martin's point about IANA owning this OID subtree
[18:35:52] <nico> I could not find anything on the IANA registries page about this
[18:36:30] <jhutz> Recurring theme today: We need reviewers for our document!
[18:36:41] <jhutz> Question: how many people have read the domain-based names drafts?
[18:36:48] <jhutz> [2 hands]
[18:37:01] <nico> wait
[18:37:08] <nico> more ppl have reviewed it than 2
[18:37:16] <jhutz> 2 hands in the room. who else?
[18:37:24] <jhutz> jaltman: 3 documents in WGLC
[18:37:46] <jhutz> : first is java bindings update. Only 3 reviewers are the chair, author, and someone who reports to the author
[18:37:57] <jhutz> : can't move this forward without review. Any volunteers?
[18:38:02] <jhutz> [shawn emery volunteers]
[18:38:22] <jhutz> one thing that makes this difficult is it is a java language document; you need both gss and java expertise.
[18:38:25] <jhutz> [leifj volunteers]
[18:38:36] --- alexeymelnikov has joined
[18:38:38] <jhutz> jaltman: I've requested several java langauge experts to review this as well
[18:39:03] <jhutz> jaltman: 2 weeks a reasonable time for review [shawn, leif both say "sure"]
[18:39:28] <jhutz> : other 2 docs were stackable mechs and extended mech inquiry
[18:39:39] <jhutz> : would like nico to speak.
[18:39:42] <jhutz> [nico unmuted]
[18:39:49] <jaltman> nico go ahead
[18:40:06] <jaltman> I think he doesn't want to talk with you :)
[18:40:07] --- leifj has joined
[18:40:15] <jhutz> jaltman: unfortunately, derek atkins, who did a review, walked out the door
[18:40:22] <jhutz> nico: why did warlord leave?
[18:42:01] <mrex> I do not object to gss_release_oid ! I just want to see strong words of caution to the addition of dynamically allocated OIDs because all OID output parameters of existing gssapi v1&2 calls are static/readonly
[18:42:42] <jaltman> mrex: I will read your comments to the audio stream if Nico does not first.
[18:42:48] <hartmans2> Martin, agreed
[18:43:25] <nico> I muted
[18:43:26] <jhutz> Martin, I think the point is that apps would be expected to always use the release operation; any _given_ mech would either return dynamically-allocated oids or not, and if not, then release would be a noop.
[18:43:29] <lha> gss_release_oid is need for some reason I can't remember now
[18:43:30] <jhutz> [nico muted]
[18:43:39] <nico> OK, I agree
[18:43:42] <lha> I strongy agree with martin
[18:43:52] <nico> ¡ there's no problem with that
[18:44:01] <hartmans2> You cannot expect todays apps to use the release operation
[18:44:07] <nico> note that we're not creating an infinite number of OIDs that would leak and leak
[18:44:28] <nico> the set of leaked OIDs would be very small
[18:44:50] <nico> is the jabber room being projected?
[18:44:58] <lha> nico: yes
[18:45:11] <jhutz> It is, now that the auto-scroll and screensaver issues are fixed.
[18:45:47] <nico> the same applies to dynamically allocated minor status codes
[18:45:59] <jhutz> hartmans: charter update is on next week's telechat
[18:46:07] <jhutz> jaltman: two changes:
[18:46:25] <nico> audio just dropped
[18:46:33] <nico> and it's back
[18:46:36] <jhutz> (1) remove work for channel definitions for ipsec, tls, etc (2) add ability to work on internationalization in GSS-API
[18:48:34] <jhutz> [nico unmuted]
[18:48:48] <jaltman> nico please continue the discussion of internationalization
[18:48:51] <lha> go nico go
[18:49:02] <hartmans> What channel are we?
[18:49:04] <nico> damn
[18:49:20] <jhutz> I believe we are channel 7.
[18:49:28] <jhutz> Or else 2. Whichever spkm wasn't
[18:49:29] <mrex> Audio Cast is channel 2
[18:49:48] <jhutz> ==mrex
[18:50:00] <hartmans> http://130.129.2.13:8000/ietf677.mp3 should be local
[18:50:16] <hartmans> O, then http://130.129.2.13:8000/ietf672.mp3
[18:51:14] <jhutz> [nico muted]
[18:51:38] <jhutz> hartmans: I really wish there were a better way of solving this
[18:51:47] <jhutz> ... without introducing multiple API's
[18:51:55] --- sc has joined
[18:51:56] <jhutz> ... but Nico and I have hashed this out; I don't think we found one.
[18:52:12] <mrex> the new unicode api calls are primarily interesting for the C-Locale
[18:52:18] <jhutz> jaltman: given the thrashing on the list, I don't think we came up with anything else that would meet everyone's needs
[18:52:46] <mrex> Since were going to use ut8, I would prefer to call them this way, i.e. gss_display_name_utf8()
[18:53:15] <jhutz> Martin, I believe the reason we didn't do that is because the use of UTF-8 is bindings-dependent.
[18:53:29] <mrex> s/C-locale/C langugage bindings/
[18:53:36] <jhutz> In a language which encodes unicode strings as ucs2, you'd want to use that
[18:53:51] <nico> say something
[18:53:53] <hartmans> Yes, but I wonder whether the c bindings should use the name Martin provides
[18:53:59] <nico> so I can measure feedback
[18:54:00] <hartmans> The function names are bindings dependentent too
[18:54:05] <nico> ^feedback^lag
[18:54:20] <jhutz> Not being interesting for java or c# is not the same as only being interesting for C
[18:54:22] <jaltman> /afs/su.se/home/l/e/leifj/public/ietf-67-kitten-gss-http-cb.pdf
[18:54:32] <jhutz> Hm, maybe.
[18:54:33] <nico> URL please
[18:55:04] <jhutz> Working on a URL...
[18:55:10] <nico> martin: locales are a part of life on Unix
[18:55:16] <jhutz> jaltman is uploading it
[18:55:27] <mrex> It doesn't work well in the presence of Microsoft Enterprise name (for users) either !
[18:55:46] <hartmans2> Martin, hu?
[18:56:05] <nico> martin: yeah, huh?
[18:56:09] <jaltman> http://www3.ietf.org/proceedings/06nov/slides/kitten-1.pdf
[18:56:19] <jaltman> that Leif's slide
[18:56:43] <jhutz> jaltman: next...
[18:56:44] <mrex> My Java colleagues complain that they can not find the user account in the Active Directory via LDAP for the principal name that they extract from the ticket
[18:57:51] <nico> more context please martin
[18:58:35] <nico> URL for Larry's slides?
[18:58:57] <jaltman> Kerberos for Web Services http://www3.ietf.org/proceedings/06nov/slides/krb-wg-4.ppt
[18:59:07] <jaltman> PKU2U http://www3.ietf.org/proceedings/06nov/slides/krb-wg-5.ppt
[18:59:43] <mrex> Sorry, I've no experience with this myself. From what I was told, the user account object only carries the Enterprise name if Enterprise names are used, and the Kerberos principal names in the tickets contain the full realm name (which usually has more components in the realm name
[19:00:17] <jhutz> leif: the name of this [kerberos-ws] is very confusing to me
[19:00:28] <jhutz> ... I expected something that improved on oasis soap stuff
[19:00:47] <jhutz> hartmans: such a document would be welcome (perhaps not in this standards body)
[19:00:55] <jhutz> hartmans: how is this different from iakerb?
[19:01:49] <jhutz> lzhu: I talked to people about iakerb; one of the problems was that it breaks the abstraction, requiring the gss acceptor to parse the kerberos messages. This mechanism encapsulates so the gss acceptor only needs to understand the wrapper
[19:02:01] <jhutz> hartmans: iakerb had a mode like that; you should call this iakerb
[19:02:14] <jhutz> simon cooper: would this work with any gss mech or just kerberos?
[19:02:25] <jhutz> hartmans: this will work with any gss app, but only if the mech you want to use is kerberos
[19:03:03] <nico> I think that would be right
[19:03:34] <nico> sam: you could use it with anything
[19:03:43] <nico> needs a new OID
[19:03:58] <jaltman> it has a new OID
[19:05:31] <nico> ooh
[19:05:33] <nico> yes
[19:06:05] <nico> mic please?
[19:06:43] <jaltman> nico we will give you the mic in a moment
[19:07:39] <nico> type when
[19:07:44] <nico> remember the lag
[19:08:05] <nico> if you when I should go then we cut the lag in half
[19:08:50] <jhutz> [nico unmuted]
[19:09:04] <mrex> rfc1964/4120 require the context to expire
[19:09:11] <mrex> (the gss-api context, that is)
[19:09:32] <jaltman> mrex: agreed
[19:10:11] <mrex> Microsoft decided to leave the security context valid, as their applications are not able to cope with context expiration (which has been in GSS-API forever, and has been in SSPI spec from the beginning -- in theory, at least).
[19:10:22] <jhutz> mrex, do you know of non-kerberos mechs that require the client to talk to some central service as part of context setup?
[19:10:31] <mrex> yes
[19:10:57] <lha> mrex: for what application are not that true ? (fail to handle gss contextes goes away)
[19:11:00] <nico> Martin: not context expiration, ticket expiration -- that's what Simon's question was about
[19:11:14] <nico> no, not GSI
[19:11:20] <nico> but anything that uses OCSP might
[19:11:21] <mrex> some pki-based gssapi mechanisms (independent of whether they use vaniall spkm1/2 on the wire) use a central server which maintains policy information
[19:11:44] <nico> jhutz: channel my other message too
[19:11:46] <nico> :)
[19:11:55] <nico> ah
[19:11:57] <nico> good point
[19:11:58] <jhutz> martin, where the _client_ needs to talk to the policy server?
[19:12:02] --- Matt has left
[19:12:23] <nico> simon/sam: all this can be done without tunneling IP in context tokens
[19:12:24] <mrex> there is one mechanism from a company in sweden TFSTech, which was for some years a subsidiary of SecurityDynamics/RSA Security
[19:12:48] <nico> sam: or for that mythical EAP-GSS that we don't have
[19:12:51] <mrex> I don't know any details about the product, though
[19:13:25] <nico> do we want to have the context expiration discussion right now or when the IAKERB discussion is done
[19:13:25] <nico> ?
[19:13:59] <nico> heh
[19:13:59] <jhutz> sam responds "never" to nico's question
[19:14:03] <mrex> there are two derivatives with their own GSS-API mechanism and protocol: DCE and SESAME
[19:14:16] <nico> so, do we want to do IAKERB as stackable?
[19:14:18] <mrex> (two Kerberos derivatives, I mean)
[19:14:55] <nico> I am now thinking: yes. If it was only about proxying KDC exchanges then I think monolythic would be fine
[19:14:56] --- sc has left
[19:15:05] <nico> but note that making it stackable
[19:15:21] --- sc has joined
[19:15:21] <nico> makes it easier for third parties to implement
[19:15:34] <nico> where there are suitable multi-mech GSS frameworks
[19:15:36] <jhutz> simon volunteers to edit something like this
[19:15:53] <nico> note too that stackable mechanisms can be done without extended mech inquiry APIs
[19:16:16] <nico> ¡ wait -- do we want to have the discussion of whether IAKERB should be stackable?
[19:16:29] --- nico has left
[19:16:36] --- nico has joined
[19:16:53] <nico> channel me
[19:17:01] <nico> sigh
[19:17:12] <jaltman> nico, we will go back to it
[19:17:14] <jhutz> argh; wasn't looking. we have lots of time, we can go back
[19:17:15] <jaltman> remind me
[19:17:40] <nico> ok
[19:19:18] <nico> I'll need the mic to comment on PKU2U
[19:19:26] <jaltman> ok
[19:19:36] <nico> it's a continuation of the SPKM discussion, yes
[19:19:47] <nico> if that's out of order then let me know
[19:20:01] <nico> (but then, why would we be having this presentation here and now?)
[19:20:42] <jaltman> we are not discussing SPKM. Just the GSS-API proposal that would have been discussed in Kerberos but we ran out of time.
[19:20:58] <hartmans2> I may cut this off.
[19:21:56] <jhutz> we're having this because jeff and I thought it would be of interest to the kerberos and kitten participants, and kitten has extra time
[19:22:06] <jhutz> [nico unmuted]
[19:22:08] <jaltman> nico you have the mic
[19:22:31] <jhutz> this is _not_ a continuation of spkm
[19:22:37] <jaltman> this is not the SPKM BOF
[19:22:43] <jhutz> nico, stop
[19:22:50] <hartmans2> Nico, AD interrupt
[19:22:56] <jaltman> Nico, we will cut you off
[19:23:13] <jhutz> [nico muted, per jaltman and sam]
[19:23:41] <nico> I agree
[19:24:03] <nico> NO
[19:24:15] <nico> yes, I agree
[19:24:20] <nico> mic please
[19:25:15] <nico> exactly
[19:25:36] <jhutz> [nico unmuted]
[19:25:43] <jhutz> anyone have clarifying questions? nico?
[19:27:02] <jhutz> simon c: why is this not a special case of the previous tunnelling mech?
[19:27:02] <nico> simon: because here there's no real KDC
[19:27:36] <nico> in IAKERB?
[19:27:36] <nico> how
[19:27:37] <nico> ?
[19:27:45] <nico> please explain Sam
[19:27:48] <nico> no
[19:27:56] <nico> looking
[19:28:01] <jaltman> checking for SPNEGO extensibility markers
[19:28:15] <nico> yes
[19:28:23] <nico> SPNEGO has extensibility markers
[19:28:57] <nico> mic
[19:29:16] <jhutz> go ahead
[19:29:16] <nico> mic
[19:30:26] <jhutz> [nico muted]
[19:30:59] <jhutz> sam: problem is usually before using a krb mech, I want to know if I can get tickets. I can't do that until after choosing the proxy mech.
[19:31:14] <jhutz> sam: also, a proxy may not be willing to proxy to my realm
[19:31:21] <nico> oh I get it
[19:31:23] <nico> yes
[19:31:24] <nico> but
[19:31:31] <nico> mic
[19:31:31] <jhutz> [nico unmuted]
[19:32:04] <jhutz> nico: you wouldn't negotiate iakerb; you'd have to know up front you want to use it.
[19:32:06] <mrex> SPNEGO is not so much about negotiation, but rather it leaves the server the choice for the best or preferred mechanism
[19:32:23] <jhutz> nico: as for pku2u, it's PK; if I have a cert, I know what mech to use
[19:32:43] <nico> done
[19:32:54] <raeburn> Is this any different from selecting Kerberos without knowing whether your realm and the server's realm can talk to each other?
[19:33:16] <jhutz> SPNEGO _is_ about negotiation; it involves selecting a mech when one or both parties support more than one but does not know a priori which mech will be used
[19:33:17] <nico> sam: please send me pointers to the EMU discussion later
[19:33:26] <jhutz> raeburn: I don't think so
[19:33:52] <jhutz> ken, I suggest you wrest a mic from the hand of sam or larry, and make your comment
[19:33:59] <jhutz> [nico muted]
[19:34:11] <nico> ¡ also, sam, EMU is about EAP, and there we're talking about initial authentication generally, no?
[19:34:25] <jhutz> [raeburn repeats his comment]
[19:34:47] <nico> ken: good point
[19:34:53] <jhutz> lzhu: in that case, with spnego, the client has to acquire creds for each mech before starting spnego
[19:35:03] <nico> larry: no! that won't work for PKIX-based mechs
[19:35:05] <mrex> if the server-side selection needs to take into account other information besides a list of OIDs, context attribute bits, then one would need a way to forward this information to the server, or extend SPNEGO to return to the client sufficient information to do a conscious preselection in a second attempt
[19:35:12] <nico> (mind you, our ssh(1) actually does that)
[19:35:42] <nico> sam: I have a huge case of dejà vu
[19:35:46] <jaltman> nico, what does your ssh(1) do?
[19:35:57] <mrex> wait: the client needs to acquire a cred handle -- that is something abstract!
[19:35:59] <nico> we've discussed negotiating what the server wants in the past
[19:36:06] <hartmans2> Martin, an interesting way to look at it.
[19:36:12] <nico> jaltman: calls gss_init_sec_context() before negotiating mechs
[19:36:17] <nico> note
[19:36:19] <jhutz> martin, yes, you'd have to do one of those things. So far, we've been trying to avoid that both in GSS and in other frameworks by having whole families of names or OID's to collapse down to one level.
[19:36:29] <mrex> and spnego will use that cred handle to create an initial context token
[19:36:42] <nico> the extended mech inquiry API does allow for discovering whether that approach can work for a given mechanism
[19:36:49] <nico> there's a mech attribute for this
[19:36:57] <jhutz> martin: no, in practice, you try to acquire creds for each underlying mech, and then use that plus your policy to tellspnego which mechs you are willing to use.
[19:37:18] <hartmans2> Martin, agreed. But I don't think a cred handled completely implies an underlying credential.
[19:37:49] <nico> damn it, I want the mic again
[19:38:00] <hartmans2> I.E. the iakerb mech's cred handle does not mean I have kerberos tickets
[19:38:10] <jhutz> or, you do if you're using the gss-api. Of course, if you're using SSPI, the API is different, and a lot of the policy and other issues are handled for you.
[19:38:12] <hartmans2> Nico, how bad is the lag?
[19:38:18] <nico> 5+ seconds
[19:38:20] <mrex> when extending an existing architecture, one must be creative in interpreting what is really already there and committed
[19:38:42] <nico> I want to comment on the TLS thing
[19:39:06] <jhutz> if we do this audio thing again, we need to make sure we have a cable to feed the audio into skype
[19:39:13] <jhutz> [nico unmuted]
[19:39:15] <nico> ready
[19:39:18] <jhutz> you get 20 words
[19:39:47] <mrex> the fact that rfc-1964/4120 immediately thinks of a TGT when a credential handle is created does not mean that an IAKERB mechanism must do the same
[19:39:58] <jhutz> [nico muted]
[19:40:33] <nico> GUAM
[19:40:35] <jhutz> yes, martin, that is true.
[19:40:46] <nico> GUAM
[19:41:10] <nico> Larry, look up at the projector :)
[19:41:17] <hartmans2> Martin, you and I are in strong agreement that 4120's interprentation of a cred handle need not apply to iakerb
[19:41:23] <nico> there are ppl working on something called GUAM
[19:41:25] <lha> nico: you need to raise larrys offer and produce an draft...
[19:41:28] <nico> ok, not so many ppl
[19:41:34] <jhutz> the problem is, if the iakerb acceptor is unwilling to proxy to your particular realm, or if there is no service principal for that service, then IAKERB is going to fail.
[19:41:35] <nico> but it would help if you worked with us
[19:41:47] <nico> GUAM is all about what you just said
[19:41:50] <jhutz> ... but you can't find that out until you've selected the mechanism, and then it's too late to switch.
[19:41:59] <jhutz> That's a multi-layter negotiation problem.
[19:42:51] <nico> briefly
[19:42:51] <jaltman> nico, do you want to jump back to IAKERB stackable?
[19:43:12] <jhutz> [nico unmuted]
[19:43:58] <nico> done
[19:44:08] <jhutz> nico: increase in stackable mechanisms is increasing; people need to review the drafts!
[19:44:11] <jhutz> [nico muted]
[19:45:12] <nico> no, it doesn't need to be
[19:45:54] <nico> that's what composition rules are for
[19:46:27] <nico> ¡ OK, we can add a composition order precedence attribute
[19:46:48] <nico> ok
[19:46:48] <jhutz> hartmans: not sure that's the right approach, but will read the draft and think about it
[19:47:13] <nico> krb5
[19:47:23] <nico> exactly
[19:47:26] <nico> mic
[19:47:53] <mrex> I would like to know whether people think we need to rush the two API specs to the IESG, or whether it might be preferable (thinking of the gss-api history) to wait with submitting the document to the IESG until we have a good amount of implementation experience
[19:48:04] <nico> martin
[19:48:08] <nico> we are not rushing anything
[19:48:10] <nico> relax
[19:48:27] <nico> martin: we asked for a WGLC in order to get reviews
[19:48:42] <jhutz> jeff is relaying martin's comment and giving background.
[19:48:49] <jhutz> martin, are you listening to the audio?
[19:49:00] <nico> we got reviews now, three + two coming + now presumably more
[19:49:22] <nico> the two I-Ds will not pass WGLC
[19:50:02] <nico> we will go through another round of review-edit-submit or three before we progress
[19:50:26] <mrex> look at how "agile" kitten has shown in clearing up ambiguities in gssapi v2u1 -- and cross-check the kitten charter when it had planned to submit either a BCP or gssapi v2u2 to the IESG ...
[19:51:12] <nico> Martin: I've not focused on GSS-API v2u1 clarifications
[19:51:39] <mrex> cat/krb/kitten do not have a good track record of timely updating RFCs. We're much better at updating internet-drafts
[19:52:00] <nico> Martin: then perhaps you should not be worried
[19:53:17] <jhutz> jaltman: will bring this issue to the list
[19:53:21] <nico> mic please
[19:53:30] <nico> yes
[19:53:33] <jhutz> [nico unmuted]
[19:54:13] <nico> done
[19:54:16] <jhutz> [nico muted]
[19:54:23] <nico> muted
[19:54:56] <nico> perhaps I've misinterpreted the same comments?
[19:55:07] <nico> I think we could do this fairly quickly, yes
[19:55:15] <nico> cheers
[19:55:23] <jaltman> meeting closed
[19:55:42] <nico> l8er
[19:55:42] --- jaltman has left
[19:56:16] --- nico has left
[19:57:03] --- jhutz has left
[19:58:12] --- tlyu@jis.mit.edu has left
[19:59:58] --- ietf-meeting has left: Disconnected
[20:00:10] --- raeburn has left: Replaced by new connection
[20:00:44] <mrex> good night (it's 2am here)
[20:01:28] --- lha has left
[20:02:38] --- sc has left: Computer went to sleep
[20:07:19] --- alexeymelnikov has left
[20:07:36] --- rlbob has left
[20:11:05] --- leifj has left: Computer went to sleep
[20:23:37] --- mrex has left
[20:40:19] --- hartmans has left
[20:40:54] --- leifj has joined
[20:41:35] --- alexeymelnikov has joined
[20:42:06] --- alexeymelnikov has left
[20:45:30] --- leifj has left
[20:50:44] --- sc has joined
[21:14:01] --- sc has left
[22:42:45] --- hartmans2 has left: Disconnected