Subject: [Syslog] WGLC review of draft-ietf-syslog-dtls-01

From: "David Harrington" <[email-masked]>
Date: Wed, 3 Feb 2010 15:32:54 -0500

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-masked]
[email-masked]
[email-masked]