Subject: RE: FW: Probable Cause

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 2 May 2002 13:20:09 +0300

Thank you for the clarification. The issue is still on our open issues list. The initial intention (this is at least my understanding) was to provide the ITU Alarms as default set, and to add values from other sources if we discover cases not covered by the ITU. This is intended to be an open list, managed by the IANA. However, we got into complications because of the partial superposition of some values, and the 1:n, n:1, and n:n mappings that several contributions to the list pointed to. We are still agonizing on what the better compromise would be.

Regards,

Dan

> -----Original Message-----
> From: Andrea Westerinen [mailto:[email-masked]]
> Sent: Thursday, May 02, 2002 10:10 AM
> To: Randy Presuhn; [email-masked]
> Cc: [email-masked]
> Subject: RE: FW: Probable Cause
> 
> 
> Randy and Dan,
> I would like to clarify a few items about the DMTF mapping of 
> ProbableCause.
> There is concern that we have 1:n, n:1, and n:n mappings 
> between the DMTF
> and the ITU stuff to consider.  I would like to explain some 
> of the issues
> and how the DMTF approached them.  Probable Cause in CIM really has 2
> fields - one enumerated "cause" and another string field
> (ProbableCauseDescription) with more details.  It is assumed that the
> Description property provides any additional details that may 
> be available.
> 
> In an early posting, Randy noted that CIM's Cause="HVAC 
> Problem" was an
> example of a 1:N mapping (CIM to ITU).  Specifically, CIM's 
> HVAC Problem
> mapped to ITU's coolingSystemFailure or ventilationSystemFailure or
> airCompressorFailure or airConditioningFailure or airDryerFailure or
> heatingVentCoolingSystemProblem.  However, we made that 
> choice consciously
> since it was not possible to define the difference between
> coolingSystemFailure, airConditioningFailure and
> heatingVentCoolingSystemFailure.  So, if we could not define 
> when one would
> be used versus the other - we opted for a general enumerated 
> value and a
> specific description field to indicate what else might be known.
> 
> Andrea
> 
> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 1:56 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: FW: Probable Cause
> 
> 
> Hi -
> 
> > content-class: urn:content-classes:message
> > Subject: RE: FW: Probable Cause
> > Date: Tue, 16 Apr 2002 14:05:49 +0300
> > Message-ID:
> <[email-masked].
> avaya.com>
> > From: "Romascanu, Dan (Dan)" <[email-masked]>
> > To: "Randy Presuhn" <[email-masked]>, <[email-masked]>,
> >         <[email-masked]>
> > Cc: <[email-masked]>
> ...
> > I am not sure that I follow you completely. Our concept is 
> that the ITU
> list is the basic staff and reference model for the list of 
> possible causes.
> We should add staff from other sources only when we think something is
> missing in the ITU list. This was the reason - as I 
> understood it - to look
> into the DMTF stuff.
> 
> If we're just passing through stuff from other sources, we don't
> even need to maintain the list.  But if we really do care what the
> enumeration *means*, we've got a problem.
> 
> What worries me here is the question of what kind of guidance we can
> provide to those using these values.  If our list includes everything
> from both the DMTF and ITU sources, there are several possible values
> that might be used to report, for example, a heating problem.
> 
> >
> > If somebody invents a better and greater list later, he 
> could go to IANA
> and have the his new values added to the TC, as well as explanatory
> commented text to document the mapping of other values from 
> his list in the
> previously available values.
> 
> 
> That's fine.  My question is how someone implementing the
> code to generate an alarm would choose a particular value for
> ProbableCause from the overlapping possibilities.  I think
> it amounts to recommending to implementors that they choose
> the narrowest semantic which does not exclude the real
> "probable cause".
> 
> > IMO the text assigning the responsibility of administrating 
> the list to
> the disman wg for eternity should be changed.
> ...
> 
> Agreed.
> 
>  ------------------------------------------------------
>  Randy Presuhn          BMC Software, Inc.  1-3141
>  [email-masked]  2141 North First Street
>  Tel: +1 408 546-1006   San Josi, California 95131  USA
>  ------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  ------------------------------------------------------
> 
>

---

From: "Andrea Westerinen" <[email-masked]>
Date: Thu, 2 May 2002 08:22:55 -0700

Dan, If I can help, I am interested in contributing.  This is a complex
problem that we are struggling with also.  Alignment and mapping would be
great!

I will sign up for the DISMAN list to prevent all the CC:s.
Andrea

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 3:20 AM
To: Andrea Westerinen; Randy Presuhn; [email-masked]
Cc: [email-masked]
Subject: RE: FW: Probable Cause

Thank you for the clarification. The issue is still on our open issues list.
The initial intention (this is at least my understanding) was to provide the
ITU Alarms as default set, and to add values from other sources if we
discover cases not covered by the ITU. This is intended to be an open list,
managed by the IANA. However, we got into complications because of the
partial superposition of some values, and the 1:n, n:1, and n:n mappings
that several contributions to the list pointed to. We are still agonizing on
what the better compromise would be.

Regards,

Dan