Re: [netconf] leafrefed data item in YANG Push

Martin Bjorklund <mbj@tail-f.com> Mon, 16 December 2019 08:33 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC9D1200F1 for <netconf@ietfa.amsl.com>; Mon, 16 Dec 2019 00:33:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 12fPXYPaXoV6 for <netconf@ietfa.amsl.com>; Mon, 16 Dec 2019 00:33:33 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8271200B5 for <netconf@ietf.org>; Mon, 16 Dec 2019 00:33:33 -0800 (PST)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id EEFC71AE02AA; Mon, 16 Dec 2019 09:33:28 +0100 (CET)
Date: Mon, 16 Dec 2019 09:32:53 +0100
Message-Id: <20191216.093253.1924268578146352097.mbj@tail-f.com>
To: bill.wu@huawei.com
Cc: jason.sterne@nokia.com, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAA94FA4E5@dggeml511-mbx.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABAA94FA4E5@dggeml511-mbx.china.huawei.com>
X-Mailer: Mew version 6.8 on Emacs 25.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Lp6yLP66XWxQPRghaRpYqJdXUtI>
Subject: Re: [netconf] leafrefed data item in YANG Push
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2019 08:33:35 -0000

Hi,

Qin Wu <bill.wu@huawei.com> wrote:
> Thanks Jason for clarification, 2 leafs associated with each other via
> leafref can be defined in the same module, can be defined in two
> separate modules (see example module below),
> I am wondering whether these two cases are treated by the server in
> the same way.

Yes they are, in the sense that a leafref is not treated different
than e.g. a string by the  YANG Push server.

> RFC8639 provides a dependency parameter to describe the relationship
> between two subscriptions, I am wondering whether this dependency
> parameter is designed to address
> the case where two leafs are associated with each other via leafref in
> two different modules.
>
> Take the below modules as an example,
> We may have two subscriptions, one subscription A is used to
> subscribed to leaf aa in module foo, the other subscription B is used
> to subscribed to leaf cc and bb in module bar. So the subscription A
> will use dependency parameter to indicate leaf bb is associated with
> leaf aa in subscription B, right?

No the dependency parameter is not used by a subscriber to "indicate"
(to whom?) that two leafs are associated.

> If the answer is no, what is the real case for dependency parameter
> defined in RFC8639?

From RFC 8639, section 2.3:

   If a subscription has the "dependency" parameter set, then any
   buffered notification messages containing event records selected by
   the parent subscription MUST be dequeued prior to the notification
   messages of the dependent subscription.

It it used to control the order in which the notifications are sent.


/martin



> 
> -Qin
> 发件人: Sterne, Jason (Nokia - CA/Ottawa)
> [mailto:jason.sterne@nokia.com]
> 发送时间: 2019年12月14日 3:20
> 收件人: Qin Wu <bill.wu@huawei.com>; netconf@ietf.org
> 主题: RE: leafrefed data item in YANG Push
> 
> Hi Qin,
> 
> For subscriptions, I don't think it matters if 2 leafs are associated
> with each other via a leafref.  When you subscribe to each of those
> leafs, it is just like subscribing to any other 2 leafs (that aren't
> associated with eachother).
> 
> About the 'dangling reference': that should be accepted into the
> running datastore. It would fail validation. So it can only exist in
> the candidate.
> 
> Jason
> 
> From: netconf
> <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> On Behalf
> Of Qin Wu
> Sent: Thursday, December 12, 2019 11:09 PM
> To: netconf@ietf.org<mailto:netconf@ietf.org>
> Subject: [netconf] leafrefed data item in YANG Push
> 
> Hello:
> Can I subscribe to specific data item that refer to data item in
> another YANG module with other data item in the same subscription?
> Module bar {
> import foo {prefix ex;}
>      leaf cc{type int8;}
>      leaf bb {
>        type leafref {
>          path "../ex:aa";
>        }
>      }
> }
> 
> Module foo {
>      leaf aa {
>        type int8;
>      }
> }
> In addition, If there is dangling reference, e.g., leaf bb refer to
> leaf aa which doesn’t exist, how this failure is handled by the server
> and exposed to the client?
> 
> -Qin