Re: [netmod] datastore-specific constraints

Robert Wilton <rwilton@cisco.com> Wed, 12 December 2018 15:24 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 A29A2130DFF for <netmod@ietfa.amsl.com>; Wed, 12 Dec 2018 07:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.959
X-Spam-Level:
X-Spam-Status: No, score=-15.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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, URIBL_BLOCKED=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 3mDp268O3w_q for <netmod@ietfa.amsl.com>; Wed, 12 Dec 2018 07:24:00 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD501130DF9 for <netmod@ietf.org>; Wed, 12 Dec 2018 07:23:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8247; q=dns/txt; s=iport; t=1544628240; x=1545837840; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=bTm99cKykeUYyzNKvq0bMtTbViU/bTpv3UI2jvw+Tbg=; b=SGWMKpMFk0UnqwK2jMW376Oh4uV0wdX1sQE7R+mmjvhNIwNMqep2F8El 1xIx4hWmz0vMpFWIVbyqw7HuevgyYy4X5CGH+eRcEi49LEPGYyUVn64aI GHXSP/KVv8BGCAXaIaDytOVZfRmgfBy8HyZPB2lcyI1vg73mbq5Wrxn5H g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ARAAC3JhFc/xbLJq1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUwIBAQEBAQsBgmlwEieMc40TLZF6hVmBeg0YAQqEA0YCgx42Bw0BAwEBAgEBAm0cDIU9AQEEAQFsGwsYJwcnHxEGAQwGAgEBgx0BggEPpw8fhSGEaQWMU4FAP4ERJ4Jrgx4BAYFLhXECoQwJkVEGGIl5h02JKYkthmmBTQonKIEuMxoIGxU7gmyLHIU/PwMwjgMBAQ
X-IronPort-AV: E=Sophos;i="5.56,344,1539648000"; d="scan'208,217";a="8752018"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2018 15:23:54 +0000
Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id wBCFNqUv017017; Wed, 12 Dec 2018 15:23:52 GMT
To: Jan Lindblad <janl@tail-f.com>, Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org
References: <87zhtan7bo.fsf@nic.cz> <BE57F393-5E00-4877-BA04-7B980DDB3CDF@tail-f.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <2c2eff9a-4cdb-d755-dc2b-05c01d8c8d1d@cisco.com>
Date: Wed, 12 Dec 2018 15:23:52 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <BE57F393-5E00-4877-BA04-7B980DDB3CDF@tail-f.com>
Content-Type: multipart/alternative; boundary="------------4B656F997B2E1AC819AF956B"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.68, dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/vx2tUQb2BgjqVNiL1GrCdWKuuHE>
Subject: Re: [netmod] datastore-specific constraints
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, 12 Dec 2018 15:24:12 -0000

Hi Lada,

I basically agree with Jan's suggestion.

I don't think that I would use a when statement for this scenario since 
you want a leaf to report the operational value that is in effect, and 
one of the aims of NMDA is to try and get the configured and operational 
value onto the same path wherever possible.

But, I think that the question about validity of must statements is more 
interesting.  RFC 8342 states that these can be violated in operational, 
but the intention is that the constraints in <operational> should 
generally apply (but never be actually checked by the server).  In this 
case, it might be useful to be able to annotate a must statement to 
indicate that it only applies to configuration data and not operational 
data.

Thanks,
Rob


On 12/12/2018 14:52, Jan Lindblad wrote:
> Lada,
>
> Maybe you could just skip the when and explain the behavior in the 
> description? E.g.
>
> leaf foo {
>  ...
>  description "Foo controls bla, bla.
>   Any configured value will be ignored when auto-foo is true.";
> }
>
> Best Regards,
> /jan
>
>> On 12 Dec 2018, at 15:33, Ladislav Lhotka <lhotka@nic.cz 
>> <mailto:lhotka@nic.cz>> wrote:
>>
>> Hi,
>>
>> in some cases, constraints expressed with "when" or "must" may only be
>> intended for configuration datastores. A typical example is an
>> auto-negotiable parameter:
>>
>> leaf auto-foo {
>>  type boolean;
>>  default true;
>>  description "If true, parameter 'foo' will be auto-negotiated.";
>> }
>> leaf foo {
>>  when "../auto-foo = 'false'";
>>  ...
>> }
>>
>> This means that if auto-foo is true, it is impossible to configure the
>> foo parameter. However, even with auto-foo = true, it is desirable to
>> see the auto-negotiated value in <operational>, so, ideally, the "when"
>> constraint should not apply in <operational>.
>>
>> How can this logic be modelled under NMDA? Is an extra leaf
>> "foo-operational" needed?
>>
>> Thanks, Lada
>>
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org <mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod