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

Reply via email to