Hello everyone,
I'm in the process of writing a new syslog server and thought it'd be cool
to make it comply with the latest and greatest syslog rfc. But after reading
draft-ietf-syslog-protocol-20 (DISP20), I have a number of concerns:
(a) Section 5.1.
I don't quite see how a "non-disruptive transition" can be achieved by
requiring new implementations to support udp and tls transports. I have no
use for the udp transport because transport level reliability is a
prerequisite for my project. People writing a local syslog server that will
only be deployed on their lan will probably not see any value in the tls
transport either. If at all possible, please change the language in this
section to SHOULD instead of MUST. There are other ways to achieve a
non-disruptive transition [see point (c) below].
(b) Section 6.
I don't understand why PRIVAL in the ABNF is restricted to 0..191,
especially since section 6.2.1 claims that PRIVAL as described in that
section is not normative. How about simply saying that PRIVAL may have any
value and moving Tables 1 & 2 to an appendix titled "Recommended PRIVALs for
Unix-like Platforms" or something similar ? As it stands, it looks too much
like syslog is being designed for Unix-like platforms only.
(c) Section 6.2.1.
I have issues with the requirement that PRIVAL MUST start with "<", end with
">" and not have more than 3 decimal digits. The problem is that this makes
it very hard to detect if any given message should be parsed according to
DISP20 or according to common usage (RFC3164). If you do the exact opposite
by requiring PRIVAL to satisfy one or more of the following:
(i) starts with any token other than "<" (choose for example, "<!" or "<-")
(ii) ends with any token other than ">" (choose for example, "->")
(iii) has a minimum of four decimal digits
then by simply looking at PRIVAL, the message receiver can decide whether
the message is from a DISP20 compliant source and should be parsed
accordingly. This also facilitates a non-disruptive transition to the new
syslog protocol.
Cheers,
Mike
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog