1. Reports from Meetings.

Chas met with personnel from the LionShare Project at Pennsylvania State University (PSU). He will write up a summary of that meeting with next steps. The meeting raised good thinking about peer to peer relationships, in particular logging and privacy. He has begun thinking about peers turning logging off and on.

[AI] Chas will write up a summary of his meeting at PSU with LionShare Project team. Also this will include next steps.

[AI] The LionShare Project Team will be writing up their answers to the Top 10 Questions about diagnostics to be submitted to E2ED.

While at PSU Chas met with Max who is in charge of Shibboleth deployment for PSU. He had a very good discussion with him. Max has concerns about Shibboleth v 1.2 deployment. There are a number of problems they see that are not with Shibboleth. For example just that the user has not turn on specific attributes in the authentication authority.

Chas noted that there is good technical synergy with Shibboleth. If the log is turned on with sharing between two hosts they are ready for supporting the diagnostic Backplane.

[AI] Max will write up their responses to the Top 10 Questions in the diagnostic domain.

Discussion moved to the SURFNet Detective. Chas noted that we owe the SURFNet team information about how the Diagnostic Backplane can be integrated into the SURFNet Detective and visa versa. He has been working with Klaas directly on that. Mark said that Chas will continue to work with the team to figure out how they will be involved as early adopters.

[AI] Chas will check in with Klaas to update status on SURFNet Detective and Diagnostic Backplane.

There was brief discussion about getting a dialog started with Cisco in response to meetings of John Chambers of Cisco on Carnegie Mellon University (CMU) campus. Mark expressed interest in determining how E2ED relates to Cisco products. How to interact with Syslog and SNMP.

[AI] Follow up with identifying areas for discussion and collaboration with Cisco.

2. E2ED Early Adopter Focus Group Identification Process
Wiki discussion from last call can be found at,
http://people.internet2.edu/~ghb/pmwiki/pmwiki.php/MWe2eD/MWe2eD1021

The participants of the call then discussed the information found on the wiki pages that had been started during the last call. Chas pointed out that he had edited the page with comments from the group in real time during the last call, and that it had been added to it and cleaned it up since then.

Mark said that the page helps to present the idea in terms of the early adopter who wants to get reasonable diagnostic coverage of things. It points out what domains are to get breadth and depth. It identifies end user applications that are distributed and rely on infrastructure and diagnostic back plane. What data is right now in vertical stove pipes and how to collect it in ways that will make it more accessible. For example if network and middleware applications / services functioned more in a matrix, then they'd be able to help each other more synergistically. This would give better access to diagnostics as well as be a conduit to diagnostic information. The notion is how to decide what to keep in something like a Shibboleth sub system that would be of value to diagnostics.

Russ pointed out that this is helping to make more sense. He said that there are so many different pieces that we can't work with them all at once. The diagrams on the wiki page are helping to focus on tools and layers of the issues. The diagrams would help with correlations. If a person is writing tools to make diagnostics better they usually tend to lose touch with other areas. This matrix helps them to keep in touch, to keep in mind the other areas. Russ and Mark talked about how communication between the different groups listed is very important not just to make data available, but also to help identify the particular tools that are being developed for diagnostics.

Chas said that this was a very helpful conversation. That the initial matrix would evolve. He suggested identifying what tools a person would use and what data would be needed for particular domains. The next thing is to go out and get people to help fill out the information for the matrices. Need to get each community in and have them discuss their areas and what's needed. This will help fill out the matrices as well as build cases.

Russ pointed out that this process would link to the upcoming NSF "Bridging the Gap" Workshop which will work with representatives from network engineering, network Wizards, applications developers and domain specialists / scientists. Mark agreed that this would be useful to test of the matrices. Russ said the concern has been that the people supporting the researchers do not understand the issues of distributed applications over networks. This workshop will be happening late Spring of 2005. Chas and Mark agreed that it will be good to keep in touch with Russ and George about how the workshop can fit into the E2ED framework. Mark suggested a phone call that might help inform the workshop planning.

[AI] Start planning early, get a timeline for the workshop, arrange call to discuss recommended groups.

3. Post Pilot Plans
a. Post pilot feature list can be found at
http://middleware.internet2.edu/e2ed/private/Munster.pdf

Chas asked for people's feedback on the detailed feature list in the pdf file.

[AI] Let Chas know any comments or questions generated by the document.

b. Renaming the project

Chas said that the project nickname of ccBay is going to be changed. Current thinking is EDDY. Chas described the visual of an eddy (calm area) in the current of a stream of data as a logical place for diagnostics. He would like some feedback on that name choice.

c. Timeline can be found at http://middleware.internet2.edu/e2ed/private/eddy/timeline.pdf

Chas said the current goals are to get the first release out soon. This will take best parts of the pilot and those that need to be changed and get them out soon. He noted that the timeline might be a bit too aggressive and moved it to Feb 2005. He said that Duke University and CMU developers already had been meeting. Chas said that other folks had been looking at it as well. Next steps will be an early adopter outreach program to get information out there to people in the horizontal areas in the matrices discussed earlier.

Once v 0.5 is out there people should be ready to write to the API. A major milestone will be to get the Common Event Record (CER) finalized and a white paper published.

4. Whitepapers
a. Diagnostic Backplane Concept
http://middleware.internet2.edu/e2edDiagnosticsMotivationWhitepaper0.93.pdf

Chas said the next thing to do is to look at the drafts of the white paper and comment on it. Mark said it's important to identify what is not clear, what is not appropriate, and what is missing.

[AI] Read and comment on white paper

5. EDDY Developers Group Formed
Wiki can be found at,
https://acs-wiki.andrew.cmu.edu/twiki/pbin/view/E2ed/

Chas noted that the developer group has been formed. They are working on the CMU wiki. He said they are working hard to meet the Feb distribution date.

[AI] Wiki page access needs to be opened.