Subject: RE: [Syslog] RE: Message format

From: "Moehrke, John \(GE Healthcare\)" <[email-masked]>
Date: Wed, 23 Nov 2005 09:02:55 -0600

I don't think we are asking for anything specific. The XML payload (RFC
3881) is text, and somewhat human readable. We went with XML payload
because we have well defined object identifiers that have been
standardized and used throughout the hospital by many different systems
provided by many different vendors. These identifiers cover data
objects, patients, doctors, equipment, drugs, orders, etc... Taking this
nicely coded information and putting it into a unformatted string seemed
very counter. The XML string is descriptive enough that simple string
parsing works, but is also well defined so that XML parsing can be done
as well.

What I am trying to do is figure out if the charter for this group is
really to force the payload to be a human readable text string, or if
the payload can include an XML formatted event description. 

We do not need binary. We do not need Mega-Byte MTUs. We really have
tried to fit within the requirements that we understood syslog to have.
We (healthcare) want to do what we do best (treat patients), and leave
you (syslog) community to what you do best. We don't want to
analyze/report/alert/etc on security events, we expect you are experts
in this field. It is a shame to see this get in the way of an
opportunity for both of us.

John

> -----Original Message-----
> From: Darren Reed [mailto:[email-masked]] 
> Sent: Wednesday, November 23, 2005 8:09 AM
> To: Moehrke, John (GE Healthcare)
> Cc: [email-masked]; Rainer Gerhards; [email-masked]
> Subject: Re: [Syslog] RE: Message format
> 
> > To all,
> > 
> > The view that syslog must only be used to transport "human readable
> > syslog messages" is disturbing. Is this the view of the syslog
> > community?
> 
> At present what we're concerned with is a logging facility that does
> generate and consume human readable messages.
> 
> At some point in the future, when we have agreement on the human
> readable version, then we can consider what to do with messages
> that aren't human readable.
> 
> So while I accept your assertion, addressing it is out of scope for
> the current discussion.  We have smaller fish to fry, first, before
> attempting the big ones.  Trying to solve "all the problems" is what
> got this group into the situation we are in now.  We need to take a
> step back and focus on resolving smaller and more well defined
> problems before looking at a "grand unified logging protocol" (GULP).
> 
> Nothing lasts forever, not even standards.
> 
> Darren
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 23 Nov 2005 22:05:50 +0100

Sounds more like one for the netconf WG, where XML is king, backwards
compatability is not an issue, messages can be orders of magnitudes larger,
security is inherent etc etc.  The only downside is that work on
notifications/events has only just started but one school of thought is that it
should be syslog-like.

What you want could be to netconf as private.enterprises is to SNMP.

Tom Petch

----- Original Message -----
From: "Moehrke, John (GE Healthcare)" <[email-masked]>
To: "Darren Reed" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 23, 2005 4:02 PM
Subject: RE: [Syslog] RE: Message format

John

---

From: "Andrew Ross" <[email-masked]>
Date: Fri, 25 Nov 2005 12:37:24 +1300

Hi John,

I guess the whole thing depends on how one would define "human readable". In
my view, XML tags and content are still human readable. Binary data could
also be counted as human readable if it was preceded with a tag and encoded
in base64 etc. Something like [Bin_Data_Base64 = "kahskdjashd=="] would be
fine. That way it would be obvious to someone reading the log what part is
what. 

The idea is to avoid someone trying to send chunks of unencoded binary or
hex data over syslog. 

Syslog was originally intended as a way of alerting operators to system
malfunctions or things that required their attention. By tailing the
Alert/Warning/Error logs on the console, it was easy to keep an eye on the
condition of the systems. Some apps would also send verbose debug
information to the logs. This was usually never seen by the operator and
simply written to disk for analysis later. 

Sending XML medical or encoded binary data over syslog would fall into the
debug category since no human would be reviewing the logs in real time on
the screen. As long as you choose the level and facility (<PRI>) correctly,
I feel it would still work fine.

That is just my opinion. I'd be interested to hear what others on the list
have to say.

Cheers

Andrew