Re: [CCAMP] Opsdir last call review of draft-ietf-ccamp-alarm-module-07

Joe Clarke <jclarke@cisco.com> Tue, 19 March 2019 14:16 UTC

Return-Path: <jclarke@cisco.com>
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 2D77B13128D; Tue, 19 Mar 2019 07:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Y0jeMYmYUVop; Tue, 19 Mar 2019 07:16:20 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F81A130F00; Tue, 19 Mar 2019 07:16:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3797; q=dns/txt; s=iport; t=1553004980; x=1554214580; h=to:cc:references:from:subject:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=nzE4r+D/UpcJWwmh3px5FqPJrHJwx/RmRFxxlP8LMHc=; b=icxeBv+lS28eB9E+rJZldFK2qwf75fpjVY0IQSAGlpKOsXBkD/Oc9yNq RgOJu2sUr5sk8auufAzpNKfvlDO5NRGSkuJH8D1J6AW/yImj/F09Wizhj XLedGWIZLCnvx3ovJEnL41jYQwxb4Wfs2goLyzdJoS/VAJp4tYOcUqlHL 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrAACg+JBc/5xdJa1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYIRa00zhDKTRoFgLZotDYRsAoRrIjgSAQEDAQEJAQMCbSi?= =?us-ascii?q?FSwEFIw8BRhALGAICCB4CAlcGDQgBAYMegXapfoEvijuBCyQBizAXgUA/gTi?= =?us-ascii?q?Ca4RrgyCCVwOkCWAJiyNBh0IGGYF8iRcmiCWeN4FeIYFWTSMVO4JtkGYjA4p?= =?us-ascii?q?lAQE?=
X-IronPort-AV: E=Sophos;i="5.58,498,1544486400"; d="scan'208";a="537057440"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Mar 2019 14:16:19 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTP id x2JEGHmE024770; Tue, 19 Mar 2019 14:16:18 GMT
To: stefan vallin <stefan@wallan.se>
Cc: ops-dir@ietf.org, draft-ietf-ccamp-alarm-module.all@ietf.org, ccamp@ietf.org, ietf@ietf.org
References: <155292844015.26147.11067773612585181394@ietfa.amsl.com> <22EBF1ED-7CE4-4A4F-A105-C76D17D2F2DA@wallan.se>
From: Joe Clarke <jclarke@cisco.com>
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= mQINBFx0f7kBEACpXvK/9vZPCzcdpjMCFxTYDJSbYGPBj4jAct6j26evawhP4nQFuk8a/N0T u/l5KhN8nj0F+4wYLBBm/Vq6OYnXcuu/Qnaa5SeN6A8xp0KGFvY81x2BzPMqoM1XLnBAgcHU BlO+OikGlQSouJYagtw1qhlJpmtjwdcJ91Sun5N0SLd8iJVTU2ndCBdlj4PFuDBae9urft7D lkL3sDeAimsnPp8SJF8L2wdMWBXuht666lla+xYzwQ76+ibEmH+zr9Xy3JWySCcS75pbIikj eV/LF/YdyVPr6YGPXawO+srQGiiaqAcUY4oeWYEuFZuG0zGiCDNl106Sc4GVPOTOragqFMZv 1DoFvdaHvmBz3dbKQJ7L+W/paaBxk9F7uu73g9pPWgdio/Bh63iDlEfOm360qIQI3cbisSPF yR9RLnQTUWsy3aolG3NmxSJ+YPDwunNS9soPvPwZixbL6XUy05sUyu6d4lFKMtfo135VJ8N0 SgxNlBn/MZwFsuj66nLq015rz+bud5kz1EIK428q9+Kn4t92uq61oa/9un42qm9Xp/mm4j0J LUdNXXp987F1lZdZltcqkoYlY66OWmUr+YcVB+JAGPCA+C0T7CDjXgxkeyA3/9y7/jtVEDSx UWzCzLhzU/78QqC3NtMyUVRG7feRF0NWRzcc+d4ZEsojicmdEwARAQABtCtKb2UgQ2xhcmtl IChqY2xhcmtlKSAoKSA8amNsYXJrZUBjaXNjby5jb20+iQJOBBMBCAA4FiEE40r9XruLwkD8 nwY9s2u9ges9Y6oFAlx0f7kCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQs2u9ges9 Y6oT1Q//Vjy5ZVYA2Hy6eDz0jrmdkwQZklLU/MXvRgI8WWj6wGs2JKugdKSkkfwvDbD7Rg7b nqkMaZDcLK5eh/492CcwXwvcJKo/9bH1gUPYcDbu5INahiEagkgOS9GOjuHQs4cVr1JNiExf UZ/UcF0R+agP9jfqlJ7eiUN74w1cddZUfhfM0U0cLJ5TJtTjqnqsOCefNiWBLdSn+9RX8c6y cW77N4TVO6Vtv03SvLs5KniLmb6r7qwg6gkU2Vw6TDCk9UdJWSsKHEiOBmq1aGGmZHfBq9iZ GxwCaEqUBdN438JYN8RJMB2qv7EzTsv+KVz2E96jUBzeWdTFqu2xPikg4mwwUmJ1SAqc6AGI JZ8ICNr50xONoPpfdR+1QQzImnua8TuV28pracEDKex8r/ieDZQh8UyVM3mdGL7RSVa4/+EO iKCVmFfHLdnbuwhJLUhsHOlfeYSmRzmHUwS9K1sERMPUJCImMJUOAynQEoeTuLc6dDWq0oTP 6kJ3my7eMcg5MsFsGob8qtUDujiGof7LKZYHOqwYjCzrK4s4vwyX1Yh228sLRiEuNbCpvlD1 U/iKBv/VL5FMbI1kd0FPXvY+ygW+aobZYUOYXOvvdTeq9phCL2aHa5hHG7QNhSF6NsCuZhg6 mnOFOdAF7imXVmLa6cYEYqV17SGgceDKotNea2AxL965Ag0EXHR/uQEQAOIdXbR7GqhQdITX a+tCgi9r8p0o5e2Q2Rq22YIMR6FiyeWFTO2RQpW2NZW4yDfpGZnvBdFTWB62MWxu5Z7FwA09 ZON0l7c4IK7TFJ7Vx9azx1Ebx7r1p5hcARSmvU4CmlJZGPR0m9b+p9rPx27B5vCIWITQbWB/ PPgbksEdxXYYHCVJCWHk6LxL5iZJFVjoQGvHX/3PtzxByHtnVWQ937PZRCHaSAgERr6qVNWd XaO9ZlHm8l2yqMxKk+LUxOtj0FYY/vVdVwFFaGGkhXzhr4f6FJ7+j6Q+aOBbCvO2z/xfw/mh Tlg8W3cQYFwQcaW//FzdTprIRD8AiBRuEH5daLHZAhqj1M1srMv1SRyE7wu/e233ngUZ7UbZ J52bE2RsmA4sUVQVPB57/mn1U9xXW1pyus0n45sQi0GRsFl8fHujeQeAVPWIZl9AL8FiNlLZ +VDvMV0V24vChwRo7OVgohJNkc9NkIb7zYsv8Hqo2OinXWmQmMsluQzU9nSkGdC2eSgOPzVF fzY1KEcifF5O7A5PH2DPNsC1hPer+4vVZbMEQwW5mBIl04IvuCA3S3j+Vvfj3yyPuhf5ExjM 0YtaP5x0S4pqXVKNhzrHX/YtV13c3BP6Zx56MW2t5KnmV0MF97h2vejh/DHPSymz5blUv2Mr 0kknFYhJ+tp/rqP7B8+HABEBAAGJAjYEGAEIACAWIQTjSv1eu4vCQPyfBj2za72B6z1jqgUC XHR/uQIbDAAKCRCza72B6z1jqpFIEACKHqK4wdmimwJU+uq3HJcDBP12vnISDxkrcq19xWCv 01EWp1DR4izRLJXFIke7jlGk1GWfHKkjpUmkXOdujxYZvrVUXD9BwnNDWfDlZaPgpQNoMIlH Pcnq+MovlsuHiLnA29RRxUfRRn49fnpB4MQhB9tzsHGcghApFxB0h/CLs8ZWLTP6EDyDSNem ynEeJ8YjsbyBDqmAHs/+PS14FS7R6jHW8XNonzu5qKVvwkfA5EAI17CLJWTLkFwa3y7vOL6v x6qsoGNPvN4kolAGhz8cm2zqyZ/ts3paYnjZnBWnziYATv3hZzijcLKlLKBJaP7dUlkdNePN yzLkeN+oCVcz1DTGBhfIzlp+Dk3ySFoV2bYyEqiFmttpaDcBbPoB1LKvVZE/C1/f0Z9Tc0Fi VYQ2R60npDISUCanFF0JsN14PGoJdaV90Ouitr8GBzUJpKXFYi93L4M8gHCnSGWmjqAFGNj9 374pUwI8wbBAK5GI1hmjQZLA1UFM/SJ9J86gBzPUPNFR1xTSU+GTEufGHtcQ7wL42X+xz/lv 2pzhluScPl2WWXnwMSiE1a8AaVIhJvsrHuBxNH2l0RHuknWvJOjKtn6wdvPnEURJMH5dQ0jl QFqXPmJVYpL5AvqTYKXtS0Jy1z9oQN6ZUngZoaIYLDogKSQ9DOYd8WvdmOE24auWtA==
Organization: Cisco
Message-ID: <15ac10fa-db49-df31-c532-03a3692a2ca2@cisco.com>
Date: Tue, 19 Mar 2019 10:16:17 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <22EBF1ED-7CE4-4A4F-A105-C76D17D2F2DA@wallan.se>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.118.87.86, rtp-jclarke-nitro5.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/ih_UkGse2Fnmm_2crqzMPWFr7zI>
Subject: Re: [CCAMP] Opsdir last call review of draft-ietf-ccamp-alarm-module-07
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: Tue, 19 Mar 2019 14:16:22 -0000

On 3/19/19 10:07, stefan vallin wrote:
>> Additionally, some of the features like alarm-history and alarm-shelving have a
>> potential operational impact with respect to local server resources, and
>> perhaps that's worth calling out.
> Good comment: suggested edits 
> (could of course go somewhere else than in the feature desc)
> 
>      feature alarm-history {
>        description
>          "This feature indicates that server maintains a history of
>           state changes for each alarm.  For example, if an alarm
>           toggles between cleared and active 10 times, these state
>           changes are present in a separate list in the alarm.
> ADDED:
>           The alarm-history feature has an impact on server memory 
>           resources.         
>           ";
>      }
> 
> 
>      feature alarm-shelving {
>        description
>          "This feature indicates that the system supports shelving
>           (blocking) alarms.
> ADDED:
>           Alarm shelving has an impact on server processing resources
>           in order to match alarms against shelf criterion";
>      }

This is a good start, but people will miss this buried in the YANG
module.  I think it deserves some text in the document itself.  With
respect to resources, I recommend memory get called out especially
since, as I recall, you want all changes to be recorded in the history.

> 
> 
>>
>> The leaf "has-clear" seems like it would read better as "has-cleared" from an
>> English standpoint.  Thoughts?
> Note well that this leaf is for the alarm *inventory*, not the alarm itself.
> For the alarm itself the leaf is called "is-cleared".
> The alarm inventory lists all candidate alarms and it is important for
> operations to know if the server/instrumentation is capable of detecting
> and generating alarm clear. So "has-clear" states that a specific alarm-type
> will be cleared by the instrumentation when the alarm condition disappears.
> I guess "has-clear" works in this context?

Got it.  I do see the is-cleared, and I got a bit confused here.  After
re-reading the has-clear leaf definition, I think will-clear makes more
sense for this node.

>>
>> Finally, I can see where it might be desirable to suppress alarm notifications
>> without shelving them per se.  That is, the alarm remains in the list, but
>> notifications are not sent.  That doesn't seem possible, and I'm wondering if
>> it's worth considering.
> It is possible using the /alarms/control/notify-status-changes choice:
>  leaf notify-all-state-changes {
>              type empty;
>              description
>                "Send notifications for all status changes.";
>            }
>            leaf notify-raise-and-clear {
>              type empty;
>              description
>                "Send notifications only for raise, clear, and re-raise.
>                 Notifications for severity level changes or alarm text
>                 changes are not sent.";
>            }
>            leaf notify-severity-level {
>              type severity;
>              description
>                "Only send notifications for alarm state changes crossing
>                 the specified level.  Always send clear notifications.";
>            }
> 
> You could consider turning all of by adding another leaf:
> leaf notify-none {
>    type empty;
>    description
>      "Don't send any notifications.";
>  }
> Not sure if that would make sense, recommend to leave that out for further study.
> Note well that you can always stop to subscribe to the notification stream.

What if I want to control notifications on a per-alarm basis?  Like
shelving filtering, but keeping the alarms on the list instead of a shelf.

Joe