this has been exactly the kind of discussion I was hoping for!
I agree that we have bigger issues than timestamps - that is just my pet
peeve
So to take a stab at things... we may need to define:
1. What a clients responsibilities are (with respect to [wrt] content)
2. What a servers responsibilities are (wrt confirming that content was
received and recorded).
3. What a client and servers responsibilities are wrt network services:
ie - privacy, compression, authenticity, non-repudiation
4. What are requirements for claiming compliance.
-----Original Message-----
From: Carl Friedberg [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 19, 1999 3:01 PM
To: 'Chad.Schieken'; syslog-sec
Subject: RE: introduction
<snip>
A bigger issue here will be a clear definition of our objectives beyond
documenting the existing syslog(s). These clearly include
(1) integrity of the logfile;
(2) validity of data in the logfile;
(3) networking issues, such as encryption and authentication of syslog
clients and communication paths.
(4) Is UTP the right way to go? (flame suit on).
But we do need objectives.
In my case, I am more involved with non-Unix systems (e.g., OpenVMS and
WindowsNT) but I need a reliable network logging service (I only know about
this because of several boxes that emit syslog messages). Of course, much of
the world has gone over to building network appliances which included http
servers, so we don't want to go over that ground...
<snip>
