Re: [netmod] yang-data-ext issues

Ladislav Lhotka <lhotka@nic.cz> Sun, 22 April 2018 12:56 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 3506F1204DA for <netmod@ietfa.amsl.com>; Sun, 22 Apr 2018 05:56:55 -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 pwThS0ELt4GB for <netmod@ietfa.amsl.com>; Sun, 22 Apr 2018 05:56:52 -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 4C1B11200C5 for <netmod@ietf.org>; Sun, 22 Apr 2018 05:56:51 -0700 (PDT)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 43EF762BEE for <netmod@ietf.org>; Sun, 22 Apr 2018 14:56:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1524401809; bh=md2rtvpD6W7/XeRmEGZHchEfLYPN6t/Sj+uY/8dRKKk=; h=From:To:Date; b=wgIPxf1hiqaeSBxTSm4qBXH4qrFfD1mDbfvB8BpC850ENSufmeJpvS/VTbPerJEV4 SXNth8jl+M6t1u0ckfclzDNojkMlfvUcGfuC3JtC3cvXSsABerXM5kfkvmIPIYMSy4 gKcLe7D+2x99hblaHinNu61Rb6gE2aC7mrtNHEYs=
Message-ID: <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: netmod@ietf.org
Date: Sun, 22 Apr 2018 14:56:51 +0200
In-Reply-To: <a7d3702d-1406-7bd2-caf6-7c07812c86aa@hq.sk>
References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> <a7d3702d-1406-7bd2-caf6-7c07812c86aa@hq.sk>
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/PTNSzTCBUsoscMbsJqHQT8OSxA8>
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: Sun, 22 Apr 2018 12:56:55 -0000

On Sat, 2018-04-21 at 03:16 +0200, Robert Varga wrote:
> On 17/04/18 07:35, Ladislav Lhotka wrote:
> > Hi,
> > 
> > this is a slippery slope. If we want to turn YANG into a general-purpose
> > schema language, it should IMO be done the other way around: design a
> > general-purpose schema language with a sound architecture, and then use
> > it for defining schemas of datastores, protocol messages or whatever.
> > 
> > YANG extensions make changes to the original YANG architecture way too
> > easy, but the result may be a bastard with no architecture at all.
> 
> +1 in general, although I am not convinced we need to start from scratch.

I didn't mean to start from scratch, but the thing is that YANG spec contains
many references to the specific NM context that don't make sense in other
contexts, so these would need to be removed. To begin with, it is the config true/false dichotomy.

> 
> The problem is that the metamodel behind YANG is not formally defined,
> which means every implementer has to reverse-engineer it from
> RFC6020/7960 (and 6241, and others). Since there is no metamodel spec,
> it is very hard to reason about how an extension affects it, especially
> in edge cases -- which can (and most probably will) lead to bastardization.

In fact, for the major XML schema languages the metamodel stems from a specific
formal validation algorithm. This article is quite instructive:

http://pike.psu.edu/publications/toit05.pdf

A useful side effect of the YANG-to-DSDL mapping was the evidence that YANG 1.0
was still pretty close to the mainstream of XML schema languages.
  
> 
> One example: YANG 1.1 was supposed to be a backwards-compatible, yet it
> introduced multiple-inheritence to a language which was previously
> strictly single-inheritence. That sort of change is a major revision of
> the metamodel and certainly does not qualify as backwards-compatible at
> that level of abstraction.

I'd defend YANG 1.1 here, I think it was a well managed and conservative update.
The meaning of backward compatibility was defined in the charter: YANG 1.0
modules should continue to work in 1.1. Apart from fixing evident bugs, I
believe this goal was achieved.

I am much more concerned with some of the post-1.1 features, also because YANG
is now being updated in several directions without a clear vision. And another
big problem is that YANG extensions are used for these changes, so we will
probably end up with several different versions of YANG, although formally
everything will be 1.1.  

Regarding your example: from my own experience, implementing validation of
identityref values with multiple inheritance is not terribly complicated in
comparison to single inheritance. I have other favorites for the most peculiar
feature in YANG.

> 
> It may not be important for run-of-the-mill NETCONF operations, but
> becomes pivotal when you are mapping YANG to other languages.

You are right, if such a mapping is what you need. I have myself given up
updating the DSDL mapping.

Lada

> 
> Regards,
> Robert
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67