[sip-clf] Rough notes

["Elwell, John" <[e-mail]>]

Problem Statement Draft - WGLC comments
 http://tools.ietf.org/html/draft-ietf-sipclf-problem-statement-01.txt 
 30 min
 Vijay Gurbani

Slides included rough calculations of data volume, which does not necessarily need to 

Cullen: Off by factor of 2-4 for IPv6 addresses
Brian: ????
Robert: Analysis inspired by earlier email thread. What does this tell us? Does it drive a technical decision. Perhaps need averages across production networks.
Brian: Volume not a problem
Peter ????: Question on retransmitted request. Answer that timestamp would change.
Chris ????: Didn't see a threat model.
Robert: Has Chris read charter? Moving across wires out of scope.
Chris: If putting on disc, is there concern about anyone accessing records.
Vijay: Covered in draft.
Chris: Would suggest need some text.
????: Is this only limited so SIP, or will at some time you correlate this with real message flows?
Vijay: This is to do with IPFIX collector/flows terminology I am not familiar with. Not sure we need to transfer in IPFIX way.
????: In couple of years will need to correlate with other sources of information, so data model is important.
Vijay: Not covered by problem statement at present.
Chair: Asked for clarification that one example is correlating media with signalling.
????: Yes
Henning: Two conditions. Need SDP. And proxy needs access to media stream, which for a simple proxy is not the case. So would need to extend data capture considerably. Would need to do a different type of logging, a log of accepted media transactions.
Dale Worley: Might want to consider extension for SDP, as test case for extensibility.
Vijay: Have considered, but doesn't overcome proxy problem.
Dale: SIP diagnosis - a lot more signalling problems than media problems. Need detailed logging at SIP level.
Cullen: When problems with media, much harder to debug than anything with signalling. Most people will be logging media information if it is a media device.
Hadriel: Robert's point, how do these calculations help me? 
Vijay: Are we sending it to disc, are we doing syslog or ipfix? Volume question is going to come up whichever.
Hadriel: Is opinion that one of the options is better than another?
Vijay: ????
Vijay: Cannot see how I would use IPFIX. Also IPFIX doesn't seem to be well known by implementers.
Hadriel: It is only format of log that is different. The volume is only a fraction of that for CDRs. For some, writing to disc might be more of a problem than transmitting elsewhere. Also writing to disc consumes more time than formatting.
Chris ????: Agree that writing to disc is the big part. Would like to see whether you really want to put on disc or just update counters.
Someone: Charter says just log.



 
IPFIX Proposal
 http://tools.ietf.org/id/draft-niccolini-sipclf-ipfix-00.txt
 30 min
Benoit Claise

Who read the draft? About 6.
Chair: We should try to avoid doing anything that would prevent us doing things in the future.
Richard Graveman: May be the best solution. I am more convinced now than earlier. What are the alternatives? Could write a lot of same words for other formats. Do we need a tabular comparison?
Benoit: 3 alternatives: define own, syslog, ipfix.
Richard G: Don't think define own is a good idea.
Benoit: I can't speak for syslog.
Chair: DISPATCH session revealed we needed more information to understand IPFIX. Take Richard's point that it would be good to have comparison, and with this input from Benoit we are getting to the point where we could have this comparison.
????: O&M trying to keep mechanisms to a minimum - IPFIX and SYSLOG for reporting.
Hadriel: Didn't think syslog was even on table. Our choices are ipfix or indexed-ascii.
Chair: Most discussion since Hiroshima on mailing list has been syslog (70%), followed by ipfix (20%). But this discussion did not turn into drafts yet.
Cullen: Data modelling language is a very important consideration, but looking at what we need and extensibility model, SIP is so ossified that we could never extend it. OK, you could add new headers and new bodies, but to change SIP message in a way outside that! Clear to all that ipfix and 10 other things that could work.
Robert: Group was chartered to start talking about content of log records, and has not done this very well. Need that conversation to start. Needs to spend highly focused time talking about what the content is.
Chair: Problem statement draft takes us a little way in this direction.
Henning: Cultural distinction - those coming from web server environment, and those coming from the measurement / debug community. Latter more comfortable with open source and tools to play with. Different people have comfort with different things. Given these cultural differences, lower end devices will choose something looking more like a log, and higher level applications would use something like ipfix. So might end up with two things.
Spencer: Are some of the predefined fields binary or ascii
Benoit: Binary.
Henning: Summary, will see two types of format. So argument we are having is moot. If there is an RFC for text file format and if there is an RFC for ipfix file format, will implement both.
Chair: Charter explicitly allows us to do both.
Benoit: For any sort of filtering, need some structure.
Vijay: Apache uses two formats. Concerning Robert's comment, these headers have been laid down since original draft. My idea of correlation was with fork trees. Another idea of correlation arises when call is between domains. Present elements cover both.
Hadriel: Agree with Henning. Two different worlds of requirements / use cases. Can we decide something this week?
Brian: If we need to do both, let's accept that. The important thing is the data, not the presentation.
Eric: 

Chair: Hum for being in favour of just one format.
Someone: We haven't had the comparison.
Henning: Are there are particular issues?
Someone: There was a previous discussion that not everyone understood syslog and ipfix.
Cullen: Two proposals, one is ipfix-based, and the other is a new indexed format.
Vijay: Indexed format has changed, to make it easy to skip things.
Chair: Does anyone feel they don't yet have enough information to take hums - nobody.
Chair: Hum for one format only or for two options: Strong consensus for working on both options.

 
Discussion on Direction
 none
 30 min
 chairs
Chair: We don't have a draft on framework yet. Presented 'modest proposal' from slides.

Mary Barnes: Need to progress work on session-ID in DISPATCH - has been quiet recently. Pointed out deadline for topics for DISPATCH at IETF#78 (will align with deadlines for BoFs).
Vijay: I am lost - do we need to spin off more work in DISPATCH concerning management framework.
Robert: Outside charter - would have to go to DISPATCH.
Hadriel: We brought up session-ID before, and not a lot of interest in DISPATCH, but timing might have been bad.
Sparks: Mary will send not to list on where solving other problems can go. Let's get back to what this WG can do - last two points on slide. Pull up RFC SIP torture tests, which push the edge cases of SIP message formats. Take the well-formed messages there and render concrete records, send to mailing list tomorrow. We may learn from this.
Chair: Great idea. From Hiroshima, everyone was saying we need a way to do correlation, but now we are a lot further forward.

Chair: presented slide on work plan for IETF#78. Who is going to be contributed to getting the problem statement out by April? Only Vijay raised his hand.

Sparks: Do we have volunteers for putting out example records to mailing list? Hadriel, Vijay, Adam.

Sparks: So this WG is a pilot experiment of groups coming out of DISPATCH. Within DISPATCH we had a kernel of energy. My interpretation of AD so far is that it has fallen on its face. If doesn't show signs of life soon, I will pronounce it dead.

Chair: Is April a reasonable timeline for picking a format, and is June for completing it?
Vijay: More comfortable with May for picking a format.
Chair: Are these dates for file format comfortable.
Sparks: I don't see anything happening - people waiting to see what happens with initial actions. Let's at least update charter dates to these at least.



 
Work plan for IETF 78
 charter
 20 min
 chairs