Re: [netmod] The when-choice loop

Ladislav Lhotka <lhotka@nic.cz> Thu, 15 October 2015 12:53 UTC

Return-Path: <lhotka@nic.cz>
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 C798A1B3145 for <netmod@ietfa.amsl.com>; Thu, 15 Oct 2015 05:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level:
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 qSCaRNeyOw_D for <netmod@ietfa.amsl.com>; Thu, 15 Oct 2015 05:53:25 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C5CC1B3147 for <netmod@ietf.org>; Thu, 15 Oct 2015 05:53:25 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:4595:7241:573a:b276] (unknown [IPv6:2001:718:1a02:1:4595:7241:573a:b276]) by mail.nic.cz (Postfix) with ESMTPSA id 12FC2181907; Thu, 15 Oct 2015 14:53:24 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1444913604; bh=jPukZHuMCNeor6/7Q1cLbFE96Ejdxu2+aTl5fbTSg2Y=; h=From:Date:To; b=MzETHcLnQOwXRiSN1SswpG0UzfT6sPw8mK37k/tT2id1Ee+f6iCBPyRCJGrHiT0p3 aeiIN1mcoa5x19bYhxc7hlpppzOzJYTJyAFryB62X8HzR5QBHgc8OcLhzZXNr1lPaj 7YvWWwz0nQll3Oi0WF3SqTmh6zTZuztVc0GpzShI=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <561F9509.4060008@ericsson.com>
Date: Thu, 15 Oct 2015 14:53:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <573D0C59-1801-422C-AB66-63FB63E2B9EA@nic.cz>
References: <561F9509.4060008@ericsson.com>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
X-Mailer: Apple Mail (2.3094)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/QmlgnsGtuEBuE4k68E_EnQR6m1E>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] The when-choice loop
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, 15 Oct 2015 12:53:28 -0000

Hi Balazs,

one lesson taken from early XML schema languages (DTD) was that modifying the validated document during validation easily leads to nasty race conditions. That's why RELAX NG avoids changing the XML infoset like plague.

I've already got tired reiterating (and providing examples) that "when" statement is inherently broken - the schema should not depend on evaluating arbitrary expressions in the context of an instance document that is supposed to be validated with the schema. The standard disclaimer is that it works for simple cases, and more complicated corner cases are "garbage in - garbage out".

Lada

P.S. Note that XPath expressions like "not(../a2)" evaluate to false if ../a2 exists, even if its content is "false". So you'd need expressions like "not(../a2 = 'true')".

> On 15 Oct 2015, at 13:59, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
> 
> Hello,
> In RFC6020bis we write:
> "There MUST NOT be any circular dependencies in these "when" expressions."
> How about a circular when-choice loop?
> 
>        leaf a1 {
>            type boolean;
>            when not(../a2);
>        }
>        choice c2 {
>            default case2;
>            case case1 {
>                when not(a1);
>                leaf b1 {type int8;}
>            }
>            case case2 {
>                leaf a2 {
>                    type boolean;
>                    default true;
>                }
>            }
>        }
> 
> Initial state: a1=false, b1=5;
> - Set a1=true
> - case1 and b1 disapears
> - case2 and a2=false are set as default
> - a1 disappears
> - if there is no a1 why did we delete case1/b1?
> Did I miss something, is this really what happens?
> 
> Even if someone can come up with the correct solution, operators will be 100% sure to mess this up. Usability=0 !!!
> 
> I want some of this multistep when/when, choice/choice, when/choice scenarios prohibited in RFC 6020 or 6087. Or state in 6020 that the order of evaluation is implementation dependent: that would make it unusable, so practically prohibiting then while maintaining backward compatibility :-)
> 
> I attached an even more complicated example, so go ahead have fun understand it!
> regards Balazs
> 
> PS: Why did we make YANG so complicated?
> 
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
> 
> <choice-when-interaction.yang>_______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C