I think that this document has some way to go. It has introduced, and woven
together, both TLS and TCP transport, which I think wrong. Ideally, I think
that we should have two separate documents, one dealing with TLS, the other with
TCP issues; given that both would be short, it is probably
I agree with Tom that a TCP document would be useful and probably
needed. Before someone from Huawei comes along and tries to patent this,
too, I volunteer to write this document...
Rainer
-Original Message-
From: Tom Petch [mailto:[EMAIL PROTECTED]
Sent: Friday, June 16, 2006 10:13
Oh... and, yes, there is prior Art: This spec was openly discussed some
years ago on the loganalysis mailing list. While the text itself can not
be used nowadays, I think it conveys many things that need to be
considered.
http://www.monitorware.com/en/workinprogress/selp.txt
Rainer
I was just talking to Rainer about similar concern.
I think first of all we need a basic mapping to TCP or more generally define
syslog payload (framing) format for connection-oriented protocols. This should
cover sending multiple messages over the same connection, obviously. The same
App-layer ACK is an interesting idea, but I think it opens up a big discussion.
Does the relay ACK? Overlap with RFC 3195 (syslog-beep). Overlap with SNMP
Informs. Etc.
Anton.
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
Sent: Friday, June 16, 2006 11:36
Anton,
the ACK should only be from hop to hop - much as in SMTP. It is a method
to know if the data has arrived at the next receiver. I think it
probably is worth it. I can live without the ACK, but I think a defined
closure is needed. An initiation exchange I consider useful, but again
not
