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 mandot
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:
Anton,
> -Original Message-
> From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 16, 2006 5:25 PM
> To: Tom Petch; [EMAIL PROTECTED]
> Subject: RE: [Syslog] stream
> transportwasdraft-ietf-syslog-transport-tls-01.txt
>
> I was just talking to Rainer about s
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
payloa
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
> -Origi
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:
We have chosen and used a consistent terminology up until the tls document, so I
think that tls should come in line. I think I see its problem, of not wanting
to use the phrase 'sender or relay' repeatedly, but in that case, it should
generate a new term, not redefine a well-established one. For
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 sensi
