Re: [netmod] datastore-specific constraints

Ladislav Lhotka <lhotka@nic.cz> Thu, 13 December 2018 11: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 9BF1D12D4E8 for <netmod@ietfa.amsl.com>; Thu, 13 Dec 2018 03:58:54 -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 B-fOYx0Rkxj8 for <netmod@ietfa.amsl.com>; Thu, 13 Dec 2018 03:58:51 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 9F182123FFD for <netmod@ietf.org>; Thu, 13 Dec 2018 03:58:50 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 6063D60882; Thu, 13 Dec 2018 12:58:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1544702327; bh=bw0aoeFSGU1mDjtE4nwZzqY2OfEXbn7RJGwwj5z6L34=; h=From:To:Date; b=j2yGKL1Dk++5n5vyjqOY6LK4OMKKlhee84LKZoWpXb5RfoK0DTI5BjLorgAWoG5OM MPS/n8j/OWzhgFMXRxw65umS9LYOCsbCh7uBpuRF1sJw3+2sHy24rRv+pWZTADs0GW PJwf6mLAD5Z57JRvwPnYANFXEBlXev+dSS/1z6kc=
Message-ID: <4adac832a12e852e6fc3ad5a11e19085a991e257.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Robert Wilton <rwilton@cisco.com>, Martin Bjorklund <mbj@tail-f.com>
Cc: janl@tail-f.com, netmod@ietf.org
Date: Thu, 13 Dec 2018 12:58:47 +0100
In-Reply-To: <dba07666-e229-96f4-8e94-e5403e082c87@cisco.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> <f962e20f8dfbe8f21db0abc399851f8acd454ed9.camel@nic.cz> <dba07666-e229-96f4-8e94-e5403e082c87@cisco.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/rZVmbwwxB-lRpJ5yv0bGU25NYYM>
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:58:55 -0000

On Thu, 2018-12-13 at 11:08 +0000, Robert Wilton wrote:
> 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.

MAY means "truly optional" (e.g. "because the vendor feels that it enhances the
product"). Combining different RFC2119 terms is generally problematic.

Lada

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