Re: [CCAMP] draft-ietf-ccamp-alarm-module-04/Clause 4.4 Alarm List history

Hi Marta!
Hope the below description helps:

Assume the following alarm notifications:
[time, resource, alarm-type, perceived-severity]

T1, r1, a-t1, warning
T2, r1, a-t1, clear
T3, r1, a-t1, warning
T4, r2, a-t2, warning
T5, r2, a-t2, clear
T6, r2, a-t2, warning
T7, r1, a-t1, clear

I will use the following truncated data-model for the alarm-list to illustrate:
     +--ro alarm* [resource alarm-type-id alarm-type-qualifier]
        +--ro is-cleared                 boolean
        +--ro last-changed               yang:date-and-time
        +--ro perceived-severity         severity
        +--ro status-change* [time]
           +--ro time                    yang:date-and-time
           +--ro perceived-severity      severity-with-clear

The above notifications will result in the following alarm list

alarm[r1, a-t1]
   is-cleared: true
   last-changed: T7
   perceived-severity: warning
   status-change
     T7, clear
     T3, warning
     T2, clear
     T1, warning
alarm[r2, at-2]
   is-cleared: false
   last-changed: T6
   perceived-severity: warning
   status-change
      T6, warning
      T5, clear
      T4, warning

The alarm list has two alarms, last changed at T7 and T6.
For each alarm you have the time stamps for the associated notifications.
T7
   T7
   T3
   T2
   T1
and
T6
   T6
   T5
   T4

So in order to get the original list of notifications, the management application
would have to flatten this. And this is by design. From usability perspective it
is not the list of notifcations that matters, it is how they map to the aggregated
alarm state. The operator sees two alarms and their history rather than 7 notifications.

br Stefan

> On 5 Nov 2018, at 17:35, Marta Seda <Marta.Seda@calix.com> wrote:
> 
> Hello Stefan,
> Some colleagues of mine that have been reviewing “draft-ietf-ccamp-module-04”.   We have a question about the structure used in Clause 4.4 for alarm history:
>   +--ro status-change* [time] {alarm-history}?
> 
>          |  +--ro time                  yang:date-and-time
> 
>          |  +--ro perceived-severity    severity-with-clear
> 
>          |  +--ro alarm-text            alarm-text
> 
>  
> The status-change list has a single time key.
>  
> If you wanted to troubleshoot and look at alarms that occurred during a specific time window (e.g., alarms that occurred in the past between time x and y), how could you do this in the present model?
>  
> Or is the idea that a manager above the NETCONF server would provide that functionality through its own instrumentation? 
>  
> Could you clarify the intent of the model?
>  
> Thanks.
>  
> Marta Seda
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org <mailto:CCAMP@ietf.org>
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>