RE: [Syslog] stream transport wasdraft-ietf-syslog-transport-tls-01.txt

[Miao Fuyou <[e-mail]>]

 
I believe when people talks about TLS, he is talking about RFC4346 or
RFC2246 rather than DTLS. TLS itself is over TCP, so it is not illogical to
include something about TCP. 

Yes, maybe it is favorable to have Syslog over TCP and Syslog over DTLS for
Syslog working group. But, there will be several transport documents for the
working group:
1, Syslog over UDP, already there and favorable for implementers
2, Syslog over TCP, what is the benefit? 
3, Syslog over TLS
4, Syslog over DTLS, I reckon implementer would like it, but does IESG
satisfy to this transport? 
With so many transport, implementer will be puzzled. Which is recommended by
the working group? The current ones are option 1 and 3.


> -----Original Message-----
> From: Tom Petch [mailto:[e-mail]] 
> Sent: Friday, June 16, 2006 4:13 PM
> To: [e-mail]
> 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" <[e-mail]>
> To: <[e-mail]>
> 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
> [e-mail]
> _______________________________________________
> Syslog mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/syslog
> 
> 
> _______________________________________________
> Syslog mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/syslog
> 



_______________________________________________
Syslog mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/syslog