RE: [Syslog] stream transport wasdraft-ietf-syslog-transport-tls-01.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog] stream transport wasdraft-ietf-syslog-transport-tls-01.txt
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:nwnetworks at dial.pipex.com]
> Sent: Friday, June 16, 2006 10:13 AM
> To: syslog at ietf.org
> Subject: Re: [Syslog] stream transport
> wasdraft-ietf-syslog-transport-tls-01.txt
>
> 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
> sensible to have only
> the one, but I still see the need for separation within the
> document. After
> all, DTLS exists: an outsider could, should, think that
> syslog is UDP-based,
> DTLS provides UDP security so DTLS is the obvious choice,
> what on earth is this
> document talking about? We need a section on DTLS (if only
> justifying why it is
> not for further consideration). And, for me, that alone
> justifies teasing out
> the TLS issues from the TCP issues; is FRAME-LEN needed over DTLS?.
>
> That said, I do not think that this document adequately
> covers the TCP issues,
> ones that have surfaced on the list before.
>
> TLSoTCP can deliver one syslog message, many syslog messages,
> part of a syslog
> message or a combination thereof - it is in the nature of a
> stream protocol.
> This needs spelling out.
>
> A TCP connection takes time to set up, TLSoTCP longer. This
> needs spelling out;
> if timely delivery is a concern, then the connection should
> be established in
> advance.
>
> The section on TCP termination is too weak. If we are
> recommending a timeout,
> then we should recommend a value, even specifying that it
> should be configurable
> over a range. And if we cannot agree on such values, I do
> not think we should
> be specifying a timeout.
>
> TCP perforce introduces flow control. This will slow down
> and rate limit
> messages; what is the impact of this on the application?
>
> TCP failures can terminate the connection! Again, this has
> an impact on the
> application with the time taken to become aware that the
> connection has failed.
>
> Tom Petch
>
> ----- Original Message -----
> From: "David B Harrington" <dbharrington at comcast.net>
> To: <syslog at ietf.org>
> Sent: Tuesday, May 09, 2006 4:26 PM
> Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt
>
>
> Hi,
>
> A new revision of the syslog/TLS draft is available.
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01
> .txt
>
> We need reviewers.
> Can we get
> 1) a person to check the grammar?
> 2) a person to check the syslog technical parts?
> 3) a person to check compatibility with the other WG documents?
> 4) a person to check the TLS technical parts?
>
> We also need general reviews of the document by multiple people.
>
> Thanks,
> David Harrington
> co-chair, Syslog WG
> ietfdbh at comcast.net
> _______________________________________________
> Syslog mailing list
> Syslog at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>
>
> _______________________________________________
> Syslog mailing list
> Syslog at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>
_______________________________________________
Syslog mailing list
Syslog at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.