Subject: [sip-clf] What does "both" mean?

From: Peter Musgrave <[email-masked]>
Date: Tue, 1 Jun 2010 07:09:16 -0400

HI all,

The WG has agreed to work on "both" an IPFIX and a text based logging format.

What does this imply for implementors who say they support sip-clf?

Do they have to be able to generate both formats?   (I would assume
not typically at the same time)

Can they generate only one? (They can then claim support for e.g. sip-clf-ipfix)

Are we ok with having them support only one if we have community tools
to do the conversion?

Regards,

Peter Musgrave
(As individual)

---

From: Brian Trammell <[email-masked]>
Date: Tue, 1 Jun 2010 13:27:13 +0200

Hi, Peter, all,

I would suggest, in the end, that the WG publish an RFC for each format, each referencing a common data model/architecture/what-have-you RFC. Implementors would then reference the representation they use. Support for the SIP-CLF "core" then is kind of meaningless without support for at least one defined representation.

In such a structure, I suspect that the IPFIX RFC would reference the text RFC as a MAY or SHOULD additionally support, while the text RFC would reference the IPFIX one "according to implementation requirements" or similar (the idea being that the IPFIX format is more applicable to large scale log processing, while the text format has the advantage of simpler tool support). But this is getting ahead of the question I think.

I think it's essential to support implementations generating only one, since each format has different areas of applicability, although I would also presume that there will be conversion tools as well.

Cheers,

Brian

On Jun 1, 2010, at 1:09 PM, Peter Musgrave wrote:

> _______________________________________________
> sip-clf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-clf

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 21 Jun 2010 11:45:06 -0600

My memory of the meeting was the WG was happy to see work on both as drafts, not necessarily that they wanted two standards publsihed. I though they were both proceeding so that we could later decide if we wanted A,  or B. I'll point out we are charted to produce one not two. I will be strongly arguing two standards is worse thn one.  

> Are we ok with having them support only one if we have community tools

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 22 Jun 2010 08:38:34 -0500

On 06/21/2010 12:45 PM, Cullen Jennings wrote:
> My memory of the meeting was the WG was happy to see work on both as
> drafts, not necessarily that they wanted two standards publsihed.

Cullen: My impression was the opposite, i.e., okay to produce
two representational formats of SIPCLF based on a common data model.

> I though they were both proceeding so that we could later decide if we
> wanted A,  or B. I'll point out we are charted to produce one not
> two. I will be strongly arguing two standards is worse thn one.

I understand, but in this case I think that advantages and dis-
advantages of each approach have been discussed and are, if I may
venture, clear to each community.  With a common data model, it
seems reasonable to have two representational formats.  Otherwise,
I am afraid we'd get bogged down all over again in the (indexed)
ASCII versus IPFIX discussion, which sapped away energy the last
time we did this.

BTW, the charter does not --- at least to my reading --- appear
to preclude us from more than one representation of a common
data model.

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: "Saverio Niccolini" <[email-masked]>
Date: Thu, 24 Jun 2010 18:14:58 +0200

Cullen,

the charter says:
"The working group will identify the fields to appear in a log
record and provide one or more formats for encoding those fields"

to me this reads like: we can clearly have two.

Am I missing something?
Saverio

============================================================
Dr. Saverio Niccolini
Manager, Real-Time Communications Group
NEC Laboratories Europe, Network Research Division     
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked]
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cullen Jennings
> Sent: 21 June 2010 19:45
> To: Peter Musgrave
> Cc: [email-masked]
> Subject: Re: [sip-clf] What does "both" mean?
> 
> 
> drafts, not necessarily that they wanted two standards publsihed. I
> though they were both proceeding so that we could later decide if we
> wanted A,  or B. I'll point out we are charted to produce one not two.
> I will be strongly arguing two standards is worse thn one.
> 
> 
>

---

From: Eric Burger <[email-masked]>
Date: Thu, 24 Jun 2010 16:49:03 -0400

I fully DISAGREE.

The point of the IETF is to produce interoperable protocols.

In this case, the Log File format is something that one element generates and one or more elements consume.

There is no problem whatsoever not specifying the transport between the log generator and log consumer. For now, it is fine to say "magically gets there."

HOWEVER, it is NOT FINE to have two, fundamentally incompatible formats. If one element generates a log in ASCII and another element expects to read IPFIX, you have no interoperability.

How to move forward?

In my ideal world, we make ASCII mandatory to implement and IPFIX optional.

Since that may be too controversial, I would be willing to live with writing both drafts (ASCII and IPFIX), with an expected status of EXPERIMENTAL. We can then chose later once we have road time and running code.

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 25 Jun 2010 08:20:43 -0400

>In my ideal world, we make ASCII mandatory to implement and IPFIX optional.

I agree with this sentiment, but I'm not quite sure what it means for
implementors of IPFIX.

Does this mean an IPFIX system needs to store BOTH ascii and binary
logs (i.e. double logging)? Would it suffice to log in binary and have
a community tool to convert to ASCII?

Alternatively, could IPFIX logger be something that gets the ascii
logs piped into it and then streams them to whatever device wants the
IPFIX data?

Peter Musgrave
(as individual)

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 25 Jun 2010 06:21:08 -0700 (PDT)

Hi,

> logs piped into it and then streams them to whatever device wants the

I like the sentiment for a different reason - but would argue for first 
doing an IPFIX implementation _then_ doing an ASCII one.

In syslog we've seen things like the following many times:
<header blah blah blah> Src 1.2.3.4 Dst 5.6.7.8 <remainder>
<header blah blah blah> From 1.2.3.4 To 5.6.7.8 <remainder>
<header blah blah blah> Dst 5.6.7.8 Src 1.2.3.4 <remainder>
<header blah blah blah> To 5.6.7.8 From 1.2.3.4 <remainder>

Those can all be figured out by visual inspection.  An operator would need 
to tweak an automated parser to get those into an event correlation 
engine.  However, sometimes we've seen something like the following:
<header blah blah blah> 1.2.3.4:33789 5.6.7.8:44321 <remainder>
In that case you're going to have to go back to the documentation from the 
manufacturor to figure out what's what.  ..and it might change per 
software version level of the device.

>From that, my ideal world would be to creat a very fixed format for each 
message type, with no possibility for ambiguity, and then let people 
migrate those to ASCII messages.  It would be hoped that the potential for 
ambiguity in the ASCII messages would be minimalized through this process.

My answers for Peter's questions:  Each device MUST be capable of 
generating the binary format and SHOULD be capable of generating the same 
information in ASCII.  It would be up to the operator to select which one 
goes into the log file.

Thanks,
Chris

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 25 Jun 2010 09:04:05 -0600

No that reefers to the format of the fields in the log file and was included to have possibility of an "raw"  version of the field as well as a "pre parsed" format of the field to help speed up reading the log file. Through the charter it refers to "The common log format" and "a format". I think it was pretty clearly for one. 

However, charters can be changed if that is the right thing to do. I don't want to get overly hung up on a process issue like the the charter. 

The important thing from my point of view is that at the last meeting we agree to keep working on both drafts before we made a decision about which one(s) to publish. We did not decide to publish both at that point. 

As far as deciding what we should do ... I think having both drafts on the table helps people have enough information to decide. Many of the folks that are not keen on ipfix think it will be overlay complicated and perhaps when they see the draft, they will change their mind. Once people have had a chance to look at the drafts, I think we need to ask the people that are going to implement sip logging in their products what they would be willing to implement and get data about that. Once we have that data we can ask the whole group what they want to publish and decide if a charter update is needed. 

I really don't see many paths forward other than this so I hope most people can agree this is a reasonable path. 

Cullen Jennings

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 25 Jun 2010 10:12:11 -0500

On 06/25/2010 08:21 AM, Chris Lonvick wrote:
> generating the binary format and SHOULD be capable of generating the
> same information in ASCII. It would be up to the operator to select
> which one goes into the log file.

Chris: You are pre-supposing that the SIP server is being
run by an operator.  What if it is not, and is being run
by a small enterprise, a residential user, or a small
department at a university?

The merits and disadvantages of the ASCII approach and the
IPFIX approach have been hashed out in mailing lists and
face to face discussions; I will simply summarize the outcome
of these discussions as each camp views their solution with
enough affinity to be convinced that it is the right path.

I appreciate Eric's and Cullen's sentiment to have a single
representation format, but I don't see how we can get there.
We can, by dictum, mandate IPFIX, but the result will be that
the non-operator community that favors ASCII will develop
their own SIPCLF.  Conversely, we can mandate only ASCII and
force the operator community develop a binary SIPCLF.  Who
wins then?

With both representation formats being specified, there may
be a good chance that someone in the community develops tools
to convert to/from the other one.  Certainly there are enough
tools in existence today that do post-process HTTP CLF.

Thanks,

- vijay

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 28 Jun 2010 07:07:53 -0700 (PDT)

Hi Vijay,

> department at a university?

You are incorrect; I was not pre-supposing anything of that nature. 
However, I should thank you for making my point.

When I used the term "operator" I was referring to the person who puruses 
the log file.  I'm guessing that the term "operator" has a different 
meaning in the SIP area than it does in the traditional OAM area? 
Perhaps I should have used the term "administrator"?

> force the operator community develop a binary SIPCLF.  Who

I'll let Eric and Cullen speak for themselves, but my suggestion was to 
first have a binary format.  That would fix the meaning of each message, 
hopefully in an unambiguous way.  From that, have a corresponding textual 
messsage.

My new example is:
   "Session closed by operator"

To my way of thinking, this means that someone with administrative 
privileges has terminated the session.  That 'someone' may be an 
administrator in a small enterprise or a network administrator in a small 
department at a university.  I'm guessing that you would interpret that to 
be someone from the operator community has closed the session.

Disambiguating this message would benefit everyone.  Perhaps it should be 
differentiated as:
   "Session closed by local administrator"
   "Session closed by remote site administrator"
   "Session closed by operator community"
(I will admit that I'm still not clear on the definition of an "operator 
community".)

> tools in existence today that do post-process HTTP CLF.

I expect that there will be many tools.  What I'd like is for the messages 
to be consistent enough so that any administrator/operator will be able to 
spot trends and problems without having to go through a lot of trouble. 
And by trouble, I mean that someone who is looking through the log file 
won't have to find the manual for some piece of equipment to see how to 
interpret some message that the device generated.

My recommendation stands that very clear messages should be formed by 
first describing them in a fixed format, and then describe them in a 
textual format.

Regards,
Chris

---

From: Eric Burger <[email-masked]>
Date: Mon, 28 Jun 2010 18:04:31 -0400

Speaking for myself, I would offer doing binary first means tons of time figuring out exactly what fields to capture, what values they have, and casting them in concrete, never to be changed in the real world.

Then, tool vendors can spend lots of time writing binary decoders so other developers can debug their log facilities. In a few years, people might even start to write the tools we were hoping would get written analyzing the logs.

In the mean time, perhaps Oracle, RedHat, or someone else manages to get enough market domination that we can just use their ASCII log file as a de facto standard, just like we had with Apache.

A bit of a dystopian view of the world, but a very real possible outcome.

On Jun 28, 2010, at 10:07 AM, Chris Lonvick wrote:

> You are incorrect; I was not pre-supposing anything of that nature. However, I should thank you for making my point.
> 
> When I used the term "operator" I was referring to the person who puruses the log file.  I'm guessing that the term "operator" has a different meaning in the SIP area than it does in the traditional OAM area? Perhaps I should have used the term "administrator"?
> 
>> 
> I'll let Eric and Cullen speak for themselves, but my suggestion was to first have a binary format.  That would fix the meaning of each message, hopefully in an unambiguous way.  From that, have a corresponding textual messsage.
> 
> My new example is:
> To my way of thinking, this means that someone with administrative privileges has terminated the session.  That 'someone' may be an administrator in a small enterprise or a network administrator in a small department at a university.  I'm guessing that you would interpret that to be someone from the operator community has closed the session.
> 
> Disambiguating this message would benefit everyone.  Perhaps it should be differentiated as:
> (I will admit that I'm still not clear on the definition of an "operator community".)
> 
>> 
> I expect that there will be many tools.  What I'd like is for the messages to be consistent enough so that any administrator/operator will be able to spot trends and problems without having to go through a lot of trouble. And by trouble, I mean that someone who is looking through the log file won't have to find the manual for some piece of equipment to see how to interpret some message that the device generated.
> 
> My recommendation stands that very clear messages should be formed by first describing them in a fixed format, and then describe them in a textual format.
> 
> Regards,
> Chris
> 
>> 
>> Thanks,
>> 
>> - vijay
>> --