Hi, The main issue I have with this draft is that it's there's no way for the operator to get a list of all possible alarms on the device, without device-specific semantic knowledge. They can get a list of all alarm *types*, but there's no information that says, for example, that a link-loss alarm can't be raised for a local CPU resource (or indeed, that the local CPU resource even exists). This is exacerbated by the ability of operators can delete alarm entries; even if a device initially populates the alarm list with all possible alarms, the operator can still delete some of them, in which case the list no longer reflects all possible alarms.
We have an internally developed (but not yet published) YANG model for alarms which is very similar to this draft model, but with the following key differences: * It does not track past status changes (they are stored in a separate event log); it is only concerned with current state. * Alarms are associated with entities (from ietf-entity.yang) rather than arbitrary strings or instance-identifiers. * It contains a list of all-alarms, regardless of whether they have ever been raised. This includes static information (description, severity) as well as current state information. * It contains a separate list of raised-alarms, which mostly duplicates the information from all-alarms, but only contains an entry for an alarm if it is raised. This allows a subtree filter to retrieve only information about raised alarms, but it may be redundant. * Instead of shelved alarms, we have a simple boolean "disabled" setting for each alarm; raised disabled alarms still appear as raised in the all-alarms list (with another indication they're disabled), but do not appear in the raised-alarms list. With this model (and because ietf-entity.yang defines a hierarchy of entities) it is easy to display a hierarchical view of all entities and their associated alarms. In our model, entries in the all-alarms list can only be added when resources are added to the system, and can only be deleted when resources are removed from the system. Other comments: * is-cleared feels like a double negation (false means "this alarm is not not raised"); I would like to see it changed to is-raised * I would like to see a YANG feature for past status changes, or perhaps this part moved to a separate module augmenting ietf-alarms. * has-clear doesn't need to be a union of only one type * The meanings of "impacted resource" and "root cause resource" are unclear. * "This list is used to shelf alarms" should be "... to shelve alarms" * "Shelv alarms for ..." should be "Shelve alarms for ..." (multiple occurrences) Alex ________________________________________ From: netmod <[email protected]> on behalf of Martin Bjorklund <[email protected]> Sent: Thursday, 6 October 2016 1:26 a.m. To: [email protected] Subject: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt Hi, We have posted a new version of the alarm module. The previous document was called draft-vallin-alarm-yang-module-00, this new version is called draft-vallin-netmod-alarm-module (hence it is also a -00). This updated version incorporates comments on the previous docuement, and adds support for alarm shelving. It would be good to know if people in this WG are interested in this work. /martin and stefan A new version of I-D, draft-vallin-netmod-alarm-module-00.txt has been successfully submitted by Martin Bjorklund and posted to the IETF repository. Name: draft-vallin-netmod-alarm-module Revision: 00 Title: YANG Alarm Module Document date: 2016-10-05 Group: Individual Submission Pages: 58 URL: https://www.ietf.org/internet-drafts/draft-vallin-netmod-alarm-module-00.txt Status: https://datatracker.ietf.org/doc/draft-vallin-netmod-alarm-module/ Htmlized: https://tools.ietf.org/html/draft-vallin-netmod-alarm-module-00 Abstract: This document defines a YANG module for alarm management. It includes functions for alarm list management, alarm shelving and notifications to inform management systems. There are also RPCs to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
