Re: [netmod] yang-data-ext issues

Robert Wilton <rwilton@cisco.com> Fri, 27 April 2018 10:23 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 3DB161243FE for <netmod@ietfa.amsl.com>; Fri, 27 Apr 2018 03:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 hnHPy3mZaOYX for <netmod@ietfa.amsl.com>; Fri, 27 Apr 2018 03:23:45 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F731127076 for <netmod@ietf.org>; Fri, 27 Apr 2018 03:23:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7230; q=dns/txt; s=iport; t=1524824625; x=1526034225; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=nSimABvrcp7Mh0KnL1itO5NMY1FTkcJ/0CgykPGOuwA=; b=NcC4SO24pnZp/TiJxDZMyDPhjRyQly78VsXS1tUJ60XnB8WTgYpzwLCa qSRCE5/XHTwRetsyHeegWX7l2jGRMzXcd3ck3qh6otXtOaFQBbjtSFnz8 ct1CkTJh8yA2XEk7lEJ+JuEjCmPK2/W2xNN1y4o5/DzSZyK7uPKkZrQTV c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAQB1+eJa/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMUgRB6KINriGCOEYEPkxQUgWQLGAuEA0YCgm42FgECAQE?= =?us-ascii?q?BAQEBAmwcDIUpAQEBAwEBIQ8BBTYLEAsOCgICJgICJzAGAQwGAgEBF4R0D6g?= =?us-ascii?q?SghyEWIN2gkAFgQmIXz+BMoFpf4MRAQGBLQESAQmDFoJUApgNCI5EBodOhQe?= =?us-ascii?q?LGIUigSUiATFhcTMaCBsVO4JDixCFPz4wjwSCNwEB?=
X-IronPort-AV: E=Sophos;i="5.49,334,1520899200"; d="scan'208";a="3436306"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2018 10:23:43 +0000
Received: from [10.63.23.54] (dhcp-ensft1-uk-vla370-10-63-23-54.cisco.com [10.63.23.54]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w3RANhFj024792; Fri, 27 Apr 2018 10:23:43 GMT
To: Martin Bjorklund <mbj@tail-f.com>, lhotka@nic.cz
Cc: netmod@ietf.org
References: <87muxq1pk9.fsf@nic.cz> <CABCOCHSwB8m6Uk82MZHnjnVi=0ofRohqEPT0Q06NM=+3n5gtFA@mail.gmail.com> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com>
Date: Fri, 27 Apr 2018 11:23:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180427.120325.419501937185262392.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/PiUa2u1BtZHWf59K_taig9lXZ_Q>
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 10:23:48 -0000


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.cz>; 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.
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.

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