Do not fear about deployments from the Healthcare (IHE) community. Due
to the lack of syslog-community support for Reliable-Syslog, we have
told our members to not implement it. My important point in my post last
week is that right now the only thing we can find as a transport for our
security-audit-message is BSD-Syslog. You are all very aware of the
problems with that. The Healthcare community is very anxious about using
a protocol that is lossy-without-notice, as we take great care in
handling patient data (and thus patient health and safety).  THEREFORE,
I want the to encourage the syslog-community to work on one thing, the
replacement for BSD-Syslog. I now understand that syslog-protocol and
family are out... I thus want to encourage the implementation of
syslog-protocol and family by you all. The Healthcare (IHE) community is
very happy to leave BSD-Syslog and Reliable-Syslog if we have evidence
that syslog-protocol will be widely implemented.

Things like syslog-sign are interesting, but are not as high priority as
a well implemented working replacement for BSD-Syslog.

John 

> -----Original Message-----
> From: Rainer Gerhards [mailto:[EMAIL PROTECTED] 
> Sent: Friday, January 26, 2007 10:51 AM
> To: David Harrington
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Syslog] 3195bis before syslog-sign
> 
> Hi David,
> 
> I am keeping track of 3195 implementations here:
> 
> http://www.syslog.cc/ietf/rfcs/3195.html
> 
> I've just added the Cisco implementation, which is the first one by a
> major player (but RAW mode only).
> 
> I do *not* know of any actual deployments, at least not in production
> environments. I'd suspect there are some users of SDSC syslog which
> eventually use 3195 and maybe even in the limited COOKED mode 
> available.
> As far as I can tell, noone from our own user basis has ever deployed
> 3195. There were some test cases and some university projects, but as
> far as I know nothing lasting. I assume there are some deployments in
> IHE environments, but John can probably comment on that much 
> better. As
> far as I know, the most interest has come from the IHE community,
> because there was a somewhat imprecise specification of the 
> message size
> limit found in 3195, which enabled IHE to transfer oversize 
> messages in
> a way that could be claimed to be standards-compliant (see
> http://www.syslog.cc/ietf/autoarc/msg01454.html).
> 
> A side note: While I browsed that threat, I found this message here:
>    
>    http://www.syslog.cc/ietf/autoarc/msg01463.html
> 
> The important quote is:
> ###
> As a specific example of what Rob Horn mentioned, see RFC 
> 3881.  This is
> also incorporated in the work of multiple healthcare standards groups.
> Cooked reliable syslog messages are the transport.
> 
> Glen Marshall
> ###
> 
> This seems to indicate there is a field of yet-unknown deployed
> implementations. This also seems to be at the bottom of John's concern
> from earlier today. If COOKED reliable syslog is already 
> referenced AND
> implementend AND eventually even deployed, we should be very careful
> about obsoleting 3195.
> 
> Rainer
> 
> > -----Original Message-----
> > From: David Harrington [mailto:[EMAIL PROTECTED]
> > Sent: Friday, January 26, 2007 4:57 PM
> > To: Rainer Gerhards; 'Chris Lonvick'; 'Moehrke, John (GE 
> Healthcare)'
> > Cc: [EMAIL PROTECTED]
> > Subject: RE: [Syslog] 3195bis before syslog-sign
> > 
> > Hi Rainer,
> > 
> > Since you have looked around already, can you give us a quick survey
> > of how many have implemented or deployed RAW mode?
> > 
> > David Harrington
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> > 
> > 
> > > -----Original Message-----
> > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, January 26, 2007 10:42 AM
> > > To: Chris Lonvick; Moehrke, John (GE Healthcare)
> > > Cc: [EMAIL PROTECTED]
> > > Subject: RE: [Syslog] 3195bis before syslog-sign
> > >
> > > Chris,
> > >
> > > I know that SDSC syslog has a partial implementation of
> > > COOKED (PATH is
> > > not covered). I have an implementation of COOKED (also without
> > PATH),
> > > but now know that there are some issues with it (which I do not
> > intend
> > > to fix, given the desinterest of the logging community). I know of
> > at
> > > least one other proprietary implementation of COOOKED 
> inside the IHE
> > > community. I do not know if that project is still active.
> > >
> > > I do not know of any *deployment* of COOKED. I do not know of
> > > any major
> > > vendor COOKED implementation.
> > >
> > > Rainer
> > >
> > > > -----Original Message-----
> > > > From: Chris Lonvick [mailto:[EMAIL PROTECTED]
> > > > Sent: Friday, January 26, 2007 4:08 PM
> > > > To: Moehrke, John (GE Healthcare)
> > > > Cc: [EMAIL PROTECTED]
> > > > Subject: RE: [Syslog] 3195bis before syslog-sign
> > > >
> > > > Hi John,
> > > >
> > > > Is the healthcare industry using COOKED now?  I can't tell from
> > your
> > > > note
> > > > below.  I'll invite all others to say if they know of any
> > > > implementations
> > > > of RFC 3195 that use COOKED.  From what I've seen the
> > > implementations
> > > > are
> > > > only using RAW.  Now is the time to set the direction 
> for 3195bis.
> > > >
> > > > A point on the process:  We are done with 
> syslog-protocol.  It has
> > > been
> > > > submitted to the IESG along with syslog-transport-udp and
> > > > syslog-transport-tls.  We're waiting on IESG review and
> > > then time for
> > > > the
> > > > RFC Editor to get it published.  We're now focusing on
> > > syslog-device-
> > > > mib,
> > > > syslog-sign, and now 3195bis. You can follow the 
> progress of these
> > > > here:
> > > >
> > > https://datatracker.ietf.org/public/pidtracker.cgi?command=sea
> > > rch_list&
> > > >
> > > search_job_owner=0&search_group_acronym=syslog&search_status_i
> > > d=1&searc
> > > >
> > > h_cur_state=&sub_state_id=6&search_filename=&search_rfcnumber=
> > > &search_a
> > > > rea_acronym=&search_button=SEARCH
> > > >
> > > > Thanks,
> > > > Chris
> > > >
> > > >
> > > > On Fri, 26 Jan 2007, Moehrke, John (GE Healthcare) wrote:
> > > >
> > > > > The Healthcare industry has tried to use COOKED... WHY is it
> > > > considered
> > > > > "no uptake"? We have security audit events that get 
> captured in
> > an
> > > > XML
> > > > > message; thus COOKED would be preferred. (See RFC 3881)
> > > > >
> > > > > I agree that the audit servers have not implemented 
> it, but then
> > > > again
> > > > > there isn't much conformance to any other syslog specification
> > > > either. I
> > > > > would like to understand why "no uptake" is a reason for
> > removing
> > > > this.
> > > > > It is not for lack of trying.
> > > > >
> > > > > As a very interested observer and consumer of your 
> standards, I
> > am
> > > > > getting very frustrated at the lack of commitment to ANY
> > > > specification
> > > > > and lack of interest in completing anything. I strongly
> > recommend
> > > > > singular focus on syslog-protocol and it's bindings. Get them
> > > > > implemented before you start messing around with other
> > > things. I had
> > > > > thought this was the agreement of the committee last year.
> > > > >
> > > > > John Moehrke
> > > > > GE Healthcare
> > > > >
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Eliot Lear [mailto:[EMAIL PROTECTED]
> > > > >> Sent: Friday, January 26, 2007 4:46 AM
> > > > >> To: Chris Lonvick
> > > > >> Cc: [EMAIL PROTECTED]
> > > > >> Subject: Re: [Syslog] 3195bis before syslog-sign
> > > > >>
> > > > >> Chris & all,
> > > > >>
> > > > >> As you mentioned, Darren, Marshall, and I will produce an
> > > > >> internet-draft
> > > > >> that revises RFC 3195 (rfc3195bis).  As part of that effort
> > > > >> we envision
> > > > >> accomplishing the following:
> > > > >>
> > > > >>     * Obsoleting RAW and COOKED profiles.  The RAW profile
> > > > >> has a length
> > > > >>       limitation that we have been told is not 
> appropriate for
> > > > >>       syslog-signed.  The COOKED profile has seen no
> > > uptake.  This
> > > > >>       dramatically simplifies the draft.
> > > > >>     * A new profile that has taken on the name of 
> TARTARE will
> > > > >>       essentially be RAW rev 2.  Messages sent with the
> > > > >> TARTARE profile
> > > > >>       will conform to draft-ietf-syslog-protocol's
> > > syntax, and have
> > > > no
> > > > >>       length limitation.
> > > > >>     * We will review existing security considerations.  For
> > > > instance,
> > > > >>       RFC 3195 calls for use of 3DES for TLS.  We
> > > propose that the
> > > > new
> > > > >>       draft take on a more modern approach with regard
> > > to algorithm
> > > > >>       agility and which algorithm SHOULD be the low bar.
> > > > >>
> > > > >> In our early drafty draft, we were unable to eliminate all
> > > > >> references to
> > > > >> RFC 3164, due to reference of security considerations
> > > seemingly not
> > > > >> covered in draft-ietf-syslog-protocol. However, those
> > references
> > > > that
> > > > >> remain are NOT normative.  If a complete separation for 3164
> > > > >> is desired
> > > > >> we will need to incorporate a few of those remaining 
> concerns,
> > > where
> > > > >> IMHO the existing text in 3164 is sufficient.
> > > > >>
> > > > >> Finally, do people desire any other changes that would be
> > > considered
> > > > >> necessary either for draft-ietf-syslog-protocol or for the
> > > > >> forthcoming
> > > > >> syslog-signed work?
> > > > >>
> > > > >> We predict this work to progress rapidly.
> > > > >>
> > > > >> Thanks,
> > > > >>
> > > > >> Eliot
> > > > >>
> > > > >> Chris Lonvick wrote:
> > > > >>> Hi Folks,
> > > > >>>
> > > > >>> David Harrington and I had a talk about syslog-sign and its
> > > > >>> dependencies upon 3195bis.  As was noted in the email
> > discussion
> > > it
> > > > >>> would be messy to try to publish syslog-sign with 
> dependencies
> > > upon
> > > > >>> 3195, then update 3195, then revise syslog-sign.  We had a
> > > > >> talk with
> > > > >>> Sam Hartman, our AD, who agreed that we should revise
> > > RFC 3195 to
> > > > >>> eliminate unnecessary dependencies.
> > > > >>>
> > > > >>> David and I are pleased to announce that Darren New,
> > > > >> Marshall Rose and
> > > > >>> Eliot Lear have volunteered to produce a revision to
> > > RFC 3195.  We
> > > > >>> expect that this will be a transport for syslog-protocol so
> > that
> > > > >>> syslog-sign, and any other, future applications, 
> can make use
> > of
> > > > >>> syslog-protocol without having to worry about transport
> > > > >> dependencies.
> > > > >>> Other goals of 3195bis will be to deal with the length
> > > > >> limitation in a
> > > > >>> manner consistent with the other transports, and to 
> eliminate
> > > > >>> references to RFC 3164.
> > > > >>>
> > > > >>> We've have had an initial explanation of how the authors
> > > > >> will revise
> > > > >>> 3195 which sounds reasonable.  I will let Darren, Marshall
> > > > >> and Eliot
> > > > >>> propose the changes to the list.  This should be a
> > > quick effort so
> > > > >>> please pay attention and discuss this on the list so we
> > > can get it
> > > > >>> moving.
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Chris & David
> > > > >>>
> > > > >>> _______________________________________________
> > > > >>> Syslog mailing list
> > > > >>> Syslog@lists.ietf.org
> > > > >>> https://www1.ietf.org/mailman/listinfo/syslog
> > > > >>>
> > > > >>
> > > > >> _______________________________________________
> > > > >> Syslog mailing list
> > > > >> Syslog@lists.ietf.org
> > > > >> https://www1.ietf.org/mailman/listinfo/syslog
> > > > >>
> > > > >
> > > >
> > > > _______________________________________________
> > > > Syslog mailing list
> > > > Syslog@lists.ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/syslog
> > >
> > > _______________________________________________
> > > Syslog mailing list
> > > Syslog@lists.ietf.org
> > > https://www1.ietf.org/mailman/listinfo/syslog
> > >
> > 
> 
> 
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
> 

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

Reply via email to