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

[stefan vallin <[e-mail]>]

Hi Tom!
Ok, I will have a thorough read throughout the document to make sure I am using the terms consistently.
* alarm
* alarm notification
* alarm composite state (rather than just state)
  will make sure I emphasise it is a composite state.

When referring to alarm severity, alarm clearance etc I will make sure that is made clear that I am referring to a specific state.

Going back to your concerns on my definition of alarm and other standards.
It is interesting to follow how 3GPP Alarm IRP has changed its definition over the years.

3GPP TS 32.111-1 Part 1: 3G fault management requirements

V12.0.0 (2013-06)
* alarm: abnormal network entity condition, which categorizes an event as a fault


V15.0.0 (2018-06)
* alarm: An alarm signifies an undesired condition of a resource
             (e.g. network element, link) for which an operator action is
             required. It emphasizes a key requirement that operators [...]
             should not be informed about an undesired condition unless it
             requires operator action.

* alarm notification: Notification used to inform the recipient about the
             occurrence of an alarm.


Please note how the later version from 2018-06 is almost literally the same
as in the ietf alarm draft. The earlier version from 2013 is using
yours of alarms as a special case of event.

So I disagree totally that I do not follow standards. We are progressing standards.
(The 3GPP working group read my earlier work, during their revisions).

So the definition of the term “alarm" is focusing on the resulting condition (composite state), not the individual notifications.
We use “alarm notifications” to refer to the individual notifications that informs of an update of the alarm composite state, might be a severity change, might be a clearance, ...

Br Stefan


> On 14 Aug 2018, at 13:50, tom petch <[e-mail]> wrote:
> 
> 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
>> 
> 
>