Re: [CCAMP] draft-ietf-ccamp-alarm-module-04/Clause F.2.2.4. Alarm Reporting Control

Hi Marta!
Thanks for your comment.
You should have a look at alarm shelving.
Your examples are good examples when you configure an alarm shelf
* pre-provision a cardholder slot and you don’t want to see hardware missing alarms
* limit unwanted alarms from showing up during the test activities

Create an alarm shelf for those resources. The good thing about shelfs is that not only do they block notifications, but you also get a dedicated shelf where you can read those alarms.

I will clarify in next revision
br Stefan

> On 2 Nov 2018, at 01:26, Marta Seda <Marta.Seda@calix.com> wrote:
> 
> Hello Stefan
>  
> I have a question about your description of Alarm Control Reporting functions.  Clause F.2.2.4 states:
>    The requirements in G.7710 corresponds to features in the alarm YANG
> 
>    module in the following way:
> 
>  
> 
>       Alarm Severity Assignment Profile (ASAP): the alarm profile
> 
>       "/alarms/alarm-profile/".
> 
>  
> 
>       Alarm Reporting Control (ARC): alarm shelving "/alarms/control/
> 
>       alarm-shelving/" and the ability to control alarm notifications
> 
>       "/alarms/control/notify-status-changes".
> 
>  
> /alarms/control/notify-status-changes choice controls if notifications are sent for all state changes, only raise and clear, or only notifications more severe than a configured level.
>  
> Alarm Reporting Control (ARC) is described in ITU M.3100 in detail.  It is a common feature that standards have adopted.  It is useful for example for the purpose of managing automatic in-service actions (e.g., you pre-provision a cardholder slot and you don’t want to see hardware missing alarms).  Enabling ARC allows the managed entity not to report alarms until the cardholder slot is populated.  ARC is also used for handling maintenance/test activities (so as to limit unwanted alarms from showing up during the test activities).
>  
> ARC appears in standards like ITU-T G.988 (which defines a limited form of ARC) and RFC 3878 ARC MIB.   The description given in this clause of your document describes ITU-T M.3100 Figure 5-3 NALM state (if the notify-status-changes is set to raise and clear (I think that is the intent from the descriptions I’ve found; not 100% sure).
>  
> G.7710 supports other ARC functions (e.g., the ability for a managed entity to automatically transitioning out of the NALM state without management action).
>  
> Can you explain how ARC is achieved via the /alarms/control/notify-status-changes values?  I could see that someone may argue toggling between “only raise and clear”  to “all state changes” achieves a limited form of M.3100 Figure 5-3 NALM to ALM transitional behaviour.  The problem with that is that that behaviour does not meet M.3100 Figure F.2 which expects alarms to clear while an entity is in the NALM state and alarms not to be raised while in the NALM state.  I’m not sure based on the descriptions in the document that ARC is being supported (other ARC states (e.g., timed states) are not in the document). 
>  
> Regards,
>  
> Marta Seda 
>  
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org <mailto:CCAMP@ietf.org>
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>