Re: [Syslog] -syslog-tc-mib Facilities
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Syslog] -syslog-tc-mib Facilities
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
----- Original Message -----
From: "Chris Lonvick" <clonvick at cisco.com>
To: <syslog at ietf.org>
Sent: Friday, June 15, 2007 10:54 PM
Subject: [Syslog] -syslog-tc-mib Facilities
> 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
> Syslog at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________
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.