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

[stefan vallin <[e-mail]>]

Hi Nick!
The x733 module is augmenting the core ietf-alarms.yang.
All leafs are optional, and config false.
I do not think it is necessary to if-feature them (?)
Br Stefan


> On 4 Jul 2018, at 09:58, NICK HANCOCK <[e-mail]> wrote:
> 
> Hi Stefan,
>  
> Although I see that these new leafs are optional, I am wondering whether they should nevertheless be best if-featured. For example, if an implementation does not support ‘monitored-attributes’, but just the basic attributes ‘event-type’, ‘probable-cause’ and ‘probable-cause-string’ using  if-features on ‘threshold-information’, ‘monitored-attributes’ etc. would make this absolutely clear to the client. What do you think?
>  
> Best regards
> Nick
>  
> From: CCAMP [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of stefan vallin
> Sent: Tuesday, July 03, 2018 2:18 PM
> To: Marta Seda
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: Re: [CCAMP] draft-ietf-ccamp-alarm-module-01, Missing Alarm Attributes
>  
> Hi Marta!
> Adding to ietf-alarms-x733 from the ITU specs.
> Could look something like this:
> 
> augment /al:alarms/al:alarm-list/al:alarm:
> +--ro event-type? event-type
> +--ro probable-cause? uint32
> +--ro probable-cause-string? string
> +--ro threshold-information
> | +--ro triggered-threshold? string
> | +--ro (threshold-level)?
> | | +--:(up)
> | | | +--ro up-high? observed-value
> | | | +--ro up-low? observed-value
> | | +--:(down)
> | | +--ro down-high? observed-value
> | | +--ro down-low? observed-value
> | +--ro arm-time? yang:date-and-time
> +--ro monitored-attributes* []
> | +--ro id? al:resource
> | +--ro value? string
> +--ro proposed-repair-actions* string
> +--ro trend-indication? trend
> +--ro backedup-status? boolean
> +--ro backup-object? al:resource
> 
> Question to you, additional-information, that super generic thing. Do you think it is useful?
> How should the definition look like…
> AdditionalInformation ::= SET OF ManagementExtension
> ManagementExtension ::= SEQUENCE
> {
> identifier DMI-EXTENSION.&id({ManagementExtensionSet}),
> significance [1] BOOLEAN DEFAULT FALSE,
> information [2] DMI-EXTENSION.&Value({ManagementExtensionSet}{@.identifier})
> }
> 
> We could have a list with leafs identifier string, significance boolean and information string ?
> Would it add any value?
> 
> Do you still think the security attributes are useful?
> Br Stefan
> 
> 
> > On 28 Jun 2018, at 02:01, Marta Seda <[e-mail] <mailto:[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] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>