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

Ladislav Lhotka <lhotka@nic.cz> Thu, 11 October 2018 05:58 UTC

Return-Path: <lhotka@nic.cz>
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 D4D86130E2B for <netmod@ietfa.amsl.com>; Wed, 10 Oct 2018 22:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 k5aSkEotUAuC for <netmod@ietfa.amsl.com>; Wed, 10 Oct 2018 22:58:50 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 9133E130E04 for <netmod@ietf.org>; Wed, 10 Oct 2018 22:58:49 -0700 (PDT)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 6CF0A600DA; Thu, 11 Oct 2018 07:58:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1539237526; bh=rGQnaj6LANmSenacISTViGsFOTcL+kfcBy+FpPedVOQ=; h=From:To:Date; b=G6EgTCCoHK5KFxFkVBGYbaneYim1oFVeefqzYZJMy892fx+TzwsY46dN8AeGmzbm2 p7JXbeaTswKvhb1NfxCNpRyYcw85bJwDYuua6uCvfVh7TDBnxU0/b/jquM5wCI97Uz YWNHTa+lrq/tc2RuPXRFEImAOnNI8vwI9i/9tQRA=
Message-ID: <0eddc4f5aa4a719d4fec39041696e05f00a7829d.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Michael Rehder <Michael.Rehder@Amdocs.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Cc: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>, "Walker, Jason (Jason_Walker2@comcast.com)" <Jason_Walker2@comcast.com>
Date: Thu, 11 Oct 2018 07:58:46 +0200
In-Reply-To: <AM0PR06MB4083AB058834759ECEA3FEEEE7E00@AM0PR06MB4083.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>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.1
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/8DDYMCkcGjWKD4sJdwrtEqKXX8c>
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 05:58:54 -0000

On Wed, 2018-10-10 at 18:44 +0000, Michael Rehder 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.

Data nodes in YANG are optional by default and become mandatory only in certain
cases (in RFC 6020 these cases were specified in section 3.1). In contrast,
RELAX NG <element> patterns are mandatory by default and <optional> is used to
make them optional.

Lada

> 
> 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]
> > Sent: Wednesday, October 10, 2018 2:25 PM
> > To: Michael Rehder <Michael.Rehder@Amdocs.com>
> > Cc: Robert Wilton <rwilton@cisco.com>; Ladislav Lhotka <lhotka@nic.cz>;
> > netmod@ietf.org; Walker, Jason (Jason_Walker2@comcast.com)
> > <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]
> > > > Sent: Wednesday, October 10, 2018 11:33 AM
> > > > To: Michael Rehder <Michael.Rehder@Amdocs.com>; Ladislav Lhotka
> > > > <lhotka@nic.cz>; netmod@ietf.org
> > > > Cc: Walker, Jason (Jason_Walker2@comcast.com)
> > > > <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]
> > > > > > Sent: Wednesday, October 10, 2018 10:28 AM
> > > > > > To: Michael Rehder <Michael.Rehder@Amdocs.com>; 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 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
> > > > > 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
> > > 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”.
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67