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
