Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 30 Nov 2005 18:16:46 +0100

Darren,

sorry, but this one calls for a very blunt and direct answer... All
others, this is flamish, but I can no longer stand it. Enough is enough.
Complaints and flames please to me personally.

Rainer

> -----Original Message-----
> From: Darren Reed [mailto:[email-masked]] 
> Sent: Wednesday, November 30, 2005 4:48 PM
> To: Rainer Gerhards
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting
> 
> > Andrew,
> > 
> > > Also, if we are to transport syslog over TCP at some stage, 
> > > we need to keep
> > > a delimiter character free from use in the message. Again, a 
> > > LF would be a
> > > good choice for this delimiter.
> > 
> > Here, I disagree. I think we can not set aside a character 
> for this. If
> > we go for TCP, let's do octet-couting. Its reliable, efficient and
> > proven. Anyhow, we are not yet doing a TCP mapping, so I 
> suggest we save
> > this discussion until later.
> 
> Why not use LF?

Because we - the WG!!!! - have said we want to have the full character
set available in the message. Search the archive. Read the drafts. I am
tired of doing (re)search for you. I have better things to do than to
support your lazyness.

The past days, you've brought up a lot of arguments, declined proper
queries on your own research (which seems to be non-existing, by the
way), thrown in vaporware and shown that you do not know the contents of
the drafts.

Can you tell me a single reason why I should take your seriously?

Ignorance is not a good replacement for evidence.

> It will work.  There are syslogd implementations about that use LF as
> a record delimeter.  In other emails you're saying "we must support
> binary because some people are going to use this".  Now we've 
> got people
> that support LF as a record delimeter already but you don't want to
> take this into account.

If we change that, we need to change the whole idea. Tell me a single
implementation that relies on LF as terminator. On UDP. I know it is
done in TCP, but that's a different story, because there it is not part
of the message but part of the framing (I guess you understand the
difference?). TCP needs to be redefined in any way. So, once again,
would you please come up at least once with evidence for your claims?

> 
> Why does what one vendor is going to do mean more than what other
> vendors are already doing ?  Is there bias here somewhere ?  Do you
> have any particular preference based on work you've done or through
> some sort of affiliation ?

My preference is to finish *this* work. It doesn't help to restart this
discussion. May I provide a quote from Marshall T. Rose in a similar
situation in this WG:

###
to carry your argument to its logical conclusion, no working group would
ever actually produce any final document, because someone would always
be
free to introduce additional requirements for a just and noble cause.

the ietf is about engineering, not perfection.

engineering is about bounding a problem, looking at the tradeoffs, and
coming up with a solution.

the ietf is about fairness, not perfection.

fairness is about providing an process that has transparency and
closure.

the time to raise these issues was when the group was developing the
charter
and negotiating it with the iesg...
/mtr
###

(see http://www.syslog.cc/ietf/autoarc/msg00336.html, Jan, 6 2001)

Rergarding my affiliation and past experience: I have actually
*implemented* EVERYTHING that currently exists in syslog. Even RFC 3195.
Both on Windows and Linux. How about you and your experience and
affiliation? [you even quote code without knowing how the iov[] is
handled later on in F_FORW... poor guy...]

> If you want to discount use of LF as a record delimeter then there
> is no reason we must support use of binary because what vendors are
> doing is obviously irrelevant.
> 
> Darren
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Darren Reed <[email-masked]>
Date: Thu, 1 Dec 2005 06:01:48 +1100 (EST)

> tired of doing (re)search for you. I have better things to do than to

I don't see why having a full character set available in a message means
that you can't chose to select a particular character for an EOR marker.
Protocols everywhere use special characters for this or that yet there
are no restrictions on what messages they convey.

Maybe I'm confusing implementation detail with protocol specification
by asking for LF be used as a EOR marker.

So, you're right, we shouldn't set aside any particular character to
mean EOR in syslog-protocol, that should be left up to the construction
of syslog over each protocol.  Do you agree on that?

> discussion. May I provide a quote from Marshall T. Rose in a similar

Marshall T Rose is responsible for 3195 and that could be considered
to be a failure by many.

> How about you and your experience and affiliation?

I was the focal point of a lot of people wanting to do work on the syslog
protocol before the WG formed.  At the first syslog IETF BOF I gave a small
presentation on the work I'd done to implement syslog over TCP, including
using SSL as the transport with the transfer of hashes and storing them
on disk.  At the first BOF there was a large room full of a lot of people,
a far cry from the numbers in Vancouver.

The syslog replacement I wrote over 5 years ago was the basis of the work
that has resulted in syslog-ng for Linux, even though today it no longer
even closely resembles what I did originally.

I, like many I suspect, became disenchanted with the direction of the
group when it started to go down the road that led to 3195 and I just
lost interest for a long time because I did not have the energy to put
into fighitng it.

In this group, I represent myself.

Darren