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

From: stefan vallin <[email-masked]>
Date: Wed, 8 Aug 2018 19:36:01 +0200

Hi!
Sorry for slow response!
Thanks again for your comments.
The larger scope the more complexity. 
I think it is important to prove the model in the scope of a NE/device first. Then extend with requirements for the controller/mid-level manager in a later revision or a separate augmenting module.
I am also convinced that the current model works as a base for the controller based on implementation experience. We had some more leafs in the controller than in the device.

So in summary, I would like to progress this to an RFC targeting the NE scope in a first step before adding more features targeting the controller.
Br Stefan

> On 23 Jul 2018, at 11:39, Qin Wu <[email-masked]> wrote:
> 
> Are you saying the controller model should be different from device model or the model in the southbound interface of the controller should be different from the model used in northbound interface of the network device?
> Or the model used in northbound interface of the controller should be different from one used in the northbound interface of the network device?
> Why not have one generic model which can be applied to both southbound and northbound interfaces?
>  
> -Qin
> 发件人: stefan vallin [mailto:[email-masked] <mailto:[email-masked]>] 
> 发送时间: 2018年7月23日 2:37
> 收件人: Qin Wu; [email-masked] <mailto:[email-masked]>
> 主题: Re: Second review of draft-ietf-ccamp-alarm-module-01
>  
> Hi again!
> Addition to #8
> You could augment with a device leaf in your mgmt app.
>  
> The module scope is within one device primarily
>  
> Br stefan
> 
> Mvh stefan
> +46(0)705233262
> 
> 22 juli 2018 kl. 20:17 skrev stefan vallin <[email-masked] <mailto:[email-masked]>>:
> 
> Hi Qin!
> Thanks for your review and comments, see inline below:
> 
> 
> On 21 Jul 2018, at 14:16, Qin Wu <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi, Stefan:
> Before the next version of alarm model comes up, I would like to have the following suggestions and comments:
> 1.       UUID support for the type of resource under alarm list
> Last time you said:
> “
> Good point, will consider adding it in the next revision.
> However, there is a danger here in that developers might escape throwing UUIDs to operators. As an operator in a NOC it is hard to know what to do with a UUID.
> In many cases UUID are a sign of using the alarms as a log/debug thing for developers.
>  
> typedef resource {
>         type union {
>           type instance-identifier {
>             require-instance false;
>           }
>           type yang:object-identifier;
>           type string;
>         }
> “
> However in our implementation case, we did allow operator in a NOC to use UUID to correlate resource objects in the alarm-inventory, don’t we?
> We have added UUID to the upcoming version:
>   typedef resource {
>     type union {
>       type instance-identifier {
>         require-instance false;
>       }
>       type yang:object-identifier;
>       type yang:uuid;
>       type string;
>     }
>  
> Resource-match is also updated to handle UUIDs.
>  
>  
>  
> 
> 
>  
> 2.       Dependency between root-cause-resource, impacted-resource, related-alarm
> Under alarm list, there are three dependent parameters: root-cause-resource, impacted-resource, related-alarm
> It is still not clear to me how root-cause-resource, impacted-resource are used together with resource parameter under related-alarm, why root-cause-resource and impact-resource not part of related-alarm.
> If the answer is no, for root-cause-resource leaf-list, I am wondering why not add is-root-cause parameter to indicate a specific alarm under alarm list is root cause alarm. Only when is-root-cause is set to true, then root-cause-resource will be provided. Does this make sense?
> In our practice, we usually design one root cause alarm and several derived alarms, the derived alarm will use leafref to point to root cause alarm, I am wondering whether we assume each alarm under alarm list is root cause alarm and Related-alarm are derived alarms. If the answer is no, I think we should one new parameter under related-alarm list to reference to the root cause alarm.
> We have updated the test in the RFC document on this topic:
> 3.6.  Root Cause, Impacted Resources and Related Alarms
>  
>    The general principle of this alarm module is to limit the amount of
>    alarms.  The alarm has two leaf-lists to identify possible impacted
>    resources and possible root-cause resources.  The system should not
>    represent individual alarms for the possible root-cause resources and
>    impacted resources.  These serves as hints only.  It is up to the
>    client application to use this information to present the overall
>    status.
>  
>    A system should always strive to identify the resource that can be
>    acted upon as the "resource" leaf.  The "impacted-resource" leaf-list
>    shall be used to identify any side-effects of the alarm.  The
>    impacted resources can not be acted upon to fix the problem.  An
>    example of this kind of alarm might be a disc full problem which
>    impacts a number of databases.
>  
>    In some occasions the system might not be capable of detecting the
>    root cause, the resource that can be acted upon.  The instrumentation
>    in this case only monitors the side-effect and needs to represent an
>    alarm that indicates a situation that needs acting upon.  The
>    instrumentation still might identify possible candidates for the
>    root-cause resource.  In this case the "root-cause-resource" leaf-
>    list can be used to indicate the candidate root-cause resources.  An
>    example of this kind of alarm might be an active test tool that
>    detects an SLA violation on a VPN connection and identifies the
>    devices along the chain as candidate root causes.
>  
>    The alarm module also supports a way to associate different alarms to
>    each other with the "related-alarm" list.  This list enables the
>    server to inform the client that certain alarms are related to other
>    alarms.
>  
>    Note well that this module does not prescribe any dependencies or
>    preference between the above alarm correlation mechanisms.  Different
>    systems have different capabilities and the above described
>    mechanisms are available to support the instrumentation features.
> 
> 
>  
> 3.       Consolidate tuple corresponding to a single alarm instance into pair
> This YANG alarm module uses the tuple (resource, alarm type identifier, alarm type qualifier)to identify a single alarm instance. I am wondering whether the tuple can be reduced into (resource, alarm-type identifier), allow alarm-type identifier support a union of identity and string. The reason for that is inherit base identity for alarm-type-identifier to get a bunch of derived identity is not sufficient when alarm-type can be fine granularity classified into hundreds type.
>  
> No that will not work, read the text in the RFC document, alarm type identifier Is static design-time, qualifier is runtime and a refinement of the alarm-type identifier.
> See updated text in the upcoming version of the RFC:
> 3.2.  Alarm Type
>  
>    This document defines an alarm type with an alarm type id and an
>    alarm type qualifier.
>  
>    The alarm type id is modeled as a YANG identity.  With YANG
>    identities, new alarm types can be defined in a distributed fashion.
>    YANG identities are hierarchical, which means that an hierarchy of
>    alarm types can be defined.
>  
>    Standards and vendors should define their own alarm type identities
>    based on this definition.
>    The use of YANG identities means that all possible alarms are
>    identified at design time.  This explicit declaration of alarm types
>    makes it easier to allow for alarm qualification reviews and
>    preparation of alarm actions and documentation.
>  
>    There are occasions where the alarm types are not known at design
>    time.  For example, a system with digital inputs that allows users to
>    connects detectors (e.g., smoke detector) to the inputs.  In this
>    case it is a configuration action that says that certain connectors
>    are fire alarms for example.  A potential drawback of this is that
>    there is a big risk that alarm operators will receive alarm types as
>    a surprise, they do not know how to resolve the problem since a
>    defined alarm procedure does not necessarily exist.  To avoid this
>    risk the system MUST publish all possible alarm types in the alarm
>    inventory, see Section 4.2.
>  
>    In order to allow for dynamic addition of alarm types the alarm
>    module also allows for further qualification of the identity based
>    alarm type using a string.
>  
>    A vendor or standard can then define their own alarm-type hierarchy.
>    The example below shows a hierarchy based on X.733 event types:
>  
>      import ietf-alarms {
>        prefix al;
>      }
>      identity vendor-alarms {
>        base al:alarm-type;
>      }
>      identity communications-alarm {
>        base vendor-alarms;
>      }
>      identity link-alarm {
>        base communications-alarm;
>      }
>  
>    Alarm types can be abstract.  An abstract alarm type is used as a
>    base for defining hierarchical alarm types.  Concrete alarm types are
>    used for alarm states and appear in the alarm inventory.  There are
>    two kinds of concrete alarm types:
>  
>    1.  The last subordinate identity in the "alarm-type-id" hierarchy is
>        concrete, for example: "alarm-identity.environmental-
>        alarm.smoke".  In this example "alarm-identity" and
>        "environmental-alarm" are abstract YANG identities, whereas
>        "smoke" is a concrete YANG identity.
>  
>  
>  
>  
>  
> Vallin & Bjorklund      Expires January 11, 2019                [Page 6]
> Internet-Draft              YANG Alarm Module                  July 2018
>  
>  
>    2.  The YANG identity hierarchy is abstract and the concrete alarm
>        type is defined by the dynamic alarm qualifier string, for
>        example: "alarm-identity.environmental-alarm.external-detector"
>        with alarm-type-qualifier "smoke".
>  
>    For example:
>  
>      // Alternative 1: concrete alarm type identity
>      import ietf-alarms {
>        prefix al;
>      }
>      identity environmental-alarm {
>        base al:alarm-type;
>        description "Abstract alarm type";
>      }
>      identity smoke {
>        base environmental-alarm;
>        description "Concrete alarm type";
>      }
>  
>      // Alternative 2: concrete alarm type qualifier
>      import ietf-alarms {
>        prefix al;
>      }
>      identity environmental-alarm {
>        base al:alarm-type;
>        description "Abstract alarm type";
>      }
>      identity external-detector {
>        base environmental-alarm;
>        description
>          "Abstract alarm type, a run-time configuration
>           procedure sets the type of alarm detected. This will
>           be reported in the alarm-type-qualifier.";
>      }
>  
>    A server SHOULD strive to minimize the number of dynamically defined
>    alarm types.
>  
> 
> 
>  
> 4.       Semantics difference between description under alarm-inventory and alarm-text nder alarm list
> See description definition and alarm-text definition as follows:
> “
> description：A description of the possible alarm.  It SHOULD include information on possible underlying root causes and corrective actions.
> alarm-text：The string used to inform operators about the alarm. This MUST contain enough information for an operator to be able to understand the problem and how to resolve it.  If this string contains structure, this format should be clearly documented for programs to be able to parse that information.
>    “
>    I am not sure any semantics difference between description and alarm-text, why not replace one with another? Or we can further broke down description/alarm-text into root-cause and corrective-actions. I believe they are key information we want to convey through description/alarm-text.
> Alarm description is dynamic/run-time, conveys relevant information for the specific alarm state change.
> Description in the inventory is static, cannot convey dynamic state change information
> 
> 
>  
> 5.       Alarm arrive time support
> Under operator-state-change, we have time parameter to represent Timestamp for operator action on alarm, I am wondering do we need to add alarm-arrive-time to represent the time when alarm arrive at the management system.
> It is useful information for the alarm management.
> The alarm has a leaf representing the real time the state change appeared:
>     +--ro alarm* [resource alarm-type-id alarm-type-qualifier]
>           ...
>        +--ro last-changed               yang:date-and-time
>        +--ro status-change* [time]
>           +--ro time                    yang:date-and-time
> This should represent the time it really happened. Not the time the notification arrived at the management system. If you need that, that is something you can add in your mgmt system.
>  
>  
> 6.       Alarm-name field support for alarm and alarm inventory
> In the current model, each alarm under alarm list is uniquely identified by three leaf key (resource, alarm type identifier, alarm type qualifier),would it more desirable to define a single leaf key, e.g., add alarm name or alarm-no to uniquely identify each alarm? That will simplify the alarm management from the management system perspective. Make sense?
> A string no…
> This is a fundamental design principle in the alarm module. The key, the tuple, carries semantic information, there is no doubt how to match notifications to the alarm state.
> 3GPP Alarm IRP, for example, introduced a confusing single key alarmId key which created paradoxes, 
> if you have different alarmIds but for the the same alarmtype and resource, what does it mean?
> 
> 
>  
> 7.       Reason-id support for alarm list and alarm inventory
> In the current model, is root cause resource is the reason to generate each alarm? If not, I propose to add reason-id for each alarm under alarm list and alarm inventory.
> See answer to #2
>  
> 8.       Alarm generating device or location support for alarm list and alarm inventory
> In the current model, it seems the resource type can potentially indicate the device or location where the alarm is generated, but not explicitly. I am wondering why not add alarm-generating-device and alarm-generating-location two parameters to explicitly indicate the device or location where the alarm is generated, that will simplify alarm management, make sense? 
>  
> I guess you are considering a management application and not the device? 
> The resource is a leafier which could/should include the device in your model in your management application.
> 
> 
> 9.       Alarm notification category support
> In the current model, alarm notification is defined as follows:
> “
> This notification is used to report a state change for an alarm. The same notification is used for reporting a newly raised alarm, a cleared alarm or changing the text and/or
> severity of an existing alarm.
>  
> ”
> However it is not clear how to distinguish alarm notification for newly reaised alarm from alarm notification for a cleared alarm. Would it be more sensible to add alarm notification category support something as follows:
> “
> leaf category {
>          type enumeration {
>            enum fault {
>              description
>                "Alarm raised.";
>            }
>            enum recovery {
>              description
>                "Alarm cleared.";
>            }
>            enum Change {
>              description
>                "Alarm changed.";
>            }
>          }
> ”
> Not needed, this is obvious when you map the notification towards the key tuple.
> 
> 
> 10.   Consistency between alarm list construct and alarm notification construct
> We see the difference between alarm list construct and alarm notification construct is operator action defined under alarm notification construct and operator state change under alarm list construct.
> As specified in RFC7950,
> “
> An action MUST NOT be defined within an rpc, another action, or a
>    notification
> ”
> I am not sure action can be allowed within alarm-notification construct, in that case, I would propose to remove operator action from alarm notification construct.
> In addition, the operator parameter under operator-state-change can be removed or consolidated into set-operator-state action.
> I do not understand
> The action is not defined in the notification.
> 
> 
>  
> 11.   Additionalinfo support for alarm list
> I think we should allow vendor specific extension to be added as part of alarm list, the vendor specific extension can be defined in TLV format.
> The alarm module does not restrict any vendor additions, better to use augmentation.
> 
> 
>  
> 12.   Alarm-no support for set-operator-state
> If we believe set-operator-state is useful action under alarm list. I am wondering if we can add alarm-no or alarm-name to identify each alarm under set-operator-state. This will help a lot for alarm ack operation based on each alarm number.
> See above
> 
>  
> 13.   Is-acked for alarm list
> Since we have is-cleared parameter under alarm list to indicate the current clearance state of the alarm, why not add is-acked parameter under alarm list to indicate the current acked state of the alarm, make sense?
> You can get that from the operator-state-change list.
> 
>  
>  
> Br Stefan

---

From: Qin Wu <[email-masked]>
Date: Thu, 9 Aug 2018 02:54:24 +0000

Thank for your update in v-(02)
https://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-alarm-module-02
Why not have a generic model applicable to both controller and the device, I see this model as alarm monitoring framework. Also this draft said in the introduction:
“
   The purpose is to define a standardised alarm interface for network
   devices that can be easily integrated into management applications.
   The model is also applicable as a northbound alarm interface in the
   management applications.

”
In addition, I believe you haven’t touched my followup comments posted at:
https://www.ietf.org/mail-archive/web/ccamp/current/msg18904.html
which are not controller support specific comment, appreciate your response to those comments.
4 issues highlighted below:

1.       Alarm-type-id supports union of identity and string

I know defining alarm-type-id as identity make alarm-type-id is more extensible, but waste more space than using enum.

I am wondering why not define alarm-type-id as uint32 or string with embedded format such as groupid-alarmid(e.g., ”2310-36700394”), this will help manage millions of alarm types easier.

Defining alarm-type-id as identity seems wasting a lot of space and hard to deal with millions of alarm type in the design time since Enumerating each of them require human to enter all of alarm types in yang file.

2.       Alarm-name or alarm-serial-no field support for alarm and alarm inventory

Suppose we have alarm-name or alarm-serial-no, I believe it is more easier to based on one field rather than 3 tuple(resource, alarm-type-id, alarm-type-qualifier) to identify each alarm instance,

The most important is this will simplify operation and management.

3.       Alarm notification category support

Do we based on’ is-cleared’ and ‘status-change’ field to tell The same notification is used for reporting a newly raised alarm, a cleared alarm or changing the text?

How do we know the notification is used for newly raised alarm is not clear to me, since we don’t have raised field.

4.       Consistency between alarm list construct and alarm notification construct
Why alarm notification can not be used to notify the time when this alarm entry was created rather than just the time when alarm status is changed?
Why alarm notification can not be used to notify whether the alarm is cleared or not?
To address this, the proposal is to make Consistency between alarm list construct and alarm notification construct, make sense?

Regards!
-Qin
发件人: stefan vallin [mailto:[email-masked]]
发送时间: 2018年8月9日 1:36
收件人: Qin Wu
抄送: [email-masked]
主题: Re: Second review of draft-ietf-ccamp-alarm-module-01

Hi!
Sorry for slow response!

On 23 Jul 2018, at 11:39, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

-Qin
发件人: stefan vallin [mailto:[email-masked]]
发送时间: 2018年7月23日 2:37
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
主题: Re: Second review of draft-ietf-ccamp-alarm-module-01

Hi again!
Addition to #8

Br stefan
Mvh stefan
+46(0)705233262

22 juli 2018 kl. 20:17 skrev stefan vallin <[email-masked]<mailto:[email-masked]>>:
Hi Qin!
Thanks for your review and comments, see inline below:

On 21 Jul 2018, at 14:16, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Stefan:

typedef resource {
        type union {

     import ietf-alarms {
       prefix al;
     }
     identity vendor-alarms {
       base al:alarm-type;
     }

   For example:

”

Br Stefan

---

From: tom petch <[email-masked]>
Date: Fri, 10 Aug 2018 11:53:04 +0000

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" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 22, 2018 7:17 PM

---

From: stefan vallin <[email-masked]>
Date: Fri, 10 Aug 2018 16:37:40 +0200

Hi!

> On 9 Aug 2018, at 04:54, Qin Wu <[email-masked]> wrote:
> 
Yes :) and it works. But I appreciate you coming back to the topic. I have not been clear on the details
The most important thing is how to handle the reference to the alarming resource within a device when the alarm model is used in the controller.
Then the resource must somehow also include the reference to the device.

I am working on a detailed clear answer to this, stay tuned...

> https://www.ietf.org/mail-archive/web/ccamp/current/msg18904.html <https://www.ietf.org/mail-archive/web/ccamp/current/msg18904.html>
A) a flat enum does not work globally across enterprises and organisations, see ITU failure with probable cause
B) Millons of alarm types ??? No that will not happen
C) uint32, that is meaningless for operators
D) string, that will result in surprises for operators, developers will introduce strings in their code that suddenly shows up in the NOC.
E) I do not get your last comment ”require human to enter all alarm types in yang file”.
     You have to design which alarm types your system has, that should not come as.a surprise to the operator. 

There are several benefits of hierarchical identities for alarm types:
- Alarm types can be parsed from YANG modules
- You can reason about “abstract” alarm types
- Extensibility, enterprises and organisations can extend previous identities

> The most important is this will simplify operation and management.
I think that
(GigabitEthernet0/15, link-alarm, “")

Tells more than:
42

> How do we know the notification is used for newly raised alarm is not clear to me, since we don’t have raised field.
A) You have your stateful alarm list in your controller
B) You get a notification:
       leaf perceived-severity {
         type severity-with-clear;
This tells you the (new) severity state
- So if this is clear the alarm is cleared.
- If you do not have an entry for the key, it is a new alarm
- Well if the only thing that is different from your entry is the text, the text has changed...

> Why alarm notification can not be used to notify the time when this alarm entry was created rather than just the time when alarm status is changed?
The first entry in the status-change list represents the first state change for the alarm, “creation”.
Note however that there is no absolute truth here over time.
Alarm entries might be deleted by house-keeping or admin purposes. What is creation?

See above
> To address this, the proposal is to make Consistency between alarm list construct and alarm notification construct, make sense?
?

Best regards!

> On 23 Jul 2018, at 11:39, Qin Wu <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 10 Aug 2018 19:17:49 +0000

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

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.

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.

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.

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😊  

Deborah
(AD hat on)

-----Original Message-----
From: CCAMP <[email-masked]> On Behalf Of tom petch
Sent: Friday, August 10, 2018 7:53 AM
To: stefan vallin <[email-masked]>
Cc: [email-masked]
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

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.

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" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 22, 2018 7:17 PM

_______________________________________________
CCAMP mailing list
[email-masked]
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=

---

From: stefan vallin <[email-masked]>
Date: Sat, 11 Aug 2018 19:52:33 +0200

Hi Tom!

> On 10 Aug 2018, at 13:53, tom petch <[email-masked]> wrote:
> 
> Stefan
> 
> I find this I-D (too) hard to understand.  
Sad to hear, I spent some time on describing it...

> The problem I have is with
OK, I read you, understand I need to improve on the basic definitions, important
Terminology is everything.

> I cannot understand the document.
Oh oh, fundamental, I need to improve, let my try a quick one:
I think I need to improve the right side of the function
 (resource, alarm-type-id, alarm-type-qualifier)->(alarm state)
The alarm state is really a composite state.

From pyang tree output:

     |  +--ro alarm* [resource alarm-type-id alarm-type-qualifier]
     |     +--ro resource                 resource
     |     +--ro alarm-type-id            alarm-type-id
     |     +--ro alarm-type-qualifier     alarm-type-qualifier
     |     +--ro alt-resource*            resource
     |     +--ro related-alarm* [resource alarm-type-id alarm-type-qualifier]
     |     |     ...
     |     +--ro impacted-resource*       resource
     |     +--ro root-cause-resource*     resource
     |     +--ro time-created             yang:date-and-time
     |     +--ro is-cleared               boolean
     |     +--ro last-changed             yang:date-and-time
     |     +--ro perceived-severity       severity
     |     +--ro alarm-text               alarm-text
     |     +--ro status-change* [time] {alarm-history}?
     |     |     ...
     |     +--ro operator-state-change* [time] {operator-actions}?
     |     |     ...
     |     +---x set-operator-state {operator-actions}?
     |     |     ...
     |     +---n operator-action {operator-actions}?
     |           ...

This means:
(resource, alarm-type-id, alarm-type-qualifier)->(time-created, is-cleared, last-changed, perceived-severity, alarm-text, status-change, operator-state-change)

So by alarm state the composite state of an alarm comprises the alarm severity, if it is cleared, the text, list of resource alarm state changes, list of operator state changes)

This means that you can ask what is the alarm state of (FastEthernet1/0, linkAlarm) and get the answer: current severity, is it cleared?, current operator state like “ack” etc.

> would make no sense here.

I disagree, the focus of the definition in this draft is to exclude general events to appear as alarms.
> against it rather than build on it.
Yes!
I am well aware of prior work, spent 25 years in the alarm industry, standards and systems.
Prior is not equivalent to art by definition.

This draft stands in giants shoulders, X.733, 3GPP Alarm IRP, RFC3877 etc but with improvements.

Your statement is very general, hard to comment. Can you make a more specific statement? Example?
I can mention some areas where I did make some design decisions that does not align with X.733, 3GPP Alarm IRP etc.

* Most alarm standards are focused on a list of notifications, this draft is focused on the alarm list as a function (resource, alarm-type-id, alarm-type-qualifier)->(composite alarm state)

* Key for alarm / alarm notification
  X.733 uses managed object (resource), event type, probable cause, specific problem. The most relevant attribute being probable cause, a global flat enum.
  3GPP Alarm IRP has confusing redundant overlapping keys “alarmId” an integer, and the X733 tuple. The standard even shows an example where alarmId and the X733 tuple is in conflict.
 
 This draft simplifies this with the hierarchical alarm-type-id.

* Separation of resource life-cycle and operator life-cycle.
  For example, 3GPP Alarm IRP has the notion of “manual-clear”, an operator setting the alarm clearance state. This is confusing.

* Separating alarm clearance from alarm severity.
  This alarm module separates the clearance state of an alarm from the alarm severity. X.733 and 3GPP does not.

And more….

Br Stefan

---

From: stefan vallin <[email-masked]>
Date: Sat, 11 Aug 2018 19:58:47 +0200

Hi Deborah!

> On 10 Aug 2018, at 21:17, BRUNGARD, DEBORAH A <[email-masked]> 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 i…
Appendix F and references
> 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 (…
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 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

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Mon, 13 Aug 2018 19:35:57 +0000

Hi Stefan,
Comments below-
Thanks-
Deborah

-----Original Message-----
From: stefan vallin <[email-masked]> 
Sent: Saturday, August 11, 2018 1:59 PM
To: BRUNGARD, DEBORAH A <[email-masked]>
Cc: tom petch <[email-masked]>; [email-masked]
Subject: Re: [CCAMP] review of draft-ietf-ccamp-alarm-module-01

Hi Deborah!

Both :)
[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.

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.

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

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.

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

 [deborah] See above.

Br Stefan

---

From: tom petch <[email-masked]>
Date: Tue, 14 Aug 2018 11:50:24 +0000

Stefan

I have the same difficulties with your response as I have with the
I-D:-(

When you say,
" (resource, alarm-type-id, alarm-type-qualifier)->(alarm state)"
 I read it as meaning that
 a given value of a resource and
 a given value of an alarm-type-id and
 a given value of an alarm-type-qualifier
defines a value of alarm-state with other values such as
 time-created
 perceived-severity
 alarm-text
being irrelevant.

When you then say
"So by alarm state the composite state of an alarm comprises the alarm
severity, if it is cleared, the text, list of resource alarm state
changes, list of operator state changes)"
I understand that the definition of alarm state includes
 alarm severity
 if it is cleared
 the text
 list of resource alarm state changes
 list of operator state changes

This tells me that the meaning of the term 'alarm state' varies
throughout the document in a way I cannot predict, I cannot grasp.  I
then struggle (fail?) to understand the I-D.

With the term 'event', prior art uses 'event' as a generic term with
'alarm' being that subset that indicates a fault. This says to me that
if you want to give a different meaning to 'event', as you say below,
then you should define 'event' (else - again - I get confused).

Tom Petch

----- Original Message -----
From: "stefan vallin" <[email-masked]>
To: "tom petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, August 11, 2018 6:52 PM

Hi Tom!

> terminology which seems elastic.
OK, I read you, understand I need to improve on the basic definitions,
important
Terminology is everything.

From pyang tree output:

     |     +--ro related-alarm* [resource alarm-type-id
alarm-type-qualifier]

This means:
(resource, alarm-type-id, alarm-type-qualifier)->(time-created,
is-cleared, last-changed, perceived-severity, alarm-text, status-change,
operator-state-change)

So by alarm state the composite state of an alarm comprises the alarm
severity, if it is cleared, the text, list of resource alarm state
changes, list of operator state changes)

This means that you can ask what is the alarm state of (FastEthernet1/0,
linkAlarm) and get the answer: current severity, is it cleared?, current
operator state like “ack” etc.

> would make no sense here.

I disagree, the focus of the definition in this draft is to exclude
general events to appear as alarms.
> against it rather than build on it.
Yes!
I am well aware of prior work, spent 25 years in the alarm industry,
standards and systems.
Prior is not equivalent to art by definition.

This draft stands in giants shoulders, X.733, 3GPP Alarm IRP, RFC3877
etc but with improvements.

Your statement is very general, hard to comment. Can you make a more
specific statement? Example?
I can mention some areas where I did make some design decisions that
does not align with X.733, 3GPP Alarm IRP etc.

* Most alarm standards are focused on a list of notifications, this
draft is focused on the alarm list as a function (resource,
alarm-type-id, alarm-type-qualifier)->(composite alarm state)

* Key for alarm / alarm notification
  X.733 uses managed object (resource), event type, probable cause,
specific problem. The most relevant attribute being probable cause, a
global flat enum.
  3GPP Alarm IRP has confusing redundant overlapping keys “alarmId” an
integer, and the X733 tuple. The standard even shows an example where
alarmId and the X733 tuple is in conflict.

* Separation of resource life-cycle and operator life-cycle.
  For example, 3GPP Alarm IRP has the notion of “manual-clear”, an
operator setting the alarm clearance state. This is confusing.

* Separating alarm clearance from alarm severity.
  This alarm module separates the clearance state of an alarm from the
alarm severity. X.733 and 3GPP does not.

And more….

Br Stefan

---

From: Qin Wu <[email-masked]>
Date: Tue, 14 Aug 2018 12:32:29 +0000

Hi, Stefan:
Thanks for quick response, please see followup comments below.
发件人: stefan vallin [mailto:[email-masked]]
发送时间: 2018年8月10日 22:38
收件人: Qin Wu
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: Second review of draft-ietf-ccamp-alarm-module-01

Hi!

On 9 Aug 2018, at 04:54, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

”

[Qin]: One way to handle the reference to the alarming resource is add Alarm-name or alarm-serial-no as one field of alarm list.
So alarm-name or alarm-serial-no can be seen as alias of 3 tuple (resource, alarm-type-id, alarm-type-qualifier).

Defining alarm-type-id as identity seems wasting a lot of space and hard to deal with millions of alarm type in the design time since Enumerating each of them require human to enter all of alarm types in yang file.
A) a flat enum does not work globally across enterprises and organisations, see ITU failure with probable cause
B) Millons of alarm types ??? No that will not happen
[Qin]: That’s the reality we are facing.(:-
C) uint32, that is meaningless for operators
[Qin]: That’s why we should have both alarm-name and alarm-serial-no, alarm-name provide meaning for operators.
D) string, that will result in surprises for operators, developers will introduce strings in their code that suddenly shows up in the NOC.
[Qin]: The essence of alarm-type-qualifier is string qualifier, so you believe introduce alarm-type-qualifier will result in surprises for operators as well??
E) I do not get your last comment ”require human to enter all alarm types in yang file”.
     You have to design which alarm types your system has, that should not come as.a surprise to the operator.
[Qin]: Enter 2 million alarm type in YANG file is challenging to human.
There are several benefits of hierarchical identities for alarm types:
- Alarm types can be parsed from YANG modules
- You can reason about “abstract” alarm types
- Extensibility, enterprises and organisations can extend previous identities

Tells more than:
42

[Qin]: The limitation of 3 tuple is when the same alarm identified by (GigabitEthernet0/15, link-alarm, “")
is raised again, (GigabitEthernet0/15, link-alarm, “")can not be used to distinguish first raised alarm and second raised alarm.
By introducing unsigned integer type alarm-serial-no and string type alarm-name, this issue can be solved.

[Qin]: If you correlate alarm instance with alarm name or alarm-serial-no, it will be easier to look up each alarm instance based on alarm-name or alarm-serial-no than using 3 tuple(resource, alarm-type-id, alarm-type-qualifier).

[Qin]: Don’t understand this, can you provide an example to explain this.

[Qin]: I feel confused, time-created leaf within alarm-list and time leaf within alarm-notification are defines as follows separately:
“

         leaf time-created {
             type yang:date-and-time;
             mandatory true;
             description
               "The time-stamp when this alarm entry was created. This
                represents the first time the alarm appeared

       leaf time {
         type yang:date-and-time;
         mandatory true;
         description
           "The time the status of the alarm changed.  The value
            represents the time the real alarm state change appeared
            in the resource and not when it was added to the
            alarm list. The /alarm-list/alarm/last-changed MUST be
            set to the same value.";
       }
”
could you clarify their difference. My impression time-created is for newly raised alarm, the leaf time is applied to both newly raised alarm and alarm with severity change. Is leaf time applicable to cleared alarm is not clear to me. Would it be great to add category parameter within alarm notification to explicitly distinguish one another:
“

leaf category {

         type enumeration {

           enum raised {

             description

               "Alarm raised in case of fault.";

           }

           enum cleared {

             description

               "Alarm cleared in case of recovery.";

           }

           enum Change {

             description

               " changing the text and/or

         severity of an existing alarm.";

           }

         }

”
Make sense?

Why alarm notification can not be used to notify whether the alarm is cleared or not?
See above
[Qin]: So you should add is-cleared parameter within alarm notification to indicate this,Right?
In the current alarm notification, there is no is-cleared parameter.

To address this, the proposal is to make Consistency between alarm list construct and alarm notification construct, make sense?
?
[Qin]: For consistency, I think time-created leaf within alarm-list and time leaf within alarm-notification should be aligned.
In addition, is-cleared parameter should be added into alarm notification.

Best regards!

Regards!
-Qin
发件人: stefan vallin [mailto:[email-masked]]
发送时间: 2018年8月9日 1:36
收件人: Qin Wu
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: Second review of draft-ietf-ccamp-alarm-module-01

Hi!
Sorry for slow response!

-Qin

Hi again!
Addition to #8

Br stefan
Mvh stefan
+46(0)705233262

Hi, Stefan:

typedef resource {
        type union {

     import ietf-alarms {
       prefix al;
     }
     identity vendor-alarms {
       base al:alarm-type;
     }

   For example:

”

Br Stefan

---

From: stefan vallin <[email-masked]>
Date: Fri, 17 Aug 2018 10:31:11 +0200

Hi Tom!
Ok, I will have a thorough read throughout the document to make sure I am using the terms consistently.
* alarm
* alarm notification
* alarm composite state (rather than just state)
  will make sure I emphasise it is a composite state.

When referring to alarm severity, alarm clearance etc I will make sure that is made clear that I am referring to a specific state.

Going back to your concerns on my definition of alarm and other standards.
It is interesting to follow how 3GPP Alarm IRP has changed its definition over the years.

3GPP TS 32.111-1 Part 1: 3G fault management requirements

V12.0.0 (2013-06)
* alarm: abnormal network entity condition, which categorizes an event as a fault

V15.0.0 (2018-06)
* alarm: An alarm signifies an undesired condition of a resource
             (e.g. network element, link) for which an operator action is
             required. It emphasizes a key requirement that operators [...]
             should not be informed about an undesired condition unless it
             requires operator action.

* alarm notification: Notification used to inform the recipient about the
             occurrence of an alarm.

Please note how the later version from 2018-06 is almost literally the same
as in the ietf alarm draft. The earlier version from 2013 is using
yours of alarms as a special case of event.

So I disagree totally that I do not follow standards. We are progressing standards.
(The 3GPP working group read my earlier work, during their revisions).

So the definition of the term “alarm" is focusing on the resulting condition (composite state), not the individual notifications.
We use “alarm notifications” to refer to the individual notifications that informs of an update of the alarm composite state, might be a severity change, might be a clearance, ...

Br Stefan

> On 14 Aug 2018, at 13:50, tom petch <[email-masked]> wrote:
> 
> Stefan
>

---

From: stefan vallin <[email-masked]>
Date: Fri, 17 Aug 2018 10:41:35 +0200

Hi Deborah!

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

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 a…
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.

> 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/a…

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

---

From: stefan vallin <[email-masked]>
Date: Fri, 17 Aug 2018 11:10:01 +0200

Hi!
> So alarm-name or alarm-serial-no can be seen as alias of 3 tuple (resource, alarm-type-id, alarm-type-qualifier).
No, I will not do this. 3GPP used to notion of alarmId as a redundant/alias (and even conflicting) key to the  3GPP triplet (mo, event-type, probable-cause).
This is really confusing and the 3GPP specs showed inconsistent scenarios where you had the same (mo, event-type, probable-cause) and different alarmId.
The spec said in text that is not allowed. Which database designer would have two conflicting overlapping keys?

When you say alarmSerialNo, this is really confusing. The notion of a serial-number in alarm standards normally refer to individual notifications.

> [Qin]: That’s the reality we are facing.(:-
If you have this you need to rethink. I will not buy your equipment if I need to train my operators in the NOC to learn how to manage millions of different alarm *types*.

> [Qin]: That’s why we should have both alarm-name and alarm-serial-no, alarm-name provide meaning for operators.
Alarm-type is a yang identity, it has a clear name. No need for a separate “name”.
Just give your identity a good name
> [Qin]: The essence of alarm-type-qualifier is string qualifier, so you believe introduce alarm-type-qualifier will result in surprises for operators as well??
Read the RFC, it is explained

> [Qin]: Enter 2 million alarm type in YANG file is challenging to human.
1) You are in deep problems if your system has millions of alarm types
2) So without enumerating the alarm types in a YANG file (could be generated from whatever source you have, does not have to be “manual” ) what do you argue?
Programmers entering them “manually” as strings in a printf? Difference?

There is a huge value for the operators that the alarm-types are known

> By introducing unsigned integer type alarm-serial-no and string type alarm-name, this issue can be solved.
You are confusing the individual alarm notifications with the alarm itself.
Each notification is available in the status-change list for the alarm
       +--ro status-change* [time]
          +--ro time                    yang:date-and-time

The key being the time of the alarm-notification.

> [Qin]: If you correlate alarm instance with alarm name or alarm-serial-no, it will be easier to look up each alarm instance based on alarm-name or alarm-serial-no than using 3 tuple(resource, alarm…
Do not agree...

> [Qin]: Don’t understand this, can you provide an example to explain this.

Current alarm-list:

(GigabitEthernet0/15, link-alarm, “”) : 
   Time-created: 2018-08-17:12-00-00
   Is-cleared: True
   Last-changed: 2018-08-17:13-00-00
   Perceived-severity: major
   Alarm-text: “an operator friendly message
   Status-change:
       Time : 2018-08-17:12-00-00
       Perceived-severity: major
       Alarm-text: “an operator friendly message
       Time : 2018-08-17:13-00-00
       Perceived-severity: clear
       Alarm-text: “an operator friendly message

(GigabitEthernet0/16, link-alarm, “”) :
   Time-created: 2018-08-17:14-00-00
   Is-cleared: False
   Last-changed: 2018-08-17:14-00-00
   Perceived-severity: major
   Alarm-text: “an operator friendly message
   Status-change:
       Time : 2018-08-17:14-00-00
       Perceived-severity: major
       Alarm-text: “an operator friendly message

This will match the second alarm above:
alarm-notification:
    resource:  GigabitEthernet0/16              
    alarm-type-id: link-alarm
    alarm-type-qualifier: “"
    time: 2018-08-17:15-00-00
    perceived-severity: clear
    alarm-text: “….”

- change is-cleared to True
- update last-changed
- add a second row to the status change with perceived severity: clear

This will create a new alarm since there is no alarm for GigabitEthernet0/17 (no matching key)
alarm-notification:
    resource:  GigabitEthernet0/17          
    alarm-type-id: link-alarm
    alarm-type-qualifier: “"
    time: 2018-08-17:16-00-00
    perceived-severity: major
    alarm-text: “….”

Br Stefan

> could you clarify their difference. My impression time-created is for newly raised alarm, the leaf time is applied to both newly raised alarm and alarm with severity change. Is leaf time applicable to cleared alarm is not clear to me.
Of course, every item in the status-change corresponds to a notification, that can of course include clear.
The first item in the status-change (raise) will have the same time as time-created.

> Would it be great to add category parameter within alarm notification to explicitly distinguish one another:
> “
> leaf category {
>          type enumeration {
>            enum raised {
>              description
Ok, will consider….

> In the current alarm notification, there is no is-cleared parameter.
Not needed, this is the severity-field in the notification, if it is clear it is clear :)
> [Qin]: For consistency, I think time-created leaf within alarm-list and time leaf within alarm-notification should be aligned.
Will revisit descriptions.
> In addition, is-cleared parameter should be added into alarm notification.
No
> 抄送: [email-masked] <mailto:[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Mon, 20 Aug 2018 03:25:45 +0000

Stefan:
Remove the comments I have reached agreement.
See my followup comments marked with [Qin-2].

发送时间: 2018年8月17日 17:10

Hi!

[Qin-2]: I am not sure introducing alarmed is confusing in 3GPP standards, as described in http://www.qtc.jp/3GPP/Specs/32111-2-340.pdf,
Alarmid can be used to detect alarm loss. So it is still a useful information.

suppose you have two alarms generated on the same managed object, if you have alarmid, you can easily distinguish one from another.
But without alarmid, you just thought this is the same alarm reraised again, I don’t understand why alarmid will introduce overlapping key. With alarm id added into 3 tuples, you will identify the same type of alarm generated in the same managed object(you use resource to specify each managed object).

[Qin-2]: Yes, in some case, alarm-serial-no and alarm notification are one to one alarm relationship, in such case, you may use alarmserialno to specify each notification. In TMF814 standard, notificationId is defined to identify each notification.

[Qin-2]:See definition of alarm-type-qualifier：
“  typedef alarm-type-qualifier {
       type string;
       description
         "If an alarm type can not be fully specified at design time by
          alarm-type-id, this string qualifier is used in addition to
          fully define a unique alarm type.

          The definition of alarm qualifiers is considered being part
          of the instrumentation and out of scope for this module.
          An empty string is used when this is part of a key.";
     }
”
My point is alarm-type-qualifier will have the same issue as string.

[Qin-2]:I am not against to define alarm-types as identity, what I like to see is to add additional information that can be used to identify alarm.
In 3 tuple, resource is actually the managed object that generate alarm, so use resource as part of 3 tuples key to identify each alarm instance has limitation,
that is why we proposed to add alarm-name or alarm-id.

Tells more than:
42

[Qin-2]: See above, I am not mixing alarm-serial-no with notification itself.

[Qin-2]: See above,
1.alarmid can be used to distinguish two alarm generated at the same managed object or resource while 3 tuple not.
2.Adding alarm-name and alarmid help you manage more alarm type and provide fine granularity on alarm control.