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 AM
> To: [EMAIL PROTECTED]
> 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" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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
> [EMAIL PROTECTED]
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
> 
> 
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
> 

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

Reply via email to