[Syslog] RE: syslog-tc-mib-02

["David B Harrington" <dbharrington at comcast.net>]

Hi,

In rereading this message, I realize that "may also use" could be
misinterpreted as meaning "may use SDEs instead of". So the wording
might be better as "may use supplementary"

dbh  

> -----Original Message-----
> From: David Harrington [mailto:ietfdbh at comcast.net] 
> Sent: Monday, September 24, 2007 11:58 AM
> To: 'Chris Lonvick'; glenn at cysols.com
> Cc: syslog at ietf.org
> Subject: syslog-tc-mib-02
> 
> Hi,
> 
> I have reviewed syslog-tc-mib and have some comments.
> 
> 1. wording
> 
> /in general will/will usually/
> /among other things//
> /-- Will be assigned by IANA//
> 
> 2. The description of SyslogFacility should include the text
currently
> found in a comment
> "	   -- Some of the operating system daemons and processes are
> 	   -- traditionally designated by the Facility values given
> below.
> 	   -- Daemons and processes that do not have an explicitly
> 	   -- assigned Facility may use any of the "local use"
> Facilities
> 	   -- or they may use the "user-level" Facility."
> /of the//
> 
> 3. The descripiton of SyslogFacility should state that "The range of
> this TC cannot be extended beyond (23), because it is used to
> calculate priority, which is the product of facility and severity."
> 
> 4. I think the descripton clause for facility should include the
> following from the overview: "The facility codes 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 [RFCPROT] may also use Structured Data Elements
>    (SDEs) to clarify the entity that originated
>    the content of the message."
> (I recommend this because MIB modules are often shipped without the
> surrounding document text, and we want users to see this
information.
> I also condensed the text slightly from the comment.)
> 
> 5. The descripiton of SyslogSeverity should state that "The range of
> this TC cannot be extended beyond (7), because it is used to
calculate
> priority, which is the product of facility and severity."
> 
> 6. The decription in SyslogSeverity should explain that "the
> definitions for each severity are not clearly defined, and
> traditionally the daemon or process chooses the severity to report
> based on information it has available." I recommend adding a
REFERENCE
> clause to the discussion of severity values in RFCPROT A.3.
> 
> 7. I think the descripton clause for severity would benefit from
> including the following: 
> "The severity codes have been useful in qualifying the importance of
> the
>    content of the messages. Implementations of the
>    syslog protocol [RFCPROT] may also use Structured Data Elements
>    (SDEs) to further clarify the importance of the content."
> 
> 8. There is a NOTE that says PROT will be replaced; it does not
> identify who should do the replacement. I suggest updating the ID
> number to 23, and turning the NOTE into an RFC editor's note.
> 
> 9. I have checked the MIB module using libsmi, and the document
using
> idnits, and the document looks good.
> 
> David Harrington
> dbharrington at comcast.net
> ietfdbh at comcast.net
> 
> 
> 



_______________________________________________
Syslog mailing list
Syslog at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog