Hi, I noticed that the below comment on the relationship to the alarm MIB and X.733 severities was not adopted in the latest draft. I can't remember having seen objections to this on the mailer; I think that this mapping would have advantages in that is would be semantically cleaner and less ambiguous and would therefore like to repropose to incorporate it into a subsequent version.
Kind regards --- Alex -----Original Message----- From: Alexander Clemm (alex) Sent: Tuesday, May 10, 2005 5:27 PM To: [EMAIL PROTECTED]; [email protected] Subject: X.733 (was: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt)) Hi, I also have the following additional comment on section 6.2.3.1 - Relation to Alarm MIB. X.733 defines a critical severity as that a service impacting event has occurred and immediate corrective action is required. This appears to correspond to a syslog severity of "Alert", not "Critical" (unfortunately, both X.733 and syslog use the term critical, but their semantics is not exactly the same). X.733 severity of "minor" corresponds to syslog severity of "Error", agree. However, X.733 severity of "major" is in X.733 defined quite different from "minor" and requires "urgent" corrective action. It would appear appropriate to map it into syslog "Critical", not "Error" as well, which would make it indistinguishable from "minor". Finally, it would be nice if X.733 "Cleared" and "Indeterminate" would not both be mapped to the same syslog severity. Yes, it is possible to use "Notice" for both, but why not map "Cleared" to "Informational" instead (since it really indicates that a condition has gone away)? That would result in the following table: X.733 - Syslog -------------- X.733 Critical - Syslog Alert X.733 Major - Syslog Critical X.733 Minor - Syslog Error X.733 Warning - Syslog Warning X.733 Indeterminate - Syslog Notice X.733 Cleared - Syslog Informational --- Alex -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Clemm (alex) Sent: Monday, May 02, 2005 8:47 AM To: [email protected] Subject: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt) Resending due to apparent mailer problems, apologies if you receive multiple copies Hello, I am currently going through the syslog protocol draft, draft-ietf-syslog-protocol-11.txt. A couple of thoughts, suggestions, topics for discussion: Basic principles (section 4): May want to clarify: Will relays be allowed to send messages to multiple receivers? (Not listed as one of the scenarios.) May relays alter a message? (Currently, yes, at least with regards to truncation; should be explicit in discussing what aspects of a message may and what aspects may not be altered.) Required syslog format: There are essentially 3 parts of the message which identify the originator of the message, not even counting the host name: Facility, App-Name, Proc-ID. - Should they be grouped together - why separate them for example with the truncate field - may want to take a look at the order of the fields. I would think that the truncate field should in fact either appear after the version field, or right before the structured data field. - Why would facility consist only of digits, not alphanumeric characters - Are three fields really needed? It seems that it makes sense to allow to identify the type of the subsystem or application that generates the syslog message, as well as the particular instance in case there are several. This makes two fields. Why a third field? Concerning message length: would it make sense to allow for a means by which messages could be fragmented, as an option in addition to truncating? This could be addressed by having standard structured data elements that specify a message as part 1 of 2, for example. Of course, with regards to relays it may imply that messages may need to be altered by relays accordingly. Relationship to Alarm MIB (Section 6.2.3.1 )- suggest adding a table that lists the corresponding relation. Also, really the proper reference to use is probably the ITU specification, X.733. The structured data is an extremely important concept, as this provides for extensibility and separates the "core" fields from the "extension" fields. For the structured data, would it make sense considering to reserve a prefix character (for example, the underscore character) for the SD-name that should not be used for vendor-defined SD elements, so that if later extensions to the syslog protocol are standardized in form of new SD elements there won't be conflicts - or vice versa, to require vendor extensions to start with it? --- Alex _______________________________________________ Syslog-sec mailing list [email protected] http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list [email protected] http://www.employees.org/mailman/listinfo/syslog-sec
