Liaison statement
Response to comments on draft-ietf-ccamp-alarm-module-01

The CCAMP Working Group would like to thank the ITU-T SG15 for the comments on
draft-ietf-ccamp-alarm-module-01 and would like to share the  progress of the
work. The document has passed the working group last call and has been
submitted to the IETF for publication.

Replies to the comments provided can be found in line in the text below.

>"Regarding the alarm management, we would like to see the FM and PM modelling
based on the same architecture, and to harmonize with the requirements in
Recommendation G.7710."

The approach adopted by the draft is to define a core Alarm YANG model that is
simple enough to get wide implementation support, and that can be augmented by
other models. Some of the features described by the ITU-T recommendations have
been simplified/excluded by design in order to keep the "ietf-alarms" YANG
module small and simple. The definition of a separate model called
"itu-alarm-module" augmenting the "ietf-alarms" one with more advanced features
can be considered.

>"The YANG module should also allow transport technology specific
augmentations." That is the intention. That would mostly mean to  define YANG
identities for the technology specific alarm types.

>"Regarding the scope of the YANG Alarm Module, the draft should explicitly
state that the modeling of how transport resource alarms are raised and cleared
by the underlying transport instrumentation is out of the scope of this draft.
Specifically, the modelling of defect detection, defect coordination into fault
cause, consequent action, persistency verification declaring fault cause as
failure, and raising failure as alarm and its subsequent clearing should belong
to the SDO/group that owns the transport technology."

This has been added to Section 1 of the document.

>"The alarm YANG draft adopts the X.733 alarm severities, but doesn’t support
the function of alarm severity assignment (i.e., configuring the severity of an
alarm type of a resource), i.e., the feature of the Alarm Severity Assignment
Profile (ASAP) object of M.3160/M.3100 is not supported by the draft. Is this
intended to be out of the scope of the alarm YANG draft?"

Support for the alarm severity assignment has been added (please see section
3.8 in version -06).

> "For alarm reporting control, the alarm YANG draft supports only the simple
alarm shelf function. It doesn’t support the rich features of the Alarm
Reporting Control (ARC) function of M.3160/M.3100, which is required by G.7710."

The control of notifications has been expanded in version -06. Please see
section 4.1.

>"Listed below are specific comments from our review of the YANG Alarm Module
1.   Section 4.2, paragraphs 5 & 6 discuss unknow alarm type at design time and
dynamic addition of alarm types using string. Please note that the Spec Model
approach of the Core Information Model (ITU-T Recommendation G.7711 Annex G)
(also in ONF TR-512.7) provides a generic formal way to allow run time
enhancement/decoration."

The use of alarm-qualifier is a specific mechanism to allow for dynamic alarm
types which are included as key in the alarm list. Alarm-qualifier roughly
matches X.733 specific-problem but with the requirement that they must be
published in the alarm inventory.

>"2.   Section 4.4, first paragraph, second last sentence: Add “and alarm type
qualifier” so that the sentence becomes “This means that alarm notifications
for the same resource, same alarm type and same alarm type qualifier are
matched to update the same alarm instance.”" This has been clarified in the
following versions of the draft.

>"3.   Section 4.5: What is the relationship (dependency) among “alarm
clearance”, “alarm closing”, and “alarm deleting”. Will administrative deleting
automatically results in operator closing? Need more clarification among the
three types of alarm life-cycle. Otherwise will cause inconsistent handling of
alarm among different systems."

Alarm clearance is the resource life-cycle, the instrumentation clearing the
alarm. Alarm closing is the operator life-cycle, the alarm is not important
from an operations perspective (might be cleared or not) Deleting an alarm
means it is removed from the list and therefore has no states. The text of the
draft will be improved to make this more clear.

>"4.   Section 4.5.1, first paragraph, second line: Editorial error: “change
severity” occurs twice."

That is done on purpose.  From a resource perspective, an alarm can have the
following life-cycle: raise, change severity, change severity, clear, being
raised again etc” The alarm list has the following structure: [resource,
alarm-type-id, alarm-type-qualifier], [(time, severity, text, cleared), (...),
(...)] [link42, highUtilization,-](t1, warning, “”,-), (t2, minor, “”, -),(t3,
minor, “”, cleared)

Please also note that Appendix F has been added on the relationship to other
alarm standards.

To find the latest draft see:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/

Thanks,
Daniele Ceccarelli (CCAMP co-chair)
Fatai Zhang (CCAMP co-chair)