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?
> 
> 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.

> 
> 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?

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=