[netmod] YANG library bis model

Michal Vaško <mvasko@cesnet.cz> Fri, 26 January 2018 09:14 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 5238412DB6E; Fri, 26 Jan 2018 01:14:46 -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 hpOs23ZpqCyX; Fri, 26 Jan 2018 01:14:43 -0800 (PST)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E982712D95F; Fri, 26 Jan 2018 01:14:42 -0800 (PST)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 21D06602F5; Fri, 26 Jan 2018 10:14:40 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1516958080; bh=1nWFXsE/Dpu+VkPFmfxDm6/x1wdxmwYLQMxttC9901o=; h=To:Date:Subject:From; b=yiZV8z+Ogzm09Hl0YuUYXEHI6sZOfnPffrTTSXCUSKrIx4EDfLAi6Xd5AhLu4FfKK BtGRKa7UyJ3P1UTQaSXpIEWDT7AXACRuRzuuwKB5I80FpO+at///MsMRlLQndR4qfU 4HIejgfnb/d5BHxMTp+p44iRqUkzcK4n5pmPioIw=
Content-Type: text/plain; charset="utf-8"
To: netmod <netmod@ietf.org>, netconf@ietf.org
User-Agent: SOGoMail 2.3.23
MIME-Version: 1.0
Date: Fri, 26 Jan 2018 10:14:40 +0100
Message-ID: <4f1c-5a6af180-b-5fc7eb00@241510494>
X-Forward: 2001:67c:1220:80c:f5:8e35:ef0e:146c
From: Michal Vaško <mvasko@cesnet.cz>
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/wEfwfW4GyqpH4HTncZVnzBHk1qs>
Subject: [netmod] 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 09:14:46 -0000

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.

Kind regards,
Michal Vasko