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:[EMAIL PROTECTED] > Sent: Monday, September 24, 2007 11:58 AM > To: 'Chris Lonvick'; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > 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 > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
