Thanks, Chris. Yes, mine is an independent effort and not a document for this Working Group. I just provided it here as an example of the sort of payload that could be carried by a syslog message.
Some of the people I'm working with would like to implement RFC 3195 as the message transport, but the message itself is specified in a way that makes it transport-independent. There are two basic cases: 1) Dedicated-function devices such as clinical monitors and digital medical imaging would like a simple but reliable method to report audit data (and, conceptually, other system events) to a central event processing and repository service. This is where syslog is seen as the best solution direction. 2) Some multi-function systems, such as healthcare information systems and distributed networks, could use a standard method that enables two-interaction for audits (e.g., security alarm actions) and system events (e.g., enabling partial failure operating modes). In this case a messaging transport such as ebXML might be a better choice. Having only recently started following the listserv traffic in this group, I don't know if these sorts of distinctions have been discussed previously. Best, Glen -----Original Message----- From: Christopher Lonvick [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 1:52 PM To: Marshall Glen Cc: [EMAIL PROTECTED] Subject: Re: Syslog Payload (was "What Can Be Changed in syslog") Hi Glen, I don't mind if you ask this WG for input on your ID. However, our charter won't allow it to become a document of this Working Group. The same goes for any other proposal related to the formatting of the payload of syslog messages. All: Glen would like to get this ID through the process so it may become an RFC. Having it reviewed by like-minded people helps that process. If you have time+effort, please send comments either to the list or to Glen. Thanks, Chris On Tue, 17 Dec 2002, Marshall Glen wrote: > > Relative to syslog payload format, that may be partly a function of > application domains. I'll call your attention to a draft I posted at the > beginning of this month: > > http://www.ietf.org/internet-drafts/draft-marshall-security-audit-00.txt > > Conceptually, this defines what could be a security audit payload for RFC > 3195 in the healthcare application domain. > > Best, > Glen F. Marshall > > > -----Original Message----- > From: Christopher Lonvick [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 17, 2002 17:41 > To: [EMAIL PROTECTED] > Subject: What Can Be Changed in syslog > > > Hi, > > I appreciate the thoughts of everyone on the topics brought up so far. Let's > make sure that we all understand what we can do within the current scope of > the WG. > > TIMESTAMP This field may be changed in syslog-sign. We'll have to rev > 3195 to accept this after syslog-sign is accepted as an RFC. > > non-US-ASCII characters in the payload. This may be addressed in > syslog-sign, or specified in another Internet Draft (which will > be accepted as a WG document if there are enough people > supporting the idea). Just for reference: > ftp://ftp.rfc-editor.org/in-notes/rfc2825.txt > A Tangled Web: Issues of I18N, Domain Names, and the > Other Internet protocols > > payload length. It's up to the WG to change this. It may be changed in > syslog-sign if that's the concensus of the WG. In that case, > syslog-sign will have to have dire warnings of trying to push > the new format through old-style (3164) relays or collectors. > We'll have to do that anyway if we change the TIMESTAMP. > > payload format. Out of scope. I'll allow discussion on the WG mailing > list (here) but anything coming from that cannot be a document > of this WG. After we accomplish our Charter Goals, we may ask > the ADs to allow the WG to reCharter the WG to address that. > ..but not at this time. > > I'll ask anyone interested in making changes to any of these to post notes > to the WG list preferably with a suggestion of modifications to the current > IDs, or a suggestion to write a new ID (with the commitment of being the > author. :) > > Let's separate these components apart from the discussion topic of a "light" > reliable transport. > > Thanks, > Chris > > > ---------------------------------------------------------------------------- --- > This message and any included attachments are from Siemens Medical Solutions > Health Services Corporation and are intended only for the addressee(s). > The information contained herein may include trade secrets or privileged or > otherwise confidential information. Unauthorized review, forwarding, printing, > copying, distributing, or using such information is strictly prohibited and may > be unlawful. If you received this message in error, or have reason to believe > you are not authorized to receive it, please promptly delete this message and > notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you > > ------------------------------------------------------------------------------- This message and any included attachments are from Siemens Medical Solutions Health Services Corporation and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you
