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

[stefan vallin <[e-mail]>]

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
>