MW-E2ED Conference Call
July 12, 2006

*Attending*
Chas DiFatta, CMU (chair)
Michael Gettes, Duke
Steve Olshansky, Internet2
Dean Woodbeck (scribe), Internet2

*Action Items*
AI {Chas} to update project timeline on E2ED page
AI {Chas} to send more detailed project update to the list

*Discussion*
University of Washington networking group has been reviewing the EDDY framework and want to discuss helping us develop a few feature enhancements. They've identified a performance bug (which has been fixed) and have been testing the code extensively. They are analyzing whether the EDDY feature set would be a good base for building their network analysis tools.

Progress on the framework: this week we added TTLs as well as GUIDs to the base framework functionality. By the end of next week we should be testing the NetFlow 5 normalizer.

The next application we will focus on is an email diagnostic tool. At this time we are processing real-time syslog events from a small set of mail hosts which whose events include to smtp, imap, pop, and spam engine logs. Initially specific fields from these events are being filtered and stored into a simple database. We will be building a simple query interface that will be targeted at answering the email diagnostic questions that the group helped compile these last few months. While using the query interface we will ascertain its functionality and augment where needed. In the next phase of the project, we will begin to identify what types of new CERs we need to build and then finally build a simple GUI to wrap around the query tool. There should be a mockup of the GUI sometime in August.

We have had interest about building a CER factory. This is a way to get events into the EDDY framework without detailed experience of EDDY internals or knowing the details of Java. The goal of the CER factory is to enable experimentation of new types of CERs and to make it easier to gain experience using the EDDY framework. In detail, the CER factory is essentially a service that listens for templates which describes the details of a specific type CER that needs to be generated. The template contains fields that are normally found in the CER, but can be optional. Templates could be populated using a basic scripting language such as Perl, then it would pass it to the CER factory service, which would then parse the template and generate the appropriate CER and route it to the next agent in the EDDY cluster.

Next call: July 26.