> > code, the complexity to maintain them, and the lack of standardisation.
> > That is a main reason to write a RFC. And implement it.
> This sounds like the typical "because we didn't do it or because we didn't
> invent it" excuse. Typically the end result from people who uses excuses
> like that (commonly known as the "Not-Invented Here" syndrome) hardly ever
> produce something that is better, just different.
Hai Darren (I'm Sorry for the late reaction ..)
When I back read my mail and you reaction on it, it sound like I have
offended some people, including you, which wasn't I intention. I'm sorry!
Hai all,
I"dare say we do not suffer on a "Not Invented Here" syndrome! Personally, I
have argued to use syslog-sign and syslog-reliable. I did look into the
latter
implementations efforts.
However for syslog-reliable, as good as the protocol is, there are no
implementations yet!
We (my customer: "the Dutch tax computer centre") are not developing a
"box", or
sw in general!
We try to run a network :-) And USE the standard. And/or demand (ask
politely:-) that
it is used by the boxes (routers, switches, computers, ...) we need.
We can make small implementations ourselves (or let them make ..) , as last
resort.
So, Syslog-reliable isn't option NOW. As we can't "get" it!
And for security and efficiently (of out firewall), UDP isn't "nice". The
management demands a
TCP link.
So, I had several options and non options
* NO syslog-reliable
* NO UDP
* NO "self invented, hard to maintain ..."
* Bay something that is open and good (Non found)
* Use opensource, and make sure the customer can maintain it themselves
* Implement a simple protocol
* ...
As said, syslog-ng, and others, already do use a TCP binding. I have opt for
that.
However, as it only sends the rawdata, which make it hard to extent, should
it ever
be needed. E.g. to incorporate kerberios authentication (which is "hot"
here:-)
So, we tried to extend "your" protocol. We use small headers as "commands",
but still
have the /n as sync. But we can also setting up "reverse" connections (to
fetch log,
instead of push it) and do other "tricks".
As this with a small protocol, and a small, simple to maintain
implementation.
ALL I'M ASKING IS: Please read the protocol, see where we can change the
document, so that most current TCP implementations are "within spec".
(or can simple become ...)
ALL I CAN OFFER IS: to document the protocol as a RFC. And to publish the
implementation.
I will end with another quote of Darren:
> that it at least fulfills all the requirements that syslog over TCP has
> (and that's more than just sending messages in text over a TCP
connection.)
Because I really agree with him. We (I) needed a simple protocol.
We have it, I can offer it. You can ignore it.
However, I hope we can cooperate and fill the gape between the current
not-standard
pratice of syslog-over-TCP and the "high end" syslog-reliable. I would like
that,
Please respond!
