Re: [netmod] yang-data-ext issues

Ladislav Lhotka <lhotka@nic.cz> Wed, 02 May 2018 07:52 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 F123F1252BA for <netmod@ietfa.amsl.com>; Wed, 2 May 2018 00:52:22 -0700 (PDT)
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 qU_RE-ExACx2 for <netmod@ietfa.amsl.com>; Wed, 2 May 2018 00:52:19 -0700 (PDT)
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 AA7CC126C2F for <netmod@ietf.org>; Wed, 2 May 2018 00:52:18 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:8032:75ff:fe3c:7e68]) by mail.nic.cz (Postfix) with ESMTPSA id B5C77604E8; Wed, 2 May 2018 09:52:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1525247536; bh=XJ7QVnTQW3z2vimv7l5yxZNUbBH8ePe9aRuRIZcr0lA=; h=From:To:Date; b=hyo7XcIczDzAshM6A7JlhQeqy8EZKF6XQX5sL3m7F6ZQVSwmkrvAPwu+jmxkZOkvZ cpM3+Nlh3OlzrnvNbciOThXm2tXC8zKwYKegmsLYHRjpTXr7jXaNzxBaGaMnzdYBWw FAFSsYwGU/SDyWnSh5J6h1crWnnLe21O05/hoktk=
Message-ID: <1b0be1f979c8fc285461309a8d81702d16d66316.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: rwilton@cisco.com, netmod@ietf.org
Date: Wed, 02 May 2018 09:52:25 +0200
In-Reply-To: <20180502.091653.2180362536464006870.mbj@tail-f.com>
References: <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> <b9211ebacd24ffdd558ecf4da5bfa1ad71cfdabb.camel@nic.cz> <20180502.091653.2180362536464006870.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.1
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/WuS5U-EU6vP9V8jpWSTCFPJH5n8>
Subject: Re: [netmod] yang-data-ext issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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, 02 May 2018 07:52:23 -0000

On Wed, 2018-05-02 at 09:16 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > On Fri, 2018-04-27 at 12:19 +0100, Robert Wilton wrote:
> > > 
> > > On 27/04/2018 12:03, Ladislav Lhotka wrote:
> > > > On Fri, 2018-04-27 at 11:23 +0100, Robert Wilton wrote:
> > > > > On 27/04/2018 11:03, Martin Bjorklund wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > > > > On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote:
> > > > > > > > On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka <lhotka@nic.cz
> >
> > > > > > > > wrote:
> > > > > > > > > Ladislav Lhotka <lhotka@nic.cz> writes:
> > > > > > > > > 
> > > > > > > > > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote:
> > > > > > > > > > > On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka <lhotka@n
> ic.c
> > > > > > > > > > > z>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin
> Bjorklund
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > > > > > > > > > > > > Martin Bjorklund <mbj@tail-f.com> writes:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I am not sure what this statement tells us re.
> the
> > > > > > > > > > > > > > > > issue
> > > > > > > > > > > > > > > > in
> > > > > > > > > 
> > > > > > > > > this
> > > > > > > > > > > > email
> > > > > > > > > > > > > > > > thread.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > It tells us that, in my view, the approach taken
> in
> > > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > document
> > > > > > > > > 
> > > > > > > > > is a
> > > > > > > > > > > > > > > bad idea.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Do you mean that the WG shoud drop this document? 
> And
> > > > > > > > > > > > > > people that
> > > > > > > > > > > > > > need yang-data should continue to use the version in
> > > > > > > > > > > > > > 8040?  Or that
> > > > > > > > > > > > > > people that need yang-data do not have a valid use
> case
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > they
> > > > > > > > > > > > > > should do something else?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > One option is that people use yang-data as defined in
> RFC
> > > > > > > > > > > > > 8040
> > > > > > > > > > > > > until
> > > > > > > > > > > > 
> > > > > > > > > > > > IMO, people should use plain YANG. With the new YANG
> library
> > > > > > > > > > > > it
> > > > > > > > > > > > will be
> > > > > > > > > > > > possible
> > > > > > > > > > > > to confine such non-NM schemas in a special datastore so
> > > > > > > > > > > > that
> > > > > > > > > > > > the
> > > > > > > > > 
> > > > > > > > > intention
> > > > > > > > > > > > should be clear and multi-module schemas with all the
> > > > > > > > > > > > additional
> > > > > > > > > > > > data
> > > > > > > > > > > > (versions,
> > > > > > > > > > > >    features, deviations) can be used.
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > I don't see how yang-data interferes with "plain YANG" at
> all.
> > > > > > > > > > > It is for data that is not in scope for plain YANG.
> > > > > > > > > > 
> > > > > > > > > > My question is why this extension is needed in the first
> place.
> > > > > > > > > 
> > > > > > > > > For example, RFC 8040 could have used two modules instead of
> > > > > > > > > "ietf-restconf", one with the contents of grouping "errors"
> and
> > > > > > > > > the
> > > > > > > > > other with the contents of grouping "restconf". No extension.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > This is true. We used to do this before yang-data was available.
> > > > > > > 
> > > > > > > If I remember correctly, the stuff was inside groupings that were
> not
> > > > > > > used
> > > > > > > anywhere.
> > > > > > 
> > > > > > Which doesn't quite work, since no namespace is attached to the
> nodes.
> > > > 
> > > > Note that this is not what I was proposing. For RESTCONF errors, the
> module
> > > > I
> > > > had in mind could be like this:
> > > > 
> > > > module ietf-restconf-errors {
> > > > 
> > > >    container errors { // same content as in RFC 8040
> > > >      ...
> > > >    }
> > > > 
> > > >    ...
> > > > 
> > > > }
> > > > 
> > > > Please explain why this cannot serve the given purpose, apart from the
> fact
> > > > that
> > > > it looks like configuration which it isn't - but this can be explained
> in
> > > > the
> > > > module description.
> > > 
> > > It is the "because it looks like configuration" that I don't like.
> > 
> > IMO this won't change even if the same data is inside the "yang-data"
> extension
> > because RFC 7950 says in sec. 7.21.1:
> > 
> >    If the top node does not specify a "config" statement, the default is
> "true".
> > 
> > So even though the description of "yang-data" says that the "config"
> statement
> > is ignored if present, it doesn't mean that schema nodes lose the config
> > property.
> 
> No, this is not correct.  7.21.1 says:
> 
>    If "config" is not specified, the default is the same as the parent
>    schema node's "config" value.

And also:

   If the top node does not specify a "config" statement, the default is
   "true".

> 
> Note how it says *schema node*.  Nodes in a grouping that don't have a
> config statement don't have a config property.  Also, the same text
> about ignoring config is present for input/output/notfication.
> 
> Nodes in a yang-data extension statement thus also do not have a
> config value, since yang-data is not a data definition statement.

Are you saying that a container inside yang-data doesn't define a schema node?

> 
> This is an argument *for* an extension statement.  If you just define
> special nodes as normal nodes with a special description statement,
> you really break the rules for YANG.

I wouldn't *define* the schema nodes as special, just the resulting schema may
be used differently. This shouldn't matter as long as this data has nothing to
do with NETCONF or RESTCONF.

My main objections against yang-data are:

- additional complexity

- bad example (Need - or don't like - something in YANG? Just introduce an
extension.)

Lada

> 
> 
> /martin
> 
> 
> 
> > This may look like nitpicking but it illustrates the general problem: YANG
> was
> > designed for a very specific context and using it elsewhere requires
> creative
> > interpretation of its spec, with "yang-data" extension or without.
> > 
> > > 
> > > If the server supports and advertises this module then it is reasonable 
> > > to expect that a client should be able to configure the errors 
> > > container, since it is configuration ...
> > 
> > There is no point for the server to advertise it as a part of the standard
> > datastores such as "intended". And in order to advertise it as a schema for
> > error messages, it is IMO possible to use the trick that I suggested: define
> a
> > special datastore for it, such as "error-messages". So it will be the
> datastore
> > that enforces the desired semantics, and clients that support it can use it
> in
> > the intended way.
> > 
> > > 
> > > At least marking it as config false would be slightly better.
> > > 
> > > > 
> > > > With this module, one could validate error messages using generic YANG
> tools
> > > > etc.
> > > > 
> > > > (I am not proposing to update RFC 8040, just using it as an example.)
> > > > 
> > > > > OK.  So, using plain groupings doesn't work.
> > > > > 
> > > > > In cases where groupings are being used within a YANG defined RPC,
> then
> > > > > presumably they do work OK?
> > > > > 
> > > > > Is the specific problem scenario where the data is external to YANG
> > > > > defined RPCs, but yet it is still desirable to use a YANG schema and
> one
> > > > > of the associated YANG encodings to describe/encode the data?
> > > > > 
> > > > > 
> > > > > > > > > What would be wrong with this solution? Instead, the reader is
> > > > > > > > > overwhelmed with the complexity of the "yang-data" definition,
> and
> > > > > > > > > most
> > > > > > > > > tools cannot process the module.
> > > > > > > > 
> > > > > > > > There are tools that can use yang-data.
> > > > > > > > Not all use-cases involve a server to query for a yang-library.
> > > > > > > 
> > > > > > > Sure, but it is not necessary, I meant it just as an option. Such
> YANG
> > > > > > > modules
> > > > > > > can be passed straight to tools.
> > > > > > > 
> > > > > > > > Offline tools need to know about the special data somehow.
> > > > > > > 
> > > > > > > Why? Let's say I want the ascii tree, and pyang will be able to
> > > > > > > generate
> > > > > > > it. All
> > > > > > > right, there will be "rw" labels that don't apply but it is not a
> big
> > > > > > > deal.
> > > > > > > 
> > > > > > > > The yang-data extension prevents data-def-stmts from being
> treated
> > > > > > > > as if they were configuration or operational data.
> > > > > > > 
> > > > > > > This would be a problem if this yang-data is mixed with standard
> data
> > > > > > > in
> > > > > > > the
> > > > > > > same module. IMO this can be avoided, and then for it is
> essentially
> > > > > > > irrelevant
> > > > > > > for tools whether it is normal data or not.
> > > > > > > 
> > > > > > > > I agree with you that unconstrained use of yang-data is
> questionable
> > > > > > > > for a standard extension. The bar should be that all tools which
> > > > > > > > choose
> > > > > > > > to implement the extension should provide the user with the same
> > > > > > > > behavior.
> > > > > > > > Declaring that behavior out-of-scope does not help
> interoperability
> > > > > > > > at
> > > > > > > > all.
> > > > > > > 
> > > > > > > Yes, and so my proposal here is to silently misuse YANG somewhat
> where
> > > > > > > necessary
> > > > > > > rather than spend cycles on a Standard Track document that gives a
> > > > > > > false
> > > > > > > impression of a general solution.
> > > > > > 
> > > > > > I am strongly opposed to this.  IMO it is much better to put such
> > > > > > structures in an extension, which tools that don't understand it
> will
> > > > > > ignore, than relying on description statements in normal data nodes,
> > > > > > which no tool can understand without hard coding special cases.
> > > > > 
> > > > > I'm also opposed to this.
> > > > > 
> > > > > Stuff that looks like configuration should be configuration, and stuff
> > > > > that looks like state should be state.  If this data is going to be
> > > > > described in YANG then I think that there must be a programmatic way
> to
> > > > > indicate that the resultant schema is not configuration or operational
> > > > > state, but something else instead.  An extension seems to achieve
> this.
> > > > 
> > > > YANG spec deals exclusively with configuration and state data, and using
> its
> > > > statements inside an extension doesn't make this basic fact go away.
> > > > Specifying
> > > > all necessary changes properly inside a description of an extension is
> > > > simply
> > > > impossible.
> > > 
> > > If an implementation needs to support generating the error messages then 
> > > they can support the yang-data extension if they want (or just hard code 
> > > what they expect to receive).
> > 
> > Or support the "error-messages" datastore, see above.
> > 
> > Lada
> > 
> > > 
> > > Otherwise, devices can also ignore the yang-data extension and it 
> > > doesn't seem to do any harm since its doesn't change the behaviour in 
> > > any way.
> > > 
> > > Thanks,
> > > Rob
> > > 
> > > 
> > > > 
> > > > Lada
> > > > 
> > > > > Thanks,
> > > > > Rob
> > > > > 
> > > > > 
> > > > > > 
> > > > > > > It would be great to remove NETCONF specifics from YANG and I'd be
> > > > > > > willing
> > > > > > > to
> > > > > > > contribute to this work.
> > > > > > 
> > > > > > This is a different topic though.
> > > > > > 
> > > > > > 
> > > > > > /martin
> > > > > > 
> > > > > > 
> > > > > > > Lada
> > > > > > > 
> > > > > > > > > Lada
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Andy
> > > > > > > >    
> > > > > > > > > > > A plain client can ignore yang-data and not affect and
> RPC,
> > > > > > > > > > > notification,
> > > > > > > > > 
> > > > > > > > > or
> > > > > > > > > > > data
> > > > > > > > > > > definitions in plain YANG.
> > > > > > > > > > 
> > > > > > > > > > A plain (NC/RC) client should never see such data even if it
> is
> > > > > > > > > > not
> > > > > > > > > 
> > > > > > > > > protected by
> > > > > > > > > > yang-data in YANG. On the other hand, tools will be able to
> > > > > > > > > > process
> > > > > > > > > > such
> > > > > > > > > 
> > > > > > > > > schemas
> > > > > > > > > > (generate the ascii tree, convert it to something else,
> generate
> > > > > > > > > > sample
> > > > > > > > > > instances etc.) without explicitly supporting yang-data.
> > > > > > > > > > 
> > > > > > > > > > Lada
> > > > > > > > > > 
> > > > > > > > > > >    
> > > > > > > > > > > > Lada
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Andy
> > > > > > > > > > >    
> > > > > > > > > > > > > there is a version of YANG that has a proper and
> complete
> > > > > > > > > > > > > integrated
> > > > > > > > > > > > > solution. (If for example yang-data is used to declare
> > > > > > > > > > > > > error
> > > > > > > > > > > > > content
> > > > > > > > > > > > > for RPCs, then more extensions are needed or a proper
> > > > > > > > > > > > > integration
> > > > > > > > > 
> > > > > > > > > into
> > > > > > > > > > > > > YANG. Is it really good to introduce augment-yang-data
> > > > > > > > > > > > > (instead of
> > > > > > > > > > > > > making augment work with say 'data' in YANG 1.2)? And
> then
> > > > > > > > > > > > > we
> > > > > > > > > > > > > do
> > > > > > > > > > > > > uses-yang-data etc.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > /js
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > -- 
> > > > > > > > > > > > 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
> > > > > > > > > > 
> > > > > > > > > > _______________________________________________
> > > > > > > > > > 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
> > > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > netmod mailing list
> > > > > > netmod@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > > .
> > > > > > 
> > > 
> > > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67