Re: [CCAMP] review of draft-ietf-ccamp-alarm-module-01

[stefan vallin <[e-mail]>]

Hi Deborah!

> 
>> On 10 Aug 2018, at 21:17, BRUNGARD, DEBORAH A <[e-mail]> wrote:
>> 
>> Stefan, Authors,
>> 
>> I've been reviewing the SG15 liaison and your draft, as we'll need to respond in about a month to SG15. Similar to Tom, SG15 is confused on terms of reference/prior standards relationship. While the abstract says "carefully maps to relevant alarm standards", there's no direct references. In the document, it also has a sentence "based on experience from using and implementing available alarm standards". So it is not clear if this work is based on standards or "experience implementing”.
> Both :)
> Have you read Appendix F?
> [deborah]
> Sure - and version -02.
> 
> I noted you tweaked the intro a bit in -02, but the abstract remains the same, saying "The module carefully maps to relevant alarm standards." Unless you plan to clearly/carefully show the mapping by reference in the module, this sentence needs to be removed and you need to add a sentence similar to intf-ext-yang. Your choice.

Ok, I can add a section with details on how the draft maps to standards in detail. Will add that as a new subsection App F.
I will address primarily 3GPP, X.733, RFC3877, EEMUA, and ISA

> 
> On Appendix F, I don't see anything in Appendix F which identifies any standard. There is no mention of any standards except to say in F.2 "adopted to networking based on the ISA and EEMUA" which again indicates it is your interpretation. The table is on problems, nothing to do with the YANG model itself.
See above, will make a complete mapping table.

> 
> On F.1, there's also no reference to a standard for your definition of alarm/alarm state. I'm not sure the context of the quote from ISA, but your interpretation of it to say the definition of an "alarm requires action" to equal "an alarm is a state of a resource" and not the "notification" itself, doesn’t match my interpretation of the ISA quote or ITU definition or RFC3877. SG15 noted this confusion in your document in their liaison, the need for "clear separation of resource alarm life-cycle from the operator and administrative life-cycle of an alarm”.
See my response to Tom Petch. Going back in time, telco standards where focusing on alarms as a special case of event notifications, focus on the notifications.
This definition might be part of the problem why the telco alarm lists are overloaded of noise. When I deep-dived in alarm standards several years ago I found the definitions in the process industry much more meaningful, focusing on the state/condition and not the notifications, also a critical requirement that an alarm shall require action, if not, it is an event (debug info).

Note well in my response to Toms email how 3GPP has followed the same path and is now using literally the same definition as in the ietf alarm draft.


> 
> G.7710 (and X.733) may help:
> " Alarms are indications that are automatically generated by an NE as a result of the declaration of a failure. The NE shall have the ability to accept OS directions related to the events and conditions that generate autonomous reports and those that shall be reported on request."
> 
> Or RFC3877:
> Fault - condition
> Alarm - indication of a fault
> Alarm State - State of Alarm e.g. raise/clear and also severity information.
> 
> I understand your concern on some vendors reporting every event as if it needs action, but that's implementations and not per standards. There's no need to redefine standards' definition of alarm/alarm state to sort out implementation errors. Delete F.1 second paragraph. I don't see it impacting this section or anything in the document.

See above:
1) We are using the same definition as 3GPP which follows ISA/EEMUA standards
2) There is sometimes a need to change definitions from standards, we need to improve and progress. Science works that way.

And repeating myself, I will make a clearer summary on how we follow the standards, but also how we improve.
Update in App F
> 
>> 
>> During the microwave yang review, a similar concern was raised, and it was decided to clearly identify which standard is being referenced. Recommend the same should be done here. It's ok you have included "vendor implementations of alarm standards". But you need to clearly identify.
> Appendix F and references
>> 
>> There's a sentence in the abstract of draft-ietf-netmod-intf-ext-yang which may help here:
>> "These properties are common to many types of interfaces on network routers and switches and are implemented by multiple network equipment vendors with similar semantics, even though some of the features are not formally defined in any published standard."
>> And:
>> " Several of the augmentations defined here are not backed by any formal standard specification.  Instead, they are for features that are commonly implemented in equivalent ways by multiple independent network equipment vendors.  The aim of this draft is to define common paths and leaves for the configuration of these equivalent features in a uniform way, making it easier for users of the YANG model to access these features in a vendor independent way.  Where necessary, a description of the expected behavior is also provided with the aim of ensuring vendors implementations are consistent with the specified behaviour."
>> 
>> Similar to the intf-ext, it will be important to allow implementors the flexibility to choose which specific parts of the model they support, and to allow in the future supporting other standards (G.7710). It would help to include a few sentences in the draft on how this can be done.
> Please read previous emails in this group with regards to G.7710, I have commented this earlier
>> 
>> Once we have a cleaner document,
> ?
>> I'm recommending to liaison with the SDOs which you reference, ITU-T, 3GPP (and BBF in response to their earlier liaison). Hopefully with these clarifications, it will be an easier read by these other groups.
> Can you be more specific?
> If you are expecting this draft to be a syntactical mapping ot X.733 GDMO/ASN.1 or the 3GPP Alarm IRP?
> We need to improve, need to make progress and learn from experience.
> [deborah] 
> If don't want to add references, remove that sentence and add a sentence on what is in this document. I don't think saying it has "improved on standards based on experience" is appropriate, otherwise the question will be asked "why not use more recent standards vs. 25 year-old standards?". Suggest sentences similar to intf-ext will be sufficient to scope as "commonly implemented".
> 
>> 
>> Thanks Tom and Qin for reviewing -
>> 
>> Thanks Authors for continuing the dialogue- as with any solution document, the solution stabilizes, then need to clean up the description text😊  
> Clean up? Can you be more specific?
> [deborah] See above.
> 
> Br Stefan
> 
>> 
>> Deborah
>> (AD hat on)
>> 
>> -----Original Message-----
>> From: CCAMP <[e-mail]> On Behalf Of tom petch
>> Sent: Friday, August 10, 2018 7:53 AM
>> To: stefan vallin <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [CCAMP] review of draft-ietf-ccamp-alarm-module-01
>> 
>> Stefan
>> 
>> I find this I-D (too) hard to understand.  The problem I have is with terminology which seems elastic.
>> 
>> Thus 'alarm state' is not defined as a term; it is in other alarm work where the definition would fit with usage such as
>> 
>>  The operator state for an alarm can be: "none", "ack", "shelved", and
>>  "closed".
>> or
>> actual state of the alarms
>> or
>> The alarm list (/alarms/alarm-list) is a function from (resource,
>>  alarm type, alarm type qualifier) to the current alarm state.
>> 
>> But this meaning makes no sense to me when the term appears in o  Alarm Instance: The alarm state for a specific resource and alarm type.
>> or
>> o  Alarm Type: An alarm type identifies a possible unique alarm state for a resource.
>> 
>> and since I cannot understand what you mean by these two terms, I think I cannot understand the document.
>> 
>> Another example would be the use of 'event' which appears as
>> 
>> 1.  the definition focuses on leaving out events and logging information in general.
>> 
>> This I-D does not define event; previous IETF work, e.g. RFC3877 does, and makes it clear that an alarm (class) is a subset of an event which would make no sense here.
>> 
>> There is a lot of prior art in this field but this I-D seems to go against it rather than build on it.
>> 
>> Tom Petch
>> 
>> ----- Original Message -----
>> From: "stefan vallin" <[e-mail]>
>> To: "Qin Wu" <[e-mail]>
>> Cc: <[e-mail]>
>> Sent: Sunday, July 22, 2018 7:17 PM
>> 
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ccamp&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=Y7lL8No91BQpMMGov6O09yRy9kNBr_oUgXbkmXjLjqk&s=CtnVif0mRNx46GxoPzbqh7OUVBXlusn7itCGGygX-q4&e=
>