Subject: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt)))

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 2 Jun 2005 10:20:15 -0700

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-masked]; [email-masked]
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-masked]
[mailto:[email-masked]] On Behalf Of Alexander
Clemm (alex)
Sent: Monday, May 02, 2005 8:47 AM
To: [email-masked]
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-masked]
http://www.employees.org/mailman/listinfo/syslog-sec
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec