Subject: [Syslog] Review of draft-petch-gerhards-syslog-transport-dtls-01.txt"

From: fenghongyan <[email-masked]>
Date: Sun, 12 Apr 2009 00:20:28 +0800

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

---

From: "tom.petch" <[email-masked]>
Date: Wed, 22 Apr 2009 15:24:29 +0200

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-masked]>
To: <[email-masked]>
Sent: Saturday, April 11, 2009 6:20 PM
Subject: [Syslog] Review ofdraft-petch-gerhards-syslog-transport-dtls-01.txt"

> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/syslog