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

Alex Campbell <Alex.Campbell@Aviatnet.com> Thu, 18 October 2018 00:40 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 92598130E42 for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 17:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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, SPF_PASS=-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 gpuuxWJmLmEk for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 17:40:12 -0700 (PDT)
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05on060e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe50::60e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E3A130DF0 for <netmod@ietf.org>; Wed, 17 Oct 2018 17:40:12 -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=vqhTRlqKcfIeSsTUuMBayVXJKfrBdC+ULDwdzfdh7MU=; b=h/UnOzu8+V4fSx0ioqw3Cu5aI71kzI7GfwyQ3oM3qkUqOqfYExpGgeVumWyky3pT2Nj2gbEn1IWE5J7iINsVefkgxhceco3skQW6bKJiTCQPEIYqffB6aKUliNp4aXJ7/pKKlV5Bgqe5Y4QpUZp6BIhbFbdKsguIz1FOBuNK/zQ=
Received: from BN6PR22CA0036.namprd22.prod.outlook.com (2603:10b6:404:37::22) by MWHPR22MB0158.namprd22.prod.outlook.com (2603:10b6:300:5b::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.26; Thu, 18 Oct 2018 00:40:10 +0000
Received: from DM3NAM03FT054.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::203) by BN6PR22CA0036.outlook.office365.com (2603:10b6:404:37::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.20 via Frontend Transport; Thu, 18 Oct 2018 00:40:10 +0000
Authentication-Results: spf=pass (sender IP is 192.147.115.54) smtp.mailfrom=Aviatnet.com; amdocs.com; dkim=none (message not signed) header.d=none;amdocs.com; dmarc=bestguesspass action=none header.from=Aviatnet.com;
Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.54 as permitted sender) receiver=protection.outlook.com; client-ip=192.147.115.54; helo=mail-send.aviatnet.com;
Received: from mail-send.aviatnet.com (192.147.115.54) by DM3NAM03FT054.mail.protection.outlook.com (10.152.83.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1250.12 via Frontend Transport; Thu, 18 Oct 2018 00:40:09 +0000
From: Alex Campbell <Alex.Campbell@Aviatnet.com>
To: Andy Bierman <andy@yumaworks.com>
CC: Michael Rehder <Michael.Rehder@amdocs.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: AQHUZnseNYinCTu490GybfdVN02+zQ==
Date: Thu, 18 Oct 2018 00:40:08 +0000
Message-ID: <1539823208124.44400@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> <1539812601446.35899@Aviatnet.com>, <CABCOCHTFSBznTmOSY5uUPCSkE7rT5-k7uis=35N3DTWXVDW7Qw@mail.gmail.com>
In-Reply-To: <CABCOCHTFSBznTmOSY5uUPCSkE7rT5-k7uis=35N3DTWXVDW7Qw@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_153982320812444400Aviatnetcom_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:192.147.115.54; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(39850400004)(346002)(376002)(136003)(2980300002)(438002)(13464003)(51444003)(199004)(189003)(118246002)(6916009)(4326008)(84326002)(316002)(16586007)(36736006)(25786009)(26005)(8676002)(97876018)(8936002)(6306002)(6246003)(236005)(6116002)(229853002)(53416004)(3846002)(54896002)(86362001)(14444005)(6486002)(5024004)(106466001)(102836004)(19627405001)(478600001)(72206003)(54906003)(4744004)(966005)(117636001)(71190400001)(956004)(30436002)(93886005)(336012)(11346002)(4546004)(356004)(186003)(476003)(5660300001)(53546011)(36756003)(7596002)(486006)(2616005)(126002)(7636002)(446003)(246002)(606006)(114624004)(7736002)(106002)(76176011)(2906002)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR22MB0158; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; A:1; MX:1;
X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT054; 1:+d3131QNBunMdBxDbBlAWrCmwMLSrj7vGI3tPFUqHHhPGh5UyF/3iOCvdOaKgdfMaMLm2FeHNkh24HF4KU2rJ49FKIAGknep0OyD+tq2tulyr28S7FhRmrq2IBcAppYm
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 0849e28e-43ef-4d72-c09b-08d63492421d
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0158;
X-Microsoft-Exchange-Diagnostics: 1; MWHPR22MB0158; 3:Dgp17XEygyy51l9JjqUQ4IqEfOn4fcg5ReCMGQAhkqZJ9hJWAdj812i1BaHqamuZ+H/oQFeBzuTI/TeDzxZ5u7jbEpb+i9x/QsLcLF6DVulwdkLBXR5b5CBsXrDBE5GXRMOAK02ufDtapvYrruTkNsKSB1498nUao1TG+pxsdNMaiaONfDuds849CrO5LJY4/o+aNu+bk1nfEyTF03iD9QHdf1ZkF//jFcGmsl13VXUv25K1F+7wJd2NmrCTyiTzYUoUQoorIjPS8ZNC51XkAc5g5aHEx32xFJ7ob9CYDvcM1EORW83H1i+9p9NGYF1XL0Tp/TbzqVWK6JE1AGNMHFh8pJyhmm72S7NG979OYTk=; 25:VULYfKGjN/SV/TJAUd5r/+T46/QK1FEEqmk34i6WM/941jkWe8qf8Us/FtaN9wBidyuLXZ6G7nM5zFSU6sX2JmOHCdlVauup4Tfm4C4C+DI9KpJJtZ/ii5/ryKYxdKOi7ipz3nuw69BE+Bn8/efvEZlkz24s24/P6NEyb+0cwaaGzfsS6C8cdUqku/YaUJkEm0sfXO6ZzLnUYyxXpeciuk63dyyJC9HX+fpTrlgFCRXGAnT2MyXUi+ppcIRMQd9SAayX1uS+hzsjL0pv6d5CA6lvz+mKaT13QQlu6PgfrfMGZAmyamSZUV+UTZF+jErY/tF86nIGKfjWQ2bUU3kRBQ==
X-MS-TrafficTypeDiagnostic: MWHPR22MB0158:
X-Microsoft-Exchange-Diagnostics: 1; MWHPR22MB0158; 31:mIt/0wCLNVq20B/aMdadyFnUqWRsyWltr7XIjUti4zp/c5B4Pdmnhn5Sa5PI0zsu42RWT+Qx9kwqr2JKN7SP/Y0UgZQAC+ck4gtuvSyWAk/QqdCq5AxDUUbEdcA9wUUnUHp7kFlWBYJVQLat1JqNwNVr1AVxwTmthVMGVeke7rDO1PxmXBObDGesRO5jutj4z2VrLI0+Qmsbn5/Q8xquOa86obPq8y4lto+eAWhDZC8=; 20:CcQ9re+0qH8rZO9oVUGxGytvTDei54WU87+CXBvpc20NtI+d9+0azDg5yrklAC/UyTsI9RzdxOWmFnH5nXaiK0FdMYLVyKE6baCXAaPelEcTFkWHnNqn1rf5n+WdxPd9dcz3FnSaWZFXvnI8oKidtClpk8D6r5wUmj7/FIE7QTVJ9obYvMBzBJtVy2a2gRTUPK9ivMvarLiimUGfq3y+AGBPs+3ck7xPaTUSnmEwuMVIQkzPzunueyvzntwjdHRSG0NhivSrK/gYafM4rdVbgC1I5WixpS0L78Y5aCh5mAsjWcSGrtjVqg4fyiTsUysXe0rQPRPikd5V/yF7/1ZHa5UXo3Z6AGFqPzgQAPSY2Qsu+y2AL6rKm3AwOsU3G7uUsywPMGyUEpNmPaKJ1IFPcpmhk9SNtv2WzmpgBgbsP7L/JU7rXJDN0UXJg2P6hqVvvyYUvGwGq5QJr6KJIheMzhhVG+yUZLF34delUKUScrJQdHCkPMlv4ZeDAtBHTLDc
X-Microsoft-Antispam-PRVS: <MWHPR22MB01582F4A09DA09F1B66070CC87F80@MWHPR22MB0158.namprd22.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(788757137089)(166566539817055)(131327999870524)(106180626270275)(211936372134217);
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:MWHPR22MB0158; BCL:0; PCL:0; RULEID:; SRVR:MWHPR22MB0158;
X-Microsoft-Exchange-Diagnostics: 1; MWHPR22MB0158; 4:u3bCbmI693H9Tbd2J2sLTkOGs5igHykbyVBMHlEGQurWMD1z3MSNG+atDZX3Bprrn6UMUtALAmYwZEFQ4YhEjmNF/bfNZ8oscexYWWSm89MLN2Q8fDoldg84vLX6bBKGC44sUiTW/i6gyb6Yc3eURV6peU8e9EuKhCFafosuYTH390KvefOU1DRyu/1pNCyluO7y+nL7JIjZ/pcLTU1cQiO1JcU/djeIM6XiP/g7xFQB8zlcXJHFzC1jicpuVUqiIf8pbv46lGhPtD8onxViUOguV+526kizjtjkl32acZhSeA6BHC1C8kCtPPx41Ny6qY7hPVqh1TxsIj8+U7mYUpF9jJLeFLmY2PShEiCjNY6mbOYxD78907VPk3Of9rISXZcLaGiqN3NIC2SX4xgaqAaa1si0Zcdn/IWAjl3puJbRQG6AmhJXizTIgcmkOL95
X-Forefront-PRVS: 08296C9B35
X-Microsoft-Exchange-Diagnostics: 1; MWHPR22MB0158; 23:So+rPN4/W2gVMMrnpOftxxYW9s6cG2pYNcv2l2/Wof2TFqVweSXX4HxyhmZkGhO3moZRsfXf8Aw9lrcYZ5UlCvinbY3L/a+CH4AYdt6HKkrRBTSqwL6Ahr/5lylcSKbX3ZEfg46DQ5V3B4VmsoBd2GsfSNOiKmyHBRYFWMJf7fGxifrtyEY40fJjwVMJE6n+DqVU9uWTM87FY8/7MsQpVcT4i3ANvG/9HRdaLXY67H+/Vu4KMoAu5jPZBUeJ7cU1SoiQRZOq78kJmLW/sFFu/DBWlLhkGRAr+GNM2LrqIXgJmCxBdFd876q2tGN+gHYDqiF4/fJymAmoVAgAKFUTQLiS1UAsYzpKexmh4F8HzNiE/llQqeI+kdIVC7AIXhI/LXJ0gFd7vaVB2aKvhEMx1yaeGCLhgTW3AeAIMzwsp5jkt9QWRj/6AjACSBir6pPD0Zb53XG2fLUnWIk0DLnZaLV2rzBCcgi3gzdRsRcVqTX+mCIu0g8rl8UhSwA7+wIzbOerYwxnC9o4U2hgTqVJ+HrRxQvTcr7/AWVYSTbBnJUeFiWa75eQtSfVdAA/RjttMMqattNa7PAZSB7/ZdgTouDC0Y1fkhd58xb0Q6XhAM9Ll6EzR0SVNRIzEQerJXE/7glxpWeSUMILTPwf4NHysLEVNRUfc6FYujVMf80ey5eD/3cINLtr6bfDjIoh/aZibcO4/Z8a/d7S1UYROtooDylT/+CbjfqUN4Q99yh7py65wOtN0C1TPgAkFB4Qy4gdiO1MEk0dpVpN2rWc4eUOx5HrrPSUOja97ZpIblDCTFNQ/rG2AZoLQdR6d3pqEzcCVzCS45ddZnwD4sYTVAkwKUhCq23vZpNL68WYn/jUIhkbTOur7fdUGIQ9gml/AkwPPhc3ATQOyCcaSR48J8ye8+FLm0biQs7oBVqhpy4TZ3l8s+j2vdmLvFd9XyzsTT1EnnccuWBeYkXnI0//CGGO3g4szL6x6JdDjBBm/zFPZiQvse/DKF0H2pXMuzWx4PPD2zmQDxQngzz9ndb8g//vcxOYc87B3z6nXpOs7a+KxRAwZdrfU+GEa0cySKD+Y+j+kk9rinHajvqSgZw+IeaVsdDGMWY+SwjPYpsPPRaDqeu3MFQNVodW8odrK4LNOpepJ/mmT8RYhUN5FQ0TFbmuN0hvsSrfJMjpPFskMTDoJE6nXwk9shgGP4Bf8GoG0cz4VX/s5DGRsDIzqxo7Utaezi1/pT3NWvHrVpEjCgsuR/rseDVOgHWtbd7ykdlYO/A9rQHhJ3RW8WtxO4JUgEOX+8ZM7yTYyluG0R6K9YW73WjYgj4GGa6vt/hAYuHeQKjHz3UFI+PlZs3+9Iy2I8lryiqHNevpJ1n/tri6mypUkfKipaqjwL6g6h3Te+nWFOZA0c8k1GJzKU/RwczhaVvbXwKIq0/rn5KQWs2wI1HZzxNjgKkKxVI0MT+GfD8djGA/gCIlmzL/8OhtIDU690W2g3N8fnC07Tl7wNUI6s3DQaU=
X-Microsoft-Antispam-Message-Info: Li9M7IzO29d6grLNUJxfSIIZjZfbkjkHUtW5TleqZqB2QsLvyUnYqz49X6DavSkEns2t5VnSzUWT9HkARtSrSLErhAjqcaCCLKPFKC1y74VgTjmtLoA6ewIXeKp5WHCzmhaTZETN+yO7eNpjwmm1/9Vh+JWZlSemdGa4nfhsQih68JWKuRwrUkJ5wfAb2qTxkkk02t/1Hm0xjQZJDyIReLLSys9McArm4TsT/zGm1yS4btCOFiHNwfZdW3N6JYVMbGG9VyXunukya9DoMTsjfXt9eWSub0L95dzkwhcA1UH6UXjTBRjuinA7hvS7EoJTI5etj25+aCRgX1jafaoRgse4F0s24HCV9r9NxQDLjbA=
X-Microsoft-Exchange-Diagnostics: 1; MWHPR22MB0158; 6:izIZuqdwnYmuQh0Jx7F+HqZjb4Gbi1OZY8ui1q8+ptL8ew9tYpOW1dZuEbPk7Wo7wQUAYfhheXb1vG+EGKX7Z6TqcETrOnDuAs9yRN3vGGLrU4DreTpv2BblNgZLREIYaEz/P/8SlTxaQgSS7OvH2wMEOqGdon/BBb/1S3FpS3d9DU95pSzEeqKXfZeLemo3IJzbLhcba9gYlJeoy0YrPlvn896fEo9KUEu6SR/9imr3Vq2bPOxdMLr/UuJTIb6ZS/rO3X9OOZolLGowgDqi2DopND1uUZLFWlt0EUEovDcHBd7lIPye7tJB3YQ/EycGHBIZ/wPhGY7sjJp1X9HBqjNO2dXZ2LrB6pTwYgZHMJ2lkNvpC0vg0MYcHCiMBJlbplJ2rbPwe4hry0wq7JKkYXjajFIgzTVKPVcFC91tnuHdt+/JQMLdHIwzh3Tzqd//v6fHShSGOh6jYuiOjwyshQ==; 5:X68WJaToeCWnwQj3ZJDm9Mtr+WlsCbxX3C5YwLQmqkPHBvKQxLauGRzQTpfR/4sar6kdQty+Ti6Zy1Aa2crklPJlKXJVMvILFPKFWKH9XfB/YLYW89OojEF/3uuG8tiTYD/K66aBxYDLqTam46uBIfBzSp8R+pukvt6sJSu8yEA=; 7:eYgnudwL20tQHADxB5rD+OUibKayGqSUjvQ2h+rBHJX2t5cdNq1GvNA6woD2agc+ELYzEmrBRjfaNn+Z7LkowlJJyroVFlcr6TVp5Tnm0YT2afFGOV8lrJqEM+aCHT0iE5MXvzZEdYiKKEGP9w5XeR/PBGOY/SCtyCm8zsgWqyNcw7Si3MvcR2OUJ4Iiq+KYc5fn65DEI+14yXmBB21KJCidzDuoaDOqYUSX2aosEtTf7EF91pFbuAoUSA0iSSr1
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2018 00:40:09.5963 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0849e28e-43ef-4d72-c09b-08d63492421d
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.54]; Helo=[mail-send.aviatnet.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0158
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/XJ6mfQGoQk8rvilAP9hqU-0qxNI>
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: Thu, 18 Oct 2018 00:40:16 -0000

It means if the model has a node such as:


    leaf some-feature {

        when "../type = 'ipv4' or ../type = 'ipv6'";

        type int32;

    }


and a certain device doesn't supports this on IPv6, it is not possible for a deviation to change the condition to "../type = 'ipv4'"


Is that intentional? It seems more like an omission to me.


________________________________
From: Andy Bierman <andy@yumaworks.com>
Sent: Thursday, 18 October 2018 10:54 a.m.
To: Alex Campbell
Cc: Michael Rehder; 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 2:43 PM, Alex Campbell <Alex.Campbell@aviatnet.com<mailto:Alex.Campbell@aviatnet.com>> wrote:

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



This was intentional.
I meant that deviations can already be used to add/replace/remove constraints within data nodes.
It is true that there is no way to say certain constraints only apply based on external data.
As Robert said, I don't understand why we need that.


Andy

________________________________
From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> on behalf of Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>
Sent: Thursday, 18 October 2018 7:21 a.m.
To: Michael Rehder
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 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<https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g>
> >> 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