At 02:05 PM 10/20/1999 -0400, [EMAIL PROTECTED] wrote:
>>>>>> "Darren" == Darren Reed <[EMAIL PROTECTED]> writes:
>
>Darren> This is somewhat related to the other IETF syslog effort.
>
>Darren> See draft-abela-ulm-05.txt on your local IETF ftp server.
>
>Darren> I think message content and the protocol used by syslog daemons to
>Darren> exchange information are two different problems.
>
>Unfortunately, I disagree. We have 3 options here:
>
>- Leave _all_ message contents unspecified
>
>This means we use regexps to dispatch data, or we throw it all in the same
>place, as there is nothing of fixed format. This is a bit random for my
>tastes.
>
>- Specify _some_ message contents
>
>This is what syslog does today. Facility and Severity are specified. The
>rest is implementation specific. I would, at a minimum, add originating
>system time to this list. I like this option the best, and we can have lots
>of arguments about what is specified, what is mandatory, what is
>optional... :)
>
>- Specify _all_ message contents
>
>This would combine the 2 efforts, and is, I beleive, too difficult to
>accomplish.
I tend to agree with Carson that the middle approach is good.
What we can do is to specify how the contents of log messages will be
protected (at whatever level or levels are needed), specify the minimum
amount of syslog-sec-specific message content required to do this (>= 0),
and otherwise leave message content alone.
Looking at draft-abela-ulm-05.txt, it seems that additional fields required
for authentication could be added to their proposed ULM (Universal Logger
Messages) scheme without too much hearbreak. Ordering of fields for
purposes of hash computation would probably be important to syslog-sec, but
field order seems to be pretty irrelevant to ULM records for other purposes.
A new field could be added for authentication. The whole record could be
encrypted for privacy (field label Encrypted-ULM, perhaps) alongside basic
syslog info (date, origin host, etc.) for record handling.
If there is a working group formed for syslog-sec, I hope it will consider
this work as the basis for a message syntax rather than inventing a new one.
Bob
