Subject: [sip-clf] draft CLF charter

From: Robert Sparks <[email-masked]>
Date: Fri, 17 Jul 2009 16:13:58 -0500

All -

We are working on forming a CLF working group based on DISPATCH's  
decision.

Below is a proposed charter for this working group. Please review and  
comment
on this list. Depending on the feedback we receive, we will target  
forming this
group shortly after the Stockholm meeting.

We'll also be discussing this in Thursday's opsarea meeting.

Thanks,

RjS

> The SIP Common Log File (CLF) working group is chartered to define
> a standard logging format for systems processing SIP messages.
>
> Well-known web servers such as Apache and web proxies like Squid
> support event logging using a common log format.  The logs produced
> using these de-facto standard formats are invaluable to system
> administrators for trouble-shooting a server and tool writers to
> craft tools that mine the log files to produce reports and trends
> and to search for a certain SIP message or messages, a transaction
> or a related set of transactions.  Furthermore, these log records
> can also be used to train anomaly detection systems and feed events
> into a security event management system.
>
> The Session Initiation Protocol does not have a common log
> format. Diverse element provide distinct log formats making
> it complex to produce tools to analyze them.
>
> The CLF working group will produce a format suitable for logging
> from any SIP element. The format will anticipate the need to
> search, merge, and summarize the log records from diverse elements.
> The format will anticipate the need to correlate messages from
> multiple elements related to a given request (that may fork)
> or a given dialog. The format will take SIP's extensibility into
> consideration, providing a way to represent SIP message components
> that are defined in the future.  The format will anticipate being
> used both for off-line analysis and on-line real-time processing
> applications. The working group will consider the need for
> efficient processing in its design of this format.
>
> The working group is not pre-constrained to producing either a
> bit-field oriented or text-oriented format, and may choose to
> provide both. If the group chooses to specify both, it must be
> possible to mechanically translate between the formats without
> loss of information.
>
> Specifying the mechanics of exchanging, transporting, and storing
> SIP Common Log Format records is explicitly out of scope. Specifying
> a real-time transfer mechanism for heuristic analysis is explicitly
> out of scope.
>
> The group will generate:
>
> - A problem statement enunciating the motivation,
>  and use cases for a SIP Common Log Format. This analysis
>  will identify the required minimal information that must
>  appear in any record.
>
> - A specification of the SIP Common Log Format record.
>
> The group will consider providing one or more reference
> implementations for decoding a CLF record.
>
> Goals and Milestones
> ===========================
>
> Nov 09 - Problem statement, motivation, and use cases to IESG  
> (Informational)
> Feb 10 - SIP Common Log Format specification to IESG (PS)
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Jul 2009 16:44:29 +0200

A few comments after the first reading of the charter. 

- Is it Common Log File as it appears at the first instance, or Common
Log Format? 
- What does 'efficient processing' mean? More clarity and details here
would be welcome (is it at client, at server, both? Is it efficiency on
storage, on transmission? etc.)
- Would it be useful to include (maybe as part of the problem statement
work, maybe as a separate item) a look at what is already available as
standards for logging events (e.g. syslog is discussing rechartering at
the same IETF meeting - can syslog format be used? pcap? Other? Are
there any initial proposals?)
- if the WG ends by doing both a bit-field oriented and a text-oriented
format will these end being separate deliverables? 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Robert Sparks
> Sent: Saturday, July 18, 2009 12:14 AM
> To: [email-masked]
> Subject: [sip-clf] draft CLF charter
> 
> All -
> 
> We are working on forming a CLF working group based on 
> DISPATCH's decision.
> 
> Below is a proposed charter for this working group. Please 
> review and comment on this list. Depending on the feedback we 
> receive, we will target forming this group shortly after the 
> Stockholm meeting.
> 
> > The SIP Common Log File (CLF) working group is chartered to 
> define a 
> > standard logging format for systems processing SIP messages.
> >
> > administrators for trouble-shooting a server and tool 
> writers to craft 
> > tools that mine the log files to produce reports and trends and to 
> > search for a certain SIP message or messages, a transaction or a 
> > related set of transactions.  Furthermore, these log 
> records can also 
> > be used to train anomaly detection systems and feed events into a 
> > security event management system.
> >
> > The Session Initiation Protocol does not have a common log format. 
> > Diverse element provide distinct log formats making it complex to 
> > produce tools to analyze them.
> >
> > The CLF working group will produce a format suitable for 
> logging from 
> > any SIP element. The format will anticipate the need to 
> search, merge, 
> > and summarize the log records from diverse elements.
> > multiple elements related to a given request (that may fork) or a 
> > given dialog. The format will take SIP's extensibility into 
> > that are defined in the future.  The format will anticipate 
> being used 
> > both for off-line analysis and on-line real-time processing 
> > bit-field oriented or text-oriented format, and may choose 
> to provide 
> > both. If the group chooses to specify both, it must be possible to 
> > mechanically translate between the formats without loss of 
> > information.
> >
> > Specifying the mechanics of exchanging, transporting, and 
> storing SIP 
> > Common Log Format records is explicitly out of scope. Specifying a 
> > real-time transfer mechanism for heuristic analysis is 
> explicitly out 
> > of scope.
> >
> > The group will generate:
> >
> > - A problem statement enunciating the motivation,  and use 
> cases for a 
> > SIP Common Log Format. This analysis  will identify the required 
> > minimal information that must  appear in any record.
> >
> _______________________________________________
> sip-clf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-clf
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 20 Jul 2009 18:21:24 +0200

Just to note that previously the input from the other area director was to provide separate milestones for taking a draft to WGLC and publication request to IESG.

> We'll also be discussing this in Thursday's opsarea meeting.

Can you clarify what you mean by this? All discussion will henceforward be in opsarea or just seeking their input to continuing discussion on the dispatch mailing list.

regards

Keith

> Sent: Friday, July 17, 2009 10:14 PM
> To: [email-masked]

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 21 Jul 2009 17:25:23 -0500

> A few comments after the first reading of the charter. 

Dan: Thanks for your feedback; more inline.

> - Is it Common Log File as it appears at the first instance, or Common

CLF expands to Common Log File, though colloquially you will
see references to "the CLF format", which simply means the
specific fields and their representation.

> would be welcome (is it at client, at server, both? 

Efficiency is envisioned here to encompass both the server and the
client.  From the server's perspective, the generation of the
CLF should not cause an unnecessarily burden so as to slow the
normal processing done by the server.

 From the client perspective, the processing of the file should
not take undue time.  Some clients may consume data produced
in CLF format in real time while others may do so in "batch"
mode (i.e., find all the SIP messages corresponding to a
certain dialog.)  To do such batch mode processing, it is
advantageous if the CLF data is so structured as to aid in
skipping records that are not part of the search criteria.

> Is it efficiency on storage, on transmission? etc.)

More than storage costs or transmission overhead, efficiency
is measured in processing time at the clients and servers.

> there any initial proposals?)

The members of the sip-clf list have experimented with ASCII-,
binary- as well as a hybrid-based approach to producing the CLF.
While pcap is good for capturing network traffic, requiring a SIP
entity to expressly produce CLF in pcap format will be burdening
it to spend CPU cycles in converting the SIP message from its
internal representation to the pcap format -- this may not
be sustainable in a high transaction volume SIP proxy, for
instance.  With respect to syslog, SIP CLF is more than an
event notification message -- it is essentially continuous
spooling of the messages that a SIP entity is processing.
It could well be that the SIP entity, if it detects something amiss
in a message, emits a syslog message; however, SIP CLF itself
was not viewed as an event notification mechanism.  Hence the
charter leaves out of scope mechanisms of exchanging, transporting,
and storing CLF format records.

> format will these end being separate deliverables? 

Possibly; or they could be different sections in the same
document.  The CLF fields will be the same, just the representation
of them will differ.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 21 Jul 2009 19:47:19 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Vijay K. Gurbani
> Sent: Tuesday, July 21, 2009 6:25 PM
> 
> instance.  

I disagree with that - or rather, it's not the format conversion from an internal representation to a PCAP format that would burn CPU.  I wrote an example library for (and submitted a draft on) recording CLF in a PCAP format.  While the code was kludgy (because I'm not a programmer and I was trying to make it a generic library and thus internal-representation agnostic)... it could be written better.

But no matter what format we pick, there will be a "conversion" from an internal representation to a CLF format for most everyone, if not actually everyone.

-hadriel

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Jul 2009 10:30:02 +0200

Thanks for the answers. Most clarifications are fine with me, a couple
of observations in line. 

Dan

> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: Wednesday, July 22, 2009 1:25 AM
> To: Romascanu, Dan (Dan)
> Cc: Robert Sparks; [email-masked]
> Subject: Re: [sip-clf] draft CLF charter
> 

...

> is measured in processing time at the clients and servers.

Some clarification in the text of the charter would be welcome. 

...

> 
> > - if the WG ends by doing both a bit-field oriented and a 
> > text-oriented format will these end being separate deliverables?
> 
> document.  The CLF fields will be the same, just the 
> representation of them will differ.
> 

So, basically we are talking about fields definition (one) and mapping
of the fields to different formats (one or more). Again, clarifying this
in text may help. 

...

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Jul 2009 15:38:16 +0200

All these look good. 

Thanks,

Dan

> Sent: Wednesday, July 22, 2009 4:36 PM
> To: Romascanu, Dan (Dan)
> Dan: Thank you.  I am suggesting some changes to the charter 
> based on your comments.  Could the sip-clf list participants 
> and the AD please review and comment.
> 
> dromasca> Is it efficiency on storage, on transmission? etc.)
> vkg> More than storage costs or transmission overhead, efficiency is 
> vkg> measured in processing time at the clients and servers.
> dromasca> Some clarification in the text of the charter would 
> be welcome.
> 
> OLD:
> The format will anticipate being used both for off-line 
> analysis and on-line real-time processing applications. The 
> working group will consider the need for efficient processing 
> in its design of this format.
> 
> NEW:
> The format will anticipate being used both for off-line 
> analysis and on-line real-time processing applications. The 
> working group will consider the need for efficient processing 
> in its design of this format, where efficiency is measured in 
> processing time of the CLF at the clients and servers (i.e., 
> the generation of the CLF should not cause an unnecessarily 
> burden so as to slow the normal processing done by a server, 
> and the processing of the file should not take undue time by 
> a client.)
> 
> dromasca> - if the WG ends by doing both a bit-field oriented and a 
> dromasca> text-oriented format will these end being separate 
> deliverables?
> vkg> Possibly; or they could be different sections in the 
> same document.  
> vkg> The CLF fields will be the same, just the representation of them 
> vkg> will differ.
> dromasca> So, basically we are talking about fields 
> definition (one) and 
> dromasca> mapping of the fields to different formats (one or more). 
> dromasca> Again, clarifying this in text may help.
> 
> OLD:
> The working group is not pre-constrained to producing either 
> a bit-field oriented or text-oriented format, and may choose 
> to provide both.  If the group chooses to specify both, it 
> must be possible to mechanically translate between the 
> formats without loss of information.
> 
> NEW:
> The working group is not pre-constrained to producing either 
> a bit-field oriented or text-oriented format, and may choose 
> to provide both.  The nature of the CLF information contained 
> in a bit-field or text-oriented format will be the same, it 
> is the representation that will differ.  If the group chooses 
> to specify both, it must be possible to mechanically 
> translate between the formats without loss of information.
> 
> Thanks,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 
> Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)

---

From: Robert Sparks <[email-masked]>
Date: Wed, 22 Jul 2009 08:49:52 -0500

Just to make sure we are all on the same page:

> specific fields and their representation.

This is something we need to state more clearly.

Are we defining a file are we defining a format that might go in a file?

I think the proposals I've read so far are trying to do the second.
Does anyone disagree?

I was planning to  change the word File Dan is pointing  to in the
proposed charter to Format.

RjS

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 22 Jul 2009 08:36:10 -0500

Romascanu, Dan (Dan) wrote:
> Thanks for the answers. Most clarifications are fine with me, a
> couple of observations in line.

Dan: Thank you.  I am suggesting some changes to the charter based
on your comments.  Could the sip-clf list participants and
the AD please review and comment.

dromasca> Is it efficiency on storage, on transmission? etc.)
vkg> More than storage costs or transmission overhead, efficiency
vkg> is measured in processing time at the clients and servers.
dromasca> Some clarification in the text of the charter would be welcome.

OLD:

NEW:
The format will anticipate being used both for off-line
analysis and on-line real-time processing applications. The
working group will consider the need for efficient processing
in its design of this format, where efficiency is measured
in processing time of the CLF at the clients and servers (i.e.,
the generation of the CLF should not cause an unnecessarily
burden so as to slow the normal processing done by a server,
and the processing of the file should not take undue time by
a client.)

dromasca> - if the WG ends by doing both a bit-field oriented and a
dromasca> text-oriented format will these end being separate deliverables?
vkg> Possibly; or they could be different sections in the same
vkg> document.  The CLF fields will be the same, just the
vkg> representation of them will differ.
dromasca> So, basically we are talking about fields definition (one)
dromasca> and mapping of the fields to different formats (one
dromasca> or more). Again, clarifying this in text may help.

OLD:

NEW:
The working group is not pre-constrained to producing either a
bit-field oriented or text-oriented format, and may choose to
provide both.  The nature of the CLF information contained in
a bit-field or text-oriented format will be the same, it is
the representation that will differ.  If the group chooses to
specify both, it must be possible to mechanically translate
between the formats without loss of information.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 22 Jul 2009 08:59:06 -0500

> Are we defining a file are we defining a format that might go in a file?

The latter; my apologies since I misrepresented this in my earlier
response.  Our model and inspiration of this work has been
HTTP CLF, which also expands to "Common Log Format".

> proposed charter to Format.

Sounds good.

Thanks,

- vijay

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 22 Jul 2009 10:05:10 -0500

Just to stay on the same page :D

I had a short chat with Dave Harrington Monday, and he asked "why not 
IPFIX?" - has anyone looked at IPFIX yet?

I know Glen Zorn's question in February was "why not SYSLOG?" - the answer 
then, from Eric Burger, was (paraphrasing) "SYSLOG's the envelope, CLF might 
use SYSLOG but needs to define what goes in the envelope".

The answer may be the same for IPFIX, and we'll probably need to figure this 
out, but if anyone has already looked at this, that would be great to know.

Thanks,

Spencer

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Jul 2009 17:45:24 +0200

I need to have a more careful look, but the answer I think is No, the
argument is different. IPFIX defines information elements based on
packets inspection that characterize a 'flow' - in a SIP you cannot
differentiate packets that belong to different sessions only based on
on-wire information, so the definition of an IPFIX Information Element
(IE) may have too little or too much granularity for what we need. 

But, again, I need to read the CLF requirements and cross-match these
carefully with the IPFIX capabilities to make sure that I am not passing
a too easy judgment. 

Dan

> [mailto:[email-masked]] On Behalf Of Spencer Dawkins
> Sent: Wednesday, July 22, 2009 6:05 PM
> To: SIP-CLF Mailing List
> I had a short chat with Dave Harrington Monday, and he asked 
> "why not IPFIX?" - has anyone looked at IPFIX yet?
> 
> I know Glen Zorn's question in February was "why not SYSLOG?" 
> - the answer then, from Eric Burger, was (paraphrasing) 
> "SYSLOG's the envelope, CLF might use SYSLOG but needs to 
> define what goes in the envelope".
> 
> The answer may be the same for IPFIX, and we'll probably need 
> to figure this out, but if anyone has already looked at this, 
> that would be great to know.
> 
> Thanks,
> 
> Spencer
> 
> 
> >>> - Is it Common Log File as it appears at the first instance, or  
> >>> Common Log Format?
> >>
> >> CLF expands to Common Log File, though colloquially you will see 
> >> references to "the CLF format", which simply means the specific 
> >> fields and their representation.
> >

---

From: Robert Sparks <[email-masked]>
Date: Wed, 22 Jul 2009 12:23:10 -0500

This is just getting input from the opsarea. Conversation will  
continue on sip-clf.

RjS

On Jul 20, 2009, at 11:21 AM, DRAGE, Keith (Keith) wrote:

> Just to note that previously the input from the other area director  
> was to provide separate milestones for taking a draft to WGLC and  
> publication request to IESG.
>
> Can you clarify what you mean by this? All discussion will  
> henceforward be in opsarea or just seeking their input to continuing  
> discussion on the dispatch mailing list.
>
> regards
>
> Keith
>

---

From: Theo Zourzouvillys <[email-masked]>
Date: Wed, 22 Jul 2009 22:41:26 +0100

> IPFIX?" - has anyone looked at IPFIX yet?

yes :-)

see bottom of:

http://www.ietf.org/mail-archive/web/sipping/current/msg17205.html

 ~ Theo

-- 
http://twitter.com/zourzouvillys
http://crazygreek.co.uk/

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 22 Jul 2009 22:30:30 -0400

Yeah when I first heard someone mention ipfix at the beginning - the first thing in my mind was "we're not doing samples for flow counters".  But then I thought about it some more and think what they mean is the ipfix record format concept in particular, not ipfix the protocol/architecture/mechanism.  So for example one could define a "SIP-CLF" template set of fields which record what we want.

If that's what people mean when they say "ipfix", I like that way too, because in my mind that's pretty close to the advantages of a Pcap file format.  Ipfix is a little hokey when dealing with variable-length fields, as I recall (it was really optimized for fixed-length fields like counters and IP Addresses), but probably less hokey than Pcap.  And it'll probably be smaller record sizes which is a big deal.

-hadriel

> Of Romascanu, Dan (Dan)
> Sent: Wednesday, July 22, 2009 11:45 AM
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 Jul 2009 16:49:59 +0200

It may be a good idea to have somebody from the SIP-CLF crowd come to
the IPFIX meeting next week and make a five minutes presentation so that
IPFIX folks are aware about this. 

I am copying the IPFIX chairs so that they are not completely taken by
surprise. 

Dan

> [mailto:[email-masked]] On Behalf Of Theo Zourzouvillys
> Sent: Thursday, July 23, 2009 12:41 AM
> To: Spencer Dawkins
> Cc: SIP-CLF Mailing List

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 23 Jul 2009 10:04:22 -0500

> IPFIX folks are aware about this. 

I am not an expert at ipfix, so if Theo, Hadriel, or Spencer
would rather make a presentation, that is fine.  Otherwise, since
I am making a presentation on SIP CLF at the opsarea meeting
anyway, I can quickly present a digested version of that
slide deck at ipfix.  Regardless of who makes the presentation,
I can share the opsarea SIP CLF slide deck so we can beg,
borrow or steal slides from it for ipfix.

Thanks,

- vijay

---

From: "David Harrington" <[email-masked]>
Date: Thu, 23 Jul 2009 11:05:29 -0400

Hi,

My concern is that I am not quite sure what we are trying to log, or
why.

If we are trying to log events that occur, then syslog might be a
reasonable choice for a logging protocol.
If we are trying to log the series of IP flows that make up a SIP
transaction, then ipfix might be a reasonable choice for a logging
protocol.
Somebody suggested using libpcap format, which would indicate that we
are trying to capture the packets that make up a transaction, for
later off-line analysis. If so, then libpcap might be a reasonable
logging protocol.
If we want to use an IETF standard protocol for packet captures, or if
we do not need to capture every packet, but just sample the flows
enough to be able to track the transaction, then PSAMP might be a
reasonable logging protocol.

If there are multiple purposes we are trying to meet, then it might be
best to address each purpose separately. There may be existing
standards that would meet the separate requirements very well, but no
standard that can meet the combination of purposes because the
requirements are so varied and potentially in conflict.

I am not promoting any particular solution. I would like to make sure
we discuss the targeted purposes and the subsequent requirements, so
we can best assess whether any of the existing IETF standards or
industry defacto standards meet those requirments.

I am a bit concerned that the charter seems to have a goal of defining
a data model, without knowing what the corresponding transport
protocol will be (if transporting the data is not a requirement, why
should the IETF standardize it?). The format that the data can take is
often inter-dependent with the protocol to be used to transport it.
For example, we have existing pairings - SMIv2 MIBs and SNMP, IEs and
IPFIX, XML and Netconf, SDEs and syslog. I am not sure it makes sense
to define a common log format without knowing which protocols will be
used when it is being transported.

It is possible we could define an information model rather than a data
model, but the plan to define a specific vendor-neutral format says we
are working on a data model. See RFC 3444 for a discussion of the
difference between information model and data model.

Part of my concern about the data and the transport protocol is driven
by my OPS-DIR role; part of it is driven by my SEC-DIR role. How
sensitive will this information be? Will this potentially be used as
evidence in legal proceedings? How much information will there be?

If it used for intrusion detection purposes or as evidence, does the
data-in-flight need to have integrity protection? Will this data be
used as a legal audit log? i.e., does the data-at-rest need to have
integrity protection?  SIP transactions might include information that
should be subject to privacy protection - protection against revealing
personal information, and that means confidentiality and integrity
must be preserved for data-in-flight as well as data-at-rest. 

The charter talks about meeting efficiency requirements for client and
server. What about resource requirements? How much information do we
expect might be generated? What happens if the buffer fills? Do we
discard old data? That could enable an attacker to force a buffer
overflow to hide their tracks. Large buffers of information could
cause problems in storage-or-CPU-constrained enviornments; IPFIX is
designed to off-load information quickly to reduce local resource
requirements. 

Without understanding how this data is expected to be used, we do not
know the requirements that must be met for operations, management, and
security while at rest and while in transit to support the use cases.

I think the applicability of the data to be collected really needs to
be nailed down much better than this charter proposal does. I think
the operations, management, and security requirements need to be
nailed down better. Then we can realistically talk about what the
field formats should be.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: Wednesday, July 22, 2009 11:05 AM
> To: SIP-CLF Mailing List
> Cc: David Harrington
> - the answer 
> to figure this

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 Jul 2009 17:09:37 +0200

No expertise of IPFIX is required at this stage, I guess, but rather
presenting the problem space and mentioning that IPFIX is considered as
a possible solution or part of the solution for SIP-CLF. Stealing slides
used in OPSAREA should be fine. 

Dan

> Sent: Thursday, July 23, 2009 6:04 PM
> To: Romascanu, Dan (Dan)
> Cc: Theo Zourzouvillys; Spencer Dawkins; SIP-CLF Mailing 
> List; Nevil Brownlee; Juergen Quittek
> > the IPFIX meeting next week and make a five minutes presentation so 
> > that IPFIX folks are aware about this.
> 
> would rather make a presentation, that is fine.  Otherwise, 
> since I am making a presentation on SIP CLF at the opsarea 
> meeting anyway, I can quickly present a digested version of 
> that slide deck at ipfix.  Regardless of who makes the 
> presentation, I can share the opsarea SIP CLF slide deck so 
> we can beg, borrow or steal slides from it for ipfix.
> 
> Thanks,
> 
> - vijay
> --

---

From: "Juergen Quittek" <[email-masked]>
Date: Fri, 24 Jul 2009 09:01:33 +0200

At the IPFIX session we will have a presentation of

    http://www.ietf.org/id/draft-huici-ipfix-sipfix-00.txt

It would be great to have both presentations together in the same session.
I would prefer to have both in IPFIX as a use case discussion.

As Dan said, at this point in time no background knowledge of the
IPFIX protocol would be required. But for both use case we could
receive good advice from the SIP experts on pros and cons of using IPFIX.

Thanks,

    Juergen

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 23 Jul 2009 19:03:12 -0500

I agree with Dan here.

Thanks,

Spencer

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Vijay K. Gurbani" <[email-masked]>
Cc: "Theo Zourzouvillys" <[email-masked]>; "Spencer Dawkins" 
<[email-masked]>; "SIP-CLF Mailing List" <[email-masked]>; 
"Nevil Brownlee" <[email-masked]>; "Juergen Quittek" 
<[email-masked]>
Sent: Thursday, July 23, 2009 10:09 AM
Subject: RE: [sip-clf] draft CLF charter

Dan