Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
Michael Rehder <Michael.Rehder@Amdocs.com> Tue, 16 October 2018 15:35 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 7F1B4130DE9 for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 08:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.69
X-Spam-Level:
X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 Iu-GATYSQySm for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 08:35:04 -0700 (PDT)
Received: from mx1.amdocs.com (ramail1.amdocs.com [193.43.244.133]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9277130DC5 for <netmod@ietf.org>; Tue, 16 Oct 2018 08:35:02 -0700 (PDT)
Received: from unknown (HELO ILHFDAGDRFE1.corp.amdocs.com) ([10.224.0.130]) by ilmail01.corp.amdocs.com with ESMTP; 16 Oct 2018 18:34:53 +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; Tue, 16 Oct 2018 18:34:53 +0300
Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) 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; Tue, 16 Oct 2018 18:34:52 +0300
Received: from ILRNAEXCHEDGE01.corp.amdocs.com (10.233.34.167) 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; Tue, 16 Oct 2018 18:34:52 +0300
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (192.168.34.8) by msgedge.amdocs.com (192.168.34.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.845.34; Tue, 16 Oct 2018 18:34:52 +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=SVnE81UVrLxbfGP+6pgZLhAPx5mmTjunYySXbdF+t4s=; b=OegBi0k0DrvF5UzeRZBFsbXEwUsb6uN9vAmfeKbWHAkQ0CkC6e5Hjj69bDFOKv0Bu8jZ1zGlVKU/eH+86hc1hklet9jN5Qvvcg4Q+ba/b+B4fv5tvYc0JEiEUvLVXSv7TJpso0wGWM8vn/m5SmimvcADwIqDSX8MsDBlwtocxhM=
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com (52.133.58.152) by AM0PR06MB4324.eurprd06.prod.outlook.com (52.135.150.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.26; Tue, 16 Oct 2018 15:34:50 +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; Tue, 16 Oct 2018 15:34:50 +0000
From: Michael Rehder <Michael.Rehder@Amdocs.com>
To: Robert Wilton <rwilton@cisco.com>, 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+5AALiXBgAAuGd8AAAATuoAAPS9MgABQPKNgADaijIAAAJ4ccA==
Date: Tue, 16 Oct 2018 15:34:50 +0000
Message-ID: <AM0PR06MB4083F4308E68CC156082B2B8E7FE0@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> <9d1627e3-8a0d-491e-1d2d-ed589e12b1c5@cisco.com>
In-Reply-To: <9d1627e3-8a0d-491e-1d2d-ed589e12b1c5@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; AM0PR06MB4324; 6:XexKjI0d3hwN7zOvnOfDTudzf4XNIF5e3iqa3By6EnN0IkGesC/4moX05/QHDJaveGCvXOW3dDMo1kh2V/suSMutOn0lPtpY3+byPmzBB3fxUFcSa6ABcj1SBa4/7P0yxv8NkRaVN34UuowpaQkjj9c1yDE6BE6uveFijvYieuektsqhXsY0LLHnToCG4GOXmB+iJlgwgDCYATz8c5Vv2Be1IY+s80trefaLcAnmVrBni9au0iaRypxWInNitJ8uMjb4sFZxG7wKcDSw4ACokPcB5mXVSm7UfhWUldo0mCzkbVpN3r4QXbtSlOG9C4kJ0mFx+fOk4EoZqpRtkgRWrpZS6PA2wN39u3bTOzVNkYydp8LGJEWYudb2WrE7YUUTRKWzxLc+9emT+VfS6NrqCeuxdWOZnGCHqXSTN3lpyy/wJIEwik/6xtA4a3ltkTy09JvzgK2iNmaWx0QNhC4L5Q==; 5:KQx9johKYw3Ljm3pk+qeO6MpoF4DBeA9WbPZuv0O0JhaceWqaMOH77jqp86HssoXXtyLjhWd0Z53jAS1XemEHowHoH5Rwa6GyU52EO8oXPGSLxolnMPvwHUJ3iOtfs/HdQ+tM/7jldXK7GLS/93lE0KVcDpaYI30w28ZWFXRm54=; 7:t40/K+KmCxnuVhh4veEg613CPuBEeZj5hYxdNsWpDiEK4SsvXjhfE/nqCHGMhk7ucZo6rV1qwI9jxOXOC/BjAsXBkHWrkaTDR6PfZA/fwYyYcEWCLEKboZ8Kp9lPP46FsnNGiER5h5J18mcXeVZFeT8jGdBFY3kfZ/2Yb6m39OCsV9SRk2HL2rLBlzymF4Uy1e/6J+knIgCk61wZcEqhFjBBaizX8uHpTNY1UGi5YkYDx8EaIF9J3TO/mMxa6PK2
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: c026fdc1-ffc3-4912-dc1b-08d6337ce954
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM0PR06MB4324;
x-ms-traffictypediagnostic: AM0PR06MB4324:
x-microsoft-antispam-prvs: <AM0PR06MB432452D9C4B27C9070C7C7B1E7FE0@AM0PR06MB4324.eurprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(95692535739014)(166566539817055)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(3002001)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991067); SRVR:AM0PR06MB4324; BCL:0; PCL:0; RULEID:; SRVR:AM0PR06MB4324;
x-forefront-prvs: 0827D7ACB9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(39860400002)(346002)(376002)(199004)(189003)(13464003)(110136005)(26005)(966005)(102836004)(476003)(86362001)(4326008)(11346002)(186003)(446003)(72206003)(8936002)(81156014)(99286004)(486006)(7696005)(8676002)(14454004)(76176011)(53546011)(2900100001)(68736007)(256004)(97736004)(6506007)(33656002)(606006)(74316002)(7736002)(5250100002)(71190400001)(54896002)(81166006)(316002)(478600001)(93886005)(71200400001)(66066001)(25786009)(106356001)(2906002)(229853002)(9686003)(105586002)(6436002)(55016002)(3846002)(6116002)(236005)(53936002)(5660300001)(790700001)(6246003)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR06MB4324; 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: Zd1BabMflEj8FghGG61sbdHHuEcpcqwjJJz86RHUdFCCFNdV/UybcHp8QNh1WA5ZZpcLLlUyoU56buuhqd0FoKdFOlAi+vh1CKUWoERUpAxTUoPCIKGRPYLVEFWEHErkYzlFQjh60430JCg2FTOwK+vpObastZ/39xyusMuQuXKD7C8voXGeqkIpDT+omnqW81WMMCUaQabd0+lFrKwjgApY5VZzlNVqxgiob59+w+odsCnnaA4ckZmt+FsIkx7o9oTQJPkHVQPPGpDfveHxEvls0pWTnzdtLutpCx8jgYnA5zsF98CBry/0OPi8JRzq6JHDq+A5TsMm/qzI6lyRsqNYr5blPLl0mgeTxr98u2k=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM0PR06MB4083F4308E68CC156082B2B8E7FE0AM0PR06MB4083eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c026fdc1-ffc3-4912-dc1b-08d6337ce954
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2018 15:34:50.2337 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB4324
X-OriginatorOrg: amdocs.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/mFMe3w3pu2b13ps4htJrt9zX2ws>
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: Tue, 16 Oct 2018 15:35:07 -0000
Ok, so it is there in the RFC, just somewhat separated (in my view) from the definition of “when”. I still am somewhat surprised by this implementation. Far more often the I see a need to enforce the presence of a variant. Thanks Mike From: Robert Wilton [mailto:rwilton@cisco.com] Sent: Tuesday, October 16, 2018 9:42 AM To: Michael Rehder <Michael.Rehder@Amdocs.com>; 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 Hi Mike, On 16/10/2018 14:26, Michael Rehder wrote: 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). The section on "WHEN" just mentions the xpath mapping, not anything about changing the mandatory status of the enclosing node. 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). By YANG RFC do you mean RFC 6020/7950? Section 8.1 of RFC 7950 states the following constraints apply on valid data trees: o There MUST be no nodes tagged with "when" present if the "when" condition evaluates to "false" in the data tree. o The "mandatory" constraint is enforced for leafs and choices, unless the node or any of its ancestors has a "when" condition or "if-feature" expression that evaluates to "false". o The "min-elements" and "max-elements" constraints are enforced for lists and leaf-lists, unless the node or any of its ancestors has a "when" condition or "if-feature" expression that evaluates to "false". These rules indicate that "when" trumps "mandatory", "min-elements" and "max-elements". Thanks, Rob 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><mailto:Michael.Rehder@Amdocs.com> Cc: netmod@ietf.org<mailto: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/><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<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod “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] WHEN statement within mandatory objects … Michael Rehder
- Re: [netmod] WHEN statement within mandatory obje… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] WHEN statement within mandatory obje… Ladislav Lhotka
- Re: [netmod] WHEN statement within mandatory obje… Michael Rehder
- Re: [netmod] WHEN statement within mandatory obje… Robert Wilton
- Re: [netmod] WHEN statement within mandatory obje… Ladislav Lhotka
- Re: [netmod] WHEN statement within mandatory obje… Michael Rehder
- Re: [netmod] WHEN statement within mandatory obje… Juergen Schoenwaelder
- Re: [netmod] WHEN statement within mandatory obje… Michael Rehder
- Re: [netmod] WHEN statement within mandatory obje… Andy Bierman
- Re: [netmod] WHEN statement within mandatory obje… Ladislav Lhotka
- Re: [netmod] WHEN statement within mandatory obje… Michael Rehder
- Re: [netmod] WHEN statement within mandatory obje… Andy Bierman
- Re: [netmod] WHEN statement within mandatory obje… Michael Rehder
- Re: [netmod] WHEN statement within mandatory obje… Andy Bierman
- Re: [netmod] WHEN statement within mandatory obje… Michael Rehder
- Re: [netmod] WHEN statement within mandatory obje… Robert Wilton
- Re: [netmod] WHEN statement within mandatory obje… Michael Rehder
- Re: [netmod] WHEN statement within mandatory obje… Andy Bierman
- Re: [netmod] WHEN statement within mandatory obje… Robert Wilton
- Re: [netmod] WHEN statement within mandatory obje… Michael Rehder
- Re: [netmod] WHEN statement within mandatory obje… Juergen Schoenwaelder
- Re: [netmod] WHEN statement within mandatory obje… Michael Rehder
- Re: [netmod] WHEN statement within mandatory obje… Robert Wilton
- Re: [netmod] WHEN statement within mandatory obje… Michael Rehder
- Re: [netmod] WHEN statement within mandatory obje… Robert Wilton
- Re: [netmod] WHEN statement within mandatory obje… Ladislav Lhotka
- Re: [netmod] WHEN statement within mandatory obje… Michael Rehder
- Re: [netmod] WHEN statement within mandatory obje… Andy Bierman
- Re: [netmod] WHEN statement within mandatory obje… Alex Campbell
- Re: [netmod] WHEN statement within mandatory obje… Andy Bierman
- Re: [netmod] WHEN statement within mandatory obje… Alex Campbell