The Syslog Protocol
RFC 5424

draft-ietf-syslog-protocol-21, Section 1., paragraph 5:
>    This document obsoletes RFC3164, which is only an Informational
>    document describing some implementations found in the field.  Some
>    vendors market their products as compliant to RFC3164, but RFC3164
>    does not define a standard.  Hopefully, declaring RFC3164 obsolete
>    will reduce associated bogus marketing claims.

  Suggest to cut the commentary, i.e., cut the last two sentences of
  this paragraph.


draft-ietf-syslog-protocol-21, Section 8.5., paragraph 2:
>    It may be desirable to use a transport with guaranteed delivery to
>    mitigate congestion.

  Reliable delivery and congestion control are orthogonal features. A
  reliable transport will not necessarily have congestion control, and
  vice versa.


draft-ietf-syslog-protocol-21, Section 8.5., paragraph 3:
>    It may also be desirable to include rate-limiting features in syslog
>    originators and relays.  This can reduce potential congestion
>    problems when message bursts happen.

  This is too weak a statement on congestion control. See DISCUSS above.


draft-ietf-syslog-protocol-21, Section 8.5., paragraph 4:
>    Reliable delivery may not always be desirable.  Reliable delivery
>    means that the syslog originator or relay must block when the relay
>    or collector is not able to accept any more messages.  In some
>    operating systems, namely Unix/Linux, the syslog originator or relay
>    runs inside a high-priority system process (syslogd).  If that
>    process blocks, the system at large comes to a stand-still.  The same
>    occurs if there is a deadlock situation between syslogd and e.g. the
>    DNS server.

  This paragraph is inaccurate. One, I'm not aware of any OS that
  doesn't offer non-blocking I/O. Two, even if "a high-priority system
  process (syslogd)" would block for I/O, the system does NOT come to a
  stand-still. It's a user space daemon, not kernel code.


draft-ietf-syslog-protocol-21, Section 8.9., paragraph 1:
>    As shown in Diagram 2, machines may be configured to relay syslog
>    messages to subsequent relays before reaching a collector.  In one
>    particular case, an administrator found that he had mistakenly
>    configured two relays to forward messages with certain SEVERITY
>    values to each other.  When either of these machines either received
>    or generated that type of message, it would forward it to the other
>    relay.  That relay would, in turn, forward it back.  This cycle did
>    cause degradation to the intervening network as well as to the
>    processing availability on the two devices.  Network administrators
>    must take care not to cause such a death spiral.

  A sequence number or - even better - a hop count in the message would
  allow breaking such loops.


draft-ietf-syslog-protocol-21, Section 8.10., paragraph 2:
>    Administrators and network planners must also critically review the
>    network paths between the originators, the relays, and the
>    collectors.  Generated syslog messages should not overwhelm any of
>    the network links.

  Given that syslog can generate unlimited amounts of traffic, no level
  of critical review will guarantee that syslog won't overload the path.


draft-ietf-syslog-protocol-21, Section 8.10., paragraph 3:
>    In order to reduce the impact of this issue, using transports with
>    guaranteed delivery is recommended.

  Again, reliability != congestion control.


draft-ietf-syslog-transport-udp-09, Section 3.6., paragraph 2:
>    It is RECOMMENDED that syslog senders use valid UDP checksums when
>    sending messages over IPv4 and IPv6.

  Agree with Tim's DISCUSS - this language weakens the MUST for IPv6.


draft-ietf-syslog-transport-udp-09, Section 4.3., paragraph 0:
>   4.3.  Congestion Control

  Fully agree with Magnus' DISCUSS.


draft-ietf-syslog-transport-udp-09, Section 4.4., paragraph 1:
>    The order of
>    syslog message arrival via this transport SHOULD NOT be used as an
>    authoritative guide in establishing an absolute or relative sequence
>    of events on the syslog sender hosts.

  Better make this a MUST NOT. Also, IP packets can become duplicated
  and delivered multiple times, which should also be discussed in this
  section.

* When UTF-8 is not used, this protocol does not interoperate absent
  manual configuration on both client and server to align the charset.
  The document should state this clearly.  I'm aware of the charset
  support history in Unix so I understand this is a necessary nod for
  backwards compatibility but the document should make it clear this

* The protocol would be simpler if the UTF-8 BOM was never used.  Use of
  the UTF-8 BOM in this protocol simply changes two cases (UTF-8 or
  unknown charset) into three cases (UTF-8 with BOM, UTF-8 without BOM,
  or unknown charset).  This makes the protocol more complex than
  necessary, reduces interoperability and potentially reduces security.
  A receiver could simply apply the UTF8-octets ABNF rule to the
  received data and if it complies assume the data is UTF-8 unless an
  explicit in-band or out-of-band label states otherwise.

* This text doesn't make sense:
   If a syslog application is processing a MSG starting with a BOM, then
   it MUST be interpreted as being encoded in UTF-8 for the reasons
   outlined in UNICODE TR36 [UNICODE-TR36], section 3.1.
Correct text would say:
   Even when a MSG starts with a UTF-8 BOM, if it contains UTF-8 that is
   not shortest form it MUST NOT be interpreted as being encoded in UTF-8
   for the reasons outlined in UNICODE TR36 [UNICODE-TR36], section 3.1.
Note that the sense of the text in the document is exactly backwards from the security requirement, and this mistake is probably the result of the additional complexity caused by unnecessary use of the BOM.  Note that UNICODE TR36 never mentions the BOM.

* The ABNF for UTF-8-STRING should simply reference the UTF8-octets
  production from RFC 3629 which already mandates shortest form.

* The ABNF would be shorter if it referenced the date-time production
  from RFC 3339 instead of embedding a copy of the ABNF.  For example:

  TIMESTAMP       = NILVALUE / date-time
                  ; date-time is as defined in [RFC3339] and with
                  ; additional restrictions discussed in section 6.2.3.

This will have to be fixed I'm sure:

   The character set used in MSG SHOULD be UNICODE, encoded using UTF-8
   as specified in [RFC3629].  If the syslog application can not encode
   the MSG in Unicode, it MAY use any other encoding.

Is the second sentence supposed to read "If the syslog application can not encode the MSG in UTF-8, it MAY use any other encoding." ?  if so, is that really intentional?  There would have to be a way of specifying the encoding otherwise the recipient cannot interoperably interpret the message.  

If other encodings are indeed allowed, the sections on looking for ASCII control characters will have to be re-examined.

The remaining discuss issues I have, will be handled by Lars Eggert.