Re: [netmod] yang-data-ext issues

Ladislav Lhotka <lhotka@nic.cz> Fri, 27 April 2018 14:34 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 361D5124234 for <netmod@ietfa.amsl.com>; Fri, 27 Apr 2018 07:34:40 -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 cVDLi3OpDiVv for <netmod@ietfa.amsl.com>; Fri, 27 Apr 2018 07:34:36 -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 503321205D3 for <netmod@ietf.org>; Fri, 27 Apr 2018 07:34:35 -0700 (PDT)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 74A8162667; Fri, 27 Apr 2018 16:34:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1524839673; bh=9xsKD+OtPnBt9XXrkhmJ4s3R+Aa+Mfbp/eHGaKVrcgQ=; h=From:To:Date; b=UThjAH4fQiAfk9JOlFufII1mZmE9YugZ+HKGPSwqw+Y1Yr/ZrzN9byHdVLRuZB3fV glFFnja6QxR9G24ReX8DoUF/hyi8TPTWEPFRrAkQamLqIjM2Sg5XRzyzzzUKnwwnhG egy4leMeYmASfjKJHhVmtP8QR8b98vwFEKC/4vyM=
Message-ID: <b9211ebacd24ffdd558ecf4da5bfa1ad71cfdabb.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Robert Wilton <rwilton@cisco.com>, Martin Bjorklund <mbj@tail-f.com>
Cc: netmod@ietf.org
Date: Fri, 27 Apr 2018 16:34:38 +0200
In-Reply-To: <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com>
References: <87muxq1pk9.fsf@nic.cz> <CABCOCHSwB8m6Uk82MZHnjnVi=0ofRohqEPT0Q06NM=+3n5gtFA@mail.gmail.com> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.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/MDlS4l6u-IL9ebFTEJ1VXBz5tJo>
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: Fri, 27 Apr 2018 14:34:40 -0000

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@nic.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.

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