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

Reply via email to