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

William Ivory <wivory@Brocade.com> Thu, 25 February 2016 15:51 UTC

Return-Path: <wivory@Brocade.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69B61B2B32 for <netmod@ietfa.amsl.com>; Thu, 25 Feb 2016 07:51:05 -0800 (PST)
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
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 XHyapLBpVIah for <netmod@ietfa.amsl.com>; Thu, 25 Feb 2016 07:51:04 -0800 (PST)
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9A61B2B07 for <netmod@ietf.org>; Thu, 25 Feb 2016 07:51:03 -0800 (PST)
Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1PFja7L004928; Thu, 25 Feb 2016 07:50:58 -0800
Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 219mk4jprr-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Feb 2016 07:50:58 -0800
Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 25 Feb 2016 08:50:54 -0700
Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 25 Feb 2016 16:50:51 +0100
Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1104.000; Thu, 25 Feb 2016 16:50:51 +0100
From: William Ivory <wivory@Brocade.com>
To: Martin Bjorklund <mbj@tail-f.com>
Thread-Topic: [netmod] Clarification needed for YANG 1.1 XPATH context
Thread-Index: AdFv3R4BwHXZzI6xSlm06BqlW0gmXv//9CSA///uanCAABWHgP//6upg
Date: Thu, 25 Feb 2016 15:50:23 +0000
Deferred-Delivery: Thu, 25 Feb 2016 15:50:07 +0000
Message-ID: <304314aebb204bea8aa2e99aeed10b97@EMEAWP-EXMB12.corp.brocade.com>
References: <f790c7e329684d78bec27a1bfe150d6c@EMEAWP-EXMB12.corp.brocade.com> <20160225.161659.2204602310947308417.mbj@tail-f.com> <cac18b6591244715b79376188fa4c3fe@EMEAWP-EXMB12.corp.brocade.com> <20160225.163105.511576225570588684.mbj@tail-f.com>
In-Reply-To: <20160225.163105.511576225570588684.mbj@tail-f.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.212.156]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-25_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602250217
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Gu5X3sHVOE-15KYbLX_FxrHj4R0>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Clarification needed for YANG 1.1 XPATH context
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 25 Feb 2016 15:51:05 -0000


-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] 
Sent: 25 February 2016 15:31
To: William Ivory <wivory@Brocade.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] Clarification needed for YANG 1.1 XPATH context

William Ivory <wivory@Brocade.com> wrote:
> 
> 
> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: 25 February 2016 15:17
> To: William Ivory <wivory@Brocade.com>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Clarification needed for YANG 1.1 XPATH context
> 
> William Ivory <wivory@Brocade.com> 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.

[wivory] Is the intended use case top-level containers (directly under the root node) where you might wish to enforce that at least one such container existed?  In that case there would be no higher level node (as you can't add when/must to root) on which you could attach the 'must'.  At any other level in the tree you would always be able to attach the 'must' at a higher level.  Or am I missing some use case(s)?

Thanks,

William


/martin