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
