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

stefan vallin <stefan@wallan.se> Wed, 10 April 2019 06:44 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 0E4F31202B9 for <ccamp@ietfa.amsl.com>; Tue, 9 Apr 2019 23:44:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 zt4hq0_PhVPE for <ccamp@ietfa.amsl.com>; Tue, 9 Apr 2019 23:44:31 -0700 (PDT)
Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 B79C912011D for <ccamp@ietf.org>; Tue, 9 Apr 2019 23:44:29 -0700 (PDT)
Received: by mail-lj1-x243.google.com with SMTP id v22so1008174lje.9 for <ccamp@ietf.org>; Tue, 09 Apr 2019 23:44:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wallan-se.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2aQgrX/53nXaNvrVXHEVsKE23Z5loa/S3MnatdsIdQ0=; b=ptNZkcIxAMvZsVELZKjgXPK5ZMW4u0fjNKYuNu3GP9WSynUggHEwn2hmdR9BwlLPnP vR3KlHkFKTSTVh5Kv/4VxjgjRPi0Z3L0/75t4uoV/OmdUK9At8yLRrtBSb3JluFIjoyv 3omQ1E9kS+YibtBROA7uiPmdrjh4GRrR97PCIXEsFppvI9pjAM7qbxKSvD9cFvQGPVaB hyTsbAPelTZe05qv0mTsI7H9QwOSfuqXBwCmc26kyr6VG5neoTqGwVG4SsnM0ztWx1js a0DtcMbfI86y4ezh+r0TVGYIdg664O8EzNRxtpy+IgSx8yrLKaE7nq0TdaZxws2BwGKE /pAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2aQgrX/53nXaNvrVXHEVsKE23Z5loa/S3MnatdsIdQ0=; b=e3DT2XJCctDl0+xrsTl77sDfSd/Y0Uo1J+tugXbPMuluRLSMsMNHcl77DapUvi8ScZ QZ5pQqsxycft2/8BPEk+lqAPPl5C6tU1Juw9WGK83zPNaCF+PcULBwSdmy8K3O0WoSyo QTlYWF5Gz31KGvBiMmeRCGsDkj5UtFJocGAj2iFA2EDTw8fyAy/+wNYC1sXhPtjbVxtT bxXqDtCy1FHjdFjCncvTYREN0bNZ9fIwKgzFN2z8NAp2xnggZVedUU5SbwEhl9LwW8mU iPe3mC5IqLVpAd11c+ySXggkxLlCoithFLVUfB4D553jurF/HCL1f7QJDtr3ckwTWAJP kHTw==
X-Gm-Message-State: APjAAAWHIr3O9tosE4rgU3AjspunSDu3fXnMv+x6ZX3uCfUNg3g6aCdM UEvU308H5Fwett9Wn76azF50oA==
X-Google-Smtp-Source: APXvYqwJi8WGjL/SYzSf9fxpGm6QuBa6vOqhkcgrGdqLs6tkG5G9H77gpgVd9lCZ4Qw9bf0uveENmA==
X-Received: by 2002:a2e:86c7:: with SMTP id n7mr3468183ljj.44.1554878667765; Tue, 09 Apr 2019 23:44:27 -0700 (PDT)
Received: from [192.168.8.150] ([195.234.15.130]) by smtp.gmail.com with ESMTPSA id a13sm586570lfh.27.2019.04.09.23.44.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 23:44:27 -0700 (PDT)
From: stefan vallin <stefan@wallan.se>
Message-Id: <FA29225F-A073-400E-9D7B-A037713D2A2C@wallan.se>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D4A5EC72-8CE1-49B4-A1F6-61C54369A166"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Wed, 10 Apr 2019 08:44:24 +0200
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3322AAE@marchand>
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>
To: Roman Danyliw <rdd@cert.org>
References: <155441219772.30850.16834415326016227822.idtracker@ietfa.amsl.com> <20190408.134748.1365144734427040436.mbj@tail-f.com> <359EC4B99E040048A7131E0F4E113AFC01B3322AAE@marchand>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/0S_DpoEZTHt-psAVixSLA-k407M>
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: Wed, 10 Apr 2019 06:44:35 -0000

Hi Roman!

> On 9 Apr 2019, at 18:18, Roman Danyliw <rdd@cert.org>; wrote:
> 
>> 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."

So your question is how a client shall deal with a bug/non compliant implementation. (Violating the MUST).

I do not think discarding the alarm is the proper behaviour.
Assume an admin adds a new detector/sensor and configures it as an alarm detector.
But there is a bug so that it is not added to the alarm inventory.

When there is a fire, we would get an alarm  like:

dev:detectors/dev:detector[id=17], ]xyz-al:environmental-alarm, “smoke”

According to the alarm definition, “undesired state that requires action”, it should be handled by the client application
We certainly want the operators to do some fire fighting. Discarding the alarm would not be a good decision.
Alarm applications normally has a link to a wiki page or something with a written instruction how to handle the alarm, or
a link to an automatic action. In this case this would be void. The application should high-light that it is missing in the inventory.
But this is an application design issue. And ignoring it is not recommended.

Also consider the “simplest” alarm client, that just shows the alarm list, it would show the alarm although it is missing in the inventory

br Stefan