this message is longer than i'd like, for which i apologize in advance. > The possibility of requesting parts of the syslog stream in a separate > channel might be useful in the future, but the control messages to achieve > this needs to be defined. The problem with RFC3195 is that it provides > solutions for the future, but does not solve our current problems. Plain TCP > transport is supported in more-and-more implementations but they not > necessarily interoperate, even end devices support it sometimes: > > - kiwisyslog > - msyslog > - nsyslogd > - syslog-ng > - Cisco PIX > > And I'm sure I've forgotten some. These should interoperate, most of them do > I guess, but an RFC would help in this area right _NOW_. The BEEP solution > might be the future, but first it needs implementations, and further updates > that makes the overhead explainable.
one of the values behind standardization, and in particular, standardization of open protocols is that you get a concensus behind something which is going to support a wider range of environments than if N people go off and independently do their own thing for their own little part of the internet. if the variations between the different requirements are relatively small, then you tend to get results that are reasonably optimal for most environments. the larger the range of variations, the harder it is to do this. at some point, the variation is so large that a single engineering solution is untenable. in that case, you either cut back on the requirements or do multiple efforts targetted towards clusters of requirements that are largely self-consistent. in the case of the syslog wg, while there are some folks who say "all i need is reliability and tcp does that", there are also a lot of other folks who have requirements that are more nuanced. some people care about privacy, some don't. some people care about authenticity (but not privacy), and some don't. some people care about particular security protocols or enterprise infrastructures, and some don't. more interestingly, there are some folks who realize that their requirements today are going to be different 3 months, 6 months, and a year from now, and they'd rather not have to deploy a new syslog protocol to meet those requirements. rather, they'd prefer to edit some config files to enable/disable various features in the existing protocol. the good news is that it turns out that you can unify the entire class of requirements for folks who all want different variants of "reliable syslog" by using a negotiation model. and that's where beep comes in. i absolutely guarantee you that i could easily specify 6 different "reliable syslog" protocols, each targetted towards a particular slice of requirements, and each no less than 8% more efficient than the general beep-based solution, and all of them incompatible with each other. sorry, i'll take the 8% efficiency hit and avoid the incompatibility. if someone disagrees with this, then i congratulate them on landing a job where they have to worry about less than 10 computers... regardless, there is a second class of requirements for syslog that weren't centered around reliable delivery, but rather around (partial) ordered delivery in very short time frames. this requirement is fundamentally different than the reliability requirement. further, it remains an open research problem as to how to design a single protocol which satisfies both of these requirements. thus, the working group developed a second protocol, syslog-signed, to meet that set of requirements. from my perspective, syslog-reliable and syslog-signed are complimentary in the sense that they solve very different problems within the context of "doing syslog". operators are free to examine their own requirements and then choose to deploy one or both to meet their needs. /mtr
