Re: [netmod] YANG 1.1 inline notifications

Martin Bjorklund <mbj@tail-f.com> Mon, 10 September 2018 18:46 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B16130F62 for <netmod@ietfa.amsl.com>; Mon, 10 Sep 2018 11:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 0EX1McFgaXOY for <netmod@ietfa.amsl.com>; Mon, 10 Sep 2018 11:46:52 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6F456130F5C for <netmod@ietf.org>; Mon, 10 Sep 2018 11:46:52 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 3DBAB1AE018A; Mon, 10 Sep 2018 20:46:51 +0200 (CEST)
Date: Mon, 10 Sep 2018 20:46:50 +0200
Message-Id: <20180910.204650.2304619132062701085.mbj@tail-f.com>
To: bart.bogaert@nokia.com
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <AM6PR07MB3942653D050C62F29675AF0B94020@AM6PR07MB3942.eurprd07.prod.outlook.com>
References: <AM6PR07MB3942653D050C62F29675AF0B94020@AM6PR07MB3942.eurprd07.prod.outlook.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/X6wsJoaqibBhJmf1T92SwgtWib0>
Subject: Re: [netmod] YANG 1.1 inline notifications
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 10 Sep 2018 18:47:04 -0000

"Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com> wrote:
> Hi,
> 
> I'm trying to seek some clarification.
> 
> According to RFC7950 section 7.16.2:
> When a notification node is defined as a child to a data node, the
> <notification> element defined in [RFC5277] contains a hierarchy of
> nodes that identifies the node in the datastore.
> 
> According to RFC6241 section 1.1:
> datastore: A conceptual place to store and access information. A
> datastore might be implemented, for example, using files, a
> database, flash memory locations, or combinations thereof
> 
> When combining these two, the "hierarchy of nodes that identifies the
> node in the datastore" actually refers to resources that do exist (at
> least that is how I understand this).
> 
> Now consider the following model.
> 
> container state-data {
>   config false;
>   list elements {
>     key name;
>     leaf name {
>       type string;
>     }
>     leaf status {
>       type enumeration {
>         enum up;
>         enum down;
>       }
>     }
>     notification inline-notification {
>       description
>         "An in-line notification";
> 
>         leaf result {
>           type string;
>           mandatory true;
>         }
>     }
>   }
> }
> 
> Can a device send the notification 'inline-notification' if the list
> /state-data/elements is empty?
> My feeling is that this should not be possible as there is no
> "hierarchy of nodes that identifies the node in the datastore", so
> against what would that notification be sent in such case?

Exactly.  The idea is that the notification is tied to some instance
in the data tree.  If no instances exist, there is nothing to tie the
notification to.  But this being operational state data there is
no guarantee that the instance still exists when the notification
arrives at the client.


/martin



> 
> Best regards, Bart