I think this protocol should only address the concerns for the syslog messages delivered out from its originating box. We should not get into the syslog application to regulate how it should behave. Besides, there are typically syslog relay devices before the messages reach its target receiver boxes to make it much more complex.
We should let users determine, via configurations, what syslog messages are of concerns/interests to them instead of having this protocol stating a policy dictating what messages to be dropped. Steve > -----Original Message----- > From: Eliot Lear [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 12, 2007 7:10 AM > To: Chris Lonvick (clonvick) > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - > congenstioncontrol (fwd) > > Chris Lonvick wrote: > > Hi Folks, > > > > Here is clarification of what Magnus wants. We have so far received > > Eliot's proposal but I don't think that addresses the concern. > > > > I agree. My concern was downstream resources. Magnus' concern is the > syslog "application". This is complex because there are at least three > cases to consider: > > * syslog generator blocks on a full input queue - what to do? There > is generally no way for the application to detect the condition > prior to blocking. > * non-blocking syslog generator gets an input queue error - the best > it can do is signal back to the application. What syslog > implementation actually does this? > * a non-blocking syslog relay starts getting input queue errors. It > has no application intelligence. Is it reasonable for it to just > start dropping messages with high log_levels, and hope for the best? > > Eliot > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
