Robert, I am fine with your text.
<slightlyOffTopic> The reliability issue is not rooted in disasters or other uncommon scenarios. As of my testing, confirmed this month by Martin, the probability of message loss even in a simple server restart case is very high. For a busy network, I'd say it tends toward 100%, though I cannot provide hard evidence - I didn't bother to do a statistically large enough sample to back that statement. After all, it is irrelevant if there is a 80% or 100% probability - the point is that it is very high (probability of message loss increases with traffic volume). In any case, I expect that an operator of an enterprise logging system will routinely see message loss (if he cares to detect it) inside a system using -transport-tls. Of course -transport-udp will be much worse. But the point is that an auditor may very well question the completeness of the log data under *normal* circumstances. Martin has found a trick to get some better reliability for these normal circumstances, but the trick only works in a fast, lossless network with low traffic volume and without bursts. Plus, it is racy. But it is the best you can do. </slightlyOffTopic> All of this off-topic should NOT go into the document, but it is the reasoning behind my proposal. Rainer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 05, 2008 3:23 PM > To: Rainer Gerhards > Cc: Joseph Salowey (jsalowey); syslog; [EMAIL PROTECTED] > Subject: RE: [Syslog] Subject Name verification policy > > "Rainer Gerhards" <[EMAIL PROTECTED]> wrote on 06/05/2008 > 08:01:37 > AM: > > > I think I should have been more clear. I meant a note along these > lines > > (and only these lines, without any more specifics). > > > > ### > > It should be noted that this transport does not use application-level > > acknowledgments. As such, there exists situations where loss of data > > may occur. This protocol is not suitable if a 100% reliable solution > > is desired. > > ### > > > > How about just > ### > It should be noted that this transport does not use application-level > acknowledgments. As such, there exists situations where loss of data > may occur. > ### > > Maybe someone will find or write a good reference article explaining > the > application level issues with TCP/IPv4, TCP/IPv6, etc. Then an in > depth > explanation could be given once for all the many applications that > care. > People who are serious about this will need the full details. The rest > deserve just the short warning. I don't want them blindly telling > everyone that the syslog group has officially said that they shouldn't > use > syslog-tls because it isn't reliable. That is what would happen if we > include that final sentence. > > There are unsophisticated users who routinely demand 100% reliability. > I > deal with them by asking about how they plan to handle power failures, > hurricanes, earthquakes, floods, tornados, etc. I know that when I > cared > about such stuff I could quote the local power grid reliability > statistics > off the top of my head, and could explain our decision tree on the size > of > the fuel tank for the auxiliary diesel generator. I was also on top of > disk drive reliability figures. This was before RAIDs and hot swap was > very expensive. It turned out that downtime for disk drive problems > was a > major issue as you went below 10min/year of downtime. Their response > to > the basic disaster questions establishes what kind of response to give > for > applications level data loss. > > R Horn _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
