Re: [Syslog] -syslog-tc-mib Facilities
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.