Subject: [Syslog] -syslog-tc-mib Facilities

From: Chris Lonvick <[email-masked]>
Date: Fri, 15 Jun 2007 13:54:58 -0700 (PDT)

Hi Folks,

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.

We've had a lot of discussion during the life of this WG about the 
Facilities.  The WG chose to keep the old Facilities and add more 
information in each syslog message through the APP-NAME field in the 
header.  Even more information can be added through the SDE of "software" 
in the "origin" SD-ID.  (The APP-NAME is REQUIRED but may be nill, whereas 
the "software" SDE is OPTIONAL.)  This information should be used to 
clarify the origin of the content of the message.

Glenn:  Please insert something similar to this in the Introduction part 
of -syslog-tc-mib.

    The Facilities used in the syslog protocol have been useful in
    qualifying the originator of the content of the messages but in
    some cases they are not specific enough to explicitly identify the
    source.  Implementations of the syslog protocol that contain Structured
    Data Elements (SDEs) should use these SDEs to clarify the entity that
    originated the content of the message.

(Efforts at wordsmithing this will be appreciated. :-)

Also, David is going to find a MIB Doctor to review the next version of 
-syslog-tc-mib.  If that person finds the document to be clean then we 
will have a short WG Last Call, and then we will submit it to the IESG.

Thanks,
Chris

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "tom.petch" <[email-masked]>
Date: Tue, 19 Jun 2007 10:09:34 +0200

Chris

-protocol-21 says 

"   Facility and Severity values are not normative but often used."

(something I have quoted on this list before:-)
I am not sure how this fits with the changes to -mib.

Tom Petch

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Fri, 22 Jun 2007 18:59:42 +0900

Chris,
Chris Lonvick wrote:
> -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 ?
> header.  Even more information can be added through the SDE of 
> "software" in the "origin" SD-ID.  (The APP-NAME is REQUIRED but may be 
> nill, whereas the "software" SDE is OPTIONAL.)  This information should 
> be used to clarify the origin of the content of the message.
> 

Then we will need a reference to the syslog protocol document for SDE.
Is that correct ?
> will have a short WG Last Call, and then we will submit it to the IESG.

Glenn

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 22 Jun 2007 12:33:00 +0200

> 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

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 23 Jun 2007 14:35:39 +0900

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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Sat, 23 Jun 2007 11:21:55 +0200

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-masked]]
> Sent: Saturday, June 23, 2007 7:36 AM
> To: Rainer Gerhards
> Cc: Chris Lonvick; [email-masked]
> Subject: Re: [Syslog] -syslog-tc-mib Facilities
> 
> Rainer,
> >>> -syslog-tc-mib document; are they normative or non-normative.
> David
> >> and
> >>> 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
> > #define	LOG_AUTH	(4<<3)	/* security/authorization
messages
> */