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

Robert Wilton <rwilton@cisco.com> Fri, 12 October 2018 16:05 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 8795E130E36 for <netmod@ietfa.amsl.com>; Fri, 12 Oct 2018 09:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, 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 zXaEsBPs9w1x for <netmod@ietfa.amsl.com>; Fri, 12 Oct 2018 09:05:41 -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 D5EC5130DEB for <netmod@ietf.org>; Fri, 12 Oct 2018 09:05:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9246; q=dns/txt; s=iport; t=1539360341; x=1540569941; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=aRJ6P+miVngcWkYlaPLxkTaHjEDtqQPz3d1vFnMQG90=; b=Tk+3DK0DWHmzT6hTDypg2Ts1NbDdwfXejDUTLzKlX/P6lgr6FzNuZY1x g+BRo53dtx/XvbSWXPQShoblN0cHphm5rGDnrT7JVHLFBRAKGi1qOU25k xCk7avIKon36OfnV5UM7xZNb7TxVwCDU2vPozgNLoba7GQFkd+XlKui7K A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfAAAqxcBb/xbLJq0ZAUoaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFlAoELgkoSKIN1iHWNMi2RP4dCDYRsAoR9OBYBAwEBAgE?= =?us-ascii?q?BAm0ohTkBAQEBAgEjVgULCxgjBAMCAkYRBg0GAgEBgxyBegiIa50IgS4fhFi?= =?us-ascii?q?EYotdgUE/gTmCa4d/glcCnhwJkFIGF4FPhG+Ca4Ztj26GNoFaIYFVMxoIGxU?= =?us-ascii?q?7gmyCTo4JPjCMZAEB?=
X-IronPort-AV: E=Sophos;i="5.54,373,1534809600"; d="scan'208,217";a="7135301"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2018 16:05:38 +0000
Received: from [10.61.220.128] ([10.61.220.128]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w9CG5a3X023556; Fri, 12 Oct 2018 16:05:37 GMT
To: Michael Rehder <Michael.Rehder@amdocs.com>
Cc: Andy Bierman <andy@yumaworks.com>, "Walker, Jason (Jason_Walker2@comcast.com)" <Jason_Walker2@comcast.com>, "netmod@ietf.org" <netmod@ietf.org>
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> <DB6PR06MB4085D91F66023AC98122FEDFE7E10@DB6PR06MB4085.eurprd06.prod.outlook.com> <CABCOCHRR92w3ouFmi6igg+AN=TM7BKfnaMiweOPxq_t9WTvvyg@mail.gmail.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>
Date: Fri, 12 Oct 2018 17:05:36 +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: <CABCOCHRR92w3ouFmi6igg+AN=TM7BKfnaMiweOPxq_t9WTvvyg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------4670FDBE1650E759BC2292E2"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.61.220.128, [10.61.220.128]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ksK5XaWc6zK_MwfGbhbVDfVfnis>
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: Fri, 12 Oct 2018 16:05:43 -0000

Hi Mike,


On 11/10/2018 19:05, Andy Bierman wrote:
>
>
> On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder 
> <Michael.Rehder@amdocs.com <mailto:Michael.Rehder@amdocs.com>> wrote:
>
>     I think the wording is relevant - something can be conditional but
>     still required.
>
Yes, but I think that this is already expressed by a node that has both 
a when condition and mandatory statement.

container a {
   container x {
     when "some condition";
     leaf foo {
       mandatory true;
     }
     leaf bar {
       ...
     }
   }
   container y {
     leaf baz {
       mandatory true;
     }
     leaf tee {
       ...
     }
   }
}

a/x/foo is conditional (due to when) but required (if the when condition is met).
a/x/bar is conditional (due to when) but optional (if the when condition is met).
a/y/baz is unconditional but required.
a/y/tee is unconditional but optional.


>     It should be clarified that elements become implicitly “mandatory
>     false” when a “when” statement is used.
>
But they don't.

>     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”.
>
I'm trying to understand what this would even mean.

Taking your original example, but with "enforce-mandatory-status":

          leaf AssignmentMechanism {
             type enumeration {
               enum "DHCP";
               enum "Static";
             }
             mandatory true;
             description "The address assignment mechanism.";
           }
           list IPAddresses {
             when "../AssignmentMechanism = 'Static'" {
               enforce-mandatory-status;
             }  key Address;
             min-elements 1;
             
             leaf Address {
               type capit:IPv4Address;
               description "An ipv4 address.";
             }
            }


So this means that list IPaddresses must have at least one element 
regardless of whether the when condition holds.  I.e. no matter whether 
the assignment is DHCP or Static there must always be at least one 1 
address configured.  But I don't understand what this actually means - 
it seems like a contradiction.  What am I missing? Please can you give a 
concrete example (in YANG) of what behaviour you are looking for.

Thanks,
Rob