Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

Andy Bierman <andy@yumaworks.com> Fri, 12 October 2018 16:29 UTC

Return-Path: <andy@yumaworks.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 3B586130E4D for <netmod@ietfa.amsl.com>; Fri, 12 Oct 2018 09:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 sMM-D7jhMM8A for <netmod@ietfa.amsl.com>; Fri, 12 Oct 2018 09:29:10 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D867130E3A for <netmod@ietf.org>; Fri, 12 Oct 2018 09:29:09 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id r191-v6so9766952lff.2 for <netmod@ietf.org>; Fri, 12 Oct 2018 09:29:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=15xrYkUKx640kFiVSRvEiRqnUoPFXDqWLZQWQf0jqLg=; b=Eve/Houtd19d0KBcR/LqyIpGS7LH91pgcpWLLPdpwCqJzx1q20Pa3NH9vTZedCHPMC iykuCYaHE8/6GGEKPBDerhEkoMo5Sa1G+T4Ufkk72F1/YYVUi8la7ZC6j4whpFVIosYL HpChy+4zzb+NQtDMU063GEDfKEzHrvaA0wZmR3+yB5QOqPlJKaflRM6rsweQxngYK2Me s7WDCsPPvgM7ceE+xN8fjr4Rj4xZ1NXoDlGcGqM1DJpZfZG/BwWLKQ6NaoS5eTztbsz3 /jUYToTFFn3xLYrF/oXtRcM4Oy2y2+A/ytwET4q3ZokyGPuwk5CT+99s6HDf1kljIlDo 9VkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=15xrYkUKx640kFiVSRvEiRqnUoPFXDqWLZQWQf0jqLg=; b=HtBDwRfYeldno/+TGtZIvzPiqqkcGew9eBC7LPa+UpjYFftxP0YnES20n17SquhPWI nyMNkyVMI/qRY4wRw0hqJIHIafVOGmFxr7bDKZYQn2kfdm+HylF1Xmlp4emdAr/Vt5Y3 esMJNyvPQKPpNEakGVLHqGWI9YRsXSZhl76TlAI4qEUH3NnsssstajrPCMVSIS9OVKgI xDn9Hf3vAY8zw/zUX72+Cr/Qq5igOIMKbU7+BdDmnq+n4ARS6BpVngXS7VWxi8woUpoT hD6Ag9W4aUBBjYU6LQGZsdbs/fikQjUUz82B+j+572fTcGs29DEeKtEuU/FwBf0B9a9O 2Xrw==
X-Gm-Message-State: ABuFfoiHYivtUnMqxS01Y6WvParvxxFUxpfJOiIFcL+kW0uweptCM6HO 9irZVjW0y8zsaOgLM3kprLQjBOU+LduICRgLueY0Mdf5
X-Google-Smtp-Source: ACcGV63AXU3xG/qUDPlCAHAzX+pePgzcvH/9VA+MZuzbBMpTZx+Lnk4mn33xZlZFT3X5A1qMFC+zXK82KD2o2kp87Tg=
X-Received: by 2002:a19:f00a:: with SMTP id p10-v6mr4201883lfc.43.1539361747312; Fri, 12 Oct 2018 09:29:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Fri, 12 Oct 2018 09:29:06 -0700 (PDT)
In-Reply-To: <AM0PR06MB40839FD87E10433E10B4377CE7E20@AM0PR06MB4083.eurprd06.prod.outlook.com>
References: <AM0PR06MB4083426FA0F1D3F6515F2ECFE7E70@AM0PR06MB4083.eurprd06.prod.outlook.com> <87zhvlvpts.fsf@nic.cz> <AM0PR06MB40833D8AED0744BB597394E7E7E00@AM0PR06MB4083.eurprd06.prod.outlook.com> <d322e012-2767-a045-767a-ddf57649f36e@cisco.com> <AM0PR06MB4083B172F2424F1EEF08CFA0E7E00@AM0PR06MB4083.eurprd06.prod.outlook.com> <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de> <AM0PR06MB4083AB058834759ECEA3FEEEE7E00@AM0PR06MB4083.eurprd06.prod.outlook.com> <CABCOCHQKz-S2jcqeoJCtuG9U0DxOOw4musJz4DzwEtbCrEjqYA@mail.gmail.com> <DB6PR06MB4085D91F66023AC98122FEDFE7E10@DB6PR06MB4085.eurprd06.prod.outlook.com> <CABCOCHRR92w3ouFmi6igg+AN=TM7BKfnaMiweOPxq_t9WTvvyg@mail.gmail.com> <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com> <AM0PR06MB40839FD87E10433E10B4377CE7E20@AM0PR06MB4083.eurprd06.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 12 Oct 2018 09:29:06 -0700
Message-ID: <CABCOCHTtgCHzNpLA0qOhQ31hW0cvBx_XOQVLG8hQkNHZAhkaGw@mail.gmail.com>
To: Michael Rehder <Michael.Rehder@amdocs.com>
Cc: Robert Wilton <rwilton@cisco.com>, "Walker, Jason (Jason_Walker2@comcast.com)" <Jason_Walker2@comcast.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000213acd05780a9603"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/_0UB20-wrX8So6ZCNX2gsk0FV64>
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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, 12 Oct 2018 16:29:12 -0000

On Fri, Oct 12, 2018 at 9:08 AM, Michael Rehder <Michael.Rehder@amdocs.com>
wrote:

> The mandatory statement in that case is ignored (I’ve pointed out the RNG
> and Schematron lack of enforcement).
>
> WHEN trumps the mandatory status (via explicit mandatory or implicit
> mandatory via min-elements 1)
>
>
>


Implementation of the when-stmt is complicated, especially if the server is
expected to be fast.
RFC 7950 has many more details than RFC 6020 about implementation of this
statement,
but it is still difficult.

The schema dictates what can be in the instance documents. The when-stmt
modifies the
schema based on what is in the instance document.  Even the default value
goes away if the
when-stmt is false (as it should). I would be very surprised if static
document validation tools could handle that.

YANG validation is already heavyweight and complex to implement.
Allowing designers to pick and choose when which constraints are active,
would make much more complex.



> Thanks
>
> Mike
>

Andy


>
>
> *From:* Robert Wilton [mailto:rwilton@cisco.com]
> *Sent:* Friday, October 12, 2018 12:06 PM
> *To:* Michael Rehder <Michael.Rehder@Amdocs.com>
> *Cc:* Andy Bierman <andy@yumaworks.com>; Walker, Jason (
> Jason_Walker2@comcast.com) <Jason_Walker2@comcast.com>; netmod@ietf.org
> *Subject:* Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
>
>
> Hi Mike,
>
>
>
> On 11/10/2018 19:05, Andy Bierman wrote:
>
>
>
>
>
> On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder <
> Michael.Rehder@amdocs.com> wrote:
>
> I think the wording is relevant - something can be conditional but still
> required.
>
> Yes, but I think that this is already expressed by a node that has both a
> when condition and mandatory statement.
>
>
> container a {
>
>   container x {
>
>     when "some condition";
>
>     leaf foo {
>
>       mandatory true;
>
>     }
>
>     leaf bar {
>
>       ...
>
>     }
>
>   }
>
>   container y {
>
>     leaf baz {
>
>       mandatory true;
>
>     }
>
>     leaf tee {
>
>       ...
>
>     }
>
>   }
>
> }
>
>
>
> a/x/foo is conditional (due to when) but required (if the when condition is met).
>
> a/x/bar is conditional (due to when) but optional (if the when condition is met).
>
> a/y/baz is unconditional but required.
>
> a/y/tee is unconditional but optional.
>
>
>
>
>
> It should be clarified that elements become implicitly “mandatory false”
> when a “when” statement is used.
>
> But they don't.
>
>
>
>
> I would like to see an enhancement to YANG to control this behavior, to
> allow the mandatory status to be enforced.
>
> That is, support also “conditionally required” instead of only the current
> “conditionally optional”.
>
> I'm trying to understand what this would even mean.
>
> Taking your original example, but with "enforce-mandatory-status":
>
>          leaf AssignmentMechanism {
>
>             type enumeration {
>
>               enum "DHCP";
>
>               enum "Static";
>
>             }
>
>             mandatory true;
>
>             description "The address assignment mechanism.";
>
>           }
>
>           list IPAddresses {
>
>             when "../AssignmentMechanism = 'Static'" {
>
>               enforce-mandatory-status;
>
>             }  key Address;
>
>             min-elements 1;
>
>
>
>             leaf Address {
>
>               type capit:IPv4Address;
>
>               description "An ipv4 address.";
>
>             }
>
>            }
>
>
> So this means that list IPaddresses must have at least one element
> regardless of whether the when condition holds.  I.e. no matter whether the
> assignment is DHCP or Static there must always be at least one 1 address
> configured.  But I don't understand what this actually means - it seems
> like a contradiction.  What am I missing?  Please can you give a concrete
> example (in YANG) of what behaviour you are looking for.
>
> Thanks,
> Rob
>
> *“Amdocs’ email platform is based on a third-party, worldwide, cloud-based
> system. Any emails sent to Amdocs will be processed and stored using such
> system and are accessible by third party providers of such system on a
> limited basis. Your sending of emails to Amdocs evidences your consent to
> the use of such system and such processing, storing and access”.*
>