Hi Again! Alex, can you elaborate a bit more on your requirements for alarm-history? What are you missing in this module? I want to make sure I understand your comment properly.
Stefan Vallin ste...@wallan.se +46705233262 > On 07 Oct 2016, at 09:42, Martin Bjorklund <m...@tail-f.com> wrote: > > Hi, > > stefan vallin <ste...@wallan.se> wrote: >>> On 06 Oct 2016, at 00:22, Alex Campbell <alex.campb...@aviatnet.com> >>> wrote: >>> >>> * 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 > > I think both are valid designs; either there is a flag in the > alarm-list that marks an alarm as being shelved, or the shelved alarm > is (conceptually) moved to a separate list. The design we chose is > the latter, which has the benefit of not cluttering down the real > alarm list with disabled stuff. > >>> 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 understand Alex's concern, but since the normal state is that the > alarm is not cleared, it makes sense that the node is 'is-cleared'. > >>> * 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 > > I think Alex's point is that support for status-changes could be > made optional, by introducing a YANG feature. > >>> * has-clear doesn't need to be a union of only one type >> ? > > For some reason we have today: > > leaf has-clear { > type union { > type boolean; > } > > (the reason for this is that originally this was a union of boolean > and the enumeration 'unknown'). > > > > /martin
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod