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

Michael Rehder <Michael.Rehder@Amdocs.com> Fri, 12 October 2018 16:08 UTC

Return-Path: <Michael.Rehder@amdocs.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 77B42130E4D for <netmod@ietfa.amsl.com>; Fri, 12 Oct 2018 09:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.779
X-Spam-Level:
X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=amdocs.onmicrosoft.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 1nMZx4IWdcTp for <netmod@ietfa.amsl.com>; Fri, 12 Oct 2018 09:08:55 -0700 (PDT)
Received: from mx3.amdocs.com (ramail2.amdocs.com [193.43.244.136]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C26E130E2F for <netmod@ietf.org>; Fri, 12 Oct 2018 09:08:53 -0700 (PDT)
Received: from unknown (HELO ILHFDAGDRFE1.corp.amdocs.com) ([10.224.0.130]) by ilmail02.corp.amdocs.com with ESMTP; 12 Oct 2018 19:08:51 +0300
Received: from ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) by ILHFDAGDRFE1 (10.237.240.44) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 12 Oct 2018 19:08:51 +0300
Received: from ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) by ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Fri, 12 Oct 2018 19:08:50 +0300
Received: from ILRNAEXCHEDGE02.corp.amdocs.com (10.233.34.168) by ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34 via Frontend Transport; Fri, 12 Oct 2018 19:08:50 +0300
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (192.168.34.8) by msgedge.amdocs.com (192.168.34.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Fri, 12 Oct 2018 19:08:50 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Amdocs.onmicrosoft.com; s=selector1-amdocs-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tqC+SkVYSxmcUssMKFMrDcRz7aHxmjnj4gikOFU4He0=; b=eXLVwquwSNgdTNRMtoyl4SDoe+FrpoUF4T2hNaPuxVnoR0Mo8xL1SDlYTEDycxnLeQlE2ISOpH2xwi33sZoeTGNlbBqiCsCUxP7U8x1Ln9oRaZ7Pqqa7HZbiWtcw8AlX6s98DmQcdMPCmxp1pkPiUhGh9hN+NScB0tIK6hflP84=
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com (52.133.58.152) by AM0PR06MB5058.eurprd06.prod.outlook.com (20.178.19.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.27; Fri, 12 Oct 2018 16:08:48 +0000
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1]) by AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1%5]) with mapi id 15.20.1228.020; Fri, 12 Oct 2018 16:08:48 +0000
From: Michael Rehder <Michael.Rehder@Amdocs.com>
To: Robert Wilton <rwilton@cisco.com>
CC: Andy Bierman <andy@yumaworks.com>, "Walker, Jason (Jason_Walker2@comcast.com)" <Jason_Walker2@comcast.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
Thread-Index: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSAArOyOAAAESuDAAATBXgAAAIxIgAAXi54AAAG/FwAAAei6AAAKI+5AALiXBgAAuGd8AAAATuoA=
Date: Fri, 12 Oct 2018 16:08:48 +0000
Message-ID: <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>
In-Reply-To: <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Rehder@Amdocs.com;
x-originating-ip: [192.95.160.116]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR06MB5058; 6:FCrIzZmn8e9Jn2JPkbIdUahzFy++xTHj04tvUpOvIQKHxTf5EJByY/xECAcNJq05GcObk05ryQDwOlTe8lDi9JfRaColt3WMcFU2gGUudgEvUT745Z6t3iXIsPi3pjOmGVnjdTyiQKSy5CZ/eh3fhUwWrmoHH4c1K13ykONE0utgFatjdURWgSIuewr4+74RpwHO4sRDE0RCC8SfUn7o+Z5/XfH27MbDEdccoZ7V4lXRKD9biJgMUA4vLNCBOe2kHIpqbPtA3E9bohV6v4T10cmwDdc1X6rXRRPtcGv1LADZlgfGguEbkmkMY4F/3S5wANlRnLnMNtBTch40whQaapRAhNbkWDhoPF+lKIHro4nVjzkUmrb7lEiI6JvXrhLAwLPsw5nd2WGNHaAxnRQYvlG6NQ0srbHp8GZGaI4hltPVDDZ0Wgjb/ZkzrdHDHoc4O/uKNIoYhupggCcMsGYRDw==; 5:B5WGBupEVLITcZM/NrUqRULpiDUC89Xc/BtIaMniniPctWOKE1lct++7bUnSPP8bOoN1rybqoCW7qxtojLDlUiJ7wC1Qz18/yuvViiwGST4sRDXvwzo+yfSaBNOq3qylgMmrXLAifmF/noDFCacomyPds/E7BSJLytWpkk8GUPs=; 7:hk6OFnp8yHXmR377/uNfmjGCQdJNqTuWI4sl1CC1A8yjejgUIJmFfWwC1O0UmHnA7io1PmJtPh/ZPO6zl/9X4U06s+ZTSnu4RSV/i8MLPtjCN0qF4sPi/HIwC67SNuDk7e3buqZSNpKJG7nz8S6CJtf1+hs7BBKQlep5SBmjlBjp+PJ/ZQDNDNXBP7Kb+IesuahClnyUQt9qxKUEMNSQZJk/PVt5vyrrIOIipNoD85fN8/qDCnotIzwCGIcYT2mY
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: ab20aad6-96b7-4bf4-b839-08d6305cfea3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM0PR06MB5058;
x-ms-traffictypediagnostic: AM0PR06MB5058:
x-microsoft-antispam-prvs: <AM0PR06MB505846E8F2F84F9137854CF6E7E20@AM0PR06MB5058.eurprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(95692535739014)(166566539817055)(62221491112393)(131327999870524)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231355)(944501410)(52105095)(93006095)(93001095)(3002001)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:AM0PR06MB5058; BCL:0; PCL:0; RULEID:; SRVR:AM0PR06MB5058;
x-forefront-prvs: 0823A5777B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(376002)(346002)(136003)(366004)(199004)(189003)(51444003)(7696005)(55016002)(76176011)(53936002)(236005)(9686003)(53546011)(54896002)(11346002)(486006)(5660300001)(6506007)(446003)(33656002)(6306002)(2900100001)(2906002)(99286004)(66066001)(14454004)(54906003)(106356001)(476003)(105586002)(26005)(102836004)(25786009)(4326008)(186003)(6436002)(8936002)(229853002)(72206003)(478600001)(97736004)(6246003)(5250100002)(8676002)(81166006)(81156014)(6916009)(86362001)(7736002)(3846002)(6116002)(74316002)(316002)(71200400001)(68736007)(71190400001)(93886005)(256004)(790700001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR06MB5058; H:AM0PR06MB4083.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: Amdocs.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: OvJaxplcoaViU0Bqm16dVrHY2IoK2es5x+g97H/sIUVdsqwzX62okTjv3aWvkaxPG7/W82qaO/GiQoqy2dMHQkBlRLkLVvr8ByKycGZGy/MphDaPiAnp7wjuiME6H8ECW3gUM6ybvFBrnSywep+7/1XqC7+5ZgvPuepMrWMLBudhSb5TtPJt4YfF0I2mCmhoizQ74SyUlsDvhwD7ydKnVdmgPGmbPlL9eX+RXldlQMv+HwbLtu4K3Agi9jTmWzH7A9bDgR4bPYlr2Y/iJhhBltSN9wRP9sC0je3XA8RKBd6a/tAFbFvgsgv6ZFk1mO5+cLr338pm9nTuxMa/dKaycxQjAzQXHniwQNy0l87JxRk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM0PR06MB40839FD87E10433E10B4377CE7E20AM0PR06MB4083eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ab20aad6-96b7-4bf4-b839-08d6305cfea3
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2018 16:08:48.5269 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB5058
X-OriginatorOrg: amdocs.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/xbiNAEPdIH83YG_FfjIdkIwzu6g>
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:08:58 -0000

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)

Thanks
Mike

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<mailto: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”.