Marcus, sorry for the late reply ... this doesn't mean the messenger was running away ;) Actually, as far as syslog-protocol is concerned, I am not only the messenger but the author of this draft, so feel free to "attac" me - it's appreciated (really...;)). > Rainer is stepping forward as a messenger; I am going to try to > shoot at the message behind him, but I apologize in advance if > some of my rounds come a little close to the messenger... > > Rainer Gerhards wrote: > >I know that you do not believe in RFCs ... > > I believe in RFCs, but no longer in the process whereby they > are made... I still think that this process is better than what ISO and the other "big guys" do. IETF may become a little IOSish, but at least I do not (yet...) need to put big money to the standards body just to be able to participate... I think this is still the strength of the IETF. > >The draft is soon to be in last call, that means it is on > its way to a > >standard-track RFC. > > Hasn't this kind of been going on forever, like most IETF working > groups' efforts?? > > >At least some of your points HAVE been included > >(like the timestamp, hostname and such). There is a new, layered > >approach which enables syslog to travel over a variety of protocols. > >Thogh not popular in the IETF, this may mean it can also travel over > >non-BEEP TCP IF there is enough voiced demand for this. > > Most of the responses I've seen on this list and other places > imply that the universal response to BEEP has been gales > of uprorious laughter, in a Monty-Python-esque sort of way. > I haven't been tracking the IETF's efforts (because I know > that whatever comes out the back end will be overengineered, > overcomplex, barely functional, and will lack the fundamental > property of unity of mechanism with other core systems) - it > sounds like BEEP got stuck into the mix because it was > someone on some committee's brainchild, and now you've > got another layer that makes it an option? Ugh. You > know the old joke about an elephant being a mouse designed > by a committee? The IETF designs garbage trucks. Well... I agree that BEEP adds a lot of complexity. I don't really like it (for syslog). Anyhow, I've written a BEEP stack (focussed on syslog) and I can say from *real experience* that it is NOT as hard as it may look initially. Honestly, you can even implement a RFC3195/RAW profile with around 300 lines of code (I've done so). Again: I am NOT saying a like BEEP - I am saying it is not as bad as it initially looks. But, read on, my argument is not about BEEP... Maybe I can get you to read a little bit of the syslog-protocol draft. Eventually you will have a quick look at my presentation about it: http://www.syslog.cc/ietf/presentat/syslog-protocol-03/index.html THE basic idea of syslog-protocol is that we provide layers. So that a single message format can travel potentially over any transport. Maybe BEEP. But also potentially over a simple TLS channel... One problem, though, with the standards effort is that often the "keep it simple" pressure was completely missing. There are things in the current draft which I do not really like - but I included them because noone voiced better opinions. This would have been easy - just subscribe to the syslog-sec IETF WG mailing list and say what you have to say. Anyhow, I still think that syslog-protocol offers a good solution to address many of the issues we currently see with syslog. So why not look at it? > As many of the members of this list can attest, there are things > we don't like about syslog. There are things we'd like to see > different. But mostly we'd just like something simple that works. > We don't need BEEP or protocol-over-protocol switching. We'd > like very very few things out of a new syslog: > - year in the date > - send the traffic over a TCP optionally encrypted link > > Years in the date do not require a massive standards-track > effort; they require a change to one line of code. This is done in syslog-protcol. And it also has a FQDN as the hostname. > Transmitting the traffic over a better channel requires linking > in a library from among many. Using a totally different communications > mechanism (which is more complex than the entirety of syslog in > and of itself) is utterly silly when there are common mechanisms > in use. Though not a main goal of the IETF movement, this can be done very simple based on syslog-protocol. > If I *cared* what was going on in the working group, I'd wonder > what the hell they were thinking. NOBODY goes to it and tells it is to complex. I bet things would be different if all those that do not like it would make themselfs heared with good arguments. Actually, I stopped asking for a simple TCP based protocol simply I was more or less the only one asking for it... > >NOW is the time to make your > >voice heared, because NOW the protocol is under heavy review ... > > That's the normal IETF mode, though. RFCs are always under > heavy review until finally comes a day when there is one person > who cares left standing. And then he writes his favorite pet features > into the RFC and nobody cares anymore... > > >but > >only few voices are really heared. Honestly, I think it is > not helpful > >to say "syslog is bad" and NOT to try to change it. Of course, its > >easier ;) Standards take some time, but the good thing is > that without > >standards, we just have either interop-problems or a monopoly... > > Most of us have been doing things to fix the problem. Namely, > not waiting for the standards guys, and just going on and fixing > the problem. OK, so how HAVE you done this? Let me know the names and mail addresses of those that have the solution and I will join them in implementing the solution. Honestly. I will really do this (and, yes, we support syslog/tcp just like syslog-ng does ... but that is only part of the story). Give me a forum that agrees on a way syslog should be, and agrees in a way that is technically "clean" (not to mistake with "perfect") ... and I will gladly join. If there is no such beast, I would be delighted to form it out of this group. Actually, I do not inisit on the IETF. I just thought (and think) if there is an open standards body, why try to avoid it at all costs? Isn't that silly, too? > I must disagree utterly with your assumption that the standards > process effectively prevents either interoperation problems or > monopoly. The monopoly issue we need not discuss further, > since the reality there is blindingly obvious. With respect to > interoperability - that is a more interesting problem. The IETF, > in its original concept, was a group that favored "rough consensus > and running code" - which, if you think about it for a second, is > a ratification of installed base and reference implementation. > In a very real sense, the original concept of the IETF (though > its adherents didn't want to recognize it as such) was a ratification > of near monopoly. good point ;) > After all, if you have 2 independent, open, > functional reference implementations, you have (potentially) > an installed base. And, if that installed base is good enough > and solves the right problems, then it will be used. Or it won't. > The history if the IETF is littered with such failures - cases > where the technologist and end-user community took a look > at the results of the IETF's process and shrugged. The > short-lived competition between IETF's privacy-enhanced > effort and PGP is a good example. In a very real sense, the > wide prevalence of Microsoft-dominated single-vendor > standards represents a massive repudiation of IETF's > message and value. > > But if we hearken back to the historical roots of the IETF, we > can see that same process functioning in a different context > in the Open Source community. How many more security > practitioners are using syslog-NG right now compared to > the BEEP-based bloat? How many operating system distributions > package or port or RPM syslog-NG? Is this "rough consensus > and working code" or what? So why not go ahead and describe the way syslog-ng works in a paper and submit it to the IETF? It would be *very* interesting to see the reaction of the syslog-sec WG... > > My prediction is that if IETF ever manages to complete > getting a standard out on syslog, it'll be irrelevant and largely > ignored. If it comes out with a bloated overengineered > duplication of existing mechanism like BEEP then it'll > be laughed at, or ignored. Neither is good. This sounds like the IETF is a closed club. Obviuously, the "big political movements" ;) inside the IETF are now hard to get around the big guys. But the syslog group is *very* small. It's a shame it is so small. But this also means it would be *very* easy to participate and change syslog in the way you would like to see it changed. OK, that would prevent us from whining about the bad IETF standards... but it would make up for a better - and eventually accepted new standard on syslog. But - again - show me another group (and not only the syslog-ng source...) that talks about syslog and tries to set a "common base" (just to avoid the word "standard" ;)) - I will be happy to join them. One final thought. We, the real "log guys" found that IETF efforts are bad and should be ignored. Those poor (unknowing) outside guys do not know it. For example, the healthcare industry is obviously standardizing on BEEP-based syslog. Might it be that the "outsiders" simply assume that a standard is good? Might it be smart to let them know if we have really good arguments against this... Rainer _______________________________________________ LogAnalysis mailing list LogAnalysis@private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2.1.3 : Mon Aug 16 2004 - 12:11:14 PDT