[CCAMP] draft-ietf-ccamp-alarm-module-02 CHANGES

[stefan vallin <[e-mail]>]

Hi All!
Please find a new version 02 of the alarm module, changes below.
Going forward we would like to focus on clarifications and possible errors and limit new features.

Br Stefan and Martin

Alarm Model Changes
==================

Comments from [ITU-T Study Group 15]
================================
#1 Clearly state that the module does not define the instrumentation
Regarding the scope of the YANG Alarm Module, the draft should
explicitly state that the modeling of how transport resource alarms
are raised and cleared by the underlying transport instrumentation is
out of the scope of this draft. [...] should belong to the SDO/group
that owns the transport technology.
---
     Added clarification to the module description:

     This alarm module does not define how the underlying
     instrumentation detects and clears the specific alarms.
     That belongs to the SDO or enterprise that owns that
     specific technology.

#2 The alarm YANG draft adopts the X.733 alarm severities, but doesn’t
support the function of alarm severity assignment (i.e., configuring
the severity of an alarm type of a resource), i.e., the feature of the
Alarm Severity Assignment Profile (ASAP) object of M.3160/M.3100 is
not supported by the draft. Is this intended to be out of the scope of
the alarm YANG draft?
---
    Added alarm profile to the model:
     +--rw alarm-profile* [alarm-type-id alarm-type-qualifier-match resource] {alarm-profile}?
        +--rw alarm-type-id                        al:alarm-type-id
        +--rw alarm-type-qualifier-match           string
        +--rw resource                             al:resource-match
        +--rw description                          string
        +--rw alarm-severity-assignment-profile {severity-assignment}?
           +--rw severity-levels*   al:severity

#3 For alarm reporting control, the alarm YANG draft supports only the
simple alarm shelf function. It doesn’t support the rich features of
the Alarm Reporting Control (ARC) function of M.3160/M.3100, which
is required by G.7710.
---
Added severity filter to the notification control. Alarm shelving and
the notification filter maps to ARC.


Comments from Qin Wu Huawei
==========================
#1 Document related alarms, impacted resources, root cause
---
    Updated 3.6.  Root Cause, Impacted Resources and Related Alarms

#2 Review use of remove, delete and purge
---
    Cleaned up throughout the document

#3 Add uuid RFC6991 to resource
---
    Added uuid to the union:
    typedef resource {
        type union {
            type instance-identifier {
            require-instance false;
           }
        type yang:object-identifier;
        type string;
        type yang:uuid;
    }


Comments from Nick Hancock, Adtran
==============================

#1 Admin actions on shelved alarms
---
    Added rpc compress-shelved-alarms
    purge rpc description updated to include shelved alarms

#2 Add support for alarm severity assignment
---
    Same as ITU, see above

#3 Alarm summary should be feature
---
      feature alarm-summary {
      ...
      container summary {
          if-feature alarm-summary;

#4 Move notifications inside list
---
     notification operator-action moved into alarm list

#4 Notification filter on severity
---
    Added severity level to notification filter
          choice notify-status-changes {
        description
          "This leaf controls the notifications sent for alarm status
           updates. There are three options:
           1. notifications are sent for all updates, severity level
              changes and alarm text changes
           2. notifications are only sent for alarm raise and clear
           3. notifications are sent for status changes equal to or
              above the specified severity level. Clear notifications
              shall always be sent
              Notifications shall also be sent for state changes that
              makes an alarm less severe than the specified level.
           In option 3, assuming the severity level is set to major,
           and that the alarm has the following state changes
           [(Time, severity, clear)]:
           [(T1, major, -), (T2, minor, -), (T3, warning, -),
            (T4, minor, -), (T5, major, -), (T6, critical, -),
            (T7, major. -), (T8, major, clear)]
           In that case, notifications will be sent at
           T1, T2, T5, T6, T7 and T8.";
        leaf notify-all-state-changes {
          type empty;
          description
            "Send notifications for all status changes.";
        }
        leaf notify-raise-and-clear {
          type empty;
          description
            "Send notifications only for raise, clear, and re-raise.
             Notifications for severity level changes or alarm text
             changes are not sent.";
        }
        leaf notify-severity-level {
          type severity;
          description
            "Only send notifications for alarm state changes
             crossing the specified level. Always send clear
             notifications.";
        }
      }


Comments from Marta Seda, Calix.
============================
The ietf-alarms-x733.yang module does not contain all X733/X736
parameters.
---
   Added all X.733 parameters:
     augment /al:alarms/al:alarm-list/al:alarm:
    +--ro event-type?                event-type
    +--ro probable-cause?            uint32
    +--ro probable-cause-string?     string
    +--ro threshold-information
    |  +--ro triggered-threshold?   string
    |  +--ro observed-value?        value-type
    |  +--ro (threshold-level)?
    |  |  +--:(up)
    |  |  |  +--ro up-high?         value-type
    |  |  |  +--ro up-low?          value-type
    |  |  +--:(down)
    |  |     +--ro down-low?        value-type
    |  |     +--ro down-high?       value-type
    |  +--ro arm-time?              yang:date-and-time
    +--ro monitored-attributes* []
    |  +--ro id?      al:resource
    |  +--ro value?   string
    +--ro proposed-repair-actions*   string
    +--ro trend-indication?          trend
    +--ro backedup-status?           boolean
    +--ro backup-object?             al:resource
    +--ro additional-information* []
    |  +--ro identifier?    string
    |  +--ro significant?   boolean
    |  +--ro information?   string
    +--ro security-alarm-detector?   al:resource
    +--ro service-user?              al:resource
    +--ro service-provider?          al:resource


Authors
======

#1 Clarify that alarm-inventory is mandatory

#2 Added require-instance false for alarm-type-id and
 alarm-type-qualifier leafs in rpc compress-alarms

# Editorial changes