Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

Martin Bjorklund <mbj@tail-f.com> Tue, 23 August 2016 10:47 UTC

Return-Path: <mbj@tail-f.com>
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 5848812D92E for <netmod@ietfa.amsl.com>; Tue, 23 Aug 2016 03:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 uAPrZfe0-vkF for <netmod@ietfa.amsl.com>; Tue, 23 Aug 2016 03:47:37 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E9EE212D920 for <netmod@ietf.org>; Tue, 23 Aug 2016 03:47:36 -0700 (PDT)
Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 9EFAF1AE018C; Tue, 23 Aug 2016 12:47:32 +0200 (CEST)
Date: Tue, 23 Aug 2016 12:46:40 +0200
Message-Id: <20160823.124640.1502573929755855289.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <C5A2A165-CA74-4548-AED4-72A0162A779F@nic.cz>
References: <57BC0A70.1080006@transpacket.com> <20160823.110924.2249827059453254780.mbj@tail-f.com> <C5A2A165-CA74-4548-AED4-72A0162A779F@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/EEn7fZprUegobG9Exd8tMBDwjMQ>
Cc: netmod@ietf.org
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 23 Aug 2016 10:47:38 -0000

Ladislav Lhotka <lhotka@nic.cz> wrote:
> 
> > On 23 Aug 2016, at 11:09, Martin Bjorklund <mbj@tail-f.com> wrote:
> > 
> > Vladimir Vassilev <vladimir@transpacket.com> wrote:
> >> On 08/23/2016 10:15 AM, Martin Bjorklund wrote:
> >>> They are evaluated.  See Section 7.5.3:
> >>> 
> >>>    When a datastore is validated, all "must" constraints are
> >>>    conceptually evaluated once for each node in the accessible tree (see
> >>>    Section 6.4.1).
> >>> 
> >>> 
> >>> /martin
> >> Then we have the case I objected to and the example:
> >> 
> >> YANG 1.0:
> >> 
> >> augment "/if:interfaces/if:interface" {
> >>    container inet {
> >>        must "../name = 'me0'" {
> > 
> > This should have been a 'when' expression, not 'must'.  Alternatively,
> 
> An interesting case would be if there is the "when" statement as you
> suggest, and then also one or more "must" statements. IMO, in this
> case the "when" statement needs to be evaluated first using the
> procedure of sec. 7.21.5, and if (and only if) the result is true,
> then the "must" statements are evaluated.

Exactly.  This is no different from any other node w/ both 'when' and
'must' (or 'mandatory', or 'min-elements')


/martin

> Again, an NP-container is no
> different from a leaf with a default value.




> 
> Lada
> 
> > it should have been a P-container, since obviously the container has
> > some semantics.  Or alternatively, the must expression should have
> > been on the address leaf, since this is what you really checked.
> > 
> > 
> > 
> > /martin
> > 
> > 
> >>            description
> >>                 "The inet container is only valid for the management
> >>                 ('me0')
> >>                 interface.";
> >>        }
> >>        leaf address {
> >>            type inet:ip-prefix;
> >>        }
> >>    }
> >> }
> >> 
> >> YANG 1.1 (replace "../name = 'me0'" with "../name='me0' or not
> >> (./address)" and process 95 unnecessary Xpath evaluations).
> >> 
> >> I think this proves the argument that there will be more unnecessary
> >> Xpath processing.  In addition it illustrates how a simple task
> >> requires ugly patch (the ".. or not (./address)" added to the must
> >> expression) just to ensure the expression does not fail in the default
> >> case where the interface is not named "me0" and the user has not even
> >> attempted to create empty /interfaces/interface/inet container in YANG
> >> 1.1.
> >> 
> >> Vladimir
> >> 
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
>