This general topic was hashed out quite a while ago, but I don't think
it's been hashed out with regard to syslog-reliable in particular.
I know there's a great desire to have 100% backward compatibility and
also not get into the details of what goes into the actual syslog messages.
But... I'd have to agree with Albert that we're missing a big
opportunity here to make life easier for the future. And I don't see
the harm as long as we don't break backward compatibility and don't get
into message formatting details.
As to Albert's particulars:
* I'm not sure you need to be too flexible on severities - they're
an ordered set by definition, after all. So I think we can drop
this one.
* I'd really like to see ISO 8601:1998 as an allowed time format.
This should be fine as long as "legacy" time format is still
allowed too.
* I'd also like to see string-type facilities. In particular, I'd
recommend expressing them as a hierarchy in the form
base-facility/sub-facility/program-name (e.g.,
mail/mta/sendmail). We can avoid the message-format question by
only standardizing string representations only of the existing
facilities from syslog-syslog, but with a mention of possible
future drafts/rfc's/standards that would expand on this. Again,
this should be fine as long as you recognize the "legacy" facility
mechanism too.
* And yes, at least mention the possibility of using XML-formatted
messages and/or other message formats (such as ULM) and that there
could be a future drafts/rfc's/standards on the subject.
Albert Mietus wrote:
>Hai all
>
>Syslog-reliable, is more or less a secured version of syslog. But it's
>also a "modern" protocol. It uses mime, it uses XML, etc.
>
>Those modern influences are simply great. BUT, ...
>The current proposition is also very old-fashioned. It allows only a
>very limited set of facilities and severities. It want/needs short
>messages (at least, I understand the log-messages are still limited to
>1024 bytes), etc.
>
>Why aren't XML'ed priorities possible? Why shouldn't we at least
>_suggest_ to use XML'ed log-messages?
>Why are daytimes still without year (sure, we don't have a year 2000
>problem, this way :-). Why do we think a second is long; even when a PC
>operates at speeds 1000000000 times faster (1Ghz)?
>Even Windos know about "daylight saving time" now; and about
>time-zones.
>But modern logging still forbids sometime more clever then localtime.
>
>Sure, we need to be compatible. But doesn't that mean syslog-reliable
>can transport/use old style messages. It does!
>But, It see no reason to define a modern logging-system, that's only
>goal is to be compatible. Can't we do that better.
>
>I suggest to redefine those parts that are limiting, and/or
>old-fashioned. And to skip those limits. *BUT* require (in the
>document, and in our work) that t is still possible to
> 1) use (old) syslog-syslog messages in a modern syslog-reliable environment
> 2) operate a modern syslog-reliable environment such, that parts can
> be implemented with old style, limited, utp syslog-syslog
> components (relay, collector) WHEN NEEDED.
>
>This means, we can intermix syslog-syslog and syslog-reliable
>components. That we can use a modern protocol, which it's (security)
>enhancements, as syslog once was made.
>AND, that we have a (syslog) logging system that can be used (again)
>for years and years. New "userland features" etc can be rolled out,
>when needed.
>
>This also enhances the security of the system. Modern security is also
>about "looking ahead". Comparing several logs, of several site, and
>locations. This does require a better timestamp then the current 15
>byte, which is all that is ALLOWED now!
>
>
>See you
>
>
>---GAM
>"This should be a jolly quote"
>====
>Do NOT send MS-Word or other MS-bits to me!
>I can read them now, but I still don't like it.
>
--
Chris Calabrese
Internet Security Analyst
MerckMedco.com
