Re: [netmod] datastore-specific constraints

Ladislav Lhotka <lhotka@nic.cz> Thu, 13 December 2018 09:58 UTC

Return-Path: <lhotka@nic.cz>
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 DD53C130FD4 for <netmod@ietfa.amsl.com>; Thu, 13 Dec 2018 01:58:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 TJijL-SABABp for <netmod@ietfa.amsl.com>; Thu, 13 Dec 2018 01:58:48 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 AD913130F8B for <netmod@ietf.org>; Thu, 13 Dec 2018 01:58:46 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 47EFF629F2; Thu, 13 Dec 2018 10:58:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1544695123; bh=OWOVic3YyXC9xLV+A0K2R0zp/i4gF7IlN5CVJwNuRKs=; h=From:To:Date; b=MJXoDBU9PlP6CuRRR0Ft4djIV7Adug0LhF5/GIYQiVSm2UbVAvRZkostD8GEy9Pxl MQo+kXABlVN3nLgv68p7rvc73J36hsy7xhnzLPsUt28QMX+hD8MLheNOtMgF0M7QJp P2P1Lr6dcXIbBiVXV531x6DK4XKj71WQ91lp7C2M=
Message-ID: <f962e20f8dfbe8f21db0abc399851f8acd454ed9.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: rwilton@cisco.com, janl@tail-f.com, netmod@ietf.org
Date: Thu, 13 Dec 2018 10:58:43 +0100
In-Reply-To: <20181213.095139.2195805691286738924.mbj@tail-f.com>
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>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/G3IMUN41U6-hSL-OpNWn2zUyr_I>
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 09:59:00 -0000

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.

> 
>    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
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67