Hi WG, as the Seoul meeting is nearing, I would like to make a comment on the eventually too-precise -protocol spec. Honestly, I have not fully made up my mind and I am still waiting for some additional feedback from the security and user community.
I asked questions to several security and analysis related lists and plan to ask some more. I think due to the RSA conference, feedback so far has been very limited. I think it is vital to also get some feedback from outside the IETF, as these folks tend to use and/or implement the drafts. Having said this, I would like to bring to your attention what eventually a compromise could be: I really don't like to strip out all the precise definitions and implementors notes and simply delete them. OK, I could put them up on a web page, but that would just create a false impression of non-deletion. Essentially that would just be yet another web page on syslog and most probably implementors would not even find it - IF they search, after all. So this is not really a solution. On the other hand, many feel the spec is inappropriately thight. I am still of the impression that it should be that way. However, how about this: take those tight specifications out of -protocol, thus not making them absolutely necessary. Then, create an informational draft, let's say titled "Best practices for syslog implementation". Then, the taken-away content goes in ther. In contrast to the web site, this would have the advantage of making the information available inside a RFC, so at least those implementors really concerned about doing it right should be able to find it - much better than a web page. I have the impression, though, that this by itself introduces new potential security weaknesses as -protocol is then less precise. However, I think it is a workable compromise, so I wouldn't object it. I still think it would be more benefitial to leave -protocol precise. I have to admit that the arguments provided so far have not convinced me. The (few) feedback I got from the other lists is that preciseness adds security - but, obviously, these were security folks. But is it bad to listen? ;) I outline my philosophy behind the preciseness here: http://www.syslog.cc/ietf/why-indepth.html - feedback is appreciated (no matter how bad it may be ;)). Rainer PS: I am tracking this issue here: http://www.syslog.cc/ietf/protocol/issue13.html PPS: I am unfortunatley unable to attend the Seoul meeting. Chris has agreed to act as proxy (once again, many thanks, Chris).
