Chas began call with discussion of slides from presentation he mailed to the group.

1.1 - Goals

Chas pointed out that we did the test run without the "experts" who will be more involved in later focus groups. Russ asked about the procedure of the interview and who was supposed to be asking questions. Chas said it will be done back channel through chat and this will be covered in later slide.

1.2 What worked

Chas said we did capture most of the top 10 pain points. Russ added that the conversation was strong on problems but weak on tools to solve the problems and the he's not sure if the interviewee uses many tools.

1.3 what didn't work

Chas pointed out Russ's comment fall in the "what didn't work" slide. The diagnostician only had a small set of tools or didn't' indicate better what tools he had. Russ agreed.

Chas also said that the person being interviewed was supposed to be web application developer, but was in fact too generalized. In the future we need to constrain the problem.

Also we need to identify more participants. Russ suggested that with a particular focus if we have more than one person they could bounce ideas off each other. Chas said that's right and that's why we want more than one person in each area. Another way to look at this is the diagrams on the wiki page and then transpose the vertical with the horizontal headings.

1.4 changes for next focus group

For the next focus group it was suggested that we need more participants, a more focused interviewee, and more participants in area of focus, or multiple of the above (e.g., area being explored) such as 4 administrators.

We discussed using video conference. Should this be seen on the net? Russ said if the process were less painful to setup it might work, but video conferencing is not always that easy to do. Chas said he was thinking about Carnegie Mellon Unv (CMU) since it has good facilities.

1.5 Focus Group Findings

We talked about the findings from the first session. I was clear that there is a need for video diagnostics. The user doesn't have access to the data needed. The largest theme was that there is a big requirement for proactive reporting tools. Russ pointed out that the user wants to see indicators before an event happens.

The end user also needs tools for backups and printing. As well as proactive summary reports for spam and other applications. He wants to see when and where the thresh holds break. What are the triggers and where do they happen.

1.6 - Forensic tools for network --

A running audit of a centralized log file store as one place to look at things was recommend. Russ concurred, he said that is exactly what chas has been talking about for a long time. Chas pointed out it's what user wants for administrative controls. While other people at different levels want or need different tools.

Network tools need to be able to detect or diagnose switch anomalies with agents for certain switches. To do flow forensics takes time to set up, but there are good tools out there. Also we need to be able to repeat historical events such as the video performance issues at Supercomputing 05 -- for what if? What if we changed this or that? How to go back?

One tool mentioned, netreg, was described as too hard, to complex to install and provided too much information. Russ said what ever people use needs to be able to be tailored to their particular needs. Chas agreed and said tools need to scale properly.

1.7 Other focus groups

Then discussion turned to other focus groups. Was the session useful? Would this work for projects like OWAMP, Shibboleth, or LionShare? How about the Spam problem with mail administration?

The idea is to deal with the horizontal such as networks or security. Russ suggested that an application might be better at this point viewing it as part of a system by getting input from developer, implementor, and administrator.

Then we discussed the value of sending the slide set out to various people to get their input on the material and the process.

Video came up as topic that was raised by the first interview that should be revisited. Video is a broad area with different types and multiple communities using it. Russ suggested that this might be broadened to include collaboration tools. Then we discussed some of the details such as who in the Internet2 community is doing video diagnostics? Who would be good to have participate is such a focus group.

Chas suggested the idea of using 3 people who operate video conferencing services as a way to have them play off each other. That if we were to take the horizontal slice first with the user, operator as well as operator. Use their comments to identify cluster areas and focus on problems in the clusters. We could have amazing results. Then we should be able to see if the problem is with the network or the application. We could identify where we can make more impact with diagnostic tools.

Chas asked what were the major problem faults or trends and services with Abilene. Russ replied that Abilene, the backbone, was almost never the problem. He said the issues were closer to the end points on a campus. Chas, said ok, let's use that scenario: end user is campus, help desk is the NOC, the developer would be the network architects. Russ suggested Rich Carlsson as a tool developer. He said the first thing to do in such a diagnostic is to get the campus network person involved.

Based on the previous conversation the group agreed that future focus groups should be: video conferencing (H.323, multicast), Shibboleth, Abilene NOC, LionShare.

Next steps are to:

1. Check in with Ken
2. Check with Ohio State Unv. about how they support H.323. video. What tools to they use? Who are the participants?
3. Talk with Steven Carmody about Shibboleth and LionShare.

Chas said he'd write this up and send it out to the group.

2. EDDY Progress

Chas gave a quick update on progress with EDDY. He said it going strong. Within a week there should be additional staff including another developer and a graduate student on track to provide libraries by the end of February. EDDY will be used by two projects at CMU right away. It will be able to transport Arugus and Netflow data from at least one feed and anonymize it on campus.

Also the glossary is being setup to know what they modules do at a very high level. Starting to drill down into the specifications more. Have the event transport ready to go. Scaling back on the controlling structure to control agents across hosts. This will be held until after the February release.

Duke is involved now. We are writing a use case with netreg. Hope this will get the interest of the folks at Surfnet.

In parallel, a number of companies are interested in doing diagnostics. While not the broad scope we have, they're taking parts of network, application, and security. IBM has about 70% of our way of thinking. This verifies what we've been saying so far.

Suggestions for next call? Where go from here?
Use email for next steps, check with Ken, drill down into communities we want to involve in next focus groups.