Linda, Thank you for your comments and my apologies for not responding earlier.
Bear in mind that this I-D was written in 2006 when the tls draft did not exist in its present form and so could not be referenced. It has been re-issued now in the light of renewed interest in the topic and this required the references to be updated but otherwise the I-D was not changed. So yes, more revision is needed and hopefully will happen next week. Meanwhile, bear in mind that it was written to offer alternatives to the approaches being considered in 2006, especially that the roles of DTLS client and server could be reversed with advantage which in turn needs a protocol to agree this, which in turn is a common practice with other TLS applications and so was lifted from that. As to whether or not this is a good idea, well, the way to find out is to write an I-D and see what the response is. If there is no consensus to support an idea, then the editor removes it:-) Tom Petch ----- Original Message ----- From: "fenghongyan" <[email protected]> To: <[email protected]> Sent: Saturday, April 11, 2009 6:20 PM Subject: [Syslog] Review ofdraft-petch-gerhards-syslog-transport-dtls-01.txt" > Hi, > > I read this proposal "draft-petch-gerhards-syslog-transport-dtls-01", > I have some comments on it: > > Those changes I made in my new version this draft is also need to make, I think. > > > section 1.3 > The security discussion is similar as stated in syslog/tls, Pasi > recommended simply pointer to syslog/tls would be better. > > section 1.4 > This is covered in syslog/tls; a pointer to that document would work. > > section 2.1 > I don't see if there's a necessary for a syslog server should be a DTLS client. > In my understanding, a dtls request is alway initiate by a dtls client, if syslog server being dtls client, > how does a server know which client want to connect to it? > I think RFC5425 has state authentication in very detail and come up the corresponding security policy. > Also, fingerprint is aim to cover the case you discussed in your draft having a certificate url authentication. > A pointer to that document would work. > > section 2.2 > I think a udp "registered port number" is required to assign for udp mapping and > a sctp "registered port number" is required to assign for sctp mapping respectively. > > section 2.3 > I claimed in my proposal to minimize the operation and security where > both syslog/tls and syslog/dtls are supported, why do you need write > the commands in your proposal? > > section 2.6, section 2.8 > It is covered in syslog/tls security policy; a pointer to that document would work. > > Thanks > Linda > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
