Subject: [sip-clf] Fw: Rough notes

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 26 Mar 2010 15:49:04 -0500

With thanks to John - Robert asked that when working groups CAN post draft 
minutes before we leave town that we do so, and that's hard when we don't 
meet until Friday morning, so thanks to John for making that possible!

Spencer

----- Original Message ----- 
From: "Elwell, John" <[email-masked]>
To: "SIP-CLF Mailing List" <[email-masked]>
Sent: Friday, March 26, 2010 1:06 PM
Subject: [sip-clf] Rough notes

>
> 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
>
>
>
> _______________________________________________
> sip-clf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-clf