Re: [CCAMP] Roman Danyliw's Discuss on draft-ietf-ccamp-alarm-module-08: (with DISCUSS and COMMENT)

Roman Danyliw <rdd@cert.org> Fri, 12 April 2019 12:46 UTC

Return-Path: <rdd@cert.org>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0015E12047B; Fri, 12 Apr 2019 05:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cABBcJ7_xjEb; Fri, 12 Apr 2019 05:46:26 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A862E1203A5; Fri, 12 Apr 2019 05:46:26 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x3CCkPhf034092; Fri, 12 Apr 2019 08:46:25 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x3CCkPhf034092
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1555073185; bh=QyHolt7rORL7hPHiA9K4q1wWDwCaYnLQi9mNBv+XMOk=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=C8FlgBizO4m6KKghVRLZkfGf3NE+W8wEyS+Rd9/uUxXN8JsVoKuU1i0EVMWhj6k4N OwR3bBRpneg4uBfw8Vq9gSOunYPxZaI5xipOUDisjm3PcAAoqoXqfwcz1JxbR5c6+a N/7mgZWmiUc12p6NxXdb9ISA7+2xhg8kbBvmLKrg=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x3CCkF9o011279; Fri, 12 Apr 2019 08:46:15 -0400
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0435.000; Fri, 12 Apr 2019 08:46:15 -0400
From: Roman Danyliw <rdd@cert.org>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "draft-ietf-ccamp-alarm-module@ietf.org" <draft-ietf-ccamp-alarm-module@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>, "ccamp-chairs@ietf.org" <ccamp-chairs@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Thread-Topic: [CCAMP] Roman Danyliw's Discuss on draft-ietf-ccamp-alarm-module-08: (with DISCUSS and COMMENT)
Thread-Index: AQHU6yrJ6crbUqYXnkqASPePfAqeTKYybn4AgAAv0ZCABMM5AIABIkHA
Date: Fri, 12 Apr 2019 12:46:14 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B332A46D@marchand>
References: <155441219772.30850.16834415326016227822.idtracker@ietfa.amsl.com> <20190408.134748.1365144734427040436.mbj@tail-f.com> <359EC4B99E040048A7131E0F4E113AFC01B3322AAE@marchand> <20190411.172242.625040826307824240.mbj@tail-f.com>
In-Reply-To: <20190411.172242.625040826307824240.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/KwDou0UDQuN0dxfWpBUUEJ3DzIM>
Subject: Re: [CCAMP] Roman Danyliw's Discuss on draft-ietf-ccamp-alarm-module-08: (with DISCUSS and COMMENT)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Fri, 12 Apr 2019 12:46:29 -0000

Hi!

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Thursday, April 11, 2019 11:23 AM
> To: Roman Danyliw <rdd@cert.org>;
> Cc: draft-ietf-ccamp-alarm-module@ietf.org; ccamp@ietf.org; ccamp-
> chairs@ietf.org; iesg@ietf.org
> Subject: Re: [CCAMP] Roman Danyliw's Discuss on draft-ietf-ccamp-alarm-
> module-08: (with DISCUSS and COMMENT)
> 
> Hi,
> 
> We have now posted draft-ietf-ccamp-alarm-module-09.  Please verify that
> this version addresses your DISUSS.

Thanks for -09.  It addresses all of my issues but one.  Please see below ...

> /martin & stefan
> 
> 
> Roman Danyliw <rdd@cert.org>; wrote:
> >
> >
> > > -----Original Message-----
> > > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Martin
> > > Bjorklund
> > > Sent: Monday, April 08, 2019 7:48 AM
> > > To: Roman Danyliw <rdd@cert.org>;; noreply@ietf.org
> > > Cc: draft-ietf-ccamp-alarm-module@ietf.org; ccamp@ietf.org; ccamp-
> > > chairs@ietf.org; iesg@ietf.org
> > > Subject: Re: [CCAMP] Roman Danyliw's Discuss on
> > > draft-ietf-ccamp-alarm-
> > > module-08: (with DISCUSS and COMMENT)
> > >
> > > Hi,
> > >
> > > Thank you for this review.  See comments inline.
> > >
> > >
> > > Roman Danyliw via Datatracker <noreply@ietf.org>; wrote:
> > > > Roman Danyliw has entered the following ballot position for
> > > > draft-ietf-ccamp-alarm-module-08: Discuss
> > > >
> > > > When responding, please keep the subject line intact and reply to
> > > > all email addresses included in the To and CC lines. (Feel free to
> > > > cut this introductory paragraph, however.)
> > > >
> > > >
> > > > Please refer to
> > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > for more information about IESG DISCUSS and COMMENT positions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can be found here:
> > > > https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/
> > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > ----
> > > > DISCUSS:
> > > > ------------------------------------------------------------------
> > > > ----
> > > >
> > > > (1) Section 3.5, Alarm Life-Cycle.  The text states that “A server
> > > > SHOULD describe how long it retains cleared/closed alarms: until
> > > > manually purged or if it has an automatic removal policy.” How is
> > > > this retention policy described?  Is that in scope for this document?
> > >
> > > You are right, this is not in scope.  We suggest we add a sentence:
> > >
> > >   How this is done is outside the scope of this document.
> >
> > Works for me.
> >
> > > > (2) Section 4.2, Alarm Inventory.  The text states that “A server
> > > > MUST implement the alarm inventory in order to enable controlled
> > > > alarm procedures in the client.” What is the expected server
> > > > behavior if a client sends an alarm type not in the inventory (and
> > > > it isn’t part of the dynamic addition process)?
> > >
> > > We assume you mean what does a management application do if it
> > > receives an alarm from a device that is not in the inventory?
> >
> > Yes, exactly.
> >
> > > This is the reason for the
> > > MUST in the text; a device MUST list all alarm types in the
> > > inventory so that a management application knows about it.
> >
> > What if the device is misconfigured/rogue and doesn't implement the
> MUST (i.e., doesn't put all of the alarm types in the inventory; returns a
> different alarm type than requested by the server)?  I was expecting text
> roughly on the order of "if the management application gets an alarm of an
> unknown type it MUST discard it."

Could you please help me understand what happens in this circumstance.

Thanks,
Roman


> > > > (2) Section 10, Security Considerations.  It seems like
> > > > “/alarms/alarm-list/alarm/set-operator-state” should be listed as
> > > > an operation in the YANG model that presents a security issues
> > > > (just like
> > > “purge-alarms”).
> > > > Consider if one altered the operator alert state causing the alarm
> > > > management procedures to miss an alert (e.g., setting an alert to
> > > > “closed” before any action is taken).
> > >
> > >
> > > You are right. We suggest:
> > >
> > >    /alarms/alarm-list/alarm/set-operator-state:  This action can be used
> > >       by the operator to indicate the level of human intervention on an
> > >       alarm.  Unauthorized use of this action could result in alarms
> > >       being ignored by operators.
> >
> > Works for me.  Your editorial call on how to best sequence the operators:
> "alarms/alarm-list/set-operator-state" vs. "{alarms, alarm-list, set-operator-
> state}", "alarms, alarm-list, set-operator-state".
> >
> > > > (3) Section 10, Security Considerations.  I don’t know must about
> > > > the implementations, but wouldn’t compressing alerts (per
> > > > compress-alarms and compress-shelved-alarms operations) remove
> > > > them from
> > > consideration
> > > > by alarm management procedures?  If so, these would be a sensitive
> > > > operation that would need to be listed as the concern equivalent
> > > > to the current text for purge-alarms.
> > >
> > > Compressing only affects the history (old states) of the alarm.  The
> > > alarm itself is not affected, so we don't think this needs additional
> considerations.
> >
> > I missed that detail.  Agreed that no change it required.
> >
> > > > ------------------------------------------------------------------
> > > > ----
> > > > COMMENT:
> > > > ------------------------------------------------------------------
> > > > ----
> > > >
> > > > (1) Section 1.1, Terminology, “Fault”.  Consider expanding the
> > > > acronym
> > > “MOS”
> > > > (Mean Option Score?)
> > >
> > > Done - (Mean Opinion Score).
> > >
> > > > (2) Section 2, Objectives, Consider s/X.733/[X.733]/
> > >
> > > Done.
> > >
> > > > (3) Section 3.2, Alarm Type, Consider s/identity
> > > > based/identity-based/
> > >
> > > Done.
> > >
> > > > (4) Section 3.2, Alarm Type, Typo, s/standard
> > > > organization/standards organization/
> > >
> > > Done.
> > >
> > > > (5) Section 3.4, Identifying Alarm Instances, Consider s/were not
> > > > really clear/were not clear/
> > >
> > > Done.
> > >
> > > > (6) Section 3.5.2, Operator Alarm Life-cycle, Consider s/can also
> > > > act upon/act upon/
> > >
> > > We suggest "Operators can act upon..."  (removed "also").
> > >
> > > > (7) Section 3.5.2, Operator Alarm Life-cycle, Consider s/A closed
> > > > alarm is an alarm/For example, a closed alarm is an alarm/
> > >
> > > Done.
> > >
> > > > (8) Section 3.6, Root Cause, Impacted Resources and Related
> > > > Alarms, Consider s/Different systems have various
> > > > various/Different systems have varying/
> > >
> > > Done.
> > >
> > > > (9) Section 3.6, Root Cause, Impacted Resources and Related
> > > > Alarms, Consider s/In some occasions/On some occasions/
> > >
> > > Done.
> > >
> > > > (10) Section 3.6, Root Cause, Impacted Resources and Related
> > > > Alarms, Consider s/needs to represent an alarm that indicates a
> > > > situation that needs acting upon/raises an alarm to indicate a
> > > > situation requiring attention/
> > >
> > > Done.
> > >
> > > > (11) Section 4.1.1, Alarm Shelving, The text states “The
> > > > instrumentation MUST move shelved alarms from the alarm list
> > > > (/alarms/alarm-list) to the shelved alarm list
> > > > (/alarms/shelved-alarms/).”  It wasn’t clear when these shelved
> > > > alarms
> > > must be moved given the text.
> > >
> > > You are right.  Actually, the word "move" is a bit misleading.  We suggest:
> > >
> > > OLD:
> > >
> > >    Shelved alarms are shown in a dedicated shelved alarm list.  The
> > >    instrumentation MUST move shelved alarms from the alarm list
> > >    (/alarms/alarm-list) to the shelved alarm list (/alarms/shelved-
> > >    alarms/).  Shelved alarms do not generate any notifications.  When
> > >    the shelving criteria is removed or changed the alarm list MUST be
> > >    updated to the correct actual state of the alarms.
> > >
> > > NEW:
> > >
> > >    Shelved alarms are shown in a dedicated shelved alarm list.  Matching
> > >    alarms MUST appear in the /alarms/shelved-alarms/shelved-alarm list,
> > >    and non-matching /alarms MUST appear in the /alarms/alarm-
> list/alarm
> > >    list.  The server does not send any notifications for shelved alarms.
> > >
> > > (and the same change in the YANG module)
> > >
> > >
> > > > (12) Section 4.4, The Alarm List, The sentence, “The alarm list
> > > > (/alarms/alarm-list) is a function from (resource, alarm type,
> > > > alarm type
> > > > qualifier) to the current composite alarm state” is missing a
> word/phrase.
> > > > Removing the parenthetical remarks it reads a “The alarm list is a
> > > > function from to the current composite alarm state” is does not parse.
> > >
> > > Ok, we suggest:
> > >
> > >      The alarm list (/alarms/alarm-list) is a function from the tuple
> > >      (resource, alarm type, alarm type qualifier) to the current
> > >      composite alarm state.
> > >
> > >
> > > > (13) Consider s/Life-cycle/Lifecycle/g
> > >
> > > Done.
> >
> > All of these work for me.
> >
> > Thanks,
> > Roman
> >
> > > Thanks again for this review!
> > >
> > > /martin & stefan