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

Andy Bierman <andy@yumaworks.com> Wed, 17 October 2018 21:54 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 18818130E00 for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 14:54:49 -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 DiK0efB7XTN3 for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 14:54:46 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 849B1130DFF for <netmod@ietf.org>; Wed, 17 Oct 2018 14:54:45 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id q39-v6so20993645lfi.8 for <netmod@ietf.org>; Wed, 17 Oct 2018 14:54:45 -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=loHnknnmGRdsl8qkL7e1hqXM3pvAIBCFNkREd9rKvCk=; b=pI9QYHHcQnAZVnmLDgAYQTN/3PwDwRSOflCi8uB1oGXBAuoyp8zVakNU0ybmKCvY3d AwwSLy5cnV6K5OngE7whGVl5IAQWDkrEhjyTP7UxoAgrnhvtfo3/1EYEwz1WGYwYMme3 KRhl0Od2stK4ojhe6cLoBFgpGEesPL/+ilqFqB/0Bml6atrFlkpTi28GrqwajCC68iiI /m6Rx14PTMtEYMV0eaCxilLNQmXiqI9cvDcgBm8J3svgvf2UuET/vKQeFFrNjz9XyAmD cuUb66wfuNvWZ2TOsBorgRhTD62lpHYI/d0ebOYm1inbtep5DZKRrZ439TDlReQQY/bc F0Hw==
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=loHnknnmGRdsl8qkL7e1hqXM3pvAIBCFNkREd9rKvCk=; b=gx/KaMxgwFvSaPou9vJ4Z8nDAiyusso9S+ymkHEKTZ+XdFMqgsySZP6VF3IOqNKSFh NwdZuaj8Ira3iYrpSGlcZhAeNpkWjKXWfguolAL8suCENiqMKs/2H45oMub0cOLJkKFk VJT1j0CvWTDt1tnBc9jAJW7XrZ4NHlutCJwGHCzjsk9ccADLaferRkJSTnDO+TsrEnQL czdwaxZQwCCQRb9XU9cy7VdkNSA/CJZ9j3OQNm890bt0T4/IdNskcWyRePROyKT/xQ2/ UiuatxtUrZr3QMoTgwQp6YdhITs2eDjdhAij1EbMeIKpsRIuLvgAmN/DhtMiFN61Wou1 inhA==
X-Gm-Message-State: ABuFfogZw8AmS5HvcIHKU8j2XqkyjU4uzkTbu/0mqTyLUyUYCBiBygnw FP3yOZu7belth8/wDQbCvUGD+z36v1YbHggywMfAdg==
X-Google-Smtp-Source: ACcGV631cT9AU2x2A/PaA4anfK+zyv8iTxCd5BrJw/XLDh7/5R4P8X8wsgDvTpGRIgfVwVGoTH9N4dXMhJOXqzdvCxg=
X-Received: by 2002:a19:8d11:: with SMTP id p17-v6mr15956004lfd.116.1539813283541; Wed, 17 Oct 2018 14:54:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Wed, 17 Oct 2018 14:54:42 -0700 (PDT)
In-Reply-To: <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> <1539812601446.35899@Aviatnet.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 17 Oct 2018 14:54:42 -0700
Message-ID: <CABCOCHTFSBznTmOSY5uUPCSkE7rT5-k7uis=35N3DTWXVDW7Qw@mail.gmail.com>
To: Alex Campbell <Alex.Campbell@aviatnet.com>
Cc: Michael Rehder <Michael.Rehder@amdocs.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c94bbb057873b7ea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/pCrtJSiwB8WYLpwb9LFPwCyoUPM>
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:54:49 -0000

On Wed, Oct 17, 2018 at 2:43 PM, Alex Campbell <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> 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> 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
>> <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
>> > > 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
>>
>
>