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
