Re: [netmod] ?==?utf-8?q? [Netconf] YANG library bis model

Michal Vaško <mvasko@cesnet.cz> Fri, 26 January 2018 10:05 UTC

Return-Path: <mvasko@cesnet.cz>
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 7BBDB12D9FE; Fri, 26 Jan 2018 02:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
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 rpjtVDOWdCgq; Fri, 26 Jan 2018 02:05:39 -0800 (PST)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A2012D849; Fri, 26 Jan 2018 02:05:18 -0800 (PST)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 34461602F5; Fri, 26 Jan 2018 11:05:16 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1516961116; bh=Wz6fYuvGKhw5o1uS7fwMPLF+//+A3XQIUTD2rk5u+V4=; h=In-Reply-To:From:Date:Cc:To:Subject; b=D3i/FKRbT8Rt2gzP4pfWjNTR+XBkwNy8yjJwLF9wizNX/sbmB5HiLGspEFAgdYiIv 5KzObnMvrUY/pxWDqvLLL/bimoLFm732qhiCac9NbLD2EW+hKRYM+JO1oq7o8obryk lqhgaHwokxQhNULBFfN439OgJ6SwC2NFronktjLA=
Content-Type: text/plain; charset="utf-8"
In-Reply-To: <14c97065-5e5b-2670-6b7b-ee1eb01a8fa1@cisco.com>
From: Michal Vaško <mvasko@cesnet.cz>
X-Forward: 2001:67c:1220:80c:f5:8e35:ef0e:146c
Date: Fri, 26 Jan 2018 11:05:16 +0100
Cc: netmod <netmod@ietf.org>, netconf@ietf.org
To: Robert Wilton <rwilton@cisco.com>
MIME-Version: 1.0
Message-ID: <1ed4-5a6afd80-13-59123580@152590790>
User-Agent: SOGoMail 2.3.23
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/j8PaG9Xsw119qaFZloOji3l5S8Y>
Subject: Re: [netmod] ?==?utf-8?q? [Netconf] YANG library bis model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 26 Jan 2018 10:05:47 -0000

Hi Rob,

I have forgotten to mention that I have fixed it by modifying the leafref path the exact same way you proposed, it works fine that way.

Regards,
Michal

On Friday, January 26, 2018 10:55 CET, Robert Wilton <rwilton@cisco.com> wrote: 
 
> Hi Michal,
> 
> Thanks for raising this.
> 
> On 26/01/2018 09:14, Michal Vaško wrote:
> > Hello,
> >
> > we have tried implementing the YANG module ietf-yang-library@2018-01-17.yang from draft-ietf-netconf-rfc7895 and have encountered a problem. I am not completely certain that the issue is with the model and not our XPath evaluator, but based on the definitions I have found I believe the model is wrong.
> >
> >     module: ietf-yang-library
> >       +--ro yang-library
> >          +--ro module-set* [name]
> >             +--ro module* [name]
> >                +--ro name         yang:yang-identifier
> >                +--ro deviation* [module]
> >                   +--ro module    -> ../../name
> >
> > In the tree diagram (I have removed irrelevant parts) it can be seen that there is a "deviation" leafref that should point from one "module" list instance to another identifying the deviation module. So, the supposed evaluation should take the following steps: we start with leaf "module" we take ".." path so we get the "deviation" list. Then we take another ".." and we end up with all the "module" list instances. Finally, we try to find "name" leaf in all these instances of the "module" list.
> >
> > However, our evaluator and some I have found online (all behaving according to XPath definition, I think) proceed differently. At the point of going one step up (parent node) into what es expected to be all the "module" list instances, the context node actually becomes only the *specific module list instance* we have started from, so when looking for the "name" leaf only the name of this list instance is taken into consideration. Needless to say, the evaluation never finds a matching "name" leaf because "module/name" and "module/deviation/module" should never match in one "module" list instance and so the validation always fails.
> It looks like the leafref should be "../../../module/name".
> 
> Does that fix the issue for you?
> 
> Thanks,
> Rob
> 
> 
> > Kind regards,
> > Michal Vasko
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> > .
> >
>