Re: [netmod] Clarification needed for YANG 1.1 XPATH context

Radek Krejčí <> Fri, 13 April 2018 11:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1CE7126C25; Fri, 13 Apr 2018 04:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.321
X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W5qpp-7W_DBp; Fri, 13 Apr 2018 04:51:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5A3E1242F7; Fri, 13 Apr 2018 04:51:48 -0700 (PDT)
Received: from (unknown [IPv6:2001:67c:1220:80c:d0:552c:73a5:18da]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 0CCAD40005D; Fri, 13 Apr 2018 13:51:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=office2; t=1523620306; bh=314jx+AL0VHMstP/RO9+0vnerVqPXn0MAkN1CPIp2aI=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=OGpv8Vz6NZYEPiKuLVmaL0qc/2clKbEP6JYWAu+Z1UklsdLxGaxGYX/YtZHe4jvsH nxJC3vVxwlN3ovkcMf+tkN/UIvFv4AuFhcsnQuucKKKOb/MAbXNjPTVpoXvVKdIq9w pkXCyZE+qtEgGyHZe8NOzZ1VFKHs0DWyjRdZRWcU=
To: Martin Bjorklund <>
Cc:, YANG Doctors <>, FRANK RIMPLER <>
References: <> <> <> <>
From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Fri, 13 Apr 2018 13:51:45 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <>
Subject: Re: [netmod] Clarification needed for YANG 1.1 XPATH context
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Apr 2018 11:51:52 -0000

I'm refreshing an old thread to clarify specific use case, see below...

Dne 25.2.2016 v 16:31 Martin Bjorklund napsal(a):
> William Ivory <> wrote:
>> -----Original Message-----
>> From: Martin Bjorklund [] 
>> Sent: 25 February 2016 15:17
>> To: William Ivory <>
>> Cc:
>> Subject: Re: [netmod] Clarification needed for YANG 1.1 XPATH context
>> William Ivory <> wrote:
>>> Hi,
>>> I'm looking for clarification on the meaning of the following 
>>> paragraph in section 6.4.1 (XPATH context) in RFC6020bis:
>>>    'If a node that exists in the accessible tree has a non-presence
>>>    container as a child, then the non-presence container also exists in
>>>    the tree.'
>>> It's unclear to me what this is trying to say, and why - for example, 
>>> does this mean that I need to validate any 'must' and 'when'
>>> statements on the child container even when nothing within that child 
>>> container is configured?
>> must expressions are always evaluated if the node where the must
>> expression is defined exists, regardless of the number of children
>> this node has.
>> [wivory] So in my example where the child container (non-presence) has
>> NO children, then it doesn't exist, and any must statement on it
>> should not be run.  Only when a non-presence container has a non-zero
>> number of children should any 'must' statements on that container be
>> run.
>> [wivory] If that's the case, then would it be correct to say that the
>> intention of this paragraph is as a reminder that one must evaluate
>> 'must' statements on nodes that have no inherent meaning and exist
>> only because they contain child nodes?
> No; section 7.5.3 says:
>    When a datastore is validated, all "must" constraints are
>    conceptually evaluated once for each node in the accessible tree (see
>    Section 6.4.1).
> And the quoted paragraph of 6.4.1 says that the NP-container
> (conceptually) exists if its parent exists - regardless of number of
> children.
> So if the parent exists, any must expressions in the NP-container are
> evaluated.

what about top-level NP-container with must constraint? Is a root node something which is always present in accessible tree (even in an empty tree)? Intuitively, I believe that it is, so even constraints on top-level NP-containers are supposed to be evaluated, but I cannot find something about it in RFC.