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

Michael Rehder <Michael.Rehder@Amdocs.com> Wed, 17 October 2018 17:56 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 A7C65130EDD for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 10:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 n3AvpNbgTxEN for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 10:56:45 -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 8F8B61293FB for <netmod@ietf.org>; Wed, 17 Oct 2018 10:56:43 -0700 (PDT)
Received: from unknown (HELO ILHFDAGDRFE2.corp.amdocs.com) ([10.224.0.130]) by ilmail02.corp.amdocs.com with ESMTP; 17 Oct 2018 20:56:39 +0300
Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILHFDAGDRFE2 (10.237.240.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 17 Oct 2018 20:56:40 +0300
Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Wed, 17 Oct 2018 20:56:39 +0300
Received: from ILRNAEXCHEDGE02.corp.amdocs.com (10.233.34.168) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34 via Frontend Transport; Wed, 17 Oct 2018 20:56:39 +0300
Received: from EUR02-VE1-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_GCM_SHA384) id 15.1.845.34; Wed, 17 Oct 2018 20:56:39 +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=u93hDCr9ga/cwwYAExLEWX8MVN4UNMwpvHaGuTVlW18=; b=NQ1rMIpbnDcSWt2/SpbhQnWqQIT6euOZXQcOmvMs2x0zevEOhBEFhPwF5VQ4YxFRTpMD9eXKmKAe6JIyZpdEEpCDiYS+IAQFUwH6JjSDrqHFIVh3h7vP1jz4wGi/KKk0mjwXf9JJSeSXj2DXrSeGtwUKSK60vd7b7cXb+qG7WCo=
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com (52.133.58.152) by AM0PR06MB5155.eurprd06.prod.outlook.com (20.178.20.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.21; Wed, 17 Oct 2018 17:56:37 +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.027; Wed, 17 Oct 2018 17:56:37 +0000
From: Michael Rehder <Michael.Rehder@Amdocs.com>
To: Ladislav Lhotka <lhotka@nic.cz>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: "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+5AALiXBgAAuGd8AAAATuoAAPS9MgABQPKNgAF6DoYAABGoXEA==
Date: Wed, 17 Oct 2018 17:56:37 +0000
Message-ID: <AM0PR06MB4083997E335CBAA6FAA3B074E7FF0@AM0PR06MB4083.eurprd06.prod.outlook.com>
References: <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> <20181013211943.mpumhw5pflgq5tf3@anna.jacobs.jacobs-university.de> <AM0PR06MB4083C1601B887AEF73E616ADE7FE0@AM0PR06MB4083.eurprd06.prod.outlook.com> <87woqhhsk4.fsf@nic.cz>
In-Reply-To: <87woqhhsk4.fsf@nic.cz>
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; AM0PR06MB5155; 6:As1uwbO7Blo+u2Dr1SC7khBgkaihlhXf4JNrgglqKZZy5kmYCXiQmAtnhr6/2r03Z8K3846sveUZd5eJCPBpVuq++Fh2Mjq145wwRoYoK3iu2R0HZvJrotI4KYKtuqD2lF63DQyPHoO/dVZ0Dh7cfBM7r4qDZf50K3DqtLUK5OfCfV4i0BbFwA/A8/y/KIQQX3/XBW0S8PvtcFvZhadB6rJijBEFpjV1KS7ZZOEsiJ59fNmGDCJSXzTLg9WJ/pvx5Xn6tYPAkfnwDF+xJNkb310fm7op/rkIkS7q045v0wmlCbuaNMiLHrQXS+fUpccGu01PAsyQXPnSwDVxY5cWu7UdJtr99g2Pj0GMkC89SljM68cZ0HliMlqHNGcdnAGqWa+5CRDmDMUB0JUOENpZpdh66nHZmxdiTnwR7TVv2o0J0sOzOeLO+Hn6dxZMyaOKZdEPJgKvb/Nj+x2Gv49DjQ==; 5:AXbe3OWjD9kowTf3OM0GYUGdBhNQm9ICOWVbFSnb5LHC3ruFKAUCXF/W1EYnFVqL89mOF7TuHI8oBR7ohrF3d6mnUFxzJQM8c8aIvwlF4IK5gsnWeur9k+07KEnabjAm2eIUd4qo+VVrulbfXObVoUFd64v3+2QHz20WMScSXF0=; 7:An9n2CxervEXv7Gq1H8tcJF/Oa4gyBPZYNamRdag7ZxbzfOhl/FU8kp4GC500UZjoKUDqLiZE5i6mhB6j3Ffu+ylU44GRkxDQlTAAsNthxcZy2jTw1aNAMXkA8QVZYHHXMBCfjsL8TmK92cuKk8t//PiibpztJQ+yw8ER+br394Idl1fu5GcYnt60Lfb99AlJZbywrzW5b50vWZMdnGV+gSqzgLMC5kcGVXzS4ElNFd45i6YdeZjfGY9pFHcfC7o
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 7c8df2e7-f72f-4dd7-8c50-08d63459e28e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM0PR06MB5155;
x-ms-traffictypediagnostic: AM0PR06MB5155:
x-microsoft-antispam-prvs: <AM0PR06MB5155F07857E6066F79C07416E7FF0@AM0PR06MB5155.eurprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(131327999870524)(166566539817055);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:AM0PR06MB5155; BCL:0; PCL:0; RULEID:; SRVR:AM0PR06MB5155;
x-forefront-prvs: 08286A0BE2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(366004)(136003)(376002)(396003)(51444003)(189003)(199004)(13464003)(316002)(8676002)(93886005)(86362001)(114624004)(6436002)(2900100001)(72206003)(8936002)(81166006)(229853002)(6246003)(81156014)(25786009)(966005)(478600001)(74316002)(305945005)(7736002)(4326008)(6506007)(53546011)(71190400001)(71200400001)(76176011)(7696005)(68736007)(97736004)(110136005)(66066001)(99286004)(105586002)(14454004)(106356001)(26005)(186003)(33656002)(102836004)(5660300001)(2906002)(3846002)(256004)(5250100002)(446003)(11346002)(476003)(486006)(9686003)(55016002)(5024004)(14444005)(53936002)(6306002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR06MB5155; H:AM0PR06MB4083.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: Amdocs.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: JJf+SO9kZDYB0LIz9hNCLL0svOk4MwU0tRCOlnSJfyUf6DE575o5zHb7ijWz4gso+x1LOzCUjc/A8aXIxjklcEF1NkNZKC6VReZIT2d/fbOwmxgNHxTGQRFBeqDAwdOjwJC/qs6IFGa/gU+jn4XUy/KqnkkZOJKUhJH7f56xePjjT7ry3xYzatkPYSjiOSgFErdpkcKzblVycNnDpTGEnpZGVLG2uGSXWoDs4uSElB9/PZ6NOJ+cSupEnt47Dtb5omAwJoZubHqpPAltVg6Bo40hxT5uydF9uVMKJvgphWa7nPt5FFg/gp0MYwlve6pLiA1WOJ4BuQM6SNpD57QEqEghbkx7+ZMy0wKKTUpw0V8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c8df2e7-f72f-4dd7-8c50-08d63459e28e
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2018 17:56:37.6079 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB5155
X-OriginatorOrg: amdocs.com
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/IUNjofq842hVf5e_-PjBeK6AXoo>
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: Wed, 17 Oct 2018 17:56:48 -0000

That's exactly my point - I think that the wording is unclear in the RFC, that "conditional" doesn't necessarily mean the mandatory status is ignored.

BTW a Schematron rule is emitted to ensure a "mandatory true" CHOICE has at least one CASE present, so there already is an "existential" check built.

I'll suggest a YANG enhancement on "yang-next" for the ability to respect mandatory status or not by a when statement.

Thanks
mike
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Wednesday, October 17, 2018 4:43 AM
> To: Michael Rehder <Michael.Rehder@Amdocs.com>om>; Juergen Schoenwaelder
> <j.schoenwaelder@jacobs-university.de>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
> 
> Michael Rehder <Michael.Rehder@Amdocs.com> writes:
> 
> > I've read rfc6110 and I didn't see any mention of "WHEN" on the
> > mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't
> > list it which seems a bit odd to me).
> 
> RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is closely
> related to sec. 3.1 in 6020.
> 
> > The section on "WHEN" just mentions the xpath mapping, not anything
> > about changing the mandatory status of the enclosing node.
> 
> If you take into account the DSDL validation procedure (Figure 2 in RFC
> 6110) then everything is IMO clear:
> 
> - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in
>   <rng:optional> and thus are required during RELAX NG schema
>   validation, no matter what any "when" expression says.
> 
> - Section 12.17 explains how when expressions are mapped to Schematron
>   asserts. This means that if an instance node exists in the data and a
>   when expression attached to the corresponding data node in YANG
>   evaluates to false, Schematron will report a failed assert.
> 
> - Note that Schematron cannot by definition report absence of an
>   instance based on the when expression attached to its data
>   node: Schematron rules are only fired for elements that are present in
>   the instance document.
> 
> >
> > I still think that the YANG RFC wording of "conditional" needs to indicate if the
> node is mandatory status is affected or not.
> > Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it
> > does mention presence).
> 
> Perhaps this thread is just about misunderstanding of what "when" really
> means, which is: Instances for which the "when" expression evaluates to false
> must not be present.
> 
> It does NOT mean that instances for which the "when" expression evaluates to
> true must be present.
> 
> Lada
> 
> >
> > Thanks
> > Mike
> >> -----Original Message-----
> >> From: Juergen Schoenwaelder
> >> [mailto:j.schoenwaelder@jacobs-university.de]
> >> Sent: Saturday, October 13, 2018 5:20 PM
> >> To: Michael Rehder <Michael.Rehder@Amdocs.com>
> >> Cc: netmod@ietf.org
> >> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> >> ensure presence of the mandatory object
> >>
> >> On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder 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)
> >>
> >> Has the RNG and Schematron been obtained following RFC 6110? If so,
> >> this may be a problem with RFC 6110 but not with YANG itself. There
> >> are validators that do not use RNG or Schematron.
> >>
> >> /js
> >>
> >> --
> >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> > “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”.
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
“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”.