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

stefan vallin <stefan@wallan.se> Sun, 14 April 2019 20:09 UTC

Return-Path: <stefan@wallan.se>
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 CF311120155 for <ccamp@ietfa.amsl.com>; Sun, 14 Apr 2019 13:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wallan-se.20150623.gappssmtp.com
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 vWhJgDUH-m5n for <ccamp@ietfa.amsl.com>; Sun, 14 Apr 2019 13:09:44 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC1D1201D7 for <ccamp@ietf.org>; Sun, 14 Apr 2019 13:09:43 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id h5so8460866lfm.1 for <ccamp@ietf.org>; Sun, 14 Apr 2019 13:09:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wallan-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hj0v+/Ijt1CW6w7UViLiX5M8bMhb8YU3yjDF6td7PcY=; b=nHcBnIzZh3Plv7wkSmzpTcErFuT9Gh88cUD+ky2N7w0yM50kNCh4yJob9voe5kgik/ gzDFybZ6Ue6GMmxgbDxBUfa2oghwCB4O+jsGfvad9TcWTyp3s2ke7el2V9vure3y51ji 0sbUUGabZP/p3v4Zi4tUlwYBbxEncZYZ0sSsMK04kMXS0Q6DQHnyCWHB07AfFaKeOi8r yooWWUxp3ZhTVJ0FOzv0MgLPXw98b24BHuejVrUSuB/8oeReb04a14wmjuF0eO6LhLn/ SE7ONClTY8foThS6t2f4JrSanTxQ2o63yYXLDX/84KcuVUlvfPDT/TkiIE/mNmGzWimD +H+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hj0v+/Ijt1CW6w7UViLiX5M8bMhb8YU3yjDF6td7PcY=; b=HokrWX8PC/l8FZ3Y4t/xBOY2p4jnrL9jcQQy0aZ+9lHKzpC2uQ7Pz/ns5Gufo1DWlm qNOrvazWIsNd+euopyePRrQ0lc019hUsUz1JdMLDHQueSu0upkZcpAVCSgKCn/6xIUAA ellcoQd8psFFcRJC3j56vVhors1PCstDPc8pvk0fQaGc71ZbKwZEOsnoc6uhA/bAcizg h40xiIpchDfjGPWLFy20rQ+DCw5aaFJ90mu1oMwYE//f1llJJ1JWcqNTypnJdQDe+8l0 rB5poO9vrm2d9JZptgb9qiHr0g7RmlA9YXc9/BSErLeP0XEV/K/BN+wOcI11Ixs8B+yL mqkw==
X-Gm-Message-State: APjAAAVHNZ+YiS8HUAhUSVt7i3UT0fdRJpLGswsv1dUh2f34Z7AM4wmv y121/n6PsQ3jYLDhZKVdLz5xbZANqSH4VQ==
X-Google-Smtp-Source: APXvYqwD/ZSRS5joYXZfZ/s0WJlmm37hfWjydyfWFHy7xU7CrXl64E5m/U2wGM5jj8q/exBlfTkxCQ==
X-Received: by 2002:a19:c203:: with SMTP id l3mr35220662lfc.39.1555272580969; Sun, 14 Apr 2019 13:09:40 -0700 (PDT)
Received: from [192.168.72.11] (h95-155-237-105.cust.a3fiber.se. [95.155.237.105]) by smtp.gmail.com with ESMTPSA id u3sm9792750lju.51.2019.04.14.13.09.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Apr 2019 13:09:40 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: stefan vallin <stefan@wallan.se>
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B332A46D@marchand>
Date: Sun, 14 Apr 2019 22:09:39 +0200
Cc: Martin Bjorklund <mbj@tail-f.com>, "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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3CA7A178-2B65-4C87-92F8-32FA64ABE613@wallan.se>
References: <155441219772.30850.16834415326016227822.idtracker@ietfa.amsl.com> <20190408.134748.1365144734427040436.mbj@tail-f.com> <359EC4B99E040048A7131E0F4E113AFC01B3322AAE@marchand> <20190411.172242.625040826307824240.mbj@tail-f.com> <359EC4B99E040048A7131E0F4E113AFC01B332A46D@marchand>
To: Roman Danyliw <rdd@cert.org>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/4wXRVCmkZqyVSquK2wlDt5nrwWI>
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: Sun, 14 Apr 2019 20:09:48 -0000

Hi Roman!
Thanks for confirming 3 of 4 discuss!

On the last one, first see my previous email from 5 april on the topic.
You suggested this statement:
"if the management application gets an alarm of an unknown type it should  discard it.”
It should be the other way around, it is important that the alarm is managed by the client although it
is not available in the alarm inventory since that is a bug in the server.

We could add something like the following to the alarm-inventory description.
“If the client gets an alarm that is not present in the alarm-inventory it SHOULD still
manage the alarm. This is a non-compliant server but it is important that the client still
reports the alarm.” 

If the server has a bug/is non-compliant the client should present alarms missing in the inventory.
The client application could indicate the non-compliance  in some way so that a bug report could be sent to the server vendor.

Note well that for a well-behaved server with only static alarm types, all of them will be available as YANG identities, and no "unknown alarm types" exists.

br Stefan

> On 12 Apr 2019, at 14:46, Roman Danyliw <rdd@cert.org> wrote:
> 
> 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