Hi, I have reviewed (a slightly early revision of) draft-ietf-syslog-dtls-01 and have a few comments. Almost all are purely editorial. There are a few questions about technical decisions, and some recommendations that modify RFC2119 language.
I think this document is in great shape, and almost ready for submission to the IESG. section 1: s/ to secure syslog in more situations./and these can be used to secure syslog in more situations./ s/therefor/therefore/ section 5.1: s/Transports, such as UDP or DCCP/UDP and DCCP transports/ s/In such case, the/The/ Based on some advice from Lars, I recommend s/Implementations of this specification MUST support DTLS over UDP and SHOULD support DTLS over DCCP [RFC5238]. / Implementations of this specification MUST support both DTLS over UDP and DTLS over DCCP [RFC5238]. DCCP support itself is not a MUST, but implementations of this specification MUST be prepared to support DCCP where it is available." The sentence starting "Each SYSLOG message" needs some tweaking of the English. s/by DTLS record protocol/by the DTLS record protocol/ I think the last sentence is missing a verb - are delivered. I am not sure that "assure" is the correct word choice. s/such as UDP reliability/such as UDP, reliability/ Can we be more precise than "gone down"? s/state so/state, so/ s/When TCP is used syslog over DTLS MUST NOT be used./Syslog over DTLS MUST NOT be used to secure syslog running over TCP./ s/When a secure transport/When a secure syslog transport/ section 5.2: s/allocated/allocated by IANA/ section 5.3.1. I personally prefer consistency: s/SHALL/MUST/ Some people, including some members of IESG, believe that a SHOULD should describe roughly why this is a SHOULD rather than a MUST. I am not sure I understand why this is a SHOULD rather than a MAY - what vulnerabilities does this create if it is not done? I would like to see a bit more explanation of this SHOULD. section 5.4 s/All syslog messages MUST be sent as DTLS "application data"./A syslog/dtls transport sender MUST send syslog messages as DTLS "application data"./ "The application data is defined with the following ABNF [RFC5234] expression:" I had to think about why this was here; it was not at all obvious to me. My first recommendation was s/application data/DTLS "application data"/ In thinking about it more, I think my confusion was partly because you have text about multiple or split messages between the point that says the message is sent as "application data", and the definition of the format of the application data, so my mind had "gone elsewhere". I recommend taking the discussion of multiple/split messages and put that into 5.4.1, as part of the discussion of message size and dtls records. I think that will make it more obvious that the ABNF is there to describe the format of the "application data". s/be contained/are contained/ s/be transferred in/is split into/ section 5.4.1 s/The message length is/The message length (MSG-LEN) is/ I think it would be helpful to point out the DTLS maximum limits for UDP and DCCP transports, since those are the syslog/dtls mandatory to implement transports. If a syslog message exceeds the maximum for the transport used, will DTLS automatically split the message into multiple records? That was the impression I got from the 5.4 discussion of multiple/split messages. I think it is important to describe this because there are other standards in progress (IHE, sipclf) with very large application data that are considering using syslog as a transport, and if DTLS will make a bad transport for applications with large messages, we might want to make that explicit. section 7 why do we request the same port#? There can be multiple syslog sources on a device (e.g. in a Windows environment). Can this shared port# make things harder to work (or to configure for non-default ports)? good work! Thanks, dbh David Harrington [email protected] [email protected] [email protected] _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
