Re: [CCAMP] draft-ietf-ccamp-alarm-module-01, Missing Alarm Attributes

[stefan vallin <[e-mail]>]

Hi Marta!
Thanks for your review!
Summary answers/comments follows:

1) Your excel-sheet line 5 alarm-type-qualifier says "Alarm instance refined defined by CCAMP” in column F.
That is not correct, type qualifier refines alarm types when alarm types are not known at design time. See examples in draft

2) GR-833 <srvef>, tried to find the source but the PDF needs to be ordered at a cost of  $795 USD :)
Your description says:
- SA Service-effecting condition, immediate action required.
- NSA Nonservice-effecting condition, action required.

I can not see this adding any information to the alarm that is not carried by the severity levels defined by ITU.
Read the description clauses for severity and you will see that minor and warning is not service-affecting and higher levels are.

NSA = minor, warning
SA, major, critical

3) X733 threshold information and monitored attributes.
Have seen very little practical use of these, but in order to have a complete X733 mapping we can certainly add these attributed to ietf-alarms-x733.yang

4) Repair action.
Our experience is that repair actions are prepared in separate alarm procedure documents and seldom carried within the alarm information.
The alarm inventory functionality of the ietf-alarms module is the “index” of the alarm procedures residing in a wiki/doc library for example.
On the other hand we are stressing the fact that if an alarm does not require an operator to do something it does not qualify as an alarm.
Providing the repair action parameter in the x733 module could help foster that. Will add to ietf-alarms-x733.yang.

5) MEF 35.1 TCA type, threshold crossing alert type.
I do not think this should go into a core alarm module. Can be augmented. 

6) X.736 security attributes
Have you seen any real usage of these attributes?
Can be added to the ietf-alarms-x733 module (maybe rename to ietf-alarms-x733x736)

7) X.733 Additional information
Have you seen any real usage of this? The original data structure is fairly generic in its structure.
I have seen some systems escaping to just use text here, but why add an extra attribute for text?
I am reluctant on this one, especially to find a good data definition for it. Unclear of real usage.

---
In general I am a bit skeptic on all the various ITU alarm attributes. My experience is that in real life very few of them carry relevant information.
More adds to complexity than it helps with managing alarms
I vote for focusing on alarm information quality using a few relevant attributes, see appendix F

But for completeness I will add the “missing" x733 attributed to the x733 mapping module since we have started on that one.

Br Stefan


> On 28 Jun 2018, at 02:01, Marta Seda <[e-mail]> wrote:
> 
> Hi Stefan,
> Thank you for the updated draft v-(01) CCAMP Alarm Module.  This draft is missing alarm attributes.  I have attached an excel spreadsheet to illustrate the question.  The attachment contains two tables:
> Alarm-fields for alarm inventory
> Alarm-fields for alarm instances
>  
> Both tables compare the list of supported CCAMP alarm attributes for different “specialized” alarm types (e.g., sensor alarms, E.720-like grade of service alarms (alarms risen under certain traffic conditions), security alarms and MEF 35.1 Stateful Events Alarms).
>  
> For each attribute, traceability to which standards discusses these attributes is included in the attachment. 
>  
> If one examines the differences, the following alarm attributes are not included in the CCAMP alarm module:
> Service-effect (GR-833 defines alarm attribute – only included this in case vendors need to support this alarm attribute for legacy reasons)
> Threshold information (x.733, 3GPP TS 32.111-2 , M.3100)
> Monitored attributes (x.733, 3GPP TS 32.111-2 , M.3100)
> Proposed repair actions (x.733, 3GPP TS 32.111-2 , M.3100)
> Tca-type (MEF35.1 specific attribute)
> Security alarm detector (x.736, 3GPP TS 32.111-2)
> Security alarm cause (x.736, 3GPP TS 32.111-2)
> Service user (x.736, 3GPP TS 32.111-2)
> Service provider (x.736, 3GPP TS 32.111-2)
> Additional information (3GPP TS 32.111-2, X.736, X.733)
>  
> For the X.733 traceable alarm attributes, these attributes are considered “optional” in nature.  On the other hand, X.736 considers the security attributes (starting with “security-x”) as mandatory.
>  
> Discussion:
> a) Is there any particular reason for the omission of these attributes?   
> b) Are there any plans to support any of these attributes in the CCAMP Alarm module in the future?  Or do you view these attributes as outside of the IETF CCAMP scope (and therefore if someone needs these particular attributes they can augment the IETF CCAMP YANG?  I am attempting to understand the boundaries of what CCAMP intends to cover.
>  
> Best Regards,
>  
> Marta Seda
>  
> <alarm-attributes-per-alarm-type.xlsx>_______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp