Pre-Meeting ============ 13:28 < FrePort> Five minutes to start time. Smoke 'em if you gotta 'em (legal restrictions of your relevant countries apply) 13:28 < n1ko> That's no fun :( 13:28 < alias> soo... what am i smoking? 13:31 * alias is sick of this 12.1" laptop screen. can't code and irc at the same time 13:32 < mds> so smoke your laptop ;-) 13:32 < FrePort> No-one quite imagined when they dreamed up multitasking that real-estate would apply. 13:33 * FrePort times the meeting start by the commercials on CNN. 13:34 < FrePort> Not the world's most accurate measure, but the atomic clocks are /.ed. Meeting ========= 13:37 * FrePort_ bangs the gavel. 13:38 < FrePort_> Hear ye, hear ye. Quit your grinnin' and drop your linens. The fourth dog-auth-wag meeting is called to order. 13:38 < alias> hi. 13:38 < mds> Aye! Aye! 13:39 < FrePort_> Present are alias FrePort mds n1ko and raciel. 13:39 < FrePort_> Anyonelse present? 13:39 < FrePort_> The usual moderator fitzix is absent today and has asked me to chair the meeting. 13:40 < FrePort_> Our schedule will be modified as a result. 13:40 < FrePort_> Official business for today as follows: 13:41 < FrePort_> Return on investment was tabled from week 1 and 2. MDS will present and a free-form discussion will follow. Preferrably one on topic. 13:42 < n1ko> hehe 13:42 < FrePort_> More debate over the integration diagrams (freport, mds) with a focus on integrating MACS and Freport into a cohesive whole. 13:43 < FrePort_> Pending the arrival of member antifa we will also discuss his latest list of webservices that can be targetted for DotGNU Auth. 13:43 < FrePort_> But first... Introductions -------------- 13:44 < FrePort_> New members should introduce themselves. Explain who you are, what your skills are, and why you showed up today. 13:44 < FrePort_> n1ko: you're first. 13:45 < n1ko> I'm n1ko. I'm helping out qith qtcsharp. I'm a C, Java, and C# programmer. I'm here mostly to watch and listen. 13:46 -!- kiwnix [kiwnix@evolucion.tsps1.freenet6.net] has joined #dotgnu-auth 13:47 -!- kiwnix [kiwnix@evolucion.tsps1.freenet6.net] has left #dotgnu-auth ["Aplicación Saliendo"] 13:47 < FrePort_> Raciel... your turn 13:48 < alias> i can go 13:48 < alias> if you want 13:49 < FrePort_> go ahead alias... 13:49 < alias> i'm alias. I'm mainly working on vrs, but am very interested in working in auth also. hopefully i can contribute. freport and i are looking at maybe using macs@freport in vrs. i do java and C/C++ mainly. i'm pretty good at networking, os stuff, and security. 13:49 < alias> and complaining about my 12.1" screen 13:50 < FrePort_> Okay... assuming raciel has taken a pass. We'll move onto the first order of business. 13:50 < raciel> hi all! I am raciel and currently I am working in some developments with gnome. I am learning C# and i am a C and Python programmer, I know GTK and i would like to center in GTK# and C# development. I am here to listen and learn of us :) 13:50 < FrePort_> Cool, that's everyone then. Return on Investment (ROI) --------------------------- 13:52 < FrePort_> Okay. First order of business mds, founder of the MACS project is presenting on the topic of Return on Investment. We're all pledging our code or time to DotGNU and auth in particular and MDS wishes to explain who our work may be later commercialized. 13:52 < FrePort_> Please hold questions until the end. 13:53 * FrePort_ yields the floor to mds. 13:53 < mds> thank you. 13:53 < mds> ROI: Return on Investment: The amount of time it takes for the benefits of a system to outweigh its costs. 13:53 < mds> Usually important, but critical with emerging technologies because of the short lifecycle. 13:53 < mds> (If ROI takes 2 years, will the system still be even running in that time?) 13:54 < mds> Rapid ROI lessens the risks of adopting new technologies. 13:54 < mds> Free Software has a big advantage here, since it generally starts out with low implementation costs. 13:54 < mds> The higher cost of ownership of Free Software is mostly FUD, but it's non-trivial to get the numbers we need to make convincing anti-FUD. 13:55 < mds> Why do we care? If for no other reason, then because it tells us if we're wasting our time. 13:55 < mds> ROI affects us the same way it affects business -- if a system's ROI is too slow (or negative!) then we're better off without it. 13:55 < mds> In the interests of full disclosure, I'm trying to make money by selling implementation and support of macs. 13:55 < mds> A good ROI argument would help me bunches, as well as DotGNU. 13:56 < mds> It's just something we have to know, at least in estimate. 13:56 < mds> Near as I can tell, there are three variables involved: 13:56 < mds> Costs, including implementation, integration, maintenance, upgrades, and operation. 13:56 < mds> These are relatively easy to determine beforehand. 13:56 < mds> Savings, including reduced or delegated account provisioning and administration. 13:57 < mds> These can be guessed at, but they're different in each situation, sometimes drastically so. 13:57 < mds> New or Enhanced capabilities, including single sign-on, account self-management, portable identities. 13:58 < mds> It's hard to clearly point these out for flexible systems that are flexible and versatile (like Identity.) Also, their worth is hard to nail down. 13:59 < mds> I guess that's about it for the introduction. I yield the remainder of my time to the chair. 14:00 < FrePort_> ?me takes his seat. 14:01 < FrePort_> Okay, questions? (I have a few but I'll yield to anyone) 14:01 * n1ko shakes his head. 14:03 < FrePort_> mds: so, your basic point is that we have to lower the end user cost, to lower our time on ROI? 14:03 < mds> lower the end user cost, raise the end user's savings, and give valuable new capabilities 14:04 < FrePort_> Okay, how do we deal with each of these aspects? (your opinion) 14:05 < FrePort_> And how do we fight the perception that one can do this by combining Kerberos over cookies with LDAP? 14:05 < mds> Well, it's not so much "deal" with them, as show or explain them. 14:05 < mds> So, we answer the three-part question. 14:06 < mds> Dog-wagging saves you time and effort 14:07 < mds> Dog-wagging gets you new capabilities. 14:07 < mds> Dog-wagging costs you 14:08 < FrePort_> Other methods cost you T H I S M U C H! 14:08 < mds> The answers to these things seem obvious to me, but I'm not very good at phrasing them in a way non-techies will appreciate. 14:08 < mds> FrePort_: yes, that too. =) 14:10 < FrePort_> So, we need to translate Valspeak (geek-speak, it's a generational thing) into POE (plain olde English). 14:10 < mds> Yes. I call it "Wrapping the truth in lies." 14:10 < mds> The dictionary calls is "marketing." 14:11 * FrePort_ chuckles 14:11 < mds> The thing is, most people call it "an explanation." 14:12 < FrePort_> or a "business case". :-) 14:12 < mds> Yes! That's precisely what it is. A convincing business case. 14:12 < mds> Though for a broad interpretation of "business" 14:14 < FrePort_> Okay. So, do you have a Valspeak write-up of your ideas of what we need to prove? We could iterate that to turn it into a convincing business case and perhaps from there make marketting materials. 14:15 < mds> umm. Not offhand. I haven't been thinking about this for very long. 14:15 < mds> Been spending most of my time trying to make good in code, first. 14:16 < FrePort_> Always important. I think we might have to ask fitzix to brainstorm about this... He has a talent for making BC statements. 14:17 < mds> Good idea. 14:17 < mds> I move to have me come up with some valspeak and have fitzix come up with some poe, for next week or so. 14:18 < FrePort_> Once we've got some compelling numbers and statements, Angel (my team), myself, and a few others are quite capable of translating it into marketting terms. 14:19 < mds> Though the actual end-product marketting can (should?) wait for the code, thinking about it a little throughout the process makes for better material afterwards. 14:19 < mds> Great. 14:20 < mds> I'm satisfied, then. 14:20 < mds> Next topic? 14:20 < FrePort_> Not quite... 14:20 < FrePort_> Okay, so you want to make contact with fitzix and get started on that... for presentation in say, 1 month? 14:20 < mds> oh? 14:20 < mds> Sure, that's reasonable. 14:22 < FrePort_> I'll leave the contact point to you then. And we'll bring up next week the topic of extra help if you two find you need resources beyond yourselves. Iterate the ideas privately and post synopsis to the mailing list? 14:23 < mds> Done. I'll contact fitzix. Introductions (2) ------------------ 14:23 < FrePort_> Okay. That settled... we have two more participants who need to introduce themselves. I'm breaking order so they can. Any objections? 14:24 < dsevill4> well, I introduce myself 14:25 < FrePort_> hearing none. dsevill4. Inform everyone who you are, what you do, and why you're here. 14:25 < dsevill4> I am a PHD student on distributed component models, so this is my interest in .NET technologies 14:25 < dsevill4> but I am mostly oriented towards CORBA 14:26 < dsevill4> and the new CORBA component model 14:26 < dsevill4> that's it 14:26 < FrePort_> and we can assume you're here to lurk? 14:26 < dsevill4> yes 14:27 < FrePort_> Cool. Chillywilly? 14:27 < chillywilly> I am Daniel E Baumann member of the GNU Enterprise project...mainly I work on the application server...I am here to just hang around ;) 14:30 < FrePort_> Okay. Back to the order of meeting... Integration ------------ 14:31 < FrePort_> We're going to be discussing the integration diagrams, and along the way answering some general questions... 14:31 < FrePort_> You can find the integration diagrams at: 14:32 < FrePort_> Original MACS diagram - http://users.ids.net/~nightspd/freport/images/macs.dia 14:33 < FrePort_> Merged MACS@Freport diagram - http://users.ids.net/~nightspd/freport/images/macsfreport.dia 14:33 < FrePort_> These are in Dia 0.88 format. Does anyone need time to download them? 14:36 -!- kalahari [~lgm@dsl092-008-231.sfo1.dsl.speakeasy.net] has joined #dotgnu-auth 14:39 * FrePort_ shares the floor to mds and kalahari. 14:39 -!- absurdhero [~brandon@12-246-75-76.client.attbi.com] has joined #dotgnu-auth 14:39 < FrePort_> Kalahari produced the MACS diagram, which was used to produce the MACS@Freport dia. 14:39 < mds> kalahari and I are the main macs developers 14:40 < kalahari> yes, and it was a very hasty diagram at that 14:40 < FrePort_> and I'm the Freport team leader (uh-duh. :-) 14:40 < kalahari> but it is accurate 14:41 < FrePort_> and very clear to boot. Great job for 20 minutes of work. 14:41 < kalahari> hehe 14:41 < mds> Shall we assume that macs and FrePort are understood independently, or should we give a short summary? 14:42 < FrePort_> Summarize MACS first. I'll summarize Freport. 14:42 < mds> macs is the Modular Access Control System 14:43 < mds> Also, the Meta Access Control System 14:43 < mds> It's basic philosophy is to make available user and resource information from any number of distinct, independent user stores 14:43 < mds> in a centrally-managed way 14:44 < mds> So that we have (a) a set of core servers; (b) a set of information stores; and (c) a set of clients 14:45 < mds> the clients ask security and user information of the core servers, 14:45 < mds> which rely on the information in (b) to make decisions 14:46 < mds> kalahari: fair description, would you say? 14:47 < kalahari> yes 14:48 < FrePort_> Freport is basically trying to solve the same problems as MACS, and contains many equivalent components. 14:49 < FrePort_> The primary difference are the accents. Freport was designed specifically to protect both a user's data and transactional meta-data from mining by third parties. 14:49 < FrePort_> Thus Freport uses encryption on the clientside and data hiding through hashing extensively. 14:52 < FrePort_> A user should be able to choose their level of privacy and the degree to which they will submit to data mining. Although authentication is handled centrally, Freport allows the user to store authorization (permission to access data) and encrypted data, both locally or remotely. 14:52 -!- absurdhero [~brandon@12-246-75-76.client.attbi.com] has left #dotgnu-auth [] 14:54 < FrePort_> A user can store his authorization keyring and his data fully local, which is the most private; or he can choose to have either (or both) his authorization keyring and data stored remotely which allows limitted egrees of roaming. 14:54 < FrePort_> He only surrenders his privacy (freedom from mining) by the storing authority, by explicitely doing so. 14:55 < FrePort_> That's a good summation. Any questions? 14:55 < mds> So FrePort is more concerned with secure (possibly distributed) storage and retreival of user info, than with making decisions based on that info? 14:56 < mds> s/distributed/remote/ 14:56 < FrePort_> define "making decisions", please? 14:56 < mds> Determinind access permissions, essentially. 14:58 < FrePort_> Freport is only concerned with: 14:58 < FrePort_> 1) The user having access to their information 14:59 < FrePort_> 2) The user having paramount discretion to deny the storing authority access to this information 14:59 < FrePort_> 3) Allowing the user to retrieve this information and transmit it (through application built atop the system) to other applications. 14:59 < FrePort_> SO... 15:01 < FrePort_> I guess you could say that once the user authenticates as a certain role to Freport, they have access to all the information stored within that role, and the destination of the information is only limitted to "that's not stored for this role". 15:01 < FrePort_> I think the answer is "no, Freport isn't concerned with access permissions". It's a go/no-go based on the role. 15:02 < FrePort_> How does MACS set access permissions? 15:02 < kalahari> it doesn't really, it borrows them from other systems 15:02 < mds> And the go/no-go is for access to the user's info? 15:03 < kalahari> we do have an internal authorization database, but we also can plug into something else and use it's permissions as well 15:04 < FrePort_> kal: okay... 15:04 < FrePort_> mds: It's a little more fine grained than that. 15:04 < mds> FrePort_: does FrePort want to protect access to anything other that user information contained in FrePort? 15:07 < FrePort_> application specific data can also be protected. 15:07 < mds> no, that's if we want to protect the profile db with the ats 15:07 < mds> doh! wrong window 15:07 < FrePort_> "application profiles" as opposed to "user profiles" 15:07 < mds> FrePort_: I see. 15:08 < mds> macs is as interested in making decision based on information stored as with storing the information itself. 15:08 < FrePort_> If an application stores data within Freport under a given role, then that data will only be accessible to that application when the user is authenticated in that role at both the authmaster and the databank. 15:09 < FrePort_> basically, when i look at the two systems, the only difference I see is in the network topology, the control logic (yours is more robust), and in the data schema. 15:10 < FrePort_> and by schema, I mean that Freport encrypts and hashes extensively, whereas MACS doesn't seem to? 15:10 < kalahari> no it doesn't at all 15:10 < mds> not yet 15:10 < kalahari> save passowrds 15:11 < FrePort_> Can you give me an example (real world) of MACS "making a decision" (step by step)? 15:11 < kalahari> sure, I'll take this 15:11 < kalahari> all decicions are made around resources 15:12 < kalahari> so for example if our authorization data source is a file systems ACLs 15:13 < kalahari> the client asks the server for A permission on resource B, the server talks to the file system authz adapter 15:14 < kalahari> which maps resourc B onto one of it's file/directory objects, looks up the permission requested (based on the requesting user's roles/groups) ane returns the answer back via the same channel 15:17 < kalahari> the user's groups/roles whichever term you prefer, are determined by the authz adapter 15:17 < kalahari> by mapping a macs UID onto one of it's UIDs 15:18 < kalahari> although we have considered using a separate source of roles, the only problem is that it becomes harder to map them onto external data sources 15:20 < kalahari> but in the case where you wish build the permissions data yourself, macs provides a full set of services itself from a SQL back end 15:20 < FrePort_> backend is for an OS environment that doesn't use any ACL system? 15:20 < kalahari> we just place a high priority on interoperability with legacy systems 15:22 < FrePort_> Okay... this actually makes sense in a FrePort concept too. 15:23 < FrePort_> In Freport we'd define what you propose as a particular class of local authmaster and local databank. 15:24 < mds> in macs it's called a Method Service 15:25 < kalahari> s/Service/Adapter/ 15:25 < mds> aye 15:25 < FrePort_> Or if you built a stub at the local end to communicate with a remote gateway, which ran that local authmaster/databank; you'd have a remote service. 15:25 < mds> where the remote gateway is another Freport installation? 15:26 < FrePort_> Yes. 15:26 < FrePort_> basically your adapters are my plugins. 15:26 < mds> What if you'd like to have a remote gateway that's not a Freport installation? 15:26 < mds> (eg, an ldap store) 15:27 < FrePort_> then one would write a remote freport plugin for communicating with the LDAP store, HOWEVER... 15:28 < FrePort_> you'd need to make the LDAP store the lookup/value pairs that Freport expects to find. (we're netAPI agnostic, but demand that the data follow a certain convention) 15:28 < mds> couldn't the plugin munge the key/value pairs to fit Freport's requirements? 15:30 < FrePort_> possibly, but one would lose the privacy designed into Freport's network topology... that is: 15:31 < FrePort_> if the LDAP stores say the user's name in the clear, that would make the data minable, which defeats the purpose of Freport. 15:31 < mds> oh, I see. 15:32 <@ajmitch> morning all 15:32 < mds> It sounds like Freport would make for one kick-ass Method Adapter. Is that the idea? 15:33 < mds> ajmitch: howdy. Not the middle of the night for you anymore? =) 15:33 <@ajmitch> mds: decided that there was no point getting up at 5:30 15:33 < FrePort_> At least as I understand the concept of a method adapter, yes (conditionally). 15:34 < FrePort_> but to do it's magic Freport needs the implementation of a remote/local store (for authorization and data) AND a method of setting control logic. 15:35 * mds agrees with ajmitch. Which is why he lives in a reasonable timezone. ;-P 15:35 < mds> FrePort_: Method Adapters are completely in control of the data they present. 15:35 < mds> What control logic is necessary? 15:37 < FrePort_> Basically, the order of operations in Freport is different because the data must be en/decrypted and the access keys hashed. 15:37 < FrePort_> is different from MACS. 15:39 < FrePort_> That's all layed out in the storage and retrieval documents: 15:40 < FrePort_> retrieval - http://users.ids.net/~nightspd/freport/FrePort_Dataflow_Explanation_Retrieve.html 15:40 * mds takes a moment to look it over 15:40 < FrePort_> storage - http://users.ids.net/~nightspd/freport/FrePort_Dataflow_Explanation_Storage.html 15:41 < FrePort_> it's all text, but you'll be able to see where the various hashings and encryptions take place. 15:41 < FrePort_> These are all handled at the control logic level of the merged diagram? 15:41 < FrePort_> Why? 15:42 < FrePort_> Well, simply because they're central to the operation of Freport. One could move them down into the plugins, but at the cost of code repetition... 15:43 < FrePort_> moreover, since the plug-ins are not required to be GPL'd it was *very* important that they never be passed plain text, so that they couldn't cache data without the user's knowledge (say at a public terminal). 15:44 < mds> Is there anything in there that can't be done once the macs core hands a request for info to the Method Adapter? 15:44 < mds> I guess what I'm thinking of could be making a Module Adapter out of the Freport core box in the diagram. 15:44 < mds> err, Freport core, which lives in the SEE box, in the diagram. 15:45 < FrePort_> do you have my merged diagram handy? 15:45 < mds> With macs, even the "internal" methods are implemented as plugins -- the server core is interested only in mapping a user to her information in different methods. 15:46 < mds> yes, I'm looking at the merged diagram 15:49 < FrePort_> Basically, read "Freport/Server Core" as MACS@Freport Core" (I just talk the wording on the old diagram and threw Freport in front of it. Kala called it "server Core", so I did the same)... basically that core is the same as what is in Kala's diagram except... 15:50 < FrePort_> that I factored out the variations in the control logic, by making them internally loadable, and thus upgradeable. 15:50 < mds> Hmm. I see now. 15:51 < mds> There's a problem 15:51 < mds> macs aims to let folks use their information, no matter where it's stored. 15:52 < mds> If it's not stored in a Freport-compliant location, then having the control logic in front of everything could be a problem 15:52 < FrePort_> Hmmmm... let me think on that. Keep explaining. 15:53 < mds> Bu if the control logic were taught to understand that some data isn't "safe" to move around (like, say, a random LDAP store) then that would fix that problem 15:54 < mds> But I don't see any reason why, instead of making the Freport control logic smart (and complicated) enough to sit in front of all requests, 15:54 < mds> we can't let the control logic sit in front of only Freport-compliant requests, 15:55 < mds> by making the control logic a method adapter 15:55 < mds> a macs installation that wants to use only Freport-compliant (and therefore safe and private) data stores 15:55 < mds> can implement only the Freport adapter plugin. 15:56 < mds> Other sites can behave as they see fit, allowing users to give access to non-Freport compliant data sources, even though they're not safe and private. 15:56 < FrePort_> plugins technically, because Freport needs plugins at all three service layers. 15:57 < mds> Clear. What I'm suggesting is that Freport (in its entirety, pretty much) be fronted by the macs core -- 15:57 < mds> this would make Freport interoperable with any other data source that macs has an adapter for. 15:57 < FrePort_> freport would need a separate adapter for each of authentication, authorization, and data... 15:58 < mds> Yes. That's the way it works now. 15:59 < FrePort_> now, how would you propose to take care of the local and remote differentiaition. Freport needs it. Unfortunately implementing Freports subplugs under each adapter would sextuple the code required (all chant bloat, bloat, bloat) 16:00 < FrePort_> I like interoperability BTW... 16:01 < mds> Would it really make more code necessary? In the integrated diagram, 16:01 < FrePort_> And I think I might understand this a bit better if I knew the API between service and adapter as well as I knew the API between my core and plugins... 16:03 < mds> well, the API/protocol between pieces can be munged to fit needs, in as general a way as possible. 16:03 < mds> But changing protocols a bit won't kill us if we abstract it correctly.. 16:04 < FrePort_> In the integrated diagram I centralized all that code up at the control logic API and in the services. If I defactored all that down to below the services, then I would need one set of control logic for each of the adapters (3) and one set for remote and local at each adapter (6). Thus... about 6 times the code. 16:05 < kalahari> FrePort_: also, just because we have and authc, authz, and profile adapeter for a meothod, dosen't mean they all can't be the same thing, we just break them up logicly in the diagram 16:05 < mds> FrePort_: I see what you mean. 16:06 < mds> But I don't think it has to be that way. I'll have to think about it. 16:06 < mds> How about if I munge your integration diagram for next week? 16:06 < FrePort_> Also consider that you'd need Freport plugins to duplicate services already provided at the MACS level (like the elaboration on a bad dream); you'd need an adapter for LDAP, and at the Freport adapter a remote plugin, which would be identical for most intents and purposes... 16:07 < FrePort_> more bloat... 16:07 < FrePort_> The way I got around that was by factoring out the control logic and making adapter=plugin. 16:08 < FrePort_> Sure, by all means: give it a pass! 16:08 < mds> Yes, I see. But Freport's requirements on data are too strict -- they have to be isolated somehow. 16:08 < mds> It's going to take a bit of thought. I'll see what I can come up with. 16:09 < mds> I'm excited about this integration -- macs hasn't been this challenging in design for a bit... =) 16:10 < mds> But the hour is getting late. I move we take this up again next week, with fresh minds and more ideas. 16:10 < FrePort_> Okay, don't stress yourself. How about 2 week's hence? 16:10 < mds> Fair enough. In two weeks, then. Future Scheduling ------------------ 16:11 < FrePort_> Do we have time to firm up our schedule for next week? 16:11 < mds> I do. 16:11 < FrePort_> Okay... next week, we have basically everything involving fitzix that stacked up from last week. 16:11 < FrePort_> and the week before... 16:12 < FrePort_> and the week before... 16:12 < FrePort_> AND we have antifa's presentation. 16:12 < FrePort_> Anything else? 16:12 < mds> Don't forget to wag the auth! 16:13 * FrePort_ grins maniacally... 16:13 < FrePort_> I'm not certain what that means, but I'm certain I won't approve. :-) 16:13 < mds> FrePort_: prude. ;-) 16:14 < FrePort_> Do we have anythingelse we need to put on the schedule? 16:14 < mds> not I 16:14 < FrePort_> I'd like "alias" to give us some background on VRS, because that's on the webservices list... 16:16 < FrePort_> Any objection to me scheduling it, once I check with him? 16:16 < alias> oh 16:17 < alias> hey 16:17 < alias> i saw my name 16:17 < alias> what's up 16:17 * FrePort_ notices that alias has woken up... 16:17 < alias> yes, i'm back 16:18 < alias> do you want me to give a background on vrs now? or next week? 16:18 < FrePort_> I want to give you a segment *next week* to give an overview of VRS so that the main auth people can cogitate on possible integrations. 16:19 < alias> ok 16:19 < FrePort_> At some point we're going to have to do this with every author on the webservices list, so now's as good a time to practice (with a friendly face) as any... 16:19 * FrePort_ writes up the list for next week. 16:19 < alias> so hopefully by that time i'll have read some of the papers at mac 16:20 < FrePort_> Okay... 16:20 < alias> what is the webservices list? 16:20 < FrePort_> so, that gives us (besides previously tabled and currently unresolved) topics - 16:20 < FrePort_> two new items: 16:21 < FrePort_> 1) progress report on ROI study (mds, fitzix) 16:21 < FrePort_> 2) VRS presentation (alias) 16:21 < FrePort_> and just because I can't count: 16:22 < FrePort_> 3) discussion of a FAQ and maintenance thereof. 16:23 < FrePort_> If there is no further business??? 16:23 * FrePort_ readies the gavel.... 16:23 < kalahari> only monkey business 16:24 * FrePort_ bangs the gavel and leaves the floor to the monkeys. 16:24 < FrePort_> Meeting adjounred. Post-Meeting ============= 16:24 < mds> OK, I've got the logs. FrePort_: would you like to run through them before posting? 16:25 < FrePort_> Yes, mail them to my usual address.