Subject: [Syslog] Announcement: update of my draft, draft-feng-syslog-transport-dtls-01.txt is uploaded.

From: fenghongyan <[email-masked]>
Date: Fri, 10 Apr 2009 16:14:55 +0800

Hi, 

A new version of my draft is available, please feel free to add any comments or suggestions on it.

This revision made some editorial changes, support for SCTP according to Wes's suggestion, 
pointer to syslog/tls rather than reiterating the security discussion according to Pasi's advice.

Please feel free to have comments on this update, your suggestions will help to 
improve the text.

To Rainer and Tom:
I had read your draft after your update uploaded, I think those changes I made in my new version your draft is also need to make. 
DTLS not only works on UDP, also works on transport like DCCP, SCTP. You can see these changes in rfc4347-bis-02.  
The security discussion is similar as state in syslog/tls, simply pointer to syslog/tls would be better I think.

I made some comments on your draft:

1. Those changes is needed as I mentioned above, those security requirements should be removed and replaced with pointer to syslog-tls, i.e. RFC5425.

2. In 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. 

3. Port number, 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.

4. I have claim 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?

5. ciphersuite, tls extensions, authentication can be merged into security policy and pointer to RFC5425.

My "Message Process" section is not satisfied yet, David's comment is "a bit redundant and 
   convoluted".  I think there must be other unsatisfied places existence, would you like to be  coauthors ?
   We can work together to make the proposal on syslog-dtls to be better?

Thanks
Linda