RE: [Syslog] Charter revision / WG obsolete?
My mistake. I mis-interpreted the WG description, ...At a minimum this group will address providing authenticity, integrity and confidentiality of Syslog messages as they traverse the network. I guess I'll shift this discussion to INCITS/CS1. Thanks for the bandwidth. -Eric -Original Message- From: Darren Reed [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 5:07 AM To: Eric Hibbard Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] Charter revision / WG obsolete? As one of the many lurkers on this list, I have been monitoring this WG's activities and I'm a bit concerned with the recent posts. I had high hopes that some form of logging standardization might materialize, but that now seems to be in question. That is outside the scope of this WG. We're trying to concentrate on the protocol used to convey log information - that's all. Recent regulations within the U.S. (e.g., SOX, HIPAA, SEC, FDA, etc.) and other countries are forcing organizations to implement accountability measures. Audit logging (as well as authentication and authorization) is a critical element of these accountability measures. Seems to me that this WG might want to step up and standardize the way this gets handled. If nothing else, it could give the WG a little more focus. That information _may_ be placed in syslog messages but the scope of what you're talking about includes much more than just sending data between daemons. For now, we have other more basic problems to solve and as tempting as it is to try and solve these too, it would just be a distraction and stop the WG from achieving what it needs to achieve. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter revision / WG obsolete?
Hi all, If I get the essence in Darren's message right, what he is proposing is to create a layered architecture for syslog. Yes, by using what's gone before us as the way to start doing that. Please face it: on the WG mailing list, we are pressing for ever and ever change. More and more new things. At least in the last meeting, we are trying to conserve as much as possible (which I personally like). This won't go together. What I think the WG is lacking is a good long term focus of objectives. I believe this is largely because the group has been meandering along. I think we need to refocus by looking at where people are going with developing syslog protocols and evolve what exists today to meet that. Obviously, I am not participating in the meetings for a reason: I simply can not justify traveling around the world for a 30 minute time slot even without a strong business case. I thought that personal participance is not a absolute must in IETF work (though I clearly understand its importance). Which is why those who attend the meetings are often involved in more than a single WG. .. - we ignore running code and rough consenus existing in practice (syslog/tcp) My hope is that if we pursue a layered approach will allow us to easily document a protocol that covers the existing practice in this area as well as provide a path for future design. Please do not misunderstand me: of course, I am a bit frustrated about that this WG has fundamental problems. I personally doubt it makes sense to continue without solving them. Where I think we've gone wrong and I hear indications of going wrong are with people who want to solve their own pet problem - we've lost sight of the big picture. For example, the different message format to allow bit-banging for indicate this or that has happened to the message. For most people, it does nothing. As too with XML - I'm sure there is a large contingent of developers out there who balk at any document that mentions XML, even if its optional. I think the WG should remain and has a purpose. At the meeting Sam Hartman mentioned that we were going nowhere fast and in danger of being shut down. Apparently this isn't uncommon but I think that although there problems that they aren't beyond fixing. I think the key to achieving a good result has got to be thinking that it is ok to have lots of small documents rather than just one big document. If nothing else, it should make the work required to produce a single one down and therefore more attractive. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter revision / WG obsolete?
As one of the many lurkers on this list, I have been monitoring this WG's activities and I'm a bit concerned with the recent posts. I had high hopes that some form of logging standardization might materialize, but that now seems to be in question. Recent regulations within the U.S. (e.g., SOX, HIPAA, SEC, FDA, etc.) and other countries are forcing organizations to implement "accountability" measures. Audit logging (as well as authentication and authorization) is a critical element of these accountability measures. Seems to me that this WG might want to step up and standardize the way this gets handled. If nothing else, it could give the WG a little more focus. -Eric Eric A. Hibbard, CISSP, ISSAP, ISSMP, ISSEPSenior Director, Data Networking TechnologyChair, SNIA Security Technical Work Group Office of the CTOHITACHI DATA SYSTEMS750 Central Expressway, MS 3407Santa Clara, CA 95050-2627P 408.970.7979/ F 408.562.5477eric.hibbard@hds.com ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter revision
Chris, What I'd like to see happen is for 3195 to be broken up into 2 or more new RFCs, one (or more) which cover the protocol and one which defines their use over BEEP. i.e. One which covers the COOKED profile, one which covers a RAW profile and one which covers one or both of these over BEEP. We may also choose to add a BSD profile (which is syslog-protocol or an enhanced version of 3164.) That nails down the protocol. Next we move on to defining how the protocol is used. So we describe syslog (COOKED/RAW/BSD) over BEEP/ssh/TLS/UDP/TCP. I think if we evolve that way there is a much better chance of aligning ourselves with what people are doing and want to do without rendering what we've done to the scrap heap completely. It may also be worth taking input from those who have developed or deployed 3195 to understand if there are components of it that did/didn't work. When we get close to getting all of that documentation done, I'd be for advocating that 3195 be moved to experimental status, rather than obsolete. For example, chosing this path gives us a syslog-BSD/tcp that should be close enough to what people are doing today with this, bringing together most of these implementations as being RFC compliant. I expect work will be required on both sides to evolve it a little to get there, but I think there's considerable advantage for us and developers if a little work on the part of each party results in RFC compliant software. Sam, do you have any comments on taking this approach with the syslog protocols by the working group ? Cheers, Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
