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

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 2 Jun 2005 14:00:34 -0400

hi

I'm just context switching back here.

Cleared is definitely not informational. I image people filtering on
severity and a clear is a very important piece of information when looking
at Alarms. It should not be lumped in with 'informational'.

The ID seems to only provide the following formal definitions of its own
severities. If more are implied from other sources they should be
referenced:

Emergency: system is unusable
Alert: action must be taken immediately
Critical: critical conditions
Error: error conditions
Warning: warning conditions
Notice: normal but significant conditions
Informational: informational messages
Debug: debug-level messages

Nothing indicates that action is not required in the case of a critical. I
believe it is implicit.  In fact, I suspect action is required for emergency
as well. I believe the terms match reasonably well and subtle differences do
not justify the confusion that would be caused by having a
non-straightforward mapping (critical=minor and minor=Tuesday).

Given the above, I believe it falls out that Major is then an Error.

Sharon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Alexander
Clemm (alex)
Sent: Thursday, June 02, 2005 1:20 PM
To: [email-masked]
Subject: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog
protocoldraft(draft-ietf-syslog-protocol-11.txt)))

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

_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 29 Jun 2005 14:10:01 -0400

hi

After further discussion with some folks, we figure we can live with the
following mapping

ITUPerceivedSeverity  Critical - Syslog Alert
ITUPerceivedSeverity  Major - Syslog Critical
ITUPerceivedSeverity  Minor - Syslog Error
ITUPerceivedSeverity  Warning - Syslog Warning
ITUPerceivedSeverity  Indeterminate - Syslog Notice
ITUPerceivedSeverity  Cleared - Syslog Notice

Both mappings are problematic, so it is about picking your engineering
trade-offs.

Sharon

-----Original Message-----
From: Alexander Clemm (alex) [mailto:[email-masked]] 
Sent: Thursday, June 02, 2005 7:00 PM
To: Chisholm, Sharon [CAR:5K50:EXCH]; [email-masked]
Subject: RE: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog

Hi,

for the cleared severity, I agree that "notice" is fitting, however, it has
the disadvantage that your mapping now is no longer reversible if you use
the same for severity "minor".  Judgment call as to want to want to retain a
distinction between minor and cleared severities when doing the mapping
(they clearly have different semantics), or want to put them into the same
thing.  As X.733 distinguishes 6 severities and syslog 8, I think it would
be nice if they could still be distinguished in a
syslog mapping.   

For the other severities, I do think that the mapping as currently stated in
section 6.2.3.1 would result in altering respectively losing the semantics
of the severities of what is being mapped.  The proposal on the other hand
largely preserves the semantics, with the one caveat on "cleared" as
mentioned above.  

For your reference, I am pasting below the definition of severities from
X.733.  Major is clearly more than just an error; if it were mapped to that
the notion that urgent corrective action is required (part of the X.733
definition) is lost. Minor has semantics that are quite different from
major, also for example that it's non-service affecting.  My concern is that
if they are all mapped into the same syslog severity and distinction between
X.733 is not preserved, that it raises the question if it makes sense to
outline a mapping of severities in the syslog protocol at all.  

Thanks
--- Alex

X.733 snippet (from X.733 section 8.1.2.3):

-	cleared: The Cleared severity level indicates the clearing of
one or more previously reported alarms. This alarm clears all alarms for
this managed object that have the same Alarm type, Probable cause and
Specific problems (if given).  Multiple associated notifications may be
cleared by using the Correlated notifications parameter (defined below).
This Recommendation | International Standard does not require that the
clearing of previously reported alarms be reported.  Therefore, a managing
system cannot assume that the absence of an alarm with the Cleared severity
level means that the condition that caused the generation of previous alarms
is still present.  Managed object definers shall state if, and under which
conditions, the Cleared severity level is used.
-	indeterminate: The Indeterminate severity level indicates that
the severity level cannot be determined. 
-	critical: The Critical severity level indicates that a service
affecting condition has occurred and an immediate corrective action is
required.  Such a severity can be reported, for example, when a managed
object becomes totally out of service and its capability must be restored. 
-	major: The Major severity level indicates that a service
affecting condition has developed and an urgent corrective action is
required.  Such a severity can be reported, for example, when there is a
severe degradation in the capability of the managed object and its full
capability must be restored. 
-	minor: The Minor severity level indicates the existence of a
non-service affecting fault condition and that corrective action should be
taken in order to prevent a more serious (for example, service
affecting) fault. Such a severity can be reported, for example, when the
detected alarm condition is not currently degrading the capacity of the
managed object. 
-	warning: The Warning severity level indicates the detection of a
potential or impending service affecting fault, before any significant
effects have been felt. Action should be taken to further diagnose (if
necessary) and correct the problem in order to prevent it from becoming a
more serious service affecting fault.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sharon
Chisholm
Sent: Thursday, June 02, 2005 11:01 AM
To: [email-masked]
Subject: RE: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog
protocoldraft(draft-ietf-syslog-protocol-11.txt)))

hi

Sharon

-----Original Message-----

Hi,

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

Hi,

--- Alex

-----Original Message-----

Hello,

 

 
 
--- Alex