Action Items

• Matt and Russ think about measurement schema and how it would look.
• Further discussion about scheduling "test logging" files.
• Put common event record information on the public web page.
  

Agenda Items

Review of Previous Action Items

• A draft design document has been published to the web site.
• Chas and Matt are working on getting together for an in person meeting.
• Chas is working with Ken to craft a response to the SURFNet Detective team.
• Chas has a DTD for the Common Event Record XML that will be discussed in today's call.
• Mark and Russ talked with Brent Sweeny (Abilene NOC) during the Joint Techs Workshop in Columbus, OH. Brent expressed interest in the diagnostics work and how it would use logs from the NOC. Mark said that another conversation with Brent would be helpful. Chas suggested that Mark or Russ get another call with Brent to explain in more detail how the diagnostic process would work. Chas also suggested that Matt and Russ think about what the measurement schema should look like.

Pilot progress

Chas then provided an update on the Pilot. He reviewed a new document. Items discussed included:

• Using normalizers to convert raw data and logging data to XML documents.
• Using collectors to archive and populate database with XML data.
• Using filters to anonymize, aggregate and remove event details.
• Other tools used to analyze event and logging data.
• Four schemas based on type of data: system, application, security, and network. At this point performance data is not included as part of the pilot. There was brief discussion about the use of SNORT data for security diagnostics and that SNORT data could provide a quicker way to gather data for diagnostic analysis.
• Basic schema normalization elements were presented. Then the schemas for the other areas were presented as well.

Once the presentation was over discussion opened up.

The first question was how easy would it be to update the schema? Chas replied that all modules have version numbers that can be used to verify the most current version is being used.

Another question was about how to relate performance issues on a network link to Shibboleth issues with time-outs some where on the path. Each process have their own object of interest and the requirement is to make sure that diagnosticians get the correct data from the particular tools in order to solve problems between different point, say DC and PSC or DC and Chicago. It was suggested that what might be needed is metadata of what was the transaction set at multiple levels. This would help when following the thread of a Shibboleth event that may have to be shifted to move into the network stack and be traced there. Chas responded that in naming the schema, identification of cross domain events will be important in order to help identify cross realm events.

Russ suggested the model of a dependency tree that maps which services are dependent upon each other. Mark suggested that this is another step in the level of abstractions raised earlier of layers that may have dependencies that could be broken into constituent pieces.

Question was asked if there would be a requirement for normative naming of files in order to collect diagnostic information. Mark replied that this information will be part of the diagnostic trail which will provide information of where the data is from. This data will be in a central database. He noted that a central database will grow rapidly and will not scale. So we will use this to collect events of interest. We will need to experiment with the data to determine what events have more value.

The next item of discussion was about when there will be pilot test that people can try. Currently the developers are working on this. Chas said that a analysis framework should be in place some time later in August. This is not ready to be opened yet. Mark agreed that we should be shooting to have something by the member meeting. We could setup sample schema collectors for the demonstration such as working with an example Shibboleth target. Ken said that Derek should be available to assist with this.

A question was asked if there was a summary of the common event record available for people to see. Chas agreed to take working documents and put something on the public web page.

Marketing and Documentation

Next was discussion about the marketing aspects for diagnostics. Ken is working on document to provide a variety of different ways of looking a diagnostics and how they relate to a number of current projects. This would be a look up and down the protocol stack. It should also help people to better understand how diagnostics differ from existing tools -- the notion that there are currently simple tools that provide data on specific elements, but when combined with other compound tools will present a more comprehensive diagnostic view. What will emerge from this introductory slide deck will be an aid to help people see all different angles to approach diagnostics and see where they can help.

As the diagnostic process is developed it will be helpful to identify other processes that are outside the scope of the diagnostic project. For example there are some events that are germane to diagnostics but others are only for performance areas.

The question was asked that when test is being done are is there someone logging the test as being done. Russ said not currently. The point was made that there has been the issue that running tests have produced their own sets of problems. So, a log of tests that have been run would be helpful to better identify them as possible sources of problems. This topic should be explored more at later calls.

Russ said he is looking around for events to collect. He pointed out that CENIC is collecting entries to its trouble ticket system and might be potential data to collect. He will be sending more information about this to the list.

The call was adjourned.