Chris/Rainer,
> we continue to use <PRI>... at the start of syslog messages. This will
> allow current receivers to continue to receive messages and put them in
> the right bins. Does anyone disagree with this?
Complete agreement.
>
>
> The WG has agreed to use the timestamp Rainer has in the current
> syslog-protocol.
In principle I agree with the timestamp format. It is good.
I may have missed the discussion on this matter, in that case please
accept my apologies and ignore the rest of the mail.
To get existing BSD syslog devices specifically relays into the compatibility
fold it WILL be good idea to keep the timestamp in two parts
RainerTimestamp = BSD_syslog_timestamp + RemainderTimestamp
> One possibility would be to assemble a syslog message as:
>
> <PRI>TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG
In the context of what has been said above about the timestamp. I would
suggest
<PRI>BSD_syslog_timestamp FQDN VERSION MSGID Remainder_Timestamp [SD-ID]s MSG
That would allow existing BSD-syslog relays to handle the new syslog protocol
in a transparent manner. Everything from VERSION to the end is treated as
"message".
We do not lose information.
The Remainder_timestamp carries it - in a slightly less convenient place
though.
On the other hand if we insist on using RainerTimestamp, existing BSD_syslog
relays will relay the message as
<PRI>BSD_syslog_timestamp FQDN RainerTimestamp FQDN VERSION MSGID [SD-ID]s MSG
The message does get distorted to some extent.
> If we can agree to this then I suspect that we can have a working
> document within Rainer's timeframe. I'll propose the following charter
> to keep us focused.
>
> -------- Proposed Charter --------------
>
> Syslog is a de-facto standard for logging system events. However, the
> protocol component of this event logging system has not been formally
> documented. While the protocol has been very useful and scalable, it
> has some known security problems which were documented in RFC 3164.
>
> The goal of this working group is to address the security and
> integrity problems of the existing syslog mechanism while not breaking
> backwards compatibility. The most obvious problems that need to be
> addressed in the syslog protocol are the timestamp, which has not
> formally included a means to indicate the year, and the identification
> of the source which has been a hostname without a qualified domain
> name. Additionally, a version, some type of message indicator, and a
> means to convey structured data will be included in the protocol.
>
> syslog has traditionally been transported over UDP and this WG has
> already defined RFC 3195 for the reliable transport for the syslog
> messages. The WG will separate the UDP transport from the protocol so
> that others may define additional transports in the future.
>
> - A standard will be produced that formally documents the syslog
> protocol. A mechanism will also be defined in this specification
> that will provide a means to convey structured data.
>
> - A standard will be produced that documents the UDP transport for
> syslog.
>
> - A standard will be produced that documents a mechanism to sign
> syslog messages to provide integrity checking and source
> authentication.
>
> - A MIB definition for syslog will be produced.
>
> -------------------------------------------
>
>
> PLEASE review this and respond.
>
Glenn
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
