Re: [CCAMP] Comments regarding draft-ietf-ccamp-alarm-module-00

stefan vallin <stefan@wallan.se> Fri, 12 January 2018 18:07 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 7482C12785F for <ccamp@ietfa.amsl.com>; Fri, 12 Jan 2018 10:07:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 NUkg1yNyOZM2 for <ccamp@ietfa.amsl.com>; Fri, 12 Jan 2018 10:07:41 -0800 (PST)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 C15871200C5 for <ccamp@ietf.org>; Fri, 12 Jan 2018 10:07:40 -0800 (PST)
Received: by mail-lf0-x22b.google.com with SMTP id g72so1359868lfg.5 for <ccamp@ietf.org>; Fri, 12 Jan 2018 10:07:40 -0800 (PST)
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:message-id:references :to; bh=T/x0g9Z4gnpC8zBBYTuNqF4hqtQjYCU5Nhkz6976Qy4=; b=AD3bBeWY4m+ugjgtNM1VhooUWJkQrimyDlKNEIKVFaPGR2ExcD0XtdA+HSoYWadZ+m zAbgEAw7ttQGjHLe4Wq2fd8PSHhQGGLKIaVHLaGZOJbaqEqWGNVmE9E1Se2g8cZWqyqE 8/gpY7zSDhuTDjpinaGLo1ydbT7DVaneN2Qtf3zWTsFAQcMDjcTE89EAHnlmbbYHPq3R R2lWXBLHT2bJ7BJ65yxwbpZNccHdZ2CEE7LJaVzy0LWN9JWJ/4UsLt0XE1B2he15MQnx lj7X56VlYlsFZe6QfkRE00K9HmdBX6P9GLY5jNaYv0Eot8YQ2RacCpp17mTeXVOcVxls LZ6g==
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 :message-id:references:to; bh=T/x0g9Z4gnpC8zBBYTuNqF4hqtQjYCU5Nhkz6976Qy4=; b=mYK/2yWh2BQm4iwQ06jXd0CArmKa0WIaAmRCGk/ExAihY8OWrs9nDtk1JJ3KJTnojR 7N7xDI8GNjODi0hvIgrqnfyi3nBiPZjjZ+m+R5kyU/TQprrK8BWFC3KsW2g8X6w82Pvm U6I0yAD4ytnBjkn5ULbF5GYipY0L+lzVrjemsmnAxCUFy8ov+HbUuebyQj0CTnQiCDiA 7wPbVX6MOk03MWAAY7lQsFjsNovVLi23X5MWtGNQU2UfBj167r+8yrkDXVNSKLy7DdFW oWdfAOb0QpdoLG3YNMy6/L4pGkJwdMRsnMRFO0djAzx+VQwdP+B7t7qY51rtwDI9oDmg 9iew==
X-Gm-Message-State: AKwxyte7m4RCNWa6n58GiolbFrUx22vBv7X1jxBo0b9hQFvR/Xn75We6 X+9qMxfmR516vpK6GIiLpDax/yTwdPM=
X-Google-Smtp-Source: ACJfBos5V5bLLLumLIMpjyq/VyBULtHob07LxycNIHfuyYmtRSxYw2EBdyurqE8vxEXidomsdeOnkg==
X-Received: by 10.25.143.143 with SMTP id s15mr4998157lfk.129.1515780458326; Fri, 12 Jan 2018 10:07:38 -0800 (PST)
Received: from [192.168.1.231] (h95-155-236-214.cust.se.alltele.net. [95.155.236.214]) by smtp.gmail.com with ESMTPSA id b200sm3742623lfg.25.2018.01.12.10.07.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 12 Jan 2018 10:07:37 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_FD59A74B-9024-46DB-8DE9-BE5B43708F00"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: stefan vallin <stefan@wallan.se>
In-Reply-To: <BD6D193629F47C479266C0985F16AAC7F0691310@ex-mb1.corp.adtran.com>
Date: Fri, 12 Jan 2018 19:07:36 +0100
Cc: "ccamp@ietf.org" <ccamp@ietf.org>, JOEY BOYD <joey.boyd@adtran.com>
Message-Id: <99342A30-E8F2-45B3-BBBC-D9E4D04B071A@wallan.se>
References: <BD6D193629F47C479266C0985F16AAC7F06906D6@ex-mb1.corp.adtran.com> <46CF27E3-EB65-4FAB-96A6-CEBA08BD62ED@wallan.se> <71E07F83-8F94-4E7E-ABC3-6B15790633AE@wallan.se> <BD6D193629F47C479266C0985F16AAC7F0691310@ex-mb1.corp.adtran.com>
To: NICK HANCOCK <nick.hancock@adtran.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/5o9U0GIBXz8nGnE42tcc_p4G9zo>
Subject: Re: [CCAMP] Comments regarding draft-ietf-ccamp-alarm-module-00
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.22
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 Jan 2018 18:07:44 -0000

Hi!
Thanks for your response.
Is this something that should reside in the server?
I could argue this mapping should be done in the client, management system

br Stefan

Stefan Vallin
stefan@wallan.se
+46705233262

> On 12 Jan 2018, at 16:19, NICK HANCOCK <nick.hancock@adtran.com> wrote:
> 
> Hi Stefan,
>  
> Your comment:
>  
> Makes sense, I think we should add this capability to the alarm inventory. So the system publishes its possible alarm types (read-only).
> But each of those alarm types can have a configurable description leaf.
> Ok?
>  
> We believe that just a single configurable description leaf would be somewhat restrictive. We would rather take a more generic and extensible direction, whereby a client can map zero or more tagged values as required by his network implementation to an alarm-type-id and/or alarm-type-qualifier-match. For example, something like that shown below.
>  
> As configuration:
>  
>   +--rw custom-tags {custom-tags}?
>      +--rw custom-tag* [alarm-type-id alarm-type-qualifier-match tag-name]
>         +--rw alarm-type-id               alarm-type-id
>         +--rw alarm-type-qualifier-match  string
>         +--rw tag-name                    string
>         +--rw tag-value?                  tag-value
>  
> In the alarm inventory (state):
>  
>   +--ro alarm-type* [alarm-type-id alarm-type-qualifier]
>      +--ro alarm-type-id                       alarm-type-id
>      +--ro alarm-type-qualifier                alarm-type-qualifier
>      +--ro resource*                           string
>     :
>      +--ro custom-tags {custom-tags}?
>         +--ro custom-tag* [tag-name]
>            +--ro tag-name   string
>            +--ro tag-value? tag-value
>  
>  
> Best regards
> Nick
> This message has been classified Public by NICK HANCOCK on 12 January 2018 at 16:19:49.
>  
>  <>From: stefan vallin [mailto:stefan@wallan.se] 
> Sent: Thursday, January 11, 2018 2:29 PM
> To: NICK HANCOCK
> Cc: ccamp@ietf.org; JOEY BOYD
> Subject: Re: Comments regarding draft-ietf-ccamp-alarm-module-00
>  
> and your last comment…
>  
>  
>  
> 3. Mapping custom information to alarm types
>  
> Some operators require to be able to associate their own specific information with alarm types for use within their networks. Such a requirement could be supported within the alarm module through a generic mechanism whereby one or more tag/values could be mapped to an alarm-type-id and/or alarm-type-qualifier-match in a similar way as the list ‘x733-mapping’ allows a client to override the default X.733 mapping. Any mapped value would also need to be listed within the alarm inventory entry for that alarm-type and included within the ‘alarm-notification’.
>  
>  
> We believe that it would be advantageous if these additional requirements on alarm management were supported directly within the core alarm module to avoid the situation of each vendor implementing its own solution, which may then lead to interoperability issues between different vendors equipment.
>  
>  
> Makes sense, I think we should add this capability to the alarm inventory. So the system publishes its possible alarm types (read-only).
> But each of those alarm types can have a configurable description leaf.
> Ok?
>  
>  
> 
> 
>  
> Best regards
> Nick
> This message has been classified General Business by NICK HANCOCK on 09 January 2018 at 15:52:39.
>  
> From: CCAMP [mailto:ccamp-bounces@ietf.org <mailto:ccamp-bounces@ietf.org>] On Behalf Of internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
> Sent: Thursday, December 14, 2017 11:34 AM
> To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
> Cc: ccamp@ietf.org <mailto:ccamp@ietf.org>
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-alarm-module-00.txt
>  
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Common Control and Measurement Plane WG of the IETF.
> 
> Title : YANG Alarm Module
> Authors : Stefan Vallin
> Martin Bjorklund
> Filename : draft-ietf-ccamp-alarm-module-00.txt
> Pages : 58
> Date : 2017-12-14
> 
> Abstract:
> This document defines a YANG module for alarm management. It
> includes functions for alarm list management, alarm shelving and
> notifications to inform management systems. There are also RPCs to
> manage the operator state of an alarm and administrative alarm
> procedures. The module carefully maps to relevant alarm standards.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/ <https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/>
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ccamp-alarm-module-00 <https://tools.ietf.org/html/draft-ietf-ccamp-alarm-module-00>
> https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-alarm-module-00 <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-alarm-module-00>
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org <mailto:CCAMP@ietf.org>
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>