[08:31:00] --- galvinjamesm has joined
[10:27:34] --- becarpenter has joined
[10:37:56] --- hkruse has joined
[10:51:11] --- mlshore has joined
[10:52:21] --- JoelMHalpern has joined
[10:59:17] --- amarine has joined
[10:59:23] --- becarpenter has left: Replaced by new connection
[10:59:23] --- becarpenter has joined
[10:59:23] --- becarpenter has left
[11:00:02] --- becarpenter has joined
[11:00:18] --- lisa has joined
[11:01:15] <lisa> Saint Peter is going to be on shortly to scribe on jabber
[11:01:32] --- psa has joined
[11:01:34] <lisa> Scott's disscussing the "muddled" WG status
[11:01:54] * psa warms up fingers
[11:02:12] <psa> SB: thought we were close to consensus
[11:02:19] <psa> consensus rather collapsed
[11:02:27] <psa> about 15 posters over last month on list
[11:02:32] <psa> only 8 over last 2 weeks
[11:02:44] <psa> hard to gauge consensus with small sample size
[11:02:52] <psa> we have missed our milestone
[11:03:04] <psa> supposed to have document with recommendations out by june
[11:03:14] <psa> we do have WG draft (black + carpenter)
[11:03:26] <psa> any questions on status?
[11:03:30] <psa> moving along
[11:04:23] <psa> David Black
[11:04:35] <psa> draft outlining proposals
[11:04:58] <psa> http://www.ietf.org/internet-drafts/draft-ietf-newtrk-proposals-00.txt
[11:05:11] <psa> discuss pros and cons, not make recommendation
[11:05:21] <psa> possible metrics for success
[11:06:12] <psa> increase interop, shorten time to stable spec, reduce time required to document, improve motivation of IETF participants
[11:06:29] <psa> input from group
[11:06:48] <psa> Larry Masinter: metrics should be correlated with goals
[11:07:00] <psa> not clear how these metrics correlate with IETF's goals
[11:07:44] <psa> SB: do you have suggestion for improvement?
[11:08:26] <psa> Scott Lawrence: another possible metric is reduction in number of claims that people conform to an Internet-Draft
[11:08:39] --- sanjaya has joined
[11:09:16] <psa> easier to have quantitative metrics for failure than for success?
[11:09:58] <psa> Aaron Falk: might be desirable to get IESG-type review earlier in the process
[11:10:09] <psa> (broad interdisciplinary review)
[11:10:21] <psa> SB: result would be less bounce-back from IESG
[11:10:33] <psa> number of cross-area discusses
[11:10:50] <psa> Brian Carpenter: getting close to ICAR metrics
[11:11:10] <psa> Bob Braden: success might be inversely-proportional to its length
[11:11:42] <psa> Eliot Lear: what does that mean in terms of what we're doing here?
[11:12:15] <psa> Larry Masinter: concerned about metrics over which we have no control
[11:12:15] --- mankin has joined
[11:12:28] <psa> LM: eg., marketing references by marketing people
[11:12:28] --- dinakar has joined
[11:13:05] <psa> LM: e.g., if status of document doesn't reflect status of protocol
[11:13:27] <psa> John L: wondering how useful this is -- there are IDs and then IDs
[11:13:38] <psa> John L: restrict our focus to WG drafts?
[11:13:59] <psa> Brian C: number of months between 00 draft to RFC
[11:14:02] --- mallman has joined
[11:14:42] <psa> LM: things come in at very different levels of readiness
[11:15:33] <psa> Spencer Dawkins: I agree with Larry -- and further, we don't define criteria for becoming a WG draft
[11:16:01] <psa> John Klensin: we need to be very careful about metrics
[11:16:10] <mankin> could the jabber scribe ask david black to confirm his time issue to the tsvwg chairs - is 10:30 OK?
[11:16:25] <psa> JK: easy to manipulate any metrics
[11:16:51] <psa> mankin: yes
[11:17:03] <psa> David Black: common ground...
[11:17:33] <psa> WG seems to have rough consensus documents will be revised and re-approved with or without changing level
[11:18:57] <psa> Keith: how do we incorporate errors etc.?
[11:19:19] <psa> in other SDOs, once you've stopped changing the standard, it is obsolete
[11:19:39] <psa> how do we manage trivial errors vs. substantive errors?
[11:19:58] <psa> Larry Masinter: protocol can change without document being revised
[11:20:42] <psa> (e.g., people post changes at a website or in a research paper without coming back to the IETF)
[11:21:02] <psa> Eliot L: corollary: some docs will get old and crufty
[11:21:34] <psa> Brian C: these words are not in the draft, only on list so far
[11:21:59] --- hildjj has joined
[11:22:06] <psa> Scott L: the names of the levels are ambiguous and perhaps misleading
[11:22:16] <psa> SL: we ought to fix the names if nothing else
[11:23:08] <psa> Scott B: related nit: we get IPR disclosure that X will happen if protocol becomes a Standard
[11:23:27] <psa> Larry M: name changes are least important metric
[11:23:41] <psa> LM: back to point about encouraging docs to be revised
[11:23:55] <psa> LM: there are docs that have not been revised but need to
[11:24:39] <psa> Keith: decouple decision to revise document from decision regarding what is the intended level
[11:24:56] <psa> Scott B: depends on the scope of changes
[11:25:08] <psa> David B: Proposal 1
[11:25:27] <psa> no signficant change to 2026
[11:25:46] <psa> but make current system work better
[11:25:56] <psa> general operational improvements
[11:26:00] <psa> Proposal 2
[11:26:19] <psa> confirm 2026 intention but implement strict procedures to make it really work this time
[11:26:34] <psa> Proposal 3
[11:26:35] <lisa> I kind of like proposal 2 even though it's not at all what I would have suggested!
[11:26:42] <psa> prune the process
[11:27:05] <psa> prune number of standards levels to two (Draft Standard and Internet Standard)
[11:27:12] <psa> Proposal 4: slash and burn
[11:27:23] <psa> one standard level
[11:27:39] <psa> (same threshold as Proposed Standard today)
[11:28:11] <psa> Proposal 5: declare victory
[11:28:23] <psa> just revise 2026 to document current practice
[11:28:35] <psa> Common Ideas....
[11:28:54] <psa> WG snapshots: declare doc as stable
[11:29:08] <psa> IETF snapshots: stable WG drafts approved by ADs or IESG
[11:29:18] <psa> Interop and deployment register?
[11:29:31] <psa> explicit version number to track protocol versions
[11:29:41] <psa> better process documentation and tracking
[11:30:24] <psa> Brian C: connection here to document shepherding etc.
[11:31:21] <psa> Aaron Falk: I get stuck on (1) what happens to WG and (2) what happens to current standards
[11:31:33] <psa> AF: this could be disruptive
[11:31:58] <psa> Keith: what kind of tracking of "good" vs "bad" documents
[11:32:03] <psa> or good vs. not so good
[11:32:40] <psa> e.g., is tracking internal or external? need to be reflected by something on the cover of the document
[11:32:50] <psa> (internal to IETF)
[11:33:10] --- yjs has joined
[11:33:37] <psa> Eliot: propose that we take "just revise 2026" off the table
[11:33:58] <psa> John Klensin: defacto this means one standards level
[11:34:58] <psa> DB: so you want to take proposal 2 off the table
[11:35:04] <psa> room consensus: no!
[11:35:41] <psa> Larry M: reality does match the written record, so first step is to tell the truth about where we are today
[11:36:39] <psa> Paul Hoffman: what does the outside world think?
[11:36:50] <psa> PH: if we do slash and burn, outside world would be happy
[11:37:23] <psa> PH: concern in vendor world about how our process affects them whether or not they follow our process
[11:37:47] <psa> Brian C: do you think they want version numbering so they know they are using TCP v7 or whatever?
[11:37:50] <psa> PH: yes
[11:38:13] <psa> ?? interop and deployment register would be most helpful
[11:38:35] --- hta has joined
[11:38:35] <psa> pros and cons
[11:38:46] <hta> Endre Gr√łtnes
[11:38:53] <psa> thanks
[11:39:06] <psa> going too fast for the scribe, refer to I-D
[11:39:10] <hta> (known him for a long time...)
[11:40:34] <psa> Kurt Zeilenga: I don't see much consistency in our current processes across WGs
[11:40:54] <psa> Scott B: e.g., Routing Area has different criteria
[11:41:24] <psa> Aaron Falk: snapshots may vary across WGs and areas as well
[11:42:32] <psa> Keith: could we describe more clearly the interop and deployment registry?
[11:43:04] <psa> John ?: I-D forthcoming on registry
[11:43:34] <psa> Endre: differentiate pros and cons for internal IETF use and external consumption
[11:43:48] <psa> Questions: any major options missing?
[11:44:08] <psa> another option: do nothing
[11:45:06] <psa> Harald: do nothing means we can stop having these discussions :-)
[11:45:41] <hta> no - option 5 means we can stop having these discussions. do nothing means we continue having this discussion!
[11:46:12] <psa> oh, I thought you mean this = discussions in this WG
[11:46:19] <psa> are the descriptions reasonably accurate?
[11:46:47] <psa> how do we refine the pros and cons?
[11:47:46] <psa> Paul H: one refinement is "for whom are we doing this?"
[11:49:20] <psa> Brian C: not sure we have a good handle on the pros and cons
[11:50:08] <psa> John K: we need to understand the overlap between these proposals
[11:51:14] <psa> psa: do we need to pursue a path of decomposition and recomposition?
[11:51:57] <psa> Keith: we need to know whether we can make things like the interop/deployment registry work before we can determine if it will be a good thing
[11:52:13] <psa> Spencer D: I would like to see what we can take off the table at this meeting
[11:53:08] <psa> John K: cost/benefit tradeoffs is more objective than "goodness"
[11:53:58] <psa> Larry M: interop currently not revisited after interop required for draft
[11:54:49] <psa> Brian C: I would like to see discussion of pros and cons on the list
[11:55:31] <lisa> We could certainly oblige John...
[11:55:56] <psa> John Klensin: "A Different Access and Maintenance Model for the Standards Track"
[11:56:32] <psa> draft-klensin-newtrk-std-repurposing vs. draft-loughney-what-standards
[11:56:44] <psa> first, some history
[11:57:14] <psa> three series for standards track: RFC, STD, and BCP
[11:57:21] <psa> but one set of documents
[11:57:46] <psa> proposals for new documents: Loughney: new "label", web page with information
[11:57:59] <psa> Klensin: real STD documents with definitions, commentary, history
[12:00:05] <psa> a separate STD document would enable us to track what changes happened when, errata, etc.
[12:00:52] <psa> John L is talking about labeling and web page descriptions, etc., whereas John K talks about changing the documentation model
[12:02:19] <psa> Aaron: if we are terrible writing AS docs, why would be good at writing these new STD docs?
[12:03:24] --- Eliot Lear has joined
[12:03:25] <psa> JK: the question is how we document clearly and publicly what the IETF was doing when, for example, it published RFC 2821
[12:03:47] --- xmlscott has joined
[12:04:25] <psa> Keith: trying to understand how this will help me
[12:04:43] <psa> Keith: this might help with referencing something like TCP
[12:04:56] <psa> Scott B: actually TCP is now a poster child for this problem
[12:04:58] --- kei has joined
[12:05:25] <psa> Keith: I'm more interested in things that are not yet standards, such as SIP
[12:05:45] <psa> John K: something I did not mention is that a standard number goes on something the moment it goes to proposed
[12:06:01] <psa> JK: this doesn't require changing the standards process
[12:06:34] <psa> JK: this makes it possible to say things like "SIP is becoming like TCP and here is the list, but here is what you need to pay attention to"
[12:06:50] <psa> Bob Braden: we're working towards creating a new namespace for standards
[12:07:12] <psa> BB: RFCs are in part document labels, but not standards lavels
[12:07:14] <psa> labels
[12:07:28] <psa> agreement that that is the fundamental issue
[12:07:53] <psa> JK: attempt to separate documents registry issue from the standards issue
[12:08:39] <psa> JK: two issues: (1) standards namespace (2) boundaries of labels
[12:08:57] <psa> Aaron Falk: connection here with proto team
[12:09:12] <psa> AF: trying to get WG chairs to write protocol piece of action statement
[12:10:05] <psa> JK: this brings protocol action statements closer to WGs, which have the most local knowledge
[12:10:14] <psa> JK: the proto team effort is probably an important component here
[12:10:32] <psa> John Loughney: I think JK and I are attempting the same thing
[12:10:53] <psa> JL: how much do we capture and how do we do it?
[12:11:16] <psa> JL: e.g., never clear how updates and obsoletes work
[12:11:39] <psa> Scottt B: making it clear *how* something updates or obsoletes
[12:11:41] <lisa> Oooh, this is too good not to forward to this particular audience: http://www.fatalexception.org/action_item.html
[12:12:19] <psa> Larry M: such an overall document needs to specify what is missing and what is there
[12:12:53] <psa> JK: yes, such as informational drafts, mailing list discussions, and things that have never been written down (the "oral tradition"?)
[12:13:17] <psa> Larry M: some examples might be helpful
[12:13:52] <psa> Keith: what direction are we really heading for in terms of document type?
[12:14:09] <psa> bibliography, document tree, a full profile?
[12:15:18] <psa> JK: this would become part of the process by which a protocol action happens
[12:15:48] <psa> right now RFC Editor asks author if alleged error is an error, if so posted to Errata Sheet
[12:16:00] <psa> but no process or authenticity to such statements
[12:16:56] <psa> JK: so this proposal replaces that kind of process
[12:17:11] <psa> adding IESG discretion and so on (yet to be worked out)
[12:18:36] --- jis has joined
[12:20:20] <psa> Scott B: another common experience is that a document has not addressed a certain concept and would need to be addressed in a revision, but there has no way to document those so that we remember to address it when the doc is revised
[12:21:00] <psa> Bob Braden: errata on standards are really standards issues
[12:21:12] <psa> BB: and the RFC Editor now refers those to the IESG
[12:22:02] --- amarine has left
[12:22:02] <psa> Aaron Falk: don't we need to version the STD docs?
[12:22:34] <psa> JK/SB: conformance with STD doc as of this date
[12:23:17] <psa> Eliot Lear: I like the idea, though I think it needs to be less verbose
[12:23:59] <psa> JK: references to peripheral URIs etc. would be dangerous
[12:24:01] --- sanjaya has left
[12:24:06] --- hta has left: Disconnected
[12:24:52] <psa> Larry M: change RFC so that it contains pointer to the document that describes the STD
[12:25:36] <psa> JK: RFC is a document register, here we are talking about a STD register
[12:26:19] --- Kurt has joined
[12:26:25] <psa> Bob Braden: would be useful to separate engineering of new namespace from process
[12:26:43] <lisa> I love that SIP has become the canonical example for this kind of thing.
[12:26:47] <psa> heh
[12:27:07] <lisa> It *used* to be HTTP!
[12:27:21] <xmlscott> s/SIP/TCP/ would be just as good
[12:27:43] <psa> Scott B: you said STD 35 vs. "SIP"
[12:28:13] <psa> Scott B: frequently our standards are known by a colloquial name
[12:28:46] --- kei has left
[12:29:24] <psa> John L: good to break out some of the pieces, make one of these STD documents as an I-D
[12:29:40] <psa> JK: maintenance models
[12:29:44] <psa> (next slide)
[12:29:58] <psa> Today: RFC Editor "errata sheets" (not authoritative)
[12:30:21] <psa> update process involves full document replacement, with low-info obsoletes or replaces tagging
[12:30:28] <psa> Proposed....
[12:30:56] <psa> Klensin: documents which are easy for the IESG to change, text descriptions of relationships, impl status, etc.
[12:31:17] <psa> Loughney: introduce maintenance teams and experts, etc.
[12:31:37] <psa> JK: personal opinion is that proposals address same general space and main ideas are compatible
[12:31:46] --- becarpenter has left: Replaced by new connection
[12:32:15] <psa> repurposing STDs does not change basic way in which we work, only how things are documented -- may speed things up without more risk
[12:32:17] --- becarpenter has joined
[12:33:01] <psa> maintenance teams and web pages are a poor standards technology, especially for procurement -- bad experience in IETF and elsewhere with standing interpretation and revision committees
[12:33:41] <psa> JL: no matter what we do, someone needs to do it
[12:33:55] <psa> JL: pointing to a document rather than a web page is fine with me
[12:34:15] <psa> Scott B: two categories: (1) standards (2) historic
[12:35:32] <psa> JK: we have a definition of what constitutes TCP etc. -- go through current STD index
[12:37:05] <psa> Keith: if these are to be usable, these must carry a level of authority -- same or greater than the STD document
[12:38:00] --- loughney has joined
[12:38:25] <lisa> Yeah, WebDAV book took me three years, and people who want to implement WebDAV ask the WG to do that work for free.
[12:38:38] <psa> lisa: exactly
[12:38:51] <psa> lisa: your book came first to mind :-)
[12:39:19] <lisa> E.g. particularly, asking the WG to tell him how the Microsoft WebDAV implementation works, exactly!
[12:39:20] * psa misses Larry's question
[12:40:22] <psa> Bob Braden: nomenclature: mistake to call new this STD, perhaps ISN (Internet Standard Number)
[12:40:56] <psa> BB: problem of social engineering: future standards-track documents must refer to ISN rather than RFC number
[12:41:37] <psa> Kurt Z: you're assuming that future revision of standard is compatible with earlier version
[12:42:26] <psa> Scott B: "this document as of this date"
[12:43:40] <psa> Scott Lawrence: the need for non-normative references within standards
[12:43:56] <psa> JK: this is in the I-D
[12:44:06] <psa> Kert Z:
[12:44:09] <psa> yow
[12:45:00] <psa> Scott B: this is not entirely what applicability statements are defined as (e.g., not who should use this)
[12:45:44] --- pavlov has joined
[12:45:57] <psa> Scott B: should defining some level of indirection in standards be pursued in this working group?
[12:45:58] <lisa> Hi Stuart :)
[12:46:03] <pavlov> hi
[12:46:04] --- yjs has left
[12:46:14] <psa> Kurt Z: this seems orthogonal to defining what the standards track should be
[12:46:38] <psa> JK: you are right, but that does not imply it is not good to separate that work
[12:47:24] --- loughney has left: Disconnected
[12:47:40] <psa> SB: if we have something like this which points to a set of documents, then the important of the levels is reduced
[12:47:48] <psa> importance
[12:48:47] --- hta has joined
[12:48:54] --- hta has left
[12:48:58] <psa> JK: can even say "we have high confidence in this standard except section 7 and there is an I-D that is working to address it" etc.
[12:50:08] <psa> John L: I agree that this work should be done here
[12:50:37] <psa> Spencer: +1
[12:50:54] <psa> Scott B: hum: should work of this ilk be done in the WG
[12:50:59] <psa> no hums against
[12:51:43] <psa> lisa: I could do one for XMPP :-)
[12:51:55] <lisa> sure
[12:52:05] <lisa> go for it
[12:52:27] <psa> Eliot Lear: "Let's Talk Old and Crufty" (next presentation)
[12:53:18] <psa> STD 25, 26: Daytime, Time
[12:53:26] <psa> STD 40: Host Access Protocol
[12:53:33] <psa> STD 44: Hello
[12:53:44] <psa> STD 47: SLIP
[12:53:59] <psa> STD 52: IP over SMDS
[12:54:16] <psa> These are all full standards!
[12:54:30] <psa> more examples.....
[12:54:42] <psa> BOOTP is a Draft Standard
[12:55:28] <psa> Proposed Standards: TACACS use identification Telnet Option, ICMP Router Discovery, etc.
[12:56:05] <psa> how about RFC 2748: COPS?
[12:56:14] <psa> (poorly specified)
[12:57:02] --- JoelMHalpern has left
[12:57:34] <psa> we might want to revisit some of these standards
[12:57:41] <psa> criteria:
[12:57:53] <psa> is the standard still used? if no, old and crufty
[12:58:34] <psa> is the standard safe to use?
[12:59:02] <psa> if no, maybe RFC required to describe the dangers
[12:59:29] <psa> if it is safe, do we need an RFC to describe why it is old and crufty
[12:59:42] <psa> John L: it's much harder to remove things that are dangerous
[13:00:53] <psa> John K: this is exactly why the previous discussion needs to happen here
[13:01:25] <becarpenter> [I am staying in tsvwg - Brian]
[13:01:38] <psa> David B: difference between "waste of time" and "hazardous to your health"
[13:01:48] <psa> who determines what is old and crufty?
[13:02:15] <psa> committee, WG, individuals with approval of IESG?
[13:02:42] --- yjs has joined
[13:03:30] <psa> draft-alvestrand-newtrk-historical-00
[13:03:32] --- yjs has left
[13:03:39] <psa> (see which)
[13:04:05] --- yjs has joined
[13:04:39] <psa> Larry M: these docs can be short and are not that hard to do
[13:05:25] <xmlscott> Consideration of Really Useless Files Team
[13:05:45] <psa> xmlscott: good work
[13:06:15] <psa> Bob Braden: Jon Postel's opinion was that standards are forever, but personally I think that was the product of simpler times
[13:06:37] <psa> BB: the older documents were grandfathered into standards before the IAB invented the standards process
[13:06:46] <psa> (no process at that time)
[13:07:52] <psa> Eliot: Historic has taken on connotation of "dangerous" but some of these are not dangerous, just old and no longer in (wide) use
[13:08:23] <psa> Eliot: why do this at all?
[13:09:09] <psa> parts of the community are concerned that once something passes to PS/DS/STD, it's there for a long time, which leads the IESG to be overly careful about advancing things to those levels
[13:09:25] <psa> Eliot: let deployment experience dictate lifetime of a standard
[13:09:35] <psa> this discussion applies to standards-track document only
[13:10:36] <psa> Keith: we might think it's dangerous, but someone might be using it in a restricted sense
[13:10:58] <psa> SB: their use might not be as restricted as they think if it is going over IP
[13:11:19] <psa> Eliot: the main benefit is to introduce a release valve
[13:11:52] <psa> Kurt Z: perhaps more helpful to move things to Informational
[13:13:09] <psa> John K: we have a relatively small number of things that have sat at PS or DS for a long time, whether we like them or not but the marketplace has accepted them
[13:13:41] <psa> JK: do we advance them without applying all the more recent rules for document advancement?
[13:14:41] --- yjs has left
[13:15:09] --- yjs has joined
[13:15:19] <psa> Scott Lawrence: time is not as important as having an orderly process to address these matters
[13:15:20] --- yjs has left
[13:15:50] --- yjs has joined
[13:16:09] --- jis has left: Disconnected
[13:16:10] --- mallman has left
[13:16:11] <psa> Eliot: only reason for time perspective is that we can remove the notion that proposed standards live forever
[13:16:17] --- hkruse has left: Disconnected
[13:16:54] --- hildjj has left: Disconnected
[13:17:10] <psa> David P: I think spring cleaning in standards docs is a good thing that will force us to learn some surprising things about our process, but we need to do so in an open way
[13:17:10] --- mlshore has left
[13:17:30] --- xmlscott has left: Logged out
[13:17:44] <psa> Harald: we tried to define the most lightweight process possible to do this job
[13:18:15] <psa> Eliot: Harald and I would like to do this
[13:18:57] <psa> Eliot: and any change to Historic would happen only after IETF Last Call and IESG approval
[13:19:29] <psa> Keith: concern that these standards are still being used
[13:20:26] <psa> Eliot: document why thought to be old and crufty, put through IETF Last Call, if possible incorporate dissenting opinion
[13:20:55] <psa> Scott B: hum: should Eliot Lear if think good idea to pursue?
[13:21:02] --- Eliot Lear has left: Disconnected
[13:21:06] <psa> two or three hums against, many for
[13:22:00] <psa> hum if in favor of automatic advancement?
[13:22:05] <psa> inconclusive
[13:22:09] --- mankin has left: Disconnected
[13:22:21] <psa> Harald: object to "automatic advancement"
[13:23:31] <psa> will take it to the list
[13:23:34] <psa> </end>
[13:23:35] --- yjs has left
[13:24:27] --- lisa has left: Disconnected
[13:25:05] --- psa has left: Disconnected
[13:30:44] --- pavlov has left
[13:33:39] --- dinakar has left: Replaced by new connection
[13:33:39] --- dinakar has joined
[13:33:40] --- dinakar has left
[13:38:55] --- Kurt has left: Disconnected
[13:40:55] --- becarpenter has left: Disconnected
[14:10:04] --- galvinjamesm has left
[14:50:12] --- psa has joined
[14:51:35] <psa> log: http://www.xmpp.org/ietf-logs/newtrk@ietf.xmpp.org/2004-08-05.html
[14:52:10] --- psa has left
[14:54:47] --- Eliot Lear has joined
[14:55:03] --- Eliot Lear has left
[14:56:49] --- lisa has joined
[14:58:05] --- Kurt has joined
[15:03:32] --- lisa has left
[15:24:43] --- Kurt has left
[17:07:43] --- hta has joined
[17:26:22] --- sob has joined
[18:37:42] --- sob has left
[21:01:25] --- hta has left: Disconnected
[21:03:45] --- hta has joined
[21:48:20] --- hta has left: Replaced by new connection
[21:48:20] --- hta has joined
[21:48:21] --- hta has left