[07:21:09] --- sftcd has joined
[07:21:28] * sftcd has set the topic to: DKIM Meeting today (200609231) at 1500 UTC
[08:30:27] --- sftcd-at has joined
[08:30:27] --- dcrocker has left: Lost connection
[08:30:27] --- sftcd has left: Lost connection
[09:09:49] --- jpope has joined
[09:11:19] <jpope> <admin> ... just doing a status check. looks like things are ok.
[09:14:33] <sftcd-at> hiya -
[09:17:02] <jpope> Hi ... just saw some email from Stephen Farrell, said he was having some problem connecting, so I wanted to check on the room/server
[09:17:20] <jpope> Looks like "all is well".
[09:17:38] <sftcd-at> This is he. I had to create a new a/c since the jabber.org server seems down, but the ietf.org part is fine.
[09:18:15] <sftcd-at> Thanks for checking.
[09:18:41] <jpope> ah ... just saw your latest email. see you later.
[09:18:51] <sftcd-at> Bye
[09:18:54] --- jpope has left
[09:26:32] --- pigdog has joined
[09:40:41] --- sftcd-at has left: Replaced by new connection
[09:40:41] --- sftcd-at has joined
[10:00:03] * sftcd-at has set the topic to: DKIM Meeting today (200609231) at 1500 UTC (about an hour)
[10:00:18] <pigdog> good afternoon
[10:00:24] <pigdog> this is eliot
[10:02:20] <sftcd-at> Hi Eliot
[10:02:35] <sftcd-at> How's the new arrival getting on?
[10:03:04] <pigdog> very well thank you. hopefully in a few weeks she'll be listed in the Irish Foreign Births Registry, even.
[10:03:09] <pigdog> Lots and lots of paperwork
[10:03:32] <sftcd-at> Didn't know there was one. I can imagine the paperwork these days though.
[10:03:42] <pigdog> healthy happy, and like any father i can go on endlessly, boring absolutely everyone around me to tears.
[10:03:56] <sftcd-at> ah but there's only me for now:-)
[10:04:24] <pigdog> true, so i'll bore you. yes, our child is entitled to Orish citizenship. as well as American and British.
[10:04:27] <pigdog> sorry- Irish
[10:04:42] <pigdog> we had our first paperwork fiasco when she was but 2 hours old.
[10:04:52] <sftcd-at> Oirish is the British way to say it:-)
[10:05:10] <pigdog> on the little green form they give you here, we indicated her name, which is Joanna Máire. Guess which part they mucked up?
[10:05:45] <sftcd-at> I didn't know that this jabber client could do fadas until now funny enough
[10:06:20] <pigdog> well, surprise! but that wasn't it. they changed the e to an a. Joanna's great grandmother was a scholar on the language, and so we wanted to get it just right.
[10:07:08] <sftcd-at> Máira ?? never heard of that as a name - just a typo I guess
[10:07:14] <pigdog> i should mention i've had a second request from frank ellerman to move the issues list off of psg.com because of SSL problems. i am willing to consider this AFTER the end of the year if we're still going on.
[10:07:40] <sftcd-at> sure - I'm happy to go with whatever you prefer (what SSL problems?)
[10:07:43] <pigdog> yes, they CORRECTED her spelling. i spent an hour running all over the hospital to get it corrected, before the paperwork got to the government
[10:08:02] --- tonyhansen has joined
[10:08:04] <pigdog> beats me what the issue is, but i'm not in a position to deal with it now
[10:08:11] <pigdog> good morning tony
[10:08:23] <sftcd-at> could be worse - I used to work with a Gobait Ni Aonghusa and can't even recall where her fadas were!
[10:08:24] <tonyhansen> top of the day to you too
[10:08:25] <sftcd-at> hi Tony
[10:08:42] <pigdog> ha!
[10:09:08] <sftcd-at> what SSL problems with rt.psg.com?
[10:09:10] <tonyhansen> I was also using jabber.org for my login and just set up another login path
[10:09:22] <tonyhansen> I'll be back in 45
[10:09:22] <pigdog> hang on i'll forward you the note
[10:09:39] <sftcd-at> yeah PITA but I guess we all get the chance to invent new personae (see how inventive I was:-)
[10:10:07] <pigdog> in switzerland they can veto a name, too. but they're not supposed to "correct
[10:10:10] <pigdog> it"
[10:10:12] <tonyhansen> or me -- no imagination at all! :-)
[10:10:17] --- tonyhansen has left
[10:10:40] <pigdog> i'll be quiet for a while. doing some perl hackery
[10:11:14] <sftcd-at> later
[10:13:41] --- wildcat has joined
[10:14:04] --- wildcat has left
[10:14:19] * sftcd-at has set the topic to: DKIM Meeting today (200609231) at 1500 UTC (about 45 mins)
[10:14:30] * sftcd-at has set the topic to: DKIM Meeting today (20060921) at 1500 UTC (about 45 mins)
[10:14:57] --- santosh has joined
[10:16:16] --- santosh is now known as ssi-miami
[10:36:55] * sftcd-at has set the topic to: DKIM Meeting today (20060921) at 1500 UTC (about 20 mins)
[10:37:41] --- arvelh has joined
[10:38:10] --- arvelh has left
[10:48:07] --- ssi-miami has left
[10:51:40] * sftcd-at has set the topic to: DKIM Meeting today (20060921) at 1500 UTC (about <10 mins)
[10:57:59] --- dcrocker has joined
[10:59:28] * sftcd-at has set the topic to: DKIM Meeting Starting
[10:59:35] <sftcd-at> Hi all (or rather, few)
[10:59:46] --- wildcat has joined
[10:59:46] <dcrocker> selamat pagi
[11:00:00] --- arvelh has joined
[11:00:01] <pigdog> grüezi
[11:00:12] <arvelh> hi folks
[11:00:12] <sftcd-at> Agenda: #1 agenda bash (2 min) #2 ssp-reqs issues and requirements (50) #3 further jabber session logistics (5) #4 AOB
[11:00:13] --- tonyhansen has joined
[11:00:30] --- wildcat is now known as santosh
[11:00:43] <sftcd-at> Let's agenda bash. Anyone?
[11:01:00] <pigdog> we're missing the authors
[11:01:04] <arvelh> lol
[11:01:16] <pigdog> hang on...
[11:01:21] <pigdog> will try to reach them
[11:01:25] <sftcd-at> Yep. Probably the jabber.org problem. We can slow-start I guess.
[11:01:28] <sftcd-at> Thanks Eliot
[11:01:56] <sftcd-at> Barry may be unavailable today also.
[11:02:20] <sftcd-at> So no one here has any ogther agenda items...going..going...
[11:02:29] <sftcd-at> Gone.
[11:02:31] <dcrocker> why would we want to repeat postings, exponentially less frequently?
[11:02:37] <pigdog> mike's having trouble getting in
[11:02:43] <pigdog> might be a little bit
[11:03:02] <sftcd-at> Dave; less of anything might be a plus with this list
[11:03:13] <dcrocker> except pragmatics.
[11:03:19] <sftcd-at> indeed.
[11:03:49] <sftcd-at> While we're waiting. I was thinking of doing this each week for 3-4 weeks to try to finish ssp-reqs before San Diego
[11:04:05] <sftcd-at> Any thoughts? (But I'll say that again at the end of the hour)
[11:04:05] --- john.levine has joined
[11:04:58] <sftcd-at> If you want to do some reading while Mike gets connected, there are twelve entries in the tracker for now and two late posts to the
[11:05:03] <sftcd-at> list
[11:05:03] <dcrocker> however long it needs to go, now that we have a) a draft, and b) issues about the draft, then having regular jabber sessions to try to resolve them seems likea good idea.
[11:05:32] --- john.levine has left
[11:05:34] --- john.levine has joined
[11:05:40] <pigdog> mike is trying in earnest. he's not managed with either jabber.org or gmail. we're trying psg, which is what i'm connected through
[11:06:05] <arvelh> I'd like the San Diego meeting to focus more time on the actual SSP proposals so if we could get the req stuff done before that would be good IMO (but what do I know)
[11:06:32] <sftcd-at> Arvel: yes, that's the plan.
[11:06:33] <pigdog> wow. i could hear a pin drop on that point, arvel
[11:07:50] <pigdog> still working on it
[11:08:08] <sftcd-at> Ok. If Mike doesn't appear in the next couple of mins, we may as well forge ahead. If we have to revisit stuff for that reason, then we do it.
[11:09:09] <pigdog> sorry for the delay... still working it
[11:09:13] --- fenton has joined
[11:09:26] <fenton> (whew, finally)
[11:09:38] <sftcd-at> Hi Jim - we're hoping Mike's just behind you on the way in?
[11:09:47] <fenton> I got a local IM from Mike, he's working on getting in.
[11:10:20] <sftcd-at> All right. Let's start (1st couple are not biggies anyway I hope)
[11:10:32] <sftcd-at> First one in the tracker is #1201: change the syntax from SPF compat to human compat
[11:11:07] <sftcd-at> Thoughts on that?
[11:11:50] <fenton> I find the SPF syntax rather non-intuitive, I think it would reduce deployment errors for the syntax to be friendlier
[11:12:17] <dcrocker> +1
[11:12:21] <pigdog> [this was opened by mark delaney, who is also not present]
[11:12:23] <arvelh> no fundamental objection other than inertia - we've already got some level of deployment using the current syntax but very small and not a problem to change it
[11:12:28] <dcrocker> do we have a proposed alternative?
[11:12:40] <fenton> see allman-02
[11:12:56] <dcrocker> what do folks think of it?
[11:13:08] <sftcd-at> Jim: Can you quote the bit you mean?
[11:13:15] --- tonyhansen has left
[11:13:18] <fenton> let me find it.
[11:14:05] <santosh> ssp-02 has only two keywords UNKNOWN and STRICT
[11:14:12] --- thomasm has joined
[11:14:23] <sftcd-at> Welcome Mike.
[11:14:30] <arvelh> unknown all and strict
[11:14:33] <fenton> It's in section 4.2 , an example would be "p=strict"
[11:14:34] <arvelh> sec 4.2
[11:14:52] <sftcd-at> Ok - can someone craft a requirements-like statement about human-friendly syntax?
[11:14:57] <santosh> Sorry, right, ALL, STRICT and UNKNOWN
[11:15:31] <arvelh> I can do it and send to Mike if you want
[11:15:32] <thomasm> is there really a need to get to that fine of detail with the requirements?
[11:15:36] <fenton> Stephen: Do you want a statement or a volunteer?
[11:15:45] <sftcd-at> Arvel has volunteered.
[11:16:11] <sftcd-at> So we can CLOSE 1201 and Arvel will propose a sentence about human-friendly syntax that the WG can adopt or not
[11:16:42] <arvelh> ok
[11:16:46] --- tonyhansen has joined
[11:16:57] <sftcd-at> No objections?
[11:17:07] --- john.levine has left
[11:17:15] <arvelh> Mike mentioned that this might be too fine a point for req doc
[11:17:24] <santosh> None here.
[11:17:38] <tonyhansen> there have been several proposals with alternative syntax to o=.
[11:18:05] <tonyhansen> Ipersonally don't find STRICT any more intuitive than o=. though.
[11:18:09] <santosh> DSAP uses a ALWAYS, NEVER, OPTIONAL on two axis, 1st and 3rd party.
[11:18:11] <thomasm> me either
[11:18:24] <sftcd-at> Ok. Let's move on then.
[11:18:25] <sftcd-at> #1217: SSP: hould we drop the cryptic o=. syntax for something a little more readable?
[11:18:29] <thomasm> they both require a good deal of explaination
[11:18:58] <tonyhansen> the DSAP axes are based on suggestions on the list from a couple years ago
[11:19:32] <thomasm> at least with the cryptic values, you don't make the mistake of intuiting what you think it means
[11:19:46] <tonyhansen> obscurity is not useful
[11:19:55] <sftcd-at> Folks - we don't need to discuss specific syntaxes at this stage.
[11:20:09] <santosh> If anything, there is going to be alot of communications early on what policies are required, so the more layman the better.
[11:20:19] <tonyhansen> sf: nope, but direction
[11:20:26] <santosh> +1
[11:20:37] <fenton> I thought for a while whether to define one or two axes, decided on one because it avoided combinations that didn't make sense.
[11:21:29] <santosh> True, but it exposes all the possibilities and I was hoping from there we can eliminate the combos.
[11:22:15] <thomasm> what's next?
[11:22:29] <sftcd-at> An easy one: #1356: What is the purpose of SSP?
[11:22:39] <sftcd-at> Dave - do you want to speak to this?
[11:22:42] <pigdog> i'm sorry- resolution on 1217 is?
[11:22:52] <sftcd-at> same as 1201 - is there a difference?
[11:23:22] <santosh> I don't see the diff.
[11:23:30] <dcrocker> o
[11:23:32] <pigdog> ok, so i close 1217 as a doop
[11:23:37] <sftcd-at> Good.
[11:23:48] <dcrocker> steve, i'm not sure what i'm supposed to speak. my posting presented the issue.
[11:23:49] <pigdog> done
[11:24:02] <arvelh> Dave
[11:24:24] <sftcd-at> Dave: Fair enough. Personally I didn't quite follow your text, let me see...
[11:24:24] <santosh> What do you guys call this?? - a rat hole? <g>
[11:24:30] <arvelh> Dave's statement was good starting point on the list I thought
[11:24:32] <thomasm> what I'm trying to understand if there is One purpose of ssp which can be stated consicely
[11:24:59] <thomasm> that and I'm not sure if it's really the right place in the requirements per se
[11:25:50] <arvelh> IMO: SSP is a mechanism through which a domain owner can advertise whether and to what extent a first party DKIM signature should or shouldn't be expected. Somethign like that anyway.
[11:26:02] <dcrocker> thomas, how can we specify requirements details if we do not, first, have a basic framework for them?
[11:26:32] <santosh> I see it as simply a way to detect the consistency of the DKIM-BASE process or lack there of.
[11:26:33] <thomasm> well, that's what the scenarios are attempting to do... is put the set of desires into some context for the requirements
[11:26:44] <dcrocker> arvel, I think your statement is entirely reasonable. however i think it keeps us in a problematic place, namely failing to worry about what the receive-side is actually interested in.
[11:27:23] <santosh> There has to be a value in processing DKIM-BASE.
[11:27:36] <arvelh> yeah, I do see that but I don't see it as so big a problem as you (and others do) - but I do see it
[11:27:57] <sftcd-at> So, maybe we should park this issue for now and move on?
[11:28:03] <santosh> +1
[11:28:17] <thomasm> well, the one thing this brings up is whether the current draft is even structured right
[11:28:35] <thomasm> are you having a problem with that Dave, or is this an additional thing?
[11:28:42] <sftcd-at> fair question
[11:28:48] <fenton> I think we do need an explanation of the problem statement in the reqts draft
[11:29:00] <arvelh> we do need a statement in the req draft - yes
[11:29:11] <santosh> The TA has a very good statement for SSP.
[11:29:20] <dcrocker> problem with what, steve?
[11:29:54] <thomasm> I think you meant me dave, but I meant do you have a problem with the current structure of the draft?
[11:30:01] <sftcd-at> Dave: Mike asked whether your suggested text just needs to be added in near the start or whether...
[11:30:10] <sftcd-at> ...you think a broader restructuring is needed
[11:31:57] <dcrocker> the issue i raised was intentionally narrow, albeit with potentially broad impact. i was not trying to make suggestions about the document structure.
[11:32:15] <sftcd-at> (that pause had me worried:-)
[11:32:21] <arvelh> lol
[11:32:29] <dcrocker> anyhow, if folks are happy with my suggested text, then adding it is fine.
[11:32:39] <sftcd-at> So, how about we keep this issue open for now and work that text on the list for next time?
[11:32:43] <dcrocker> (the pause was from typing too much and then deleting most of it.)
[11:33:02] <sftcd-at> So, 1356 stays OPEN.
[11:33:07] <thomasm> I'd vote for thinking about it a bit...
[11:33:20] <sftcd-at> Next is: #1357: SSP: Clarity among the usage scenarios
[11:34:02] <sftcd-at> (I like the idea of crisp names/tags for scenarios btw)
[11:34:12] <fenton> +1
[11:34:25] <santosh> I think it is too simple and too narrow.
[11:34:50] <sftcd-at> Santosh: not clear what you mean there
[11:35:17] <fenton> I would like to see more clarity in the "bigbank" scenario that it includes expectations of no signature breakage
[11:35:28] <santosh> Well, FWIW, I don't see why the scenarios play a vital role in this protocol.
[11:35:36] <santosh> Too easy to get locked into.
[11:35:41] <arvelh> Dave asked what is the diff between Scen 1 and 2 - is it that 1 expects no breakage and 2 does?
[11:35:54] <dcrocker> On reflection, I suggest having both a label and a one-sentence description of the purpose of the example. That is, why is the scenario and interesting example?
[11:35:55] <thomasm> yeah, that was the intent Arvel
[11:36:18] <arvelh> ok, some text to make that clearer would probably deal with this issue then.
[11:36:23] <sftcd-at> That make sense to you Dave?
[11:36:30] <dcrocker> re: breakage. oh boy. i really did not get that distinction.
[11:37:31] <sftcd-at> But if that were made clear, then we could close the issue, right?
[11:37:33] <dcrocker> steve, sure, depending on what the new text(s) are.
[11:37:38] <sftcd-at> Of course.
[11:37:55] <pigdog> who's writing the new text?
[11:38:15] <sftcd-at> So for now: 1357 is CLOSED modulo Mike clarifying that 4.2 differs from 4.1 in terms of expected breakage
[11:38:26] <dcrocker> I'm glad to talk with Mike offline, to wordsmith them.
[11:38:33] <sftcd-at> Excellent.
[11:38:34] <thomasm> sounds good dave
[11:38:38] <sftcd-at> Moving on then:
[11:38:50] <dcrocker> Steve, closing an item makes sense when it is resolved, not when there is agreement to resolve it.
[11:39:25] <sftcd-at> Fair enough. So s/is CLOSRD/will be CLOSED/
[11:39:39] <sftcd-at> #1358: ssp-requirements-01 // DKIM Strict definition needed.
[11:39:47] <sftcd-at> Can we do this with no Doug?
[11:39:54] <arvelh> Doug proposed a definiton "STRICT" - isn't this "SIGNING COMPLETE" as already defined?
[11:40:09] <arvelh> wait...
[11:40:29] <arvelh> maybe not because Doug says this: "and that non-compliant services are avoided"...
[11:40:31] <thomasm> as I mentioned in my mail, I tried to avoid terms that caused confusion before
[11:40:36] <fenton> No, Doug meant STRICT as in sec 4.2 of allman-ssp-02
[11:40:37] <arvelh> does that mean "no breakage allowed"?
[11:40:47] <fenton> Arvel: correct
[11:41:21] <fenton> Mike's document consistently uses 2 axes, practices and expectations
[11:41:34] <fenton> and I think it's good to be consistent in that
[11:41:47] <sftcd-at> Do we have some support for this new/additional definition or not?
[11:42:02] <thomasm> I don't see it being any different that scenario 1
[11:42:03] <fenton> So I wouldn't define STRICT, which is a "one axis" definition at odds with the rest of the document
[11:42:16] <arvelh> It's scenario 1
[11:43:06] <sftcd-at> Can we get a clear +1 (for adding Doug's definition) or -1 (for not adding it).
[11:43:13] <thomasm> -1
[11:43:17] <arvelh> -1
[11:43:18] <santosh> -1
[11:43:28] <fenton> -1
[11:43:33] <sftcd-at> Thanks.
[11:43:56] <sftcd-at> And does anyone like the 2nd change proposed in 1358?
[11:44:18] <sftcd-at> I'll take that as a no then.
[11:44:43] <sftcd-at> So 1358 is CLOSED/REJECT as far as this group goes anyway.
[11:45:02] <pigdog> ack.
[11:45:02] <sftcd-at> Moving on...
[11:45:10] <sftcd-at> #1359: ssp-requirements-01 // Outsource First Party Signing concerns extended
[11:46:03] <dcrocker> -1
[11:46:14] <arvelh> this doesn't need to be in reqs unless we agreed that abuse reporting is a core requirement - it's not AFAIK
[11:46:32] <sftcd-at> That goes to the hub of it arvel
[11:46:39] <santosh> This is a contractual issue between the 1st party and whoever else he outsources with.
[11:46:43] <dcrocker> more generally, do we need to worry about any particular types of replay attacks. i say no.
[11:46:56] <thomasm> yeah, that's the first I've heard of anybody wanting that
[11:47:26] <sftcd-at> I'm not sensing support for this change then.
[11:47:34] <arvelh> lets leave relationships between the domain owner and their partners as a thing to be dealt with between them
[11:48:20] <sftcd-at> So 1359 is another CLOSED/REJECT then. Ok?
[11:48:25] <dcrocker> +1
[11:48:28] <thomasm> +1
[11:48:32] <arvelh> +1
[11:48:40] <sftcd-at> Moving on...
[11:48:44] <santosh> +0.9
[11:48:48] <santosh> <g>
[11:48:54] <sftcd-at> #1360: ssp-requirements-01 // Designated Signing Domain Scenario missing
[11:49:15] <dcrocker> i'm not understanding this one.
[11:49:19] <fenton> This defines an implementation, not a requirement
[11:49:58] <arvelh> This is the designated signer list issue really
[11:50:11] <sftcd-at> (Doug mailed the list. He can't connect.)
[11:50:30] <arvelh> should there be a requirement that SSP provide a means through which a receiver can determine who is and isn't a valid signer on behalf of the domain.
[11:50:34] <santosh> +1 with Arvel
[11:50:39] <arvelh> that is teh question with this issue
[11:51:08] <thomasm> well there already is a scenario for that, and a provisional requirement for it as well
[11:51:10] <dcrocker> 1. do we have an indication from the receiver community that they need to make the distinction arvel is requesting?
[11:51:17] <fenton> Arvel's description is good.
[11:51:22] <arvelh> I'm not requesting - just explaining
[11:51:25] <dcrocker> 2. what does it mean to have a valid signature that is not "authorized"?
[11:51:44] <dcrocker> s/requesting/describing/
[11:51:48] <arvelh> lol
[11:51:59] <santosh> We develop SMTP software, so that include me too - yes, dave. we need it IMO.
[11:52:24] <thomasm> hold on a bit here... I think there are two issues floating around here
[11:52:50] <thomasm> one is doug's new text, and the second is whether we accept that provisional requirement in the draft at all
[11:52:55] <dcrocker> receiver-side refers to operators of services, not implementors of software. as for "receiver community" I am hoping that it is a tad larger than the few operators present in the working group, nevermind present in this session.
[11:53:19] <sftcd-at> (I'm happy that we discuss this further but we're coming up on 55 mins. Do we go over or stop at the hour? I can stay for another 10 mins only.)
[11:53:31] <thomasm> if we can tackle the doug issue first -- that is, is it distinct from what's in the draft, we can later decide what's in the draft
[11:53:48] <fenton> My biggest concern with the form of delegation one would get through SSP is that it has different semantics from the delegation mechanisms present in -base
[11:53:53] <sftcd-at> Mike: I agree with you there
[11:54:08] <santosh> dave, implementators of software do not just do what they want - they have to please operators as well.
[11:54:09] <arvelh> Jim: yes it does
[11:54:30] <dcrocker> i suspect we have a very basic issue about "delegation" and that we should reach some basic agreements about the concept, before we try to specify any detailed requirements.
[11:54:59] <sftcd-at> I agree delegation is basic (and subtle) so I don't want us to decide this in a rush at the end of the session.
[11:55:16] <thomasm> stephen: right... this is a big issue
[11:55:33] <sftcd-at> Can I suggest we keep 1360 as OPEN for now and have it at the top of the list next time?
[11:55:33] <dcrocker> if i get a message with a valid signature, i will evaluate the associated domain name. the concept of 'authorization' seems to require that i first decide whether pay attention to the signature. why do we believe that the receive-side operational community will agree with this model?
[11:55:55] <santosh> +1 Stephen
[11:56:20] <tonyhansen> keep open +1
[11:56:25] <sftcd-at> Which brings us to agenda item 3 - logistics etc.
[11:56:29] <arvelh> +1 to table this issue for now - lets try to get a couple more done before steven has to go
[11:56:39] <sftcd-at> I propose we do this again same time next week.
[11:56:45] <thomasm> works for me
[11:56:49] <pigdog> sounds like a plan
[11:56:50] <arvelh> fine by me
[11:56:57] <sftcd-at> Do we want 60 or 90 minutes?
[11:57:13] <pigdog> 60 works better for your secretary
[11:57:18] <santosh> Plan for 90
[11:57:26] <tonyhansen> can always finish early :-)
[11:57:27] <sftcd-at> 75 then.
[11:57:32] <pigdog> ;-)
[11:57:41] <dcrocker> no, 90.
[11:57:41] <fenton> next week works for me, I'm fine with 90.
[11:57:51] <thomasm> however long is ok with me
[11:58:03] <pigdog> ok, i'll review the last 30 minutes and take actions accordingly as long as they're markeed well
[11:58:09] <sftcd-at> 90 seems more popular all right.
[11:58:09] <arvelh> I'll be in a bar with wireless anyway so I can take all day if it comes to that... ha ha
[11:58:32] <sftcd-at> That's all I had I think. Was there any other business?
[11:58:33] --- pk has joined
[11:58:55] <fenton> Peter, I think you just missed the meeting
[11:59:08] <pigdog> ciao guys
[11:59:16] <fenton> Thanks, Eliot
[11:59:18] <pk> thanks, Jim
[11:59:20] --- pigdog has left
[11:59:25] <tonyhansen> ta ta
[11:59:26] <arvelh> thanks all and looking forward to San Diego
[11:59:35] <sftcd-at> Ok so. Let's call it a day. Thanks all and type to you next week.
[11:59:40] <sftcd-at> Bye.
[11:59:47] --- pk has left
[11:59:54] --- tonyhansen has left
[11:59:59] <santosh> adios - I'm going fishing :-)
[12:00:07] --- santosh has left
[12:00:23] <dcrocker> eliot, yes, many thanks.
[12:01:07] --- dcrocker has left
[12:01:15] --- arvelh has left
[12:01:25] --- sftcd-at has left
[12:03:22] --- wildcat has joined
[12:03:40] --- wildcat has left
[12:05:50] --- thomasm has left
[12:19:50] --- fenton has left
[16:52:34] --- wildcat has joined
[16:56:36] --- wildcat has left