[netmod] Issue Y36: associate a notification with a data node

Balázs Lengyel <balazs.lengyel@ericsson.com> Wed, 23 July 2014 18:09 UTC

Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6B51A0ABD for <netmod@ietfa.amsl.com>; Wed, 23 Jul 2014 11:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.3
X-Spam-Level:
X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 TZjmJr2V0tsR for <netmod@ietfa.amsl.com>; Wed, 23 Jul 2014 11:09:09 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8721A0AC7 for <netmod@ietf.org>; Wed, 23 Jul 2014 11:09:09 -0700 (PDT)
X-AuditID: c1b4fb30-f79da6d000006b80-97-53cffa43a267
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FA.D2.27520.34AFFC35; Wed, 23 Jul 2014 20:09:07 +0200 (CEST)
Received: from ESESSMB103.ericsson.se ([169.254.3.143]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 20:09:06 +0200
From: Balázs Lengyel <balazs.lengyel@ericsson.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: Issue Y36: associate a notification with a data node
Thread-Index: Ac+mg6mM7xFT6+1YQna90h/wt1aQxAAHNpRw
Date: Wed, 23 Jul 2014 18:09:06 +0000
Message-ID: <971D4B790EC8B846BE223DD23AF72FF11EB7AE32@ESESSMB103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_971D4B790EC8B846BE223DD23AF72FF11EB7AE32ESESSMB103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvja7zr/PBBt1PlS3mX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr3Xk9gL9ntXTP3cw9jAeNGhi5GTQ0LAROL2jd2MELaYxIV7 69m6GLk4hASOMko8XbmLGcJZwihxcdFEdpAqNgFXiWOfvrOA2CIC6hIzd4J0cHIIC9hK/L/3 nBEi7iRx7e49IJsDyDaSOLbKHyTMIqAqce78ZmYQm1fAV+J+ywuwkYxAi7+fWsMEYjMLiEvc ejKfCeIgAYkle84zQ9iiEi8f/2OFsJUkVmy/xAhRny/xaeYudoiZghInZz5hmcAoNAvJqFlI ymYhKYOI60ncmDqFDcLWlli28DUzhK0rMePfIRZk8QWM7KsYRYtTi5Ny042M9FKLMpOLi/Pz 9PJSSzYxAmPi4JbfBjsYXz53PMQowMGoxMP7cP/5YCHWxLLiytxDjNIcLErivAvPzQsWEkhP LEnNTk0tSC2KLyrNSS0+xMjEwSnVwOjBxffBe7d+GfPbrwrZwcwv/t86x3HksntFsfU5KSaH HB0F69v72+psl4hPiXq4+WCzr5jqcc2TSX0JtkcPXPHOCOtk8/VVO9N08N0ugQP3py/MvV4c ITen5nDjfdnZTy/arlmlxlcmWfb1yO3tP5h9b6RPv2JS/lXM7oPGpU27JWa8YZWz9VNiKc5I NNRiLipOBABT17bqagIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7W-7Fr2957fQ0KCFqVOEbG-QkXM
Subject: [netmod] Issue Y36: associate a notification with a data node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jul 2014 18:09:12 -0000

Hello,
Ericsson would need this topic, but as someone has already raised: why just notifications, associating RPCs with data nodes would be even more important.
We see a number of reasons for this association:


1)      Access control: If RPCs and Notifications are associated to data nodes, it is enough to configure access control for the data node. Today, the operator needs to configure access control for the data nodes and after that separately for each RPC/notification again. Also understanding which action/rpc is carrying what data, thus how sensitive it is, which group should have access to it is not trivial. The operator has to read and understand all rpcs/notifications one by one. If the rpc/notification is generic (can relate to different parts of the data model), it cannot be access controlled properly at all. The amount of work needed by the operator for configuring access control is critical, if they have more work they have more room for mistakes, less likely to get it done properly.

2)      It is a natural way of thinking to associate notifications/rpcs with data items. If I want to reload a backup, I will look for the reload rpc in the backup branch of my model, not elsewhere.

3)      If we want RPCs with the same name (e.g. restart node, restart interface gracefully) but different parameters that cannot be done nicely today.

4)      For most of us YANG drives the CLI besides Netconf. In the CLI at the root of the model all rpcs will be available for the CLI user. So if the user calls help he will get a list of all rpcs. With more and more data models defined this results in dozens potentially hundreds of rpcs being listed. Unusable. If rpcs would be connected to the data nodes, then only a small number of relevant rpcs would be listed.

5)      All our(Ericsson's) internal model writers use and want rpcs connected to the data nodes.

AFAIK at least 3 separate implementations already use this feature. The same issue nearly made it into YANG 1.0, it was only dropped of because time pressure.

So for these reasons we need rpcs/notifications connected to data nodes.
Regards Balazs