Glen, it is b). I think you are assuming way too much about severity. It's a field with only 24 different values. It is *not* something like an IP port. You cannot reliably say anything on reception of a specific facility. OK, LOG_KERN and LOG_MAIL are almost always what they claim to be. But I wouldn't trust LOG_UUCP these days. And what is the distinction between LOG_AUTH and LOG_AUTH2 (in a consistent way)? What should a HTTP daemon log to? There is no LOG_HTTP. Maybe, if we save these 4 values, we can define one. But would that really help?
The concept of identifying something based on these poor 24 values is crappy. Facility is a (bad) legacy. We tried to make it useful by increasing it to an integer, but that has been rejected in 2005. The last draft actually describing facility in a useful way was http://tools.ietf.org/id/draft-ietf-syslog-protocol-15.txt Here is the relevant text: ### 6.2.2. FACILITY FACILITY is an integer in the range from 0 to 2147483647. It can be used for filtering by the receiver. It is a category, allowing a coarse grouping of messages. There exist some traditional FACILITY code semantics for the codes in the range from 0 to 23. These semantics are not closely followed by all senders, and practice has shown that common semantics for message categories are hard to establish. Therefore, no specific semantics for FACILITY codes are specified or implied in this document. ### Re-read this part: *** practice has *** shown that common semantics for message categories are hard to *** establish. That's exactly what it is, especially if you only have 24 discrete values. All drafts after -16 simply copied the text from RFC 3164, because that was WG consensus (at the time of the year ;)) and it doesn't make sense to bother doing much with a field that is mostly useless anyhow. Rainer > -----Original Message----- > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 23, 2007 7:36 AM > To: Rainer Gerhards > Cc: Chris Lonvick; [EMAIL PROTECTED] > Subject: Re: [Syslog] -syslog-tc-mib Facilities > > Rainer, > I did inot get the point. Why do we have to stick to > only the facilities that are used on all platforms? Is it > that > a. all system do not use the facility codes? > e.g. system A uses facility code "12" for ntp while > system B uses nothing or, "localuse" facility code > for ntp, > or, > b. all systems do not have the same semantics for the > facility codes ? > e.g. system A uses facility code "12" for ntp" while > system B uses facility code "12" for kernel etc. > > Glenn > > Rainer Gerhards wrote: > >>> The discussion came up about the use of the Facilities in the > >>> -syslog-tc-mib document; are they normative or non-normative. > David > >> and > >>> I discussed this and have concluded that they are normative to the > >>> version of the protocol that we are now discussing. That may be > >> changed > >>> in the future but we can't predict that. However, the fact remains > >> that > >>> the Facility really can't always pinpoint the source of the content > >> of > >>> the message. > >> Then on page 5 of syslogMIB-TC the statement > >> "Facility and Severity values are not normative but often used." > >> will need to be deleted - is that correct ? > > > > Yes, that would need to be deleted. However, we should then stick > with > > only the facilities that are used on all platforms. > > > > ntp (12),-- NTP subsystem messages > > logAudit (13),-- log audit messages > > logAlert (14),-- log alert messages > > cron2 (15),-- clock daemon messages > > > > Are note universal. See this excerpt from the current glibc syslog.h: > > > > ### > > /* facility codes */ > > #define LOG_KERN (0<<3) /* kernel messages */ > > #define LOG_USER (1<<3) /* random user-level messages */ > > #define LOG_MAIL (2<<3) /* mail system */ > > #define LOG_DAEMON (3<<3) /* system daemons */ > > #define LOG_AUTH (4<<3) /* security/authorization messages > */ > > #define LOG_SYSLOG (5<<3) /* messages generated internally by > > syslogd */ > > #define LOG_LPR (6<<3) /* line printer subsystem */ > > #define LOG_NEWS (7<<3) /* network news subsystem */ > > #define LOG_UUCP (8<<3) /* UUCP subsystem */ > > #define LOG_CRON (9<<3) /* clock daemon */ > > #define LOG_AUTHPRIV (10<<3) /* security/authorization > messages > > (private) */ > > #define LOG_FTP (11<<3) /* ftp daemon */ > > > > /* other codes through 15 reserved for system use */ > > #define LOG_LOCAL0 (16<<3) /* reserved for local use */ > > #define LOG_LOCAL1 (17<<3) /* reserved for local use */ > > #define LOG_LOCAL2 (18<<3) /* reserved for local use */ > > #define LOG_LOCAL3 (19<<3) /* reserved for local use */ > > #define LOG_LOCAL4 (20<<3) /* reserved for local use */ > > #define LOG_LOCAL5 (21<<3) /* reserved for local use */ > > #define LOG_LOCAL6 (22<<3) /* reserved for local use */ > > #define LOG_LOCAL7 (23<<3) /* reserved for local use */ > > ### > > > > When we claim to create normative names for facilities, we should not > > cause backward compatibility problems for those facilities that are > not > > even mentioned in the relevant system header files. Claiming them > would > > essentially eat up the remaining four extension possibilities. For > > example, I'd much more prefer to have a LOG_HTTP in the future than > to > > have a LOG_CRON2... > > > > Rainer > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
