[09:52:26] --- arnt has joined
[11:21:35] --- fanf has joined
[11:51:57] --- Dave Cridland has joined
[11:52:08] <Dave Cridland> Evening.
[11:53:16] --- Glenn Parsons has joined
[11:53:33] <Glenn Parsons> Greetings from Zurich...
[11:53:53] <Glenn Parsons> and yes good evening.
[11:54:09] <Dave Cridland> I think it's good evening for all of us so far.
[11:58:55] --- Alexandros Vellis has joined
[12:00:38] --- tonyhansen has joined
[12:00:39] --- pguenther has joined
[12:00:52] --- Barry Leiba has joined
[12:01:37] --- Glenn Parsons has left
[12:01:51] --- Glenn Parsons has joined
[12:04:11] <tonyhansen> jabber
[12:04:41] <tonyhansen> eric is trying to bribe us
[12:05:05] --- hardie@jabber.psg.com has joined
[12:05:11] --- alexeymelnikov has joined
[12:05:19] <Dave Cridland> Nobody here but us chickens.
[12:05:45] --- resnick has joined
[12:05:53] <pguenther> dave, can you hear us on audio?
[12:05:54] * fanf is listening
[12:06:00] <Dave Cridland> I can hear, yes.
[12:06:02] <Glenn Parsons> yes Glenn can hear fine....
[12:06:05] --- cyrus_daboo has joined
[12:06:05] --- cnewman@jabber.org has joined
[12:06:13] <pguenther> okay, just verifying
[12:06:20] <tonyhansen> new slides have been uploaded
[12:06:27] <Dave Cridland> Audio seems surprisingly unpoppy, too.
[12:07:08] <tonyhansen> pause for technical difficulties
[12:08:10] --- kmurchison has joined
[12:08:34] <fanf> what's the url?
[12:08:35] <hardie@jabber.psg.com> community jabbering
[12:08:44] --- dcrocker has joined
[12:08:48] --- harald has joined
[12:08:49] <hardie@jabber.psg.com> Note well shown
[12:09:16] <harald> agenda bashing
[12:09:32] <harald> (not scribing. making notes.)
[12:09:39] <hardie@jabber.psg.com> Suggesting to bypass convert
[12:09:51] <hardie@jabber.psg.com> to allow Alexey and Ray to do an offline document pass
[12:09:52] <resnick> fanf: URL for the audio or the presentations?
[12:09:56] <hardie@jabber.psg.com> Then bring it to the list
[12:10:00] --- randy has joined
[12:10:05] <fanf> slides
[12:10:20] <resnick> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
[12:10:25] <fanf> thanks
[12:10:26] <resnick> Look for LEMONADE.
[12:10:28] <hardie@jabber.psg.com> Search-within, filtered views, profile bis, interop seems to be the end point
[12:10:44] <tonyhansen> bash agenda: interop notifications search-within, filtered views, profile bis, convert
[12:11:49] <resnick> Interop Results, Notifications, named Searches, and URLs
[12:12:04] <tonyhansen> http://www3.ietf.org/proceedings/06nov/slides/lemonade-2.ppt
[12:13:02] <tonyhansen> alexey: issues discovered during interop
[12:14:07] <tonyhansen> alexey: urlauth: a couple bugs -- suggestions for doc
[12:14:22] <Dave Cridland> That's EXPIRE= validation during GENURLAUTH, not during URLFETCH (where everyone did, AFAIK)
[12:16:30] <Dave Cridland> Also, if clients have clocks set in the past, GENURLAUTH works but BURL fails.
[12:20:21] <tonyhansen> (blank stares on question of 'does anyone care about urlmech issues'
[12:21:10] <Dave Cridland> Might be a possibility of using a shared-key URLMECH sometime, avoid the GENURLAUTH round-trip.
[12:21:42] <pguenther> that was kind of the original design, yes
[12:21:46] --- cromwellian has joined
[12:22:16] <cromwellian> anyone see this?
[12:22:18] <tonyhansen> chris: urlmech response code is really there for methods other than internal;
[12:22:30] <pguenther> cromwellian: yes
[12:22:31] <tonyhansen> chris: add note to base?
[12:23:37] <tonyhansen> summary: add note to base : if server only implements internal, response code will not convey any info and should be optional in that case
[12:24:31] <tonyhansen> barry: question on idle issues alexey: not really idle issues
[12:25:27] <tonyhansen> alexy: condstore issues need note about CONDSTORE on CONDSTORE + UIDPLUS combination
[12:26:23] <tonyhansen> (need untagged OK to convey notification sequence)
[12:28:06] <tonyhansen> additional note: how HIGHESTMODSEQ can be returned and additional text for client on what to do if it doesn't get it
[12:28:23] <tonyhansen> alexey: constore: "STORE UNCHANGEDSINCE 0"
[12:30:48] <tonyhansen> phill: pick option 2; client can already find which flags exist
[12:31:30] <tonyhansen> alexey: prefer option 1
[12:32:57] <tonyhansen> pete: use BAD for 0?
[12:33:27] <tonyhansen> alexey: some servers also set flags, which was wrong
[12:34:12] <tonyhansen> so should have said NO
[12:35:00] <tonyhansen> summary: STORE UNCHANGEDSINCE 0 for any system/user defined flags MUST return NO lisa: BAD for system flags, NO for user flags?
[12:35:59] <tonyhansen> alexey: STORE UNCHANGEDSINCE 0 for any system/user defined flags MUST return NO.
[12:36:14] <tonyhansen> alexey: QRESYNC
[12:37:26] <tonyhansen> merge with EXPUNGED draft?
[12:39:16] <tonyhansen> why? QRESYNC is optimization on condstore, as is EXPUNGED probably used together, too many extensions, so merge? new draft: "client reconnect"
[12:40:55] <tonyhansen> summary: merge them
[12:42:45] <tonyhansen> cyrus: call this an update to condstore? alexey: no, not needed, but feel free to suggest text
[12:43:31] <alexeymelnikov> Cyrus promised to provide some text about QRESYNC updating CONDSTORE
[12:43:50] <tonyhansen> Notifications, Named Searches, and URLs
[12:44:11] <tonyhansen> http://www3.ietf.org/proceedings/06nov/slides/lemonade-1.ppt
[12:44:27] <resnick> Not at the mic, since I haven't thought this out: If EXPUNGED would be useful without CONDSTORE *and* folks would be willing to implement EXPUNGED *without* implementing CONDSTORE, then I'd rather it be a separate extension.
[12:44:29] --- Lisa has joined
[12:45:43] <tonyhansen> sorry: Status of drafts, Notification Discussion http://www3.ietf.org/proceedings/06nov/slides/lemonade-3.ppt
[12:45:49] <tonyhansen> slide 5
[12:45:55] <Lisa> Pete: It's certainly a tradeoff. Why not ask the question who would implement EXPUNGED without CONDSTORE?
[12:46:13] <randy> Pete: by 'folks' do you mean clients, servers, either, or both?
[12:46:21] <resnick> Randy: Servers.
[12:46:25] <Lisa> (And isn't it actually draft-ietf-lemonade-reconnect that it would be combined with?)
[12:47:01] <randy> Pete: it might be better to ask if its useful for clients to have only one
[12:47:04] <tonyhansen> (ray cromwell describing slide 5 ....)
[12:48:38] <resnick> Lisa/Randy: Understood. That's why I didn't get up to the mic. I'm not sure if EXPUNGED would be independently interesting to clients and has a higher likelihood of implementation on servers. Still cogitating.
[12:49:56] <randy> I have doubts that EXPUNGED alone would be useful to clients, but I'm not sure
[12:50:05] <resnick> Neither am I.
[12:50:26] <Lisa> Mark Crispin asked the same thing Randy just asked.
[12:52:28] <tonyhansen> discuss on list: whether notification payload >>needs<< to carry info to determine which filter triggered the event
[12:53:00] <resnick> On this notifications stuff: I take it folks understand that we need a charter update, eh?
[12:55:00] <tonyhansen> ... discussion of use cases ...
[12:56:01] <Glenn Parsons> Pete: what do you think is out of scope?
[12:56:30] <tonyhansen> ... unexplored in some ways, could use trial, design payload format so that extra stuff can be added later ...
[12:56:50] <resnick> Glenn: This sure sounds like server->client notifications.
[12:58:12] <Glenn Parsons> There are several parts: architecture, content, out of band & inband
[12:58:13] <tonyhansen> ... is notification a hint that client needs to go digging for update, or include sufficient info in and of itself ...
[12:59:10] <fanf> what about notifications that aren't intended to prod an IMAP client?
[12:59:37] <randy> fanf: what are those notifications intended for?
[12:59:42] <tonyhansen> ... client opaque data returned by server ...
[13:00:19] <tonyhansen> ... not filter name but client provided user data item ...
[13:00:27] <fanf> e.g. for a "you have new mail" indicator
[13:00:53] <arnt> that's an indirect way to prod an imap client
[13:00:58] <Glenn Parsons> I think our view on notifications has changed significantly since we started.
[13:01:13] <tonyhansen> ... are filters client specific? hardware specific? ...
[13:01:45] <resnick> Glenn: Absolutely. But the charter doesn't reflect that.
[13:01:46] <tonyhansen> ... "tolerant of delay and loss" sounds like flow control? throttling?
[13:02:04] <randy> My comment was about the intent of notifications: if they are merely small wake-ups that let the client know it needs to go fetch data to resync, and perhaps also include enough info to help the client decide to fetch data now or later, then the delay/loss and security requirements are very different.
[13:02:13] <Glenn Parsons> The charter does not have the specifics, but it has the spirit
[13:02:53] <randy> On the other hand, if the notifications contain enough data to resync, then the delay/loss and security requirements are significantly different
[13:02:54] <randy> I
[13:03:09] <resnick> Quite the opposite. That charter was designed to specifically not allow notifications from server to client.
[13:03:11] <randy> I've heard both discussed here and i think we need to decide which path we want to go down
[13:03:21] <tonyhansen> ... is this replacement for inband sync?
[13:04:00] <Glenn Parsons> The charter included the note that the IAB was going to rule on that issue.
[13:04:06] <tonyhansen> ... partial sync for sms's ... not job to create imap sync over X ...
[13:04:07] <resnick> I think the thoughts in this area have probably matured enough to make it reasonable for us to work on, but I think the rest of the community should be told that we're working on it.
[13:04:09] <randy> Throttling is very different from delay/loss
[13:04:58] <randy> Without throttling, notifications can be much more expensive (to operator and user) than polling
[13:06:24] <randy> Issue of where throttling is done: on event-generating server (IMAP server) or on separate notification server (perhaps in carrier network)
[13:06:25] <tonyhansen> ... last time discussion of throttling, may client could set up rules on server, but too complicated ... ... throttling would be left up to vendor implementation, client should be able to say "i've had enough" ...
[13:07:00] <Lisa> Some notification transports have their own throttling mechanisms.
[13:07:36] <tonyhansen> ... question of two filters triggering same event ...
[13:08:41] <tonyhansen> ... discuss further issues with notifications on list ...
[13:08:49] <arnt> who's speaking - ray?
[13:08:55] <tonyhansen> slide 6: ray
[13:09:08] <Glenn Parsons> And the result of the IAB ruling fed into our architecture discussion and document.
[13:09:13] <tonyhansen> (notifications today: many related drafts)
[13:09:18] <Glenn Parsons> On the recharter, we had discussed before
[13:09:52] <Glenn Parsons> the current rough consensus is that it would be nice , but not needed
[13:10:49] <tonyhansen> ray: need to unify things -- make them more coherent
[13:10:57] <tonyhansen> slide 7: Desire: simplicity and unification
[13:11:59] <resnick> AFAIK, the IAB never gave an answer ("ruling") on this issue, and I have no memory of any consensus on rechartering. Can you point me to any messages?
[13:12:36] <Lisa> I think I'm the one with the goals for unified notification, actually
[13:13:54] <Glenn Parsons> Pete: we reviewed the IAB note last year sometime ...
[13:14:43] <arnt> I'm connected to my imap server form my desktop all the time, even when I'm not in the office. I want out-of-band when not in the office.
[13:14:46] <Glenn Parsons> and the rechartering discsussions have been mostly at IETF sessions...
[13:14:52] <arnt> (channel that)
[13:15:13] <tonyhansen> summary: need to associate filters with sessions; session needs some idea of device being connected
[13:15:22] <fanf> this device identifier sounds like an XMPP resource
[13:15:49] <tonyhansen> (agreement on channeled comment)
[13:16:45] --- aaronstone has joined
[13:17:04] <tonyhansen> (user device knows what it wants; server can't guess)
[13:17:19] --- harald has left
[13:17:55] <fanf> one problem with the client explicitly asking the server to suppress notifications is what happens when the client's imap connection is abruptly lost. do notifications remain suppressed?
[13:19:03] <tonyhansen> (fanf: do you want that comment channelled?)
[13:19:13] <hardie@jabber.psg.com> Wouldn't it be useful on shared mailbox--telling someone that an item has been expunged helps indicate it's not in the queue?
[13:19:46] <fanf> yes please
[13:20:59] <tonyhansen> (anyone that wants something channelled, please include an indication of your desire)
[13:21:41] <arnt> is something beeping in the audio?
[13:21:52] <resnick> It's a little feedback.
[13:22:04] <resnick> (Unless you're hearing something we're not.)
[13:22:37] <arnt> I was wondering whether some computer or fire alarm or whatever somewhere was calling for uncle ;)
[13:22:38] <arnt> thanks
[13:22:45] <tonyhansen> ray: slide 8: Notifications: Other Desires
[13:29:13] <tonyhansen> eric: what is goal wrt DoS attacks?
[13:30:47] <tonyhansen> ... discussion ...
[13:31:34] <tonyhansen> slide 9: Notifications: Where we are
[13:32:56] <tonyhansen> ... view filters - different constraints, may be able to eliminate one of CONTEXT or VFOLDER
[13:35:48] <pguenther> hmm, fire alarms, that would be a dramatic demonstration of an out-of-band notification...
[13:35:51] <tonyhansen> ... alexey: add IDLE notify ...
[13:36:52] <tonyhansen> (to event/notification filters list)
[13:37:24] <arnt> pilip: I saw bluetooth-supporting fire alarms the other day ;)
[13:37:37] <hardie@jabber.psg.com> arnt: Are you kidding?
[13:37:39] <tonyhansen> ray would welcome proposals for notifications draft
[13:37:44] <pguenther> tony, you should cover your mic when cracking open a beer
[13:37:45] <hardie@jabber.psg.com> What the heck did the bluetooth do?
[13:37:57] <tonyhansen> slide 10: notifcations: where we are
[13:38:01] <tonyhansen> (slurp slurp)
[13:38:13] <tonyhansen> ... msg-events done ...
[13:38:50] <tonyhansen> ... s2s needs work, payload needs work ...
[13:39:47] <arnt> ted, I'm not kidding. it could talk to a pc, windows software was supplied. I did not look closer. it would be more true to say that I screamed and ran ;)
[13:40:00] <tonyhansen> eric: will there be a s2s need in the wild: between vendor A and vendor B
[13:40:41] <tonyhansen> ray: mega-notification boxes?
[13:40:49] <hardie@jabber.psg.com> arnt: well, I would have been running right beside you. At least it sounds like the bluetooth was for programming and not the actual function of the fire alarm
[13:41:20] <hardie@jabber.psg.com> Using a bluetooth push to set off the firealarm seems a tad to complicated, compared to "pull alarm"
[13:41:30] <arnt> the box did say that multiple fire alarms could talk to each other, so when one screams FIRE, all do...
[13:41:36] <pguenther> assign a zone ID to the alarm for it to report to the central box?
[13:41:38] <arnt> anyway, enough of a digression
[13:42:24] <tonyhansen> chris: good to be able to hook up s2s between servers, but not critical path. postpone to after profile-bis? eric: part of charter
[13:42:48] <tonyhansen> lisa: least part of our goals
[13:43:34] <tonyhansen> ray: leave out of profile, make supplementary in future? but don't drop eric: keep on docket but move milestone
[13:43:47] --- harald has joined
[13:43:55] <tonyhansen> slide 11: notifications: other issues
[13:45:19] <tonyhansen> chris: it's critical that servers not know device ids?
[13:46:04] <tonyhansen> ... must have on imap server, a way for client to say that there's a class of events it can make use of
[13:46:21] <Lisa> +1 to all Chris said.
[13:46:30] <tonyhansen> ... subscription managed by client, generation mananged by server, need throttling on both sides
[13:48:25] <tonyhansen> summary: desire is that devices subscribe to appropriate filters for their circumstance
[13:48:34] <tonyhansen> ... imap servers will not be device aware
[13:48:46] <tonyhansen> slide 12: notifications: issues
[13:48:57] <tonyhansen> provisioning...
[13:51:01] <fanf> <Dave Cridland> ACAP
[13:51:40] <tonyhansen> security...
[13:53:47] <harald> ??
[13:53:51] <tonyhansen> ... need integrity checks, but not necessarily e2e encryption (e.g.)
[13:54:05] <harald> doesn't a notification (potentially) contain a message sender and a subject line?
[13:54:16] <tonyhansen> ...don't want to drain batter life, DoS
[13:54:23] <harald> (disclaimer, haven't read the draft...)
[13:55:16] <tonyhansen> ... ray: integrty is SHOULD, e2e secrutiy is desirable,
[13:55:29] <arnt> it potentially does that. stress on the word potentially.
[13:55:41] <arnt> read the two dozen drafts ;)
[13:55:58] <harald> -msgevent?
[13:56:37] <tonyhansen> chris: notification model needs security issues section ... specify considerations of notificiation section
[13:56:42] <Glenn Parsons> we have a notifications architecture document -- this is not the model Chris is looking for?
[13:57:06] <arnt> no, there are _lots_. perhaps not two dozen, but _lots_. many partly competing, partly complementary proposals.
[13:57:12] <tonyhansen> ... draft-ietf-lemonade-notifications ray: too many drafts, need to be combined
[13:57:37] <Glenn Parsons> use the mike Ray
[13:57:55] <tonyhansen> lisa: two models: not systems that support subscribe, another for sms you just push out to?
[13:58:05] <resnick> We'll make sure, Glenn.
[13:59:02] <tonyhansen> ray: word subscribe being used 2 different ways
[13:59:33] <harald> -notifications-03 section 8.1 contains a "should" for encryption that IMHO should be SHOULD (for notifications with subject, sender and so on)
[13:59:57] <tonyhansen> eric: if notif mech is SIP, SIP has subscription semantics and protocols
[14:00:05] <harald> (just making notes that don't make sense in the flow of conversation)
[14:00:45] <tonyhansen> ... discussion on subscribe ...
[14:02:33] <tonyhansen> chris: 2 diff pieces: 1) event generation filters, partly controlled on server and partly policy 2) subscriptions, function of notif method ray: except SMS could address by: event generation filters are good enough, or generation trigger
[14:03:00] <Lisa> For the notes, what I was saying at the MIC was that there could be two completely different ways of authorizing and setting up event flows: one way for delivery over systems that already have a Subscription model (SIP and XMPP), and one for delivery over systems that do not have subscriptions (email and SMS).
[14:03:10] <tonyhansen> ray: do notif server need bidirectional capability?
[14:03:40] <Lisa> In the first case, the IMAP server as the notification source only needs to have authorization setup. In the second case, the notification source needs to have event streams initiated with filters etc and a way to stop them again.
[14:04:07] <tonyhansen> eric: sip clarification
[14:04:34] <tonyhansen> eric: asks if xmpp is similar
[14:04:52] <tonyhansen> lisa: clarifies xmpp
[14:05:31] <tonyhansen> ray: boil down: 1) what do we do with mechanis that don't have subscription method? does imap need way to do that?
[14:05:59] <tonyhansen> 2) is there reason why imap server needs to now if people have unsubscribed at the gateway?
[14:07:14] <tonyhansen> phil: affects on url?
[14:07:59] <tonyhansen> phil: reasonable to have aggregator tell imap to stop/restart event streams
[14:08:01] <pguenther> note quite: use URLAUTH with imap: SEARCH urls for authorizing access to notifications
[14:08:26] <tonyhansen> lisa essentially concurs
[14:09:17] <tonyhansen> ray: need to coalesce, unify and finish up
[14:10:03] <tonyhansen> alexey: need jabber interims?
[14:10:24] <arnt> use the mike?
[14:10:55] <tonyhansen> (discussing what to discuss next)
[14:11:08] <resnick> This is kibitzing about which slides will appear.
[14:11:08] <tonyhansen> back to slide 4: vfolder issues
[14:11:32] <tonyhansen> alexey: volder and context need to be discussed together
[14:11:43] <tonyhansen> SEARCH WITHIN is LC
[14:11:52] <tonyhansen> slide 3: open convert issues
[14:12:24] <tonyhansen> ray: simplify discovery mechanism?
[14:15:09] <tonyhansen> Interop Results, Notifications, named Searches, and URLs slide 11: lemonade profile bis
[14:15:10] <randy> My message to the lemonade list sent May 31 8:38 AM contained suggestions for how to simplify discovery mechanisms
[14:15:14] <tonyhansen> slide 13
[14:16:30] <tonyhansen> phil: is anything in profile bis saying: clients should not do dorky things with vfolders
[14:18:14] --- dcrocker has left
[14:18:15] <tonyhansen> slides added to http://www3.ietf.org/proceedings/06nov/slides/lemonade-4.pdf on Contexts
[14:18:35] <tonyhansen> do we need interim or jabber sessions enough?
[14:18:42] <Glenn Parsons> ack -- you didn't talk to me ...
[14:18:54] <tonyhansen> lisa: do we need notificaiton interim?
[14:19:06] <tonyhansen> alexey: notif and filtering?
[14:19:15] <tonyhansen> lisa: workshop?
[14:19:35] <tonyhansen> (ietf process governs difference)
[14:20:22] <pguenther> dave crocker suggested an interim bof
[14:20:58] <Glenn Parsons> what was Lisa talking about? A new non-LEMONADE notifications event?
[14:22:02] <resnick> Glenn: Yes.
[14:22:08] <Glenn Parsons> 12th of what?
[14:22:12] <resnick> December.
[14:22:16] <Lisa> Glenn, I really want to discuss this more with some people like Ted first, and some people outside of Apps who are working on very similar notification problems. But I was thinking of a pre-BoF: call it a workshop or whatever, but I finally see how one might write a scoped charter for a finite-time WG in this area.
[14:23:03] <Glenn Parsons> Lisa for the LEMONADE problem space we do not want a general boil the notification ocean solution.
[14:23:27] <Lisa> Yes. "I finally see how one might write a scoped charter for a finite-time WG".
[14:23:48] <tonyhansen> ... when to have jabber interim ... december 12
[14:24:00] <resnick> Discussing the time of day....
[14:24:35] <tonyhansen> 7am PST?
[14:24:55] <randy> 7PM PST?
[14:25:04] <arnt> please
[14:25:51] <Glenn Parsons> what time did we decide???
[14:25:52] <tonyhansen> 7am PST
[14:26:11] <hardie@jabber.psg.com> midnight in new zealand
[14:26:12] <tonyhansen> topic: context, vfolders, and such
[14:26:49] --- Barry Leiba has left
[14:26:49] --- Barry Leiba has joined
[14:26:54] --- Barry Leiba has left: Logging off
[14:27:21] <tonyhansen> milestones (slide 27 of chair's slides)
[14:27:55] <tonyhansen> imap url Dec?
[14:28:05] <tonyhansen> yes
[14:29:07] <tonyhansen> profile, filtered views, notifications payload format should be on time
[14:29:18] <Glenn Parsons> someone is speaking?
[14:29:25] <tonyhansen> barry: imap sieve
[14:29:59] <tonyhansen> barry: will have update to imap sieve and corresponding sieve environment draft by end of year
[14:30:09] --- Lisa has left: Logged out
[14:30:23] <Glenn Parsons> IMAP SIEVE Christmas present...
[14:30:34] <tonyhansen> alexey: ned was also talking about sieve environment, so ned and barry need to talk
[14:31:32] <tonyhansen> pete: do folks want catenate go around after profile bis is done? (would be a milestone to check off quickly, after imap url)
[14:32:04] --- kmurchison has left
[14:32:07] <tonyhansen> chris: needs to delete a clause from url
[14:33:11] <tonyhansen> burl, not url
[14:33:14] --- cromwellian has left
[14:33:14] --- randy has left: Logged out
[14:33:33] --- aaronstone has left
[14:33:39] --- harald has left
[14:33:40] --- hardie@jabber.psg.com has left
[14:33:41] <tonyhansen> dorothy: lemonade bis by june? yes
[14:33:45] --- cyrus_daboo has left
[14:33:50] --- cnewman@jabber.org has left: Logged out
[14:33:53] --- resnick has left
[14:34:05] --- Alexandros Vellis has left
[14:35:02] <Glenn Parsons> ....and to all a good ngiht.
[14:35:18] <arnt> Glenn Parsons: I think you and eric do a fine job chairing, really.
[14:35:45] <arnt> (this apropos the comment that it would be nice to tick off a milestone)
[14:35:52] <arnt> have a nice day.
[14:35:54] --- arnt has left
[14:36:24] --- alexeymelnikov has left
[14:42:10] --- tonyhansen has left: Replaced by new connection
[14:42:44] --- kmurchison has joined
[14:59:03] --- Glenn Parsons has left
[15:20:21] --- alexeymelnikov has joined
[15:28:00] --- kmurchison has left
[16:03:44] --- pguenther has left
[16:04:14] --- alexeymelnikov has left
[16:36:51] --- avel has joined
[16:37:37] --- avel has left