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>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


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