Subject: RE: [Syslog] RE: Message format

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 23 Nov 2005 16:13:38 +0100

I think this is a valid use case. Syslog traditionally has not only
focussed on network management but has always been used for
application-layer event notifications. I think what John asks for is
within our charter and doesn't even require any change to what we have
been discussing so far.

Rainer 

> -----Original Message-----
> From: Moehrke, John (GE Healthcare) [mailto:[email-masked]] 
> Sent: Wednesday, November 23, 2005 4:03 PM
> To: Darren Reed
> Cc: [email-masked]; Rainer Gerhards; [email-masked]
> Subject: RE: [Syslog] RE: Message format
> 
> 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: Darren Reed <[email-masked]>
Date: Thu, 24 Nov 2005 02:44:16 +1100 (EST)

> within our charter and doesn't even require any change to what we have

So long as XML in the message can be satisfied by saying it is part
of the "MSG" section, then yes.  I don't believe there are any planned
restrictions on what the text content of "MSG" can be.

Otherwise we're just going back down the road of 3195.

If John wanted to see XML in syslog formalised, then my vote would for
it to be a follow on draft that documented a particular SD-ID as the
means for indicating the MSG was expected to be XML.

But I cannot emphasise strongly enough that it is not appropriate for
this group to take on syslog and XML, beyond what exists in 3195, at
the present time.  We need to focus on the charter and achieve a basic
set of goals first before moving on to things like this.  This isn't
to say that it won't be addressed, but not here and now.  If this puts
you, John, in uncertain land for the time being then I think that has
to just be accepted with an understanding that it can be redressed at
some point in the future, even if it doesn't make our current charter.

Darren