Re: [netmod] yang-data-ext issues

Ladislav Lhotka <lhotka@nic.cz> Wed, 25 April 2018 15:14 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 1B052124239 for <netmod@ietfa.amsl.com>; Wed, 25 Apr 2018 08:14:08 -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 cIm-k0d68xrh for <netmod@ietfa.amsl.com>; Wed, 25 Apr 2018 08:14:05 -0700 (PDT)
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 21531124205 for <netmod@ietf.org>; Wed, 25 Apr 2018 08:14:05 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:5ce2:b9ff:fe81:cca6]) by mail.nic.cz (Postfix) with ESMTPSA id 635A662CD8; Wed, 25 Apr 2018 17:14:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1524669243; bh=Nk97b3J/H2dAnhdLZkcLRX7A13DWRWsk+KsNNwLJ9pI=; h=From:To:Date; b=GmizkyFGaRvax9zeuLLrV9YR2ZQYHEDom2F20tRiaKRgSKxN/0oqFDSDMK/PCJJNY AFxP8ylEvMTv12gNceO0aO6oCabtNDPgxg3sgfyPgkhdJW49y7A4Ss6g0QwNfS5wDp lx0g0xi/5EiuC8IxJoMId9ZBMqJiNE3ERxtZgatg=
Message-ID: <66a94c163cf41aad4def540141a38ebb19d3ba24.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>, NetMod WG <netmod@ietf.org>
Date: Wed, 25 Apr 2018 17:14:07 +0200
In-Reply-To: <CABCOCHT9RH5f+ryecVJvE-03__XmHR8CaamLUfEdy7bTa9aMsw@mail.gmail.com>
References: <20180423165104.zi7g75tifhekmezh@elstar.local> <20180423.215110.441857992070858100.mbj@tail-f.com> <87wowwr826.fsf@nic.cz> <20180424.163601.648085760139600532.mbj@tail-f.com> <20180425135550.jwwbwtpofd7vz52z@elstar.local> <3f6631298f1f7e0c752d7300585962b04ddc49cc.camel@nic.cz> <CABCOCHT9RH5f+ryecVJvE-03__XmHR8CaamLUfEdy7bTa9aMsw@mail.gmail.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/RMlGCXFQDdCV_6pAQE8RZOMTpZk>
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, 25 Apr 2018 15:14:08 -0000

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.

> 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