Re: [netmod] datastore-specific constraints

Robert Wilton <rwilton@cisco.com> Thu, 13 December 2018 11:08 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 2A9D11294D7 for <netmod@ietfa.amsl.com>; Thu, 13 Dec 2018 03:08:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.961
X-Spam-Level:
X-Spam-Status: No, score=-15.961 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, 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 W4vREuw2me7V for <netmod@ietfa.amsl.com>; Thu, 13 Dec 2018 03:08:46 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF641286E3 for <netmod@ietf.org>; Thu, 13 Dec 2018 03:08:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5171; q=dns/txt; s=iport; t=1544699325; x=1545908925; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ySclL5U0CwAa4Z0joW1WUew8VexAzVj/Ji1hQnDFiV0=; b=TCMRgc5Uhh/WpXssMOVSFejUEF9ovy3wVX4c41iDxxGmZKkVoleQkxry pFCIMRu+1YRlVIGED/cu+OcIkKNl49Gqec7XIU2SiUKNQXp3PAAAG4H3l t2BTb2V36/jjNh1vPHizI4BTrp5DcFk+Dl7mAcKKKff57cM7JeO58N8ZP U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTAAA2PRJc/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYJqcBIng3yIeI0TLZlODRgLhANGAoMkOBIBAwEBAgE?= =?us-ascii?q?BAm0cDIU8AQEBAQIBAQEhFTYLEAsYAgImAgInMAYBDAYCAQGDHQGBeAgPpmC?= =?us-ascii?q?BL4VAhG8FgQuLSIFAP4ERJ4Jrgx4BAYFLgxqCVwKQDpAsVQmRUwYYiXyHTok?= =?us-ascii?q?uiTGGaoFdIYFWMxoIGxU7gmyLHIU/PwMwjVgBAQ?=
X-IronPort-AV: E=Sophos;i="5.56,348,1539648000"; d="scan'208";a="8837118"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2018 11:08:43 +0000
Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id wBDB8gHv017628; Thu, 13 Dec 2018 11:08:42 GMT
To: Ladislav Lhotka <lhotka@nic.cz>, Martin Bjorklund <mbj@tail-f.com>
Cc: janl@tail-f.com, netmod@ietf.org
References: <BE57F393-5E00-4877-BA04-7B980DDB3CDF@tail-f.com> <2c2eff9a-4cdb-d755-dc2b-05c01d8c8d1d@cisco.com> <b434351564e5244c1341a247b819e5fe935788e5.camel@nic.cz> <20181213.095139.2195805691286738924.mbj@tail-f.com> <f962e20f8dfbe8f21db0abc399851f8acd454ed9.camel@nic.cz>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <dba07666-e229-96f4-8e94-e5403e082c87@cisco.com>
Date: Thu, 13 Dec 2018 11:08:42 +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: <f962e20f8dfbe8f21db0abc399851f8acd454ed9.camel@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
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-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/QiCUWaLh_qEL47I7_BYmKbjdco4>
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: Thu, 13 Dec 2018 11:08:48 -0000

Hi Lada,

On 13/12/2018 09:58, Ladislav Lhotka wrote:
> On Thu, 2018-12-13 at 09:51 +0100, Martin Bjorklund wrote:
>> Ladislav Lhotka <lhotka@nic.cz> wrote:
>>> On Wed, 2018-12-12 at 15:23 +0000, Robert Wilton wrote:
>>>> 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.
>>> Another option could be that "must" constraints on config data do not apply
>> in
>>> <operational>, whereas constraints on "config false" data serve as binding
>>> guidelines for implementors.
>> Not sure what "binding guideline" means, but note that RFC 8342 says
>> for <operational>:
>>
>>     <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 [...]
> According to the definition of SHOULD and MAY in RFC 2119, this sentence
> contradicts itself.

I don't actually see the contradiction here.

- SHOULD can be violated if there are good reasons to do so (otherwise 
it is a MUST)
- The MAY, and its associated condition, explains some conditions under 
which it is reasonable for the SHOULD to be violated.

Thanks,
Rob


>
>>     Only semantic constraints MAY be violated.  These are the YANG
>>     "when", "must", "mandatory", "unique", "min-elements", and
>>     "max-elements" statements; and the uniqueness of key values.
> It is nice to see "when" listed among semantic constraints. Note, however, that
> in sec. 8.1 of RFC 7950, "when" ended up among the constraints that are true in
> all data trees (despite my hefty protests in the past). So this is really weird.
>
> Lada
>
>> It would be useful with a YANG statement that indicates when the
>> modeller's intention is that a constraint doesn't apply to
>> <operational>.  For now, this can be indicated in the description
>> statement, for example:
>>
>>    leaf foo {
>>      when "../auto-foo = 'false'" {
>>        description
>>          "This when expression does not apply to <operational>.";
>>      }
>>      ...
>>    }
>>
>>
>>
>> /martin
>>
>>
>>
>>> Anyway, the logic of my example could then be implemented using "must". I
>> agree
>>> though that ignoring the configured value if auto-foo is true may be
>> preferable.
>>> Lada
>>>
>>>
>>>> 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> 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
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> -- 
>>> Ladislav Lhotka
>>> Head, CZ.NIC Labs
>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>