Hi! Thanks for your comments! Several of your comments seems to be that you might not have understood the difference between “alarm-list” and “alarm-inventory” Please read those a bit before seeing my comments See comments inline
> On 06 Oct 2016, at 00:22, Alex Campbell <alex.campb...@aviatnet.com> wrote: > > 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. I do not really get your comment here. All possible alarms are published via the alarm inventory. Nothing can be delete in the inventory. A manager reads this table to understand the possible alarms. I do not understand when you say "initially populates the alarm list with all possible alarms”. 1) the read-only “alarm-inventory” publishes all possible alarms, including a description of the possible alarm 2) the “alarm-list” shows actual alarms, which are all of an alarm-type listed in the alarm inventory > > > 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. I think there is a huge value in this module design that as a client you see the alarm history per alarm not in a separate log. As a user you select the interface of a device and you see the current alarm state as well as the history. This is important for trouble-shooting > * Alarms are associated with entities (from ietf-entity.yang) rather than > arbitrary strings or instance-identifiers. But other things than entities can have alarms. AND instance-identifers are not “free-form”. It is a strange limitation to limit alarms to the entity-model > * 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. See above, this is the alarm inventory > * 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. See above this is the alarm list > * 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. Can be done with shelfing > > 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. Alarm-inventory shall reflect the possible alarms, I will add your use case to the description. > > > > 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 think again your are confusing alarm-inventory and alarm-list. When the alarm appears for the first time it is not cleared by the resource > * I would like to see a YANG feature for past status changes, or perhaps this > part moved to a separate module augmenting ietf-alarms. It is the “status-change” list, it shows all status changes > * has-clear doesn't need to be a union of only one type ? > * The meanings of "impacted resource" and "root cause resource" are unclear. OK, I can work on improved descriptions. They idea is the following. As an operator you would like to have *one* alarm although there are several symptoms, rather than having 15 alarms per symptom. This module gives you the freedom of selecting should the faulty resource be the alarming object or the impacted resource. Both options are available. If you raise an alarm on an interface you might say that a VPN is “impacted” If you raise an alarm on a VPN due to some probing you can hint the operator on the corresponding interface who might have a bad config > * "This list is used to shelf alarms" should be "... to shelve alarms" > * "Shelv alarms for ..." should be "Shelve alarms for ..." (multiple > occurrences) Thanks, will fix br Stefan > > Alex > > ________________________________________ > From: netmod <netmod-boun...@ietf.org> on behalf of Martin Bjorklund > <m...@tail-f.com> > Sent: Thursday, 6 October 2016 1:26 a.m. > To: netmod@ietf.org > 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
