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

Robert Wilton <rwilton@cisco.com> Tue, 16 October 2018 16:06 UTC

Return-Path: <rwilton@cisco.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 B0040130E5F for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 09:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.491
X-Spam-Level:
X-Spam-Status: No, score=-14.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 tyWjU_TMTQXE for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 09:06:23 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68EA2130E5B for <netmod@ietf.org>; Tue, 16 Oct 2018 09:06:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20452; q=dns/txt; s=iport; t=1539705982; x=1540915582; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=wPeZSF82SNEHm0V3dnwoKHBJIVpWFnxfp4/FEv9BMYk=; b=l9qJe6adeBmusp0mt61kCa8wod11Ytec7ju6P3mAqYDkve2Jkgyn/7CJ bNeLYWMJQlEcZs84JvlnT6fTPaxoq4FHyaUjCuO0RrJ2rhkK8Y2Y8elta xAaf95V7KMzjLxhxz7WEESHqOVJDWZNL3YGKBSc6p8TfDEHm6v/t2LpZb o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AHAACTC8Zb/xbLJq1gAxkBAQEBAQEBAQEBAQEHAQEBAQEBgVMCAQEBAQELAYEMAUeBFW0SKIN1iHaNLwgllwcUgWYNGAEKhANGAoUINgsNAQMBAQIBAQJtHAyFOQEBAQMBAQEhCkELBQcCAgkCEAEEAQEBIwQDAgIbDB8JCAYNBgIBAYMcAYF5CA+KXJtNgS4fhRuEYQUFi16BQT+BEicMgl+DGwEBgS4BCwcBCRwbFRGCPIJXAokMhnCEOYl1CZBVBheBT4deJoZLj3aGN4FKBitkcTMaCBsVO4Jsgk6DaYRhhT8+MIkoAg0XB4IgAQE
X-IronPort-AV: E=Sophos;i="5.54,389,1534809600"; d="scan'208,217";a="7233244"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Oct 2018 16:06:20 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w9GG6Jam024278; Tue, 16 Oct 2018 16:06:19 GMT
To: Michael Rehder <Michael.Rehder@Amdocs.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
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> <9d1627e3-8a0d-491e-1d2d-ed589e12b1c5@cisco.com> <AM0PR06MB4083F4308E68CC156082B2B8E7FE0@AM0PR06MB4083.eurprd06.prod.outlook.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <b71d4a5f-d7d7-0467-9f07-efebd22ce252@cisco.com>
Date: Tue, 16 Oct 2018 17:06:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <AM0PR06MB4083F4308E68CC156082B2B8E7FE0@AM0PR06MB4083.eurprd06.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------7E3D8A655F317CC1C1EBA036"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.63, dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/bOvJVavut5q4h8TbNKEVwnht3gc>
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: Tue, 16 Oct 2018 16:06:31 -0000

Hi Mike,


On 16/10/2018 16:34, Michael Rehder wrote:
>
> Ok, so it is there in the RFC, just somewhat separated (in my view) 
> from the definition of “when”.
>
> I still am somewhat surprised by this implementation.
>
> Far more often the I see a need to enforce the presence of a variant.
>
I'm sorry, but I still haven't seen you provide any concrete example in 
YANG where this is useful.

Early in the thread you provided an example with static/dynamic IP 
addresses, and wrote 'There is no way in the IPAddresses list to enforce 
that there is at least one IP Address when the assignment method is 
"Static".'.  But as I replied previously, for YANG at least, this 
statement is wrong since your YANG achieves exactly that constraint!

Specifically, if you have a server that implements the YANG module that 
you provided and a client attempted to configure it via NETCONF or 
RESTCONF then the server would enforce that either the assignment is 
DHCP or at least one static IP address is provided, otherwise the config 
change would be rejected.

I think that your issue may be more with how the YANG is translated via 
the methods in RFC 6110 (which I am not familiar with), but that doesn't 
mean that there is a problem with the YANG definition itself.  Allowing 
mandatory/min-elements/max-elements to have precedence over 'when' 
doesn't make much sense to me, I'm missing a concrete example where it 
seems that this would be useful, certainly your IP address example does 
not require it.

Thanks,
Rob


> Thanks
>
> Mike
>
> *From:*Robert Wilton [mailto:rwilton@cisco.com]
> *Sent:* Tuesday, October 16, 2018 9:42 AM
> *To:* Michael Rehder <Michael.Rehder@Amdocs.com>; 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
>
> Hi Mike,
>
> On 16/10/2018 14:26, Michael Rehder wrote:
>
>     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).
>
>     The section on "WHEN" just mentions the xpath mapping, not anything about changing the mandatory status of the enclosing node.
>
>     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).
>
> By YANG RFC do you mean RFC 6020/7950?
>
> Section 8.1 of RFC 7950 states the following constraints apply on 
> valid data trees:
>
>     o  There MUST be no nodes tagged with "when" present if the "when"
>        condition evaluates to "false" in the data tree.
>     o  The "mandatory" constraint is enforced for leafs and choices,
>        unless the node or any of its ancestors has a "when" condition or
>        "if-feature" expression that evaluates to "false".
>     o  The "min-elements" and "max-elements" constraints are enforced for
>        lists and leaf-lists, unless the node or any of its ancestors has
>        a "when" condition or "if-feature" expression that evaluates to
>        "false".
> These rules indicate that "when" trumps "mandatory", "min-elements" and "max-elements".
> Thanks,
> Rob
>   
>
>     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> <mailto: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
>
>         Fax:   +49 421 200 3103<https://www.jacobs-university.de/>
>         <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”./
>