Hi, [speaking as co-chair]
> 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. That is what we are doing. The protocol, udp, and tls documents have been submitted to the IESG for advancement. We are (almost) done with those. Our charter very explicitly shows the agreement from last year. The next steps are to complete syslog-sign and syslog-mib. That is what we are attempting to do, by resolving some dependency problems between syslog-sign and RFC3195, as discussed in my other email. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, syslog WG > -----Original Message----- > From: Moehrke, John (GE Healthcare) [mailto:[EMAIL PROTECTED] > Sent: Friday, January 26, 2007 7:45 AM > 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) > > 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
