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

Alex Campbell <Alex.Campbell@Aviatnet.com> Wed, 17 October 2018 21:43 UTC

Return-Path: <Alex.Campbell@Aviatnet.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 E113F130DFF for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 14:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.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 uKlM9IHzFLjb for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 14:43:27 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0066.outbound.protection.outlook.com [104.47.32.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C245130E06 for <netmod@ietf.org>; Wed, 17 Oct 2018 14:43:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aZgqX9NCHlDvNs112G0LpTEwAF97FbqudmUt3XN8rPc=; b=H/89Z75iOlLESuFOXTi1suXs7RUO1tp1C0KWhlYM6EN9Osr9jWNGv95uZog8JPVfmmTLu93P3t51sc9shprA4jwlAFmv8JV+jHpt70ijxN+a33tKLjZrf3Wtc+9vnQd3gJppj1PtURTh94/KfNtiTHRZr1ahUoJybeY3Jx4oVpo=
Received: from MWHPR2201CA0078.namprd22.prod.outlook.com (2603:10b6:301:5e::31) by BN6PR2201MB1107.namprd22.prod.outlook.com (2603:10b6:405:35::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.31; Wed, 17 Oct 2018 21:43:24 +0000
Received: from DM3NAM03FT019.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::203) by MWHPR2201CA0078.outlook.office365.com (2603:10b6:301:5e::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.24 via Frontend Transport; Wed, 17 Oct 2018 21:43:23 +0000
Authentication-Results: spf=pass (sender IP is 192.147.115.52) smtp.mailfrom=Aviatnet.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=Aviatnet.com;
Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.52 as permitted sender) receiver=protection.outlook.com; client-ip=192.147.115.52; helo=mail-send.aviatnet.com;
Received: from mail-send.aviatnet.com (192.147.115.52) by DM3NAM03FT019.mail.protection.outlook.com (10.152.82.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1250.12 via Frontend Transport; Wed, 17 Oct 2018 21:43:22 +0000
From: Alex Campbell <Alex.Campbell@Aviatnet.com>
To: Andy Bierman <andy@yumaworks.com>, Michael Rehder <Michael.Rehder@amdocs.com>
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: AQHUZmJV2v7njsBPd0WncvLlgSykVw==
Date: Wed, 17 Oct 2018 21:43:20 +0000
Message-ID: <1539812601446.35899@Aviatnet.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> <AM0PR06MB4083997E335CBAA6FAA3B074E7FF0@AM0PR06MB4083.eurprd06.prod.outlook.com>, <CABCOCHQ-wOp_nkoKwYE1frH2uOaGC6QfN_=4=cOXUS+eg2Gxxg@mail.gmail.com>
In-Reply-To: <CABCOCHQ-wOp_nkoKwYE1frH2uOaGC6QfN_=4=cOXUS+eg2Gxxg@mail.gmail.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.9]
Content-Type: multipart/alternative; boundary="_000_153981260144635899Aviatnetcom_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:192.147.115.52; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39850400004)(136003)(396003)(346002)(376002)(2980300002)(438002)(51444003)(13464003)(189003)(199004)(19627405001)(54896002)(356004)(26005)(6306002)(14444005)(236005)(36756003)(606006)(118246002)(5024004)(97876018)(72206003)(478600001)(84326002)(36736006)(316002)(246002)(16586007)(110136005)(6246003)(114624004)(476003)(5660300001)(86362001)(11346002)(8936002)(93886005)(186003)(956004)(2616005)(2906002)(6486002)(446003)(106002)(30436002)(76176011)(7696005)(8676002)(3846002)(53546011)(25786009)(6116002)(102836004)(117636001)(4744004)(486006)(7596002)(71190400001)(336012)(966005)(4546004)(7736002)(53416004)(106466001)(126002)(229853002)(7636002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR2201MB1107; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; MX:1; A:1;
X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT019; 1:78uvRt9EJOvq7Jz+IjEZxL/6bJK78Se4XmHGPRkVDMDFEeP7Wxsq8DgDOB+LY8rOX4Rvy7TCNHs2LdVYc/OgZQEKYzl/5VbS1nSC+/OIz32tjkCc+Lv/kO3DTUjpYKcX
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: c92519c0-218f-48e4-ad2f-08d634798feb
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4608076)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BN6PR2201MB1107;
X-Microsoft-Exchange-Diagnostics: 1; BN6PR2201MB1107; 3:OHz9qaMU1aKbhS6v2nEet1YlHj2QdOZyC2fNoVLEbPGbJhTqhoNYG9SwtMZSbgRz6vY8XXNGgss2wc10Xz0VuvXFIG47HcVQQ6cv8H8i98um/yloKzzMjexyWSFVep+4Ja6DHGttbBS+pUZi6GKPVUnzgY6xCWD5Ce0CNqQMcAmKoo6YeXfBKjcxiakkSAMAKK/UZqDLuyPWgpOaFq6cKrXLOXznxAo3EmWurpBTzph3oEJp7BZ/yNgsbzjGoov+Hxd/8Q289VlSeGalzj0omO2Yf/HGXGOM47684I0/SBAZINaY7aRsF9EIgzonWTSAq594Oqd+DBmli/X5+EED6X6WzKdJZwetw//3s9t78SM=; 25:dU7VITNw4yaVfVPntlbNop/Cmx3c7XdTlo589Cct2eCmqJNZdexL4Qy+XD6X5SJ09hf1FYt0FSDwBlgLdyHJvwy6MIGqPvX60YFPRw5Xz1+HG0tev13ljm/ENjK+iip9t4Fa4QxHoNhMjPk+2Km5w0UxfIhSMQQEJj3gsMADFCzt7SD+2TngNYYltQshcNbdPhtv1KU3Q7SwFoODVaO5CO+SbS9Y/tTUJXa/w+uE3ALY9puaEw9VeyKSDykxzwJbcU2SuUsIfteJ5jmp8RVxg4ngVHQcjR3XkxvHJ63XsSN2SODGNAjjK/DFiW0QXk7BygfhGXbz/6yXJh5uAt/2YA==
X-MS-TrafficTypeDiagnostic: BN6PR2201MB1107:
X-Microsoft-Exchange-Diagnostics: 1; BN6PR2201MB1107; 31:56OVoJLcApYqAL3+VWEd/GdTzX0cvtwDCByM3Jjq2uDhX56QWaZtJRKAtGXrk5Xyy6OJQ7ptvxCceMEQChjOg3WcDIMnBpKNgeURSOaP2wxJgBE9sdySXolr+B2ECkH3VFbCSQRHYfguLQME5f5DWQgvkw44Xq3Bi7XJoNewE/Mz5dXPfqxVNxagJSF4kN0nZ3453Q4UabfHkHQUBIROo/hovmZMl+/RE5J6mXxl+cA=; 20:/ZrJYOTtBLfJ2MF5lAQgSYuxQcs0ypEO4jxiORFIQElhFOFz6COug+feJqaY+ikpXROOmK4WXXoGXq23rOWnz4GnKxQT2jvoEc8cetr3UoZen2f9PI4yOqN928kHhyAnfi1QFw+BDuQVZvcKRGgvP1uL+fZ84Jwp5j3v+DLOSEAgj67N6BA8/EiBz6QjuhJ+uu3hHT7jyi8qdmD8akWz4G+rn6jCgoFl1pG324krtN7L5qsQ1GrhgpbUKxw+3eE1sNVrM3jBLiPGBix/FHLvfc8XLZkHF+8ny1tEVSSg+vXjBosZYGfORvjxkJTR99VPQjh72EGaW/4QjVhCFDdJ64PXvt40/6pBohC2TZTRyVzNzp1Y9lUEQgjJiUwId8iOj+IXK/gvz311OFQpoDrpt+LGuur25QmsvZq+9NUlx/smbyNI1E5JV9nrlmHJvB284Ab2+krsudt8H+dEm3fuJaMlZ2caMc6Ddjldsxx/JqukUaJdM/d6n0XBjLaMj9eV
X-Microsoft-Antispam-PRVS: <BN6PR2201MB1107804188DE67F08601D37987FF0@BN6PR2201MB1107.namprd22.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(166566539817055)(131327999870524);
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)(93004095)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BN6PR2201MB1107; BCL:0; PCL:0; RULEID:; SRVR:BN6PR2201MB1107;
X-Microsoft-Exchange-Diagnostics: 1; BN6PR2201MB1107; 4:a1aVvVeOa7QZooauZUA5d+gHBNTkJYKHO9irpTJE0gids1PVpZUhgZNUcKhnsVhoy/M4oBl+KVC9Ad7wrNlSppJLlE6Ptn32j8PeYcm2C+zBFURcV5VisYTf4ABUfReHABQGtdYY/G22kj/JE52x7z+0wkDme2A36KmQl8OWSsm5WTAF/G69OdjP/6G7ElEMD9m5M46On/pnh7AF9AN5eNBzV+JnFpw31V8lSV21/YEsy65IM2S8yU5Me1CBUz8Fsw3iznJLJWo681kWvQYnqQMK5kcUViRZk0VaKUSbUcKpY4RvK795VwVE74qks75gLl1KZZLX3saWQimX8rLjo4wLj9FU8KWLj8Kf+vbYWC0=
X-Forefront-PRVS: 08286A0BE2
X-Microsoft-Exchange-Diagnostics: 1; BN6PR2201MB1107; 23:/HZTuqFLpywtwsu4luNrhrTFs4wt+KZau9taPiLttUrPTMyded0w2NvpfFatk9cQgzAEBa1watLZ420pufZ9sOjGN0GQoOOVB5c+TPKZFrzTOVfkM3BON/h+/TN5fBW4XcaPbaAcc18NPjPFT5u/Au+XX1CaBkICnMPPZdZEu2Bgd9N6QWdkGgD3DJbCmBVLdRtenAGZ0TOnydBZ5MruDhMbiG929FK4XR9K9qGTdYhmQFFM6zOvzGhLIJQUznumATaqUNyqmQzLDLlrMlDIG1PjCEhAihp/y6UZ7abud9UhJ+jCwiVkeL0TCT87Kcqn6Nap4cXrEx3SVdnOEx2PjSgv0Uzxh4a38wDLye0i586szGmjwg0UT684o43unze4ypVm4+XxJFIfM18uGUdBkWD/eb9a5jJoCXo0mdVJPsmvh3hI/30nOJa7QqAwQWmd/svGl0hfGgv0VmxShqRjTZ38pqqTbc+kngutJaDVXUKcfBVSU7V1Fe/jV9W7X7C7sbeGdALhm5ryZA377T6YgF3XHdCeRwOoMifasBc++Pgu8PfVBba5k4hvkyhlTK2WWytrE01PXA6NIUN6Qepshr8Vd5QCsfc+iPWLSGUyplCyjeuHJverqmCkgqcG7RoD6HhKtvom4JHvJc0fx3hBc4AfC2XLuWKoC0l/GCDHRMnmH5olni/ggmpaxl4bqhcTWzCm2bqHieEEYzcMsAn34Tq2+o+pebrpnjoke5ymUpjtjl5ANYe840w0IadD0L3fO5gAVqurcsedir5tbZ6TAI4aZPYEnMpeWQ00lknbGU7slPUA597euWTsmkwe5FqplOtREeorTpXV5eQL2AilHv8UXct7JiMrgpOtEJUJEBzyuqQ2m0rt5n2+pxM9hfgdx3wFJExEckPkG2wTzfa1FnBHx0pkIskjTgO5CqgpFblTGmN+AIIea3TwC2rUpD5jA8yvz5aKANuX/a4+LisMldOZTKeitEAKpMJVv32ruVzAwJB6dRa315DWJ7GhNdU/1yEEuBOSWt4J5Cs6xgKx4WAWhsVMfI20gH7I60J4ynn+u1SS1t2c2P4xllNsrXHWBALMLmbnlvQl6ZG0MsRLMh8u0+v4+JZELPbla3aFERXUDvtVgvFnGpApe16ySOACjxYhhyPTUJN1UQb0F9WoazIw+dCLgLnnhToBMZO5jk2r4kMY97RK80WdJypsE2yoFnzy15n+u3WXveWOvdqEIyCUhFR7aQSCv5AfNhb/LZUFLho1olVaKu2je5fOjm+KsLXk74d05bfujnJ9jmjKRhIB9sMFFasMO1w7qAzVxo036SHXQSNBBSbKDGAAvc2Ophw8t34NOvx10PBZQGggJEnjpP+S5BWglMlHf0fkyte/wovG09qVdjkvh3jOsdQ0OrLxfA0G/B2tRxpBQzYnYUeD4O72jvPxKO4lfcFv7Y/mgb1w9SMuzirCDYfDeAU2ykxfxhXlk8aIQeBAe2ICJRCtsbeFls5KMDVkvgvKqpY=
X-Microsoft-Antispam-Message-Info: PIX4Raa6gYVGBvvWl5eVw2qjWAex/qVdeeu9HGrHXnhDPjhRNbMezYHPQz3cUrxFQ9AzfllR/JGUDcpBWyavvC9Hv05rEgjxOetT7UHf671KZ2CMtYeZL4EjJXBqiGOyMJYB/7d7vILvoblvACa/VvYIR+aZ2OSvvAQYY5liWOAV031Ig7tkWnEXVBsomIxEtnjKuX3KYNq6SVApcbLtDyV+ZLVAiAEBOS+Ypv/FfkBwTE42im0bb3jAujGiLQKW1HznlmUqV6DzLC+wu/G6bjm/7xnU/qLWNgZTKdEIJB0ncKQqshrJZ++C6FBMYxjyszUlaOjVj7/NcXF2D33DTkJhuEhAzx2u9tKnuCrVU0Y=
X-Microsoft-Exchange-Diagnostics: 1; BN6PR2201MB1107; 6:2n8etR/Dt/6UPpCka1o7CApHFCIVIV+eAUDSSBRLVdU6+dfwQHnV00W8tQhmj1X3OjpT5Usz9ubsgNaOvdZcf3rAdrBWVyCaY9r+BNr78iEeU9Ns2ImUfuxYD63lBnQeTPi8bJ40rRi0aBOH+SnwX+z6qTfHAB7YlSDB3OJD6TXwtEVlw7gIHUpzACd5a6x94ZBpXihT/iEqyGPjyy4M85R0/RCiONKYdVg9Svdf3s2su3ssVMpN63PiPFZSWXR0MqBuQ0I3IYiknxedBOyfdnwVAXoUAo/LFp/U3tFt0HKMT+Xt+22ekDepHw2VODYGfY1N5ILbY/4BHpcmMJwK7ReKKBY9sI/wkCDgixvz2O0D7qrxeBXsI+vrEwFsqBgJALIDPXLPF7RkTdkBqmCsNrxvWTJ6c3gRUKyhEDy54Roge2VGXQ9iD2jDfP1vIIHUZ4BXIJ4KWD1TApxts3bIbg==; 5:nO/P1GE2kmAIkSrXzODjK1fWZp1eCGW85DbJU7ZrWNv5RAWYDS1iX1QkomwvTyZXm7y/+WfkvXqLcEgdhs3lXI9d1t+oFHKNinBUfMYOjAb3vThIpvjfLyPdu5Hk9LKA1KpEIG70KUXnHx/IfahW4qA0hh6FkPnvbeYsFpxpNWQ=; 7:dVNVy0oupP8n4aBSQ4v6OL5cUbwqmAOF2KWk/o+dJxv10Ue/eA/ITqBj0PIUex5aIwy6RDjmB6YbjnsZirZVpRVnufgvl5uJRYx1hNQrA87Sp0g3krr6DCJztLO/8CZTbQb/G9+jXDM4d2r2NPlepC9FycknxLHC32sGvpultmGmYT8jaGydO2+SkWC6tlYDv1PnDm8M/QEPtscEX5Xh1k40btavaH0RyZ6Z5BXwPHw/XaeA683cUC8n182JHStn
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Oct 2018 21:43:22.7121 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c92519c0-218f-48e4-ad2f-08d634798feb
X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.52]; Helo=[mail-send.aviatnet.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1107
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/R30nq7pNyhEGcEzSmPMT9Xy5BCU>
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 21:43:31 -0000

> At the abstract level I do not understand how when-stmt would work differently.

> IMO deviation-stmt already allows enough flexibility to rewrite the model to
> fit the implementation.

FWIW: deviation statements cannot be used to modify when statements - "when" is missing from the list of statements that can be added/removed/replaced.
I'm wondering if this should be considered errata.


________________________________
From: netmod <netmod-bounces@ietf.org> on behalf of Andy Bierman <andy@yumaworks.com>
Sent: Thursday, 18 October 2018 7:21 a.m.
To: Michael Rehder
Cc: netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object



On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder <Michael.Rehder@amdocs.com<mailto:Michael.Rehder@amdocs.com>> wrote:
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.



The when statement works as intended. The entire subtree is on or off if when-stmt is present.
There is a lot of relevant text in 7950 and it cannot be grouped into 1 section, so that may make
it more complicated.

The whole point of "augment when" and "uses when" is to allow the designer to
say "this part of the model is only relevant for a subset of all possible values
in another part of the model".  In SNMP we called this SPARSE AUGMENTS
but it was just DESCRIPTION clause text, not machine-reaable.

At the abstract level I do not understand how when-stmt would work differently.
IMO deviation-stmt already allows enough flexibility to rewrite the model to
fit the implementation.



Thanks
mike

Andy

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz<mailto:lhotka@nic.cz>]
> Sent: Wednesday, October 17, 2018 4:43 AM
> To: Michael Rehder <Michael.Rehder@Amdocs.com>; Juergen Schoenwaelder
> <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>>
> Cc: netmod@ietf.org<mailto: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<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<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/>
> > "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
>
> --
> 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".
_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod