On 2011-02-16 12:34, Rainer Gerhards wrote: [..] > The question is if such an effort must be bound restricted to a single > protocol. My PoV is that this is counter-productive.
I might be missing the parsing here, but can you explain what part is counter-productive to have a single protocol and having to write only a single parser versus having a lot of different protocols who require parsers which can resolve ambiguity? > You definitely have a point in that IPFIX may be superior than syslog in many > regards. I do not intend to argue against this. But often a simpler solution > is able to draw more attention, and thus deployments, than a (potentially or > actually) technical superior one (shouldn't we all use the OSI stack by now, > just as one example...). I wonder what the "E" in IETF stands for if I see the above statement. Why not simply use CSV or hey just pack it in XML! :) Please note that IPFIX has gathered quite some attention already. As for the OSI stack argument, the world is not ready for IPv6 either. I like to also quote: http://www.ietf.org/mail-archive/web/sip-clf/current/msg00430.html 8<----------------------------------------------------------------------------- 1. Shall we use a TAB or a SPACE (or any LWS) as field delimiters? Considerations and points raised: - TABs don’t survive Telnet or web pages very well, especially when copy/pasting. - spaces can appear inside fields (as can most other delimiters we choose) - how do TAB and SPACE delimiters interact with shell tools (rep, cut, awk) ----------------------------------------------------------------------------->8 The moment you have to worry about a delimiter, you have big problems.... that is why char format is not a good idea. Yes, you can use all the standard unix command tools to process them, but are you really going to do this on the big scale? I certainly hope not. The same with Apache logs, very useful to have to parse the IP address again to get the information you want. Especially with IPv6 where the address can have quite a number of formats based on how the address is represented, not even going talking about the point. Oh and those unix tools, they do not support UTF-8 in a lot of cases, thus they are suddenly quite useless. > I don't think it is useful to include IPFIX in syslog. But it may be an > option that IPFIX makes syslog obsolete. I think you should take that later > route. If there is going to be new effort for syslog, is that then not the route it should be taking? Structured data is so much more useful than unstructured data, and that is the big problem that > But as I said -- I do not intend to spawn another iteration of this lengthy > discussion. It has occurred sooo often in the past years. Is there a summary of this discussion with a clear listing of pro/cons? Would be good to have that in a draft, is there one? If there isn't please write one with those arguments so that it can referred to instead of stating 'we did this before, EOD'... Greets, Jeroen _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
