[netmod] NMDA <operational> output with "when' condition

Rohit R Ranade <rohitrranade@huawei.com> Wed, 11 July 2018 14:23 UTC

Return-Path: <rohitrranade@huawei.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 B4109130E8D for <netmod@ietfa.amsl.com>; Wed, 11 Jul 2018 07:23:27 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 mCJESXvO06qJ for <netmod@ietfa.amsl.com>; Wed, 11 Jul 2018 07:23:26 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 F1F6212DD85 for <netmod@ietf.org>; Wed, 11 Jul 2018 07:23:25 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 40E96F9086305 for <netmod@ietf.org>; Wed, 11 Jul 2018 15:23:22 +0100 (IST)
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 11 Jul 2018 15:23:23 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.43]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0382.000; Wed, 11 Jul 2018 22:23:13 +0800
From: Rohit R Ranade <rohitrranade@huawei.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: NMDA <operational> output with "when' condition
Thread-Index: AdQZIp19LVusgahBSiC+KJHgNolIDA==
Date: Wed, 11 Jul 2018 14:23:12 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BBD305F@dggeml510-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BBD305Fdggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/jduxZt8zw-7LJYylbdkHcoAm8vc>
Subject: [netmod] NMDA <operational> output with "when' condition
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
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, 11 Jul 2018 14:23:28 -0000

Hi All,

Consider the model below:
----------------------------------
list list1{
  key f1;
  leaf f1{
    type string;
  }
  leaf f2{
    when "../f1='hello'";
         type string;
  }
}

The intention of this model is to allow configuration of leaf f2 by user, only when value of f1 is 'hello'. For all other values of f1, say 'foo', the system will internally choose some value say 'bar'.
When query all fields on <operational>, using condition f1='foo', if need to output its corresponding f2 value (i.e 'bar') the when condition will get violated .  Is there some way to keep the restriction on <running> , but relaxing it when showing the <operational> output ?

RFC 8342 has the below section , but I think we cannot use the statements below as there is no "abnormal" value here.
   <operational> SHOULD conform to any constraints specified in the data
   model, but given the principal aim of returning "in use" values, it
   is possible that constraints MAY be violated under some circumstances
   (e.g., an abnormal value is "in use", the structure of a list is
   being modified, or remnant configuration (see Section 5.3.1) still
   exists).

Any help is appreciated.

With Regards,
Rohit R Ranade