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

stefan vallin <> Wed, 10 April 2019 06:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A03CD12017D for <>; Tue, 9 Apr 2019 23:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iwxUfZDlev_C for <>; Tue, 9 Apr 2019 23:21:56 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA650120149 for <>; Tue, 9 Apr 2019 23:21:55 -0700 (PDT)
Received: by with SMTP id f23so1003295ljc.0 for <>; Tue, 09 Apr 2019 23:21:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vcxWQ6xXE3yYBJ3d+66zyJZfi6eDxvHpYqcvwr0MdGI=; b=djP5OCLfxhLI7pl2SR3rn/58/nSjr1sB7XjjrSmOhgLsXLPUZn+YMBppKwMHVHspwF EN7qUmUdU+khPt6U0RIFZXHOR1t3QrgtW7GsreKUxdJpIPpQRjzf78vyAcyA2oA8K0+1 eM5AfkE7bufAdELBRwFNDFuCnFLm45I7N6Om3SXL7jlgxSsHAADYQ8XGB4TnPjjKUtwq WKXSqMWBrym4eJliJKp3QCazFrTOodA71lDdfl2rbSEP9c3tvpqESM7haS1dnFMzb2PY nqBAP5+L1Xxi0MGvdVbPSbbmcJ/JiloJ9qOaA5rsK9RQpaxSNcz9FxmOiXHzR7jPXmFT +oRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vcxWQ6xXE3yYBJ3d+66zyJZfi6eDxvHpYqcvwr0MdGI=; b=W8/FbuPUckUijc+D7JfNsG4xt0xxPr/ktPQnYMxKehZxUVEWePpxy/khzK861SRs7P YQAOVkFLtYDfXTYzpHnWaPVFzHebbsKCL0GBa8jeqL86zPwib1vbv7+gvEIJCEQXoQJc x62T4d6eMZGA4HChCf1oaUtpvTjKr5nIYPOKpUmN/qCpBnIhOtxZBK9kx39hKTghVXIo GlLMv32iKpgwIuLipZUec+qjLxBdQ7MCItcBe9atI1yX+PzMH4Jwo/34vcc6No6njMOX AGk0TMsWPlNpEfhOTzYIXnz/3QWvmO/eLRSHtW5PbIJuWp+S8rVAMpC2tqHDrsT1OHuw iIqg==
X-Gm-Message-State: APjAAAXBxJKRtapmvZ7oqs70iNB8TQlHLVLu/d/qTGJaHLsbZv/giagc 4yxdEhXo0Mjaa42Jcch/ijD4sA==
X-Google-Smtp-Source: APXvYqy6iRzGpsYgUPRQ+0do9YYzzoQ+uFIUGkZ4ziJ0wNge6eLa+sTyTdarZzXzCAgsWDkdG1bQAw==
X-Received: by 2002:a2e:b01a:: with SMTP id y26mr5293520ljk.38.1554877313708; Tue, 09 Apr 2019 23:21:53 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id s26sm7153978ljj.52.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 23:21:52 -0700 (PDT)
From: stefan vallin <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_94196A41-C4CB-4D97-BC42-BC7FC6AE7FB0"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Wed, 10 Apr 2019 08:21:49 +0200
In-Reply-To: <>
Cc: The IESG <>,, Daniele Ceccarelli <>,,
To: Benjamin Kaduk <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <>
Subject: Re: [CCAMP] Benjamin Kaduk's Discuss on draft-ietf-ccamp-alarm-module-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Apr 2019 06:21:59 -0000

Hi Benjamin!

> On 10 Apr 2019, at 04:30, Benjamin Kaduk <> wrote:
>> An alarm might not have an underlying fault as a cause. For example,
>> imagine a bad Mean Opppinion Score (MOS) alarm from a Voice Over IP
>> (VOIP) probe and the cause being non-optimal QoS configuration.
>>>  o  Alarm Type: An alarm type identifies a possible unique alarm state
>>>     for a resource.  Alarm types are names to identify the state like
>>>     "link-alarm", "jitter-violation", "high-disk-utilization".
>>> Are these only intended for human consumption?
>> No, these are YANG identities and intended for automation software as well
> I think my follow-up question was going to be whether there was value in a
> registry for them, to avoid proliferation of nearly-identical types from
> different vendors.  (I honestly don't know.)

Well the YANG modules are the “registry”, the important thing here is that 
identities are hierarchical, this will avoid the pollution problem. In some
previous alarm standards we have certainly had a registration/pollution problem
when alarm types where defined as flat enums (probable cause in X733 and derivatives).

See 3.2.  Alarm Type

br Stefan