Subject: RE: FW: Probable Cause

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Sun, 14 Apr 2002 05:25:54 -0400

Hi,

Some more duplication cases in ITU-IANA-ALARM-TC:
 
fire (120) & fireDetected (266)

flood (121) & floodDetected (267)

configurationOrCustomisationError (160) &
configurationOrCustomizationError(260)

underlayingResourceUnavailable (166) & underlyingResourceUnavailable(287)

and possibly 
toxicGas (133) & toxicLeakDetected (286)
     ^^^              ^^^^

Kam

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Wednesday, March 27, 2002 3:16 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: FW: Probable Cause
> 
> 
> Hi -
> 
> Looking at the ProbableCause list Andrea posted, it looks like
> there are several distinct kinds of differences of concern to
> our group:
> 
>     1) different labels or numbers.  Annoying, but
>        probably harmless.
> 
>     2) CIM codes more specific than ITU codes.  Example:
>        externalIFDeviceProblem -> either Input Device Error
>        or Output Device Error
> 
>     3) ITU codes more specific than CIM codes.  Example:
>        HVAC Problem -> coolingSystemFailure or
>        ventilationSystemFailure or airCompressorFailure
>        or airConditioningFailure or airDryerFailure or
>        heatingVentCoolingSystemProblem
> 
>     4) "fuzzy" mappings, as in the ITU modulationFailure
>        and demodulationFailure both mapping to a choice
>        in CIM between Dataset/Modem Error and Equipment
>        Malfunction.
> 
>     5) CIM codes with no ITU counterpart, e.g. Software
>        Virus Detected.
> 
> By the way, what's the difference between our iODeviceError
> and our inputOutputDeviceError codes?
> 
>  ------------------------------------------------------
>  Randy Presuhn          BMC Software, Inc.  1-3141
>  [email-masked]  2141 North First Street
>  Tel: +1 408 546-1006   San Jose, California 95131  USA
>  ------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  ------------------------------------------------------
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 14 Apr 2002 13:04:04 +0300

The question is where we go from here. Possible path:

- keep all mappings from the original ITU list (values <256)
- eliminate obvious duplication cases 
- wherever mapping of the ITU to CIM values is not perfect, add new values (>256) to fill in possible alarm cases not covered by ITU

Does this seem reasonable? 

Keep in mind that the draft is clear that 'The following shall be used as the initial values, but the latest values for these textual conventions should be obtained from IANA'.

Regards,

Dan

> From: Lam, Hing-Kam (Kam) [mailto:[email-masked]]
> Sent: Sunday, April 14, 2002 12:26 PM
> To: Randy Presuhn; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: FW: Probable Cause
> 
> 
> Hi,
>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 15 Apr 2002 07:36:53 -0400

hi

It's actually called IANA-ITU-ALARM-TC, but that
probably does not help your concerns much.

Study group 4 has seen the textual convention and
seem happy with it. I'm not sure if they noticed
the 255 limit, but we can verify. 

It would seem a liaison statement on how we get
ITU sign-off on these values would be useful.

Sharon

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Sunday, April 14, 2002 6:33 AM
To: Lam, Hing-Kam (Kam); Randy Presuhn; [email-masked];
[email-masked]; [email-masked]
Cc: Randy Bush; Sidor, Dave [NC1:6L30:EXCH]
Subject: RE: FW: Probable Cause

Is this just me that sort of wrries when I see

> Some more duplication cases in ITU-IANA-ALARM-TC:

To me it is either a set of ITU controled TCs, or a set
of IANA controled TCs. How is this going to work out
if both organisations need to stay in sync on this?

Has anybody checked with ITU that they are happy to be
restricted to 255 code points? Can we get that in a
statement from them (possibly from SG 4?)?

Do we have arranged for ITU to check and sign-off on the
values we currently have in this document?

Maybe I am just worrying too much... I am pretty busy with 
other stuff, so I have not followed all the emails/postings
all that closely.

Bert

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 15 Apr 2002 09:55:20 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: "Lam, Hing-Kam (Kam)" <[email-masked]>,
>         Randy Presuhn <[email-masked]>, [email-masked],
>         [email-masked], [email-masked]
> Cc: Randy Bush <[email-masked]>, Dave Sidor <[email-masked]>
> Date: Sun, 14 Apr 2002 12:33:01 +0200
> 
...

The problem is a both worse and not so bad.

Some of the enumerations are peculiar to the DMTF, and
even the ones that are supposed to be the same from the two
specifications have slightly different names.

However, what we're really trying to do here is to provide
a way of mapping probable cause codes from different
specifications into a single representation.

That is, we're mapping from the ITU and DMTF (and possibly
other) sets into our own.  So, from this perspective, I think
the synchronization issue is less serious.

 Tel: +1 408 546-1006   San José, California 95131  USA

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 15 Apr 2002 19:08:48 +0200

But we are limiting the range within which these other
organisations can extend (if they ever need to) right?
I think it would behoove us to try and get some official
agreement from those other orgs that this is OK. WIth 
official, I think I would be happy to see it in the form
of an email from the specifi cSG or WG (or whatever they 
call them) chair who is responsible for such codes.

Bert 

> Sent: Monday, April 15, 2002 6:55 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> > Message-ID: 
> <[email-masked]
> cent.com>

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 15 Apr 2002 10:33:00 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> To: Randy Presuhn <[email-masked]>, [email-masked],
>         [email-masked], [email-masked], [email-masked]
> Cc: [email-masked], [email-masked]
> Date: Mon, 15 Apr 2002 19:08:48 +0200
> 
...

The language in question in the IANA considerations section
does not constrain ITU in any way.  It only sets aside a space
in which ITU values and our "mapped" values will be the same.
(As a technical contributor, I don't see a lot of value to
keeping the numbers the same, except perhaps in devices too
resource-constrained to implement this MIB anyway.)

|  Values of IANAItuProbableCause less than 255 can only be given out
|  if they correspond to ITU numbers and are agreed to by the disman
|  working group. Values of IANAItuProbableCause greater than 255 can
|  be given out when agreed to by the disman working group.
|
|  Values of IANAItuEventType can be given out when agreed to by the
|  disman working group.
 
(I do agree with the earlier comment that the second
paragraph implies a kind of WG immortality that is probably
not appropriate.)

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 15 Apr 2002 15:27:38 -0700 (PDT)

Hi -

> Date: Sun, 14 Apr 2002 13:04:04 +0300
> Message-ID: <[email-masked]>
> From: "Romascanu, Dan (Dan)" <[email-masked]>
>         "Randy Presuhn" <[email-masked]>, <[email-masked]>,
>         <[email-masked]>
> Cc: <[email-masked]>
...
...

As a technical contributor, I think this might be a start,
but it's not enough.  See my posting *much* earlier in this
thread to see why.  In short: we also have 1:n, n:1, and n:n
mappings between the DMTF and the ITU stuff to consider.
At the very least I think we need to say something about
performing the mappings in such a way as to not lose precision
from whatever was received.

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 15 Apr 2002 15:38:40 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> From: "Sharon Chisholm" <[email-masked]>
> To: [email-masked]
> Cc: Randy Bush <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
> Date: Mon, 15 Apr 2002 07:36:53 -0400
...
...

Please, let's NOT get into this mode of operation.

The ITU does not "own" this MIB.  It's a product of
this working group, and part of our job is to consider
related work, such as that of the ITU, to ensure that we
can adequately represent the things we need to represent.
Both the SG4 and the DMTF have been most helpful in providing
us with information so that we might accomplish our task.

If we believe that we have a requirement to be able to
preserve "probable cause" semantics from DMTF and ITU
management information, the minimum requirement for us is
only to ensure that we define a mapping from their code sets
to ours that does not lose information.  They do not need to
approve our mappings.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 16 Apr 2002 13:53:56 +0300

>  Randy Presuhn         

I agree. 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 16 Apr 2002 14:05:49 +0300

> > - wherever mapping of the ITU to CIM values is not perfect, 
> add new values (>256) to fill in possible alarm cases not 
> covered by ITU
> > 

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 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.

IMO the text assigning the responsibility of administrating the list to the disman wg for eternity should be changed. 

Regards,

Dan

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 17 Apr 2002 09:58:17 +0200

I think I did not understand that we were talking about
a mapping. If it is a mapping then I think there is no problem.

Bert 

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Tuesday, April 16, 2002 12:54 PM
> To: Randy Presuhn; [email-masked]

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 17 Apr 2002 13:56:07 -0700 (PDT)

Hi -

> content-class: urn:content-classes:message
> Date: Tue, 16 Apr 2002 14:05:49 +0300
> Message-ID: <[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…

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 f…

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".

...

Agreed.

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 22 Apr 2002 10:35:51 -0700 (PDT)

Hi Dave -

> Message-ID: <[email-masked]>
> Date: Mon, 22 Apr 2002 12:09:55 -0400
> From: "Dave Sidor" <[email-masked]>
> To: "Wijnen, Bert (Bert)" <[email-masked]>
> Cc: Randy Presuhn <[email-masked]>, [email-masked],
>         Randy Bush <[email-masked]>, "*Matthews, Dave" <[email-masked]>,
>         "*Grim, Tom" <[email-masked]>,
>         "*IETF, communication statements" <[email-masked]>
> References: <[email-masked]>
...
> In Bert's email below he raised an issue that SG 4 addressed at its
> meeting that concluded on Friday. The SG 4 input is presented below
> Bert's email and also attached as a Word document. I have also copied
> this email to the IETF email address for communication statements from
> other organizations.
...

On behalf of the IETF disman working group, I'd like to thank you
for the helpful input from SG 4.   We'll take these comments into
account as we produce our next revision to the draft.  Of course,
comments from the individual SG 4 participants are always welcome
on our mailing list.  Again, thank you (and SG 4) for taking the
time to review our work.

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 22 Apr 2002 16:25:08 -0700 (PDT)

Hi -

...
> TITLE:	Additional input regarding the use of  M.3100 probable causes for
> the ITU Alarm MIB
...
> 3) We have noted in section 5.2 that you have specified an
> IANAItuProbableCause textual convention apparently dedicated to the
> ITU-T probable causes and support that separation from any other
> probable cause asssignments. To ensure that separation, we recommend
> that the first paragraph of section 5.2 be replaced with the following
> text:
> 
> "Values of IANAItuProbableCause can only be given out if they correspond
> to ITU probable causes semantics present in ITU-T Recommendations and
> are agreed to by the disman working group."
> 
> We believe this text reflects the fact that this textual convention is
> limited to representing the ITU semantics while at the same time
> identifying the IETF as the owner of the alarm MIB. Other textual
> conventions would be presumably required to define the semantics and
> number assignments of other probable causes. 
...

I'd like to get a sense of the working group on what the
scope of "probableCause" should be:

	a) ITU's M.3100's probable causes
	b) ITU's X.733's probable causes
	c) ITU's future probable causes
	d) DMTF's CIM's probable causes
	e) DMTF's future probable causes
	f) IETF's future probable causes

Based on the history of this work, (a), (b), and (c) 
make sense in the architecture which separates "generic" alarm
management from "specific" models, such as ITU's.

As the document is currently constituted, we're closer to
having all of (a) through (f).  If this is the direction
we're headed, then it may make sense to re-label some items
to reflect the broader scope, while retaining the references
that make it clear that supporting the full range of ITU
probable cause semantics is an objective.