Hi John, > -----Original Message----- > From: Moehrke, John (GE Healthcare) [mailto:[EMAIL PROTECTED] > Sent: Friday, January 26, 2007 1:45 PM > To: Eliot Lear; Chris Lonvick > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] 3195bis before syslog-sign > > 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)
As you know, I value the work you are doing in IHE very much. I consider the IHE record a payload of the syslog message. So having the protocol itself XML-based does not neccesarily have any influence on IHE, as the payload is not directly related to it. On the issue of COOKED, I tend to agree that it has not received any vital interest. As you know, I have implemented it, too. My implementation, as I now know, seems to have some problems. I have not intended to fix them as I actually never received any real demand on that functionality. I had one interop conversation with someone working on an IHE project (a very smart guy, was nice talking to him). This is where I became aware of the problem with COOKED in my stack. One or two other folks asked about COOKED and I think some university project implemented it. But again, no real demand. Also, I do not know a single *complete* implementation of COOKED. In my previous reply, I talked about the PATH elements. In theory, these can be quite useful. But it is pain in the ... to generate and to track them. Nobody has done that. For IHE, keep in mind that you would need to implement PATH elements if you ever want to (really) claim compliance to 3195 (these are not optional, as far as I remember out of my head). As a last example, I have learned that Cisco has implemented 3195 (which is very welcome), but also only RAW. With RAW, we have at least some actual implementations, even though I have yet to see someone who deploys them. But they would work and would interoperate. So my personal conclusion, too, is that COOKED is "no uptake". I like the idea of obsoleting it. That does not mean you can no longer use it. I question there is any specific value of COOKED for IHE. If it is done in the spirit of syslog-protocol, the IHE record needs to be encoded as sturctured data anyhow. So it does not matter if the underlying transport is XML-based or not. > 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. Here I fully agree with you. I think, however, there is currently nothing we can do to help advancing -protocol and the transport mappings. They have been submited to the IESG and are now waiting for IESG attention. So the WG can either idle or do other things. As we know 3195 needs to be revised, I find it useful to think about that. Especially as I agree it should be straightforward activity. What is questionable is if it is right to old -sign once again for completion of other work. This has done many time, maybe too many times. On the other hand, there is good reasoning to do so and the chairs have explained their reasoning. I agree with their position. HOWEVER, as soon as new work items for -protocol and the transport mappings come up, we should immediately turn our attention to them. Being through thru 4 years (or were it 5?) of revisions of -protocol, I definitely want to see this work finished ASAP. I agree there is some danger in discussing things. If -protocol and mappings need attention, it might be problematic to switch back attention to them. I see this risk. Maybe it is important enough to actually do nothing but idling... I hope this clarifies my position. I honestly believe that the current discussion is useful and is also useful for IHE. Rainer > > 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
