Re: [CCAMP] review of draft-ietf-ccamp-alarm-module-01

[tom petch <[e-mail]>]

Stefan

I have the same difficulties with your response as I have with the
I-D:-(

When you say,
" (resource, alarm-type-id, alarm-type-qualifier)->(alarm state)"
 I read it as meaning that
 a given value of a resource and
 a given value of an alarm-type-id and
 a given value of an alarm-type-qualifier
defines a value of alarm-state with other values such as
 time-created
 perceived-severity
 alarm-text
being irrelevant.

When you then say
"So by alarm state the composite state of an alarm comprises the alarm
severity, if it is cleared, the text, list of resource alarm state
changes, list of operator state changes)"
I understand that the definition of alarm state includes
 alarm severity
 if it is cleared
 the text
 list of resource alarm state changes
 list of operator state changes

This tells me that the meaning of the term 'alarm state' varies
throughout the document in a way I cannot predict, I cannot grasp.  I
then struggle (fail?) to understand the I-D.

With the term 'event', prior art uses 'event' as a generic term with
'alarm' being that subset that indicates a fault. This says to me that
if you want to give a different meaning to 'event', as you say below,
then you should define 'event' (else - again - I get confused).

Tom Petch


----- Original Message -----
From: "stefan vallin" <[e-mail]>
To: "tom petch" <[e-mail]>
Cc: <[e-mail]>
Sent: Saturday, August 11, 2018 6:52 PM

Hi Tom!

> On 10 Aug 2018, at 13:53, tom petch <[e-mail]> wrote:
>
> Stefan
>
> I find this I-D (too) hard to understand.
Sad to hear, I spent some time on describing it...

> The problem I have is with
> terminology which seems elastic.
OK, I read you, understand I need to improve on the basic definitions,
important
Terminology is everything.

>
> Thus 'alarm state' is not defined as a term; it is in other alarm work
> where the definition would fit with usage such as
>
>   The operator state for an alarm can be: "none", "ack", "shelved",
and
>   "closed".
> or
> actual state of the alarms
> or
> The alarm list (/alarms/alarm-list) is a function from (resource,
>   alarm type, alarm type qualifier) to the current alarm state.
>
> But this meaning makes no sense to me when the term appears in
> o  Alarm Instance: The alarm state for a specific resource and alarm
> type.
> or
> o  Alarm Type: An alarm type identifies a possible unique alarm state
> for a resource.
>
> and since I cannot understand what you mean by these two terms, I
think
> I cannot understand the document.
Oh oh, fundamental, I need to improve, let my try a quick one:
I think I need to improve the right side of the function
 (resource, alarm-type-id, alarm-type-qualifier)->(alarm state)
The alarm state is really a composite state.

From pyang tree output:

     |  +--ro alarm* [resource alarm-type-id alarm-type-qualifier]
     |     +--ro resource                 resource
     |     +--ro alarm-type-id            alarm-type-id
     |     +--ro alarm-type-qualifier     alarm-type-qualifier
     |     +--ro alt-resource*            resource
     |     +--ro related-alarm* [resource alarm-type-id
alarm-type-qualifier]
     |     |     ...
     |     +--ro impacted-resource*       resource
     |     +--ro root-cause-resource*     resource
     |     +--ro time-created             yang:date-and-time
     |     +--ro is-cleared               boolean
     |     +--ro last-changed             yang:date-and-time
     |     +--ro perceived-severity       severity
     |     +--ro alarm-text               alarm-text
     |     +--ro status-change* [time] {alarm-history}?
     |     |     ...
     |     +--ro operator-state-change* [time] {operator-actions}?
     |     |     ...
     |     +---x set-operator-state {operator-actions}?
     |     |     ...
     |     +---n operator-action {operator-actions}?
     |           ...

This means:
(resource, alarm-type-id, alarm-type-qualifier)->(time-created,
is-cleared, last-changed, perceived-severity, alarm-text, status-change,
operator-state-change)

So by alarm state the composite state of an alarm comprises the alarm
severity, if it is cleared, the text, list of resource alarm state
changes, list of operator state changes)

This means that you can ask what is the alarm state of (FastEthernet1/0,
linkAlarm) and get the answer: current severity, is it cleared?, current
operator state like “ack” etc.


>
> Another example would be the use of 'event' which appears as
>
> 1.  the definition focuses on leaving out events and logging
information
> in general.
>
> This I-D does not define event; previous IETF work, e.g. RFC3877 does,
> and makes it clear that an alarm (class) is a subset of an event which
> would make no sense here.

I disagree, the focus of the definition in this draft is to exclude
general events to appear as alarms.
>
> There is a lot of prior art in this field but this I-D seems to go
> against it rather than build on it.
Yes!
I am well aware of prior work, spent 25 years in the alarm industry,
standards and systems.
Prior is not equivalent to art by definition.

This draft stands in giants shoulders, X.733, 3GPP Alarm IRP, RFC3877
etc but with improvements.

Your statement is very general, hard to comment. Can you make a more
specific statement? Example?
I can mention some areas where I did make some design decisions that
does not align with X.733, 3GPP Alarm IRP etc.

* Most alarm standards are focused on a list of notifications, this
draft is focused on the alarm list as a function (resource,
alarm-type-id, alarm-type-qualifier)->(composite alarm state)

* Key for alarm / alarm notification
  X.733 uses managed object (resource), event type, probable cause,
specific problem. The most relevant attribute being probable cause, a
global flat enum.
  3GPP Alarm IRP has confusing redundant overlapping keys “alarmId” an
integer, and the X733 tuple. The standard even shows an example where
alarmId and the X733 tuple is in conflict.

 This draft simplifies this with the hierarchical alarm-type-id.

* Separation of resource life-cycle and operator life-cycle.
  For example, 3GPP Alarm IRP has the notion of “manual-clear”, an
operator setting the alarm clearance state. This is confusing.

* Separating alarm clearance from alarm severity.
  This alarm module separates the clearance state of an alarm from the
alarm severity. X.733 and 3GPP does not.

And more….

Br Stefan



>
> Tom Petch
>
> ----- Original Message -----
> From: "stefan vallin" <[e-mail]>
> To: "Qin Wu" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Sunday, July 22, 2018 7:17 PM
>