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

Michael Rehder <Michael.Rehder@Amdocs.com> Thu, 11 October 2018 18:00 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 CCD5F130EC8 for <netmod@ietfa.amsl.com>; Thu, 11 Oct 2018 11:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.788
X-Spam-Level:
X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01, 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 BzjR6-Kh-zoj for <netmod@ietfa.amsl.com>; Thu, 11 Oct 2018 11:00:26 -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 B9723130EB9 for <netmod@ietf.org>; Thu, 11 Oct 2018 11:00:23 -0700 (PDT)
Received: from unknown (HELO ILHFDAGDRFE4.corp.amdocs.com) ([10.224.0.130]) by ilmail02.corp.amdocs.com with ESMTP; 11 Oct 2018 21:00:20 +0300
Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILHFDAGDRFE4.corp.amdocs.com (10.237.241.95) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 11 Oct 2018 21:00:19 +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; Thu, 11 Oct 2018 21:00:19 +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; Thu, 11 Oct 2018 21:00:19 +0300
Received: from EUR04-DB3-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_CBC_SHA384) id 15.1.845.34; Thu, 11 Oct 2018 21:00:18 +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=P69mfv6TvbXARLo9/2cEPV7LUoCJIYRRX0tHwsuEXbw=; b=JDk4R02N+4PZjNTIl1nujm8YO3sydsrIYZCnaZjRdApZ/sn2rdh3Cd1CQ70p99oo1CvoH3S3xnht5ZWDaDr8eyQn68RBoCVn8alnzCBMxhmYUjWL8qKOaSHQ1abmiL4NHDzmPoFVhuBadWIVbaLoBqslNmnOiOdzri9LYkFYhBE=
Received: from DB6PR06MB4085.eurprd06.prod.outlook.com (10.168.22.154) by DB6PR06MB4085.eurprd06.prod.outlook.com (10.168.22.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.23; Thu, 11 Oct 2018 18:00:16 +0000
Received: from DB6PR06MB4085.eurprd06.prod.outlook.com ([fe80::e01f:4549:decc:b707]) by DB6PR06MB4085.eurprd06.prod.outlook.com ([fe80::e01f:4549:decc:b707%3]) with mapi id 15.20.1228.020; Thu, 11 Oct 2018 18:00:16 +0000
From: Michael Rehder <Michael.Rehder@Amdocs.com>
To: Andy Bierman <andy@yumaworks.com>
CC: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Walker, Jason (Jason_Walker2@comcast.com)" <Jason_Walker2@comcast.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: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSAArOyOAAAESuDAAATBXgAAAIxIgAAXi54AAAG/FwAAAei6AAAKI+5A=
Date: Thu, 11 Oct 2018 18:00:16 +0000
Message-ID: <DB6PR06MB4085D91F66023AC98122FEDFE7E10@DB6PR06MB4085.eurprd06.prod.outlook.com>
References: <AM0PR06MB4083426FA0F1D3F6515F2ECFE7E70@AM0PR06MB4083.eurprd06.prod.outlook.com> <87zhvlvpts.fsf@nic.cz> <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>
In-Reply-To: <CABCOCHQKz-S2jcqeoJCtuG9U0DxOOw4musJz4DzwEtbCrEjqYA@mail.gmail.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; DB6PR06MB4085; 6:EaOVDOl/xer+WB+f2ntTjCI6CFYPhMHgkUrvhrOFELLbYdZg9gF6ZPoxPmTbBlIViBhnXhTHTG5B5FnJZEhSsTRsCo38qNUlBO+K+JO7WiaUUamnR54BwS+4fG9/ISFeut70wwgbML1skXSlYOdBYjdMX9agwMvdrKyqtYgPTfRGDjAnmt03QHGcYLYCQ1QA/ofZVmErAw6sG3Fn4eTIC3XjS3h3dtyBx4bd+zEo42mrQB486tzZGBJWfNIfV8W13vXrUf4YXzIsBRi6Zuqrv5mxJWQgKP0ax7qKQQFjvt8lkSfFjdT2545QAxEfw6ihbSDQWRsNhOv6lwLs4Iwwn+ze9Sj1yGJye4GUfWb8neYIqqwcOyCB755N8p0etuAM12h5z0gskleDv80VMuPEoC6jBQ7yGl3Pz+E93oNaNMqhCofjtIzV1GumrvtUHx8mCWjMJaKsXT6xno1vRXUnEw==; 5:glvr6ySPYEwjIA8RTR7S+77v9Z031ASHjzW4h/3daR92JyaJiSRzja1vSaEy+RrPvRar97t9xHt8xlpII/IGJsA/32zYNvXguK0ZpLkApx1mOAZ2t8MfLCkJz8GqroOnDgMEzC+vxDIKlR78lPwq01keKyaQGQbW4EztlDf3HxE=; 7:W4Cx+IwVG1pQTp35NCB4haIrl45Wq7cuFOViyHTOmZhUH1JFqF15ty1VyyU8VsTmSfHaz1eRXS2Wu4T83HghxBT3eG8wZBlRKeVye6fBDhI902FTninVl4ZNR9pp+p7u0PCqz75euzW3yQC8avP9arBQzyNrJhoO9GIh3VsrMN/c/40SH/IXz/MIT5lcdUPoY0Jl/mhRbOxi1H9G93Sma2I/84UUjevr5gpLFTBx3oqfPVKQKUWN0uc4VzzZrQpA
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 8d0a157c-37ea-453d-bc01-08d62fa366ad
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DB6PR06MB4085;
x-ms-traffictypediagnostic: DB6PR06MB4085:
x-microsoft-antispam-prvs: <DB6PR06MB408517353513F8BA65B1DFEDE7E10@DB6PR06MB4085.eurprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(131327999870524)(166566539817055)(62221491112393)(95692535739014)(17755550239193)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991057); SRVR:DB6PR06MB4085; BCL:0; PCL:0; RULEID:; SRVR:DB6PR06MB4085;
x-forefront-prvs: 08220FA8D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(136003)(346002)(376002)(189003)(51444003)(199004)(13464003)(106356001)(2906002)(2900100001)(74316002)(606006)(114624004)(6436002)(25786009)(105586002)(54896002)(486006)(6306002)(4326008)(6916009)(236005)(19609705001)(33656002)(9686003)(55016002)(229853002)(66066001)(5660300001)(53936002)(14444005)(256004)(102836004)(53546011)(6116002)(3846002)(790700001)(7736002)(99286004)(97736004)(86362001)(93886005)(6246003)(5250100002)(54906003)(6506007)(476003)(186003)(26005)(71190400001)(71200400001)(81156014)(4744004)(8936002)(11346002)(14454004)(966005)(72206003)(446003)(316002)(76176011)(8676002)(7696005)(81166006)(478600001)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR06MB4085; H:DB6PR06MB4085.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: aRlWTXSbbke14aMA1c/ZlQ8hZi8gMOY5rCTy9N/uflKTXFb9WnVbhv/6szxTCaWrtjoA/fbaKsCXAS1UH5mDjXPm5gTHJgpWkjjNF+sT3XGSbJnDhsg4viWe3KzetUjzu/IGvkTx+Q9D1wEW4Ur2PHzvzyJTIrU/8CYRn2MXVl6etxSWrfXEZoVsOcTYyYeJXP6v4Xg56eLC/30XpN00hyFtN5WrDnWHzIatM16Lvfa9hW/MRixyFKqPVsdnBbrFDtqOMdvEBLMZtThF6Trbq28M2B0Cy8gGcKgYg41UQpjbVaL+MhXv45Zg+Wb3lZUrK8OpXRSCbHPvdLz1Z6cz6/fCCGLZqCjtgeFGqm+BbzU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB6PR06MB4085D91F66023AC98122FEDFE7E10DB6PR06MB4085eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8d0a157c-37ea-453d-bc01-08d62fa366ad
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2018 18:00:16.7559 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR06MB4085
X-OriginatorOrg: amdocs.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/lRN3-aMjcT7S88VyhERlcnd7i_A>
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, 11 Oct 2018 18:00:30 -0000

I think the wording is relevant - something can be conditional but still required.
It should be clarified that elements become implicitly “mandatory false” when a “when” statement is used.

I would like to see an enhancement to YANG to control this behavior, to allow the mandatory status to be enforced.
That is, support also “conditionally required” instead of only the current “conditionally optional”.

Thanks
Mike

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Wednesday, October 10, 2018 2:52 PM
To: Michael Rehder <Michael.Rehder@Amdocs.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>de>; Walker, Jason (Jason_Walker2@comcast.com) <Jason_Walker2@comcast.com>om>; netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object



On Wed, Oct 10, 2018 at 11:44 AM, Michael Rehder <Michael.Rehder@amdocs.com<mailto:Michael.Rehder@amdocs.com>> wrote:
Sure.

I think the RFC is unclear since it seems that the semantics are consistent in the back-end checks.
One can read the RFC and not notice by its absence that the when clause doesn't require anything to be present.

     The "when" statement makes its parent data definition statement conditional.
Should be
    The "when" statement makes its parent data definition statement conditional and optional.

This is not correct.

Step 1) if-feature makes the schema node conditional

Step 2) when-stmt makes instances of the schema-node conditional

Step 3) YANG validation applies to instances of data nodes (or the YANG default value if applicable)

Step 2 is only relevant if Step 1 is true or non-existent
Step 3 is only relevant if Step 2 is true or non-existent

Andy


I think there should be a more definite statement about this overriding any mandatory status of the parent data definition statement.
Like
     "Any mandatory status of the parent data definition statement (mandatory statement, min-element statement etc.) is overridden by this statement and made non-mandatory."

That would have made the side-effect of "when" on other declarations clearer.

Thanks
mike
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>]
> Sent: Wednesday, October 10, 2018 2:25 PM
> To: Michael Rehder <Michael.Rehder@Amdocs.com<mailto:Michael.Rehder@Amdocs.com>>
> Cc: Robert Wilton <rwilton@cisco.com<mailto:rwilton@cisco.com>>; Ladislav Lhotka <lhotka@nic.cz<mailto:lhotka@nic.cz>>;
> netmod@ietf.org<mailto:netmod@ietf.org>; Walker, Jason (Jason_Walker2@comcast.com<mailto:Jason_Walker2@comcast.com>)
> <Jason_Walker2@comcast.com<mailto:Jason_Walker2@comcast.com>>
> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
> Michael,
>
> what matters here is what the YANG specification (RFC 7950) says. Is there a
> reason to believe the IPAddresses list in your example can be absent or have no
> elements based on what RFC 7950 says? Or do we talk about a shortcoming of
> RFC 6110?
>
> /js
>
> On Wed, Oct 10, 2018 at 06:17:26PM +0000, Michael Rehder wrote:
> > If the list has a "when" clause the RNG file actually produces a "OneOrMore"
> which has a choice of <empty> or the list so it actually doesn't enforce the
> presence at least one row of the list (unless I'm mistaken in my reading).
> >               <oneOrMore>
> >                 <choice>
> >                   <empty/>
> >                   <element name="IPAddresses">
> >                     <element name="Address">
> >                       <ref name="types__IPv4Address"/>
> >                     </element>
> >                     <empty/>
> >                   </element>
> >                 </choice>
> >               </oneOrMore>
> >
> > A leaf/container would be a simpler example but would result in the same
> lack of enforcement of the mandatory status of an element with a "when"
> clause.
> >
> > This RNG seems consistent with the Schematron rules that "when" makes
> something optional.
> >
> >
> > I think a workaround would be choice with mandatory true and a when clause
> on the cases. This would ensure that at least one case is present since the
> mandatory clause implements a Schematron existence constraint.
> >
> > Thanks
> > Mike
> > > -----Original Message-----
> > > From: Robert Wilton [mailto:rwilton@cisco.com<mailto:rwilton@cisco.com>]
> > > Sent: Wednesday, October 10, 2018 11:33 AM
> > > To: Michael Rehder <Michael.Rehder@Amdocs.com<mailto:Michael.Rehder@Amdocs.com>>; Ladislav Lhotka
> > > <lhotka@nic.cz<mailto:lhotka@nic.cz>>; netmod@ietf.org<mailto:netmod@ietf.org>
> > > Cc: Walker, Jason (Jason_Walker2@comcast.com<mailto:Jason_Walker2@comcast.com>)
> > > <Jason_Walker2@comcast.com<mailto:Jason_Walker2@comcast.com>>
> > > Subject: Re: [netmod] WHEN statement within mandatory objects
> > > doesn't ensure presence of the mandatory object
> > >
> > > Hi Mike,
> > >
> > > I think that the YANG below already enforces what you want, or
> > > otherwise I don't follow your issue.
> > >
> > > The YANG below is valid in two cases:
> > >
> > > (1) AssignmentMechanism = DHCP, and IPAddresses is not present in
> > > the config (due to the when statement).
> > > (2) AssignmentMechanism = Static, IPAddresses exists and has at
> > > least one element (due to min-elements 1).
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> > > On 10/10/2018 16:23, Michael Rehder wrote:
> > > > Container "foo" would be mandatory if not for the "when" child element.
> > > > With the "when" child element, the logic becomes "inverted" and
> > > > the
> > > constraint is a negative one of "disallowed under certain condition".
> > > >
> > > > The UC is for enforcement in REST API payloads.
> > > > For a practical example:
> > > >
> > > >           leaf AssignmentMechanism {
> > > >              type enumeration {
> > > >                enum "DHCP";
> > > >                enum "Static";
> > > >              }
> > > >              mandatory true;
> > > >              description "The address assignment mechanism.";
> > > >            }
> > > >            list IPAddresses {
> > > >              when "../AssignmentMechanism = 'Static'";
> > > >              key Address;
> > > >              min-elements 1;
> > > >
> > > >              leaf Address {
> > > >                type capit:IPv4Address;
> > > >                description "An ipv4 address.";
> > > >              }
> > > >             }
> > > >
> > > > There is no way in the IPAddresses list to enforce that there is
> > > > at least one IP
> > > Address when the assignment method is "Static".
> > > > One could put a "must" on "AssignmentMechanism" to ensure at least
> > > > one
> > > element of the IPAddresses list when "Static", but I don't see this
> > > as a good schema design, to have the controlling attribute check controlled
> attributes.
> > > >
> > > > I appreciate that this semantic can't be changed in YANG at this point.
> > > > Could the "when" statement have a modifying child element to state
> > > > that the
> > > mandatory status of the element is to be enforced?
> > > > Like
> > > >      container foo {
> > > >        when "condition" {
> > > >            enforce-mandatory-status;
> > > >        }
> > > >
> > > > There is already back-end for existential checks for mandatory
> > > > choice so this
> > > seems reasonably consistent to me.
> > > > I appreciate there are existing issues for "when" but I don't see
> > > > why this
> > > would make things any worse.
> > > > In fact by promoting a better dependency "direction" between
> > > > schema
> > > elements,  think it could simplify things (so I naively think :) ).
> > > >
> > > > Thanks
> > > > Mike
> > > >> -----Original Message-----
> > > >> From: Ladislav Lhotka [mailto:lhotka@nic.cz<mailto:lhotka@nic.cz>]
> > > >> Sent: Wednesday, October 10, 2018 10:28 AM
> > > >> To: Michael Rehder <Michael.Rehder@Amdocs.com<mailto:Michael.Rehder@Amdocs.com>>; 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<mailto:Michael.Rehder@Amdocs.com>> writes:
> > > >>
> > > >>> I have a question about “when” and mandatory objects.
> > > >>>
> > > >>> It seems to me that the implemented semantics of “when” are
> > > >>> really
> > > >> “optional when”, in that the enclosing object can be absent even
> > > >> though it is mandatory and the “when” clause holds true.
> > > >>> The RFC could be clearer about this.
> > > >>>
> > > >>> Example
> > > >>>
> > > >>>     leaf color {
> > > >>>       enumeration  {
> > > >>>          enum “blue”;
> > > >>>          enum “black”;
> > > >>>       }
> > > >>>       mandatory true;
> > > >>>     }
> > > >>>     container foo {
> > > >>>        when ../color = ‘blue’;
> > > >>>        etc.
> > > >>>     }
> > > >>>
> > > >>> “foo” is optional due to the presence of the “when” statement
> > > >>> even though the object is mandatory (same is true for mandatory
> > > >>> leaf,
> > > >>> min-elements=1 list etc.).
> > > >> Maybe you intended to have, e.g., a "mandatory true" leaf inside
> > > >> "container foo"?
> > > >>
> > > >>> This is considered valid XML for the above
> > > >>>      <color>blue</color>
> > > >> Yes, it is, under current YANG rules, no matter what "etc."
> > > >> stands for. Note that evaluation of the XPath expression in this
> > > >> case (with "foo" missing) requires the peculiar procedure of sec. 7.21.5
> in RFC 7950.
> > > >>
> > > >>> In my view this makes conditionally variant schemas “loose” in
> > > >>> their enforcement (some scenarios can use choice but it doesn’t
> > > >>> cover everything).
> > > >>>
> > > >>> I think that mandatory should be respected for the enclosing
> > > >>> objects of a “when” statement.  That is, a mandatory object must
> > > >>> be present when its “when” clause holds true and a Schematron
> > > >>> statement should enforce that.
> > > >> In fact, this is one case where the DSDL mapping (RFC 6110)
> > > >> deviates from YANG 1.0. Nodes that mandatory aren't enclosed in
> > > >> the RELAX NG <optional> pattern, and are then required no matter what
> any "when"
> > > >> statements say (because RELAX NG validation comes before
> Schematron).
> > > >>
> > > >>> What is the rationale behind the current YANG rules behavior,
> > > >>> that the “when” Schematron mapping doesn’t check for presence of
> > > >>> the enclosing mandatory object?
> > > >> FWIW, I have been repeatedly protesting against this behaviour
> > > >> but without much luck. See for example
> > > >>
> > > >> https://www.ietf.org/mail-archive/web/netmod/current/msg14012.htm
> > > >> l
> > > >>
> > > >> As a result, "when" is the trickiest feature in YANG by far.
> > > >>
> > > >> Lada
> > > >>
> > > >>> thanks
> > > >>> Mike Rehder
> > > >> --
> > > >> 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
> >
> > “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
>
> --
> 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

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