ietf-alarms

Organization:

IETF CCAMP Working Group

Module:

ietf-alarms

Version:

2019-09-11

File:

ietf-alarms@2019-09-11.yang

Abstract:

This module defines an interface for managing alarms. Main inputs to the module design are the 3GPP Alarm Integration Reference...

Contact:

WG Web: <https://trac.ietf.org/trac/ccamp>
WG List: <mailto:ccamp@ietf.org>

Editor: Stefan Vallin
<mailto:stefan@wallan.se>

Editor: Martin Bjorklund
<mailto:mbj@tail-f.com>

Check for an additional details:

YANG Catalog

Description:

This module defines an interface for managing alarms. Main
inputs to the module design are the 3GPP Alarm Integration
Reference Point (IRP), ITU-T X.733, and ANSI/ISA-18.2 alarm
standards.
Main features of this module include:

* Alarm list:
A list of all alarms. Cleared alarms stay in
the list until explicitly purged.

* Operator actions on alarms:
Acknowledging and closing alarms.

* Administrative actions on alarms:
Purging alarms from the list according to specific
criteria.

* Alarm inventory:
A management application can read all
alarm types implemented by the system.

* Alarm shelving:
Shelving (blocking) alarms according
to specific criteria.

* Alarm profiles:
A management system can attach further
information to alarm types, for example,
overriding system-default severity
levels.

This module uses a stateful view on alarms. An alarm is a state
for a specific resource (note that an alarm is not a
notification). An alarm type is a possible alarm state for a
resource. For example, the tuple:

('link-alarm', 'GigabitEthernet0/25')

is an alarm of type 'link-alarm' on the resource
'GigabitEthernet0/25'.

Alarm types are identified using YANG identities and an optional
string-based qualifier. The string-based qualifier allows for
dynamic extension of the statically defined alarm types. Alarm
types identify a possible alarm state and not the individual
notifications. For example, the traditional 'link-down' and
'link-up' notifications are two notifications referring to the
same alarm type 'link-alarm'.

With this design, there is no ambiguity about how alarm and
alarm clear correlation should be performed; notifications that
report the same resource and alarm type are considered updates
of the same alarm, e.g., clearing an active alarm or changing
the severity of an alarm. The instrumentation can update the
severity and alarm text on an existing alarm. The above alarm
example can therefore look like the following:

(('link-alarm', 'GigabitEthernet0/25'),
warning,
'interface down while interface admin state is up')

There is a clear separation between updates on the alarm from
the underlying resource, like clear, and updates from an
operator, like acknowledging or closing an alarm:

(('link-alarm', 'GigabitEthernet0/25'),
warning,
'interface down while interface admin state is up',
cleared,
closed)

Administrative actions like removing closed alarms older than a
given time is supported.

This YANG module does not define how the underlying
instrumentation detects and clears the specific alarms. That
belongs to the Standards Development Organization (SDO) or
enterprise that owns that specific technology.

The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.

Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.

Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).

This version of this YANG module is part of RFC 8632; see
the RFC itself for full legal notices.