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

Andy Bierman <andy@yumaworks.com> Wed, 17 October 2018 18:21 UTC

Return-Path: <andy@yumaworks.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 DB1B1130E01 for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 11:21:58 -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 (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 55K2ZqCnqylm for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 11:21:55 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8224130DC7 for <netmod@ietf.org>; Wed, 17 Oct 2018 11:21:54 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id p143-v6so9534907lfp.13 for <netmod@ietf.org>; Wed, 17 Oct 2018 11:21:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fe0A6dGjDcPw0DBHyJ15idOGT73kAukoMr+JgBZfHio=; b=HzZ0C4XThsqr0XG//qy22nfmu++5xtiDBTL22U0ZJixZ9DIy32YjJyEvHvxC2TNTqd Zc2O3bnoC2MpPli6zhDmzx+szgENgRSnFc3B9TcUlF0AcB9kJRhtELffwwLdsXQ3XhyR nwDlfar3YYTOdYIZkDqoQK3OR0e3kJK9j6xeildVLvyQ5yyMjLVNeFKOQN4j0Y/xfdZs lj85JhMyLWSnjayOYI2+Ltnq9FDZT3hPUk9mtLlFATx7RpcjLVra9aeYW1RUSfrlkPEB XLtLIXGqVZS0Z7iMYcCK8kUSBIQG1WbOwQw1+JfSYUGLxh2yAra+0gEKLEtC5QjrTodo m+sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fe0A6dGjDcPw0DBHyJ15idOGT73kAukoMr+JgBZfHio=; b=dk456SfcnWAB9M2PWC242GHVa6MCrvWMhLuju2H39v2QiyLDgzgaitb18uoq4362/Y mWWt1Ho8GAKZazhWLHcNeybPAJxI7U3SRypEw7niv9ccV702ZkRwjsPTcoLOs4A2fXGt +02UHdP8LHaHEHCrKj0ds6RoFQzZF1VUaCHz0wk6jt7horhXVJNXUhpAh3kbOBxkDDOk ACnoVygoXJ6ZtTwjLegOC9rzDYoRo0bvL9JiFU81H1w4SShB6jSI8EG1UYAqd4tQyLco 6ScN06dLF2j6vK+72JyV0BeX3qCgBa9DhGXcI5eySVdD0nLCczoaz5iSOUYIKqPBAQ0g PcFA==
X-Gm-Message-State: ABuFfoiJ71mLjgao0EBXVqMczAIrzJ001J0qK4o/V0jfnW/admxlMmc6 6m+vrNQdNLzTsdV04omS7G0VcusIPmAgVBh1zN46JiwO
X-Google-Smtp-Source: ACcGV627UBbSk/3sxq8upKm6XVGAoso0/6T8f2NOH3YRiopTSeHkP1mKC4cclaTxJXYJvVb2JFXac7FM3KgXGohZua0=
X-Received: by 2002:a19:8d11:: with SMTP id p17-v6mr15603279lfd.116.1539800512811; Wed, 17 Oct 2018 11:21:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Wed, 17 Oct 2018 11:21:50 -0700 (PDT)
In-Reply-To: <AM0PR06MB4083997E335CBAA6FAA3B074E7FF0@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> <87woqhhsk4.fsf@nic.cz> <AM0PR06MB4083997E335CBAA6FAA3B074E7FF0@AM0PR06MB4083.eurprd06.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 17 Oct 2018 11:21:50 -0700
Message-ID: <CABCOCHQ-wOp_nkoKwYE1frH2uOaGC6QfN_=4=cOXUS+eg2Gxxg@mail.gmail.com>
To: Michael Rehder <Michael.Rehder@amdocs.com>
Cc: Ladislav Lhotka <lhotka@nic.cz>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000976f75057870beb8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/2DOr9CXOX3iXBwZbsaicN2z9TZg>
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 18:21:59 -0000

On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder <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]
> > Sent: Wednesday, October 17, 2018 4:43 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
> >
> > 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]
> > >> Sent: Saturday, October 13, 2018 5:20 PM
> > >> To: Michael Rehder <Michael.Rehder@Amdocs.com>
> > >> Cc: 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
> > > 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
> https://www.ietf.org/mailman/listinfo/netmod
>