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=search_list&; > search_job_owner=0&search_group_acronym=syslog&search_status_id=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
