[CCAMP] Genart last call review of draft-ietf-ccamp-alarm-module-07

Dan Romascanu via Datatracker <noreply@ietf.org> Mon, 18 March 2019 20:27 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ccamp@ietf.org
Delivered-To: ccamp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDDC1311C1; Mon, 18 Mar 2019 13:27:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dan Romascanu via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: draft-ietf-ccamp-alarm-module.all@ietf.org, ccamp@ietf.org, ietf@ietf.org, dromasca@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Dan Romascanu <dromasca@gmail.com>
Message-ID: <155294084679.26073.4005125072161491147@ietfa.amsl.com>
Date: Mon, 18 Mar 2019 13:27:26 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/_HvfsNw-sqRlPqEmJytP7Qz6dHY>
Subject: [CCAMP] Genart last call review of draft-ietf-ccamp-alarm-module-07
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Mar 2019 20:27:27 -0000

Reviewer: Dan Romascanu
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-ccamp-alarm-module-07
Reviewer: Dan Romascanu
Review Date: 2019-03-18
IETF LC End Date: 2019-03-20
IESG Telechat date: Not scheduled for a telechat


The document defines a YANG module for Alarm management. While it's clear and
comprehensive, it ignores previous work done in the IETF and does not provide a
good motivation about the reasons of ignoring it. I would suggest to revisit
that part and provide a clear motivation for the need of this new design.

Major issues:

1. The definition of Alarm is key for the whole model. It reads like this:

> Alarm (the general concept): An alarm signifies an undesirable state in a
resource that requires corrective action.

However, RFC 3877 already defined a number of concepts including:

>  Error
      A deviation of a system from normal operation.

      Lasting error or warning condition.


      Persistent indication of a fault.

I believe that there is a need to show why the model defined by RFC 3877 needs
to be changed, and why the difference that RFC 3877 was making between a Fault
and an Alarm is no longer needed. Also, RFC 3877 defined in Section 3 a
Framework and an Architecture that was consistent with X.733. This document has
no such section, and while acknowledging the need for a mapping to X.733 it
states as a goal:

> Mapping to X.733, which is a requirement for some alarm systems. Still, keep
some of the X.733 concepts out of the core model in order to make the model
small and easy to understand

More details about what is left out and why these are not needed would help.

Minor issues:

1. Section 2 makes a statement that includes

> ... While IETF has not really addressed alarm management

This is is actually not accurate. RFC 3877 addressed Alarm Management. Maybe
there is a need to revise that approach, but this should be done explicitly,
not by stating that it did not exist.

2. Section 3.5:

> Closing an alarm implies that the operator considers the corrective action

Is this always true? The undesirable state may have been cancelled by some
other event than corrective action, for example the resource is no longer used,
or the time elapsed mat have made the undesirable state irrelevant.

3. In section 3.5.1:

> Alarms are not cleared by operators, only the underlying instrumentation can
clear an alarm.  Operators can close alarms.

So, the document makes a distinction between clearing an alarm and closing an
alarm. It may be good to define two two concepts to make the distinction clear.

4. Appendix F.1:

> The alarm MIB is state oriented rather than notification oriented, an alarm
is a "lasting condition", not a discrete notification reporting about a
condition state change.

I am not sure that I understand this comment. Alarm states are defined also in
this document, and Alarms as defined here are also different than ' a discrete
notification reporting about a condition state change'. So, what does this
comment really try to say?

Nits/editorial comments: