Re: [netmod] YANG next

Andy Bierman <andy@yumaworks.com> Tue, 23 July 2019 18:35 UTC

Return-Path: <andy@yumaworks.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 821AE120804 for <netmod@ietfa.amsl.com>; Tue, 23 Jul 2019 11:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 KHINUq5WDxLn for <netmod@ietfa.amsl.com>; Tue, 23 Jul 2019 11:35:44 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505741207F6 for <netmod@ietf.org>; Tue, 23 Jul 2019 11:35:44 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id h10so42049781ljg.0 for <netmod@ietf.org>; Tue, 23 Jul 2019 11:35:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UoCnStP8oxAAeVRmQvphQg8MpbJ7YCwoC1T7nsYnAv4=; b=MdaWSHeyK5wDE/v24TK5838mWLnsJjp6F6DawsKFQ9C4WfT8PZfqaIHkDetei6KBu2 2SYiX6Rme8919ZT4spEeetKFFVay88yDc3DmmKjrqRBpoaz+W8B7HMfvEM4Y0WBaZr30 MpGU1zlFNc/oGvZQt4Bd7MwlRzXSyFPmm2BsztcdbB5eg3jHw0sc1LNfOK5KRm3nhYUL /u4k4x6SmyDse0Yqm1tgZk1GqDyHCteSXMEFZUzHkPAUNTtvALOIywKsaVDPsQAUZFk5 uYcpxRXjuNMwXF9suu+NOpWgT3yVklD7m4vy2DWlaUdrcRDaywlqb+Ya6xysRTYG7W5V Cpzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UoCnStP8oxAAeVRmQvphQg8MpbJ7YCwoC1T7nsYnAv4=; b=ko295+CbAMk79T3BofoQvi7ki1XLXmNZUnkoQVn3EPn/b2cKKo1cqQ41HO/VG4nqDN /o/fg4foWWHVcbDwCxzyGq8cKLANzyqQgRUPa98xVWOW9Vol3QWtSKkYpOqB0dhAdlGA jS1rc6NhKsfcttB9ZQe+jTgdotsONTzOGdL8KZikRPXclqF1jduXp0obvK2FHkWOck25 aOSgYnO5zBc4BVQVVmfp6aWkzVdzibol74pHt0mXbJCNkQ8Se7OuO+JtQvE9+hfwbwYH bgBz45dUZKwRtBpb22VQII3604KPbx7H2Jo7WtBVpJiBNd9/syDhfHfF+Pp35teDrTSI avIg==
X-Gm-Message-State: APjAAAVzDrkePcY13VZEWKPsjpozUr8H+rnNnARcXBqHNMJn7hDfeXRc pt9H8tVmOidg9R9lar8KEWa2ucXoVglEY9lLoOM8dA==
X-Google-Smtp-Source: APXvYqxf/3Sc5E6Y4tKYH2+8uW+aSrREOfoQLgY2vVazWtazGIYxX0kp84JaPjr2JS619nNRoehtQwnVGeZ5T+zeank=
X-Received: by 2002:a2e:8583:: with SMTP id b3mr4284729lji.171.1563906942446; Tue, 23 Jul 2019 11:35:42 -0700 (PDT)
MIME-Version: 1.0
References: <ff5d90b51872df190abb226cb10d51a635e88521.camel@nic.cz> <CABCOCHRxfKWh1OS3bUJAabk3XAqTCiOswiE65JtMC8eyxMUxMA@mail.gmail.com> <02c4110737b4ff23f966e6153fad764f04436089.camel@nic.cz>
In-Reply-To: <02c4110737b4ff23f966e6153fad764f04436089.camel@nic.cz>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 23 Jul 2019 11:35:31 -0700
Message-ID: <CABCOCHQoKAiugVsDhuHSvhfnCbP2D2caLU88cF-AkkH0aCSOUA@mail.gmail.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: NETMOD WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c44176058e5d7590"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/X7FVyjc-1w7SW0Zy0dBFfAmpMLE>
Subject: Re: [netmod] YANG next
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 23 Jul 2019 18:35:48 -0000

On Tue, Jul 23, 2019 at 11:00 AM Ladislav Lhotka <lhotka@nic.cz> wrote:

> On Tue, 2019-07-23 at 09:22 -0700, Andy Bierman wrote:
> >
> >
> > On Tue, Jul 23, 2019 at 9:03 AM Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > Hi,
> > >
> > > this morning I attended the side meeting "Next Step of IETF YANG". I
> was
> > > somewhat misled into thinking that it would be about future evolution
> of
> > > YANG
> > > the language, which was not the case at all. However, my personal
> conclusion
> > > from the meeting is that it would be a total disaster to throw in a new
> > > version
> > > of YANG within the next few years or so.
> > >
> >
> >
> > I hope a summary of the meeting is posted to the WG mailing list.
>
> I think so, minutes were taken.
>
> >
> > > The operators and equipment vendors are busy putting together YANG
> modules
> > > and
> > > tools, filling the gaps, coping with NMDA, schema mount, IETF versus
> > > OpenConfig
> > > etc. A new YANG version (and modules written in it) would IMO be
> extremely
> > > counter-productive at this rather turbulent stage.
> > >
> > > So, if we want to continue the yang-next discussion, I think we first
> have
> > > to
> > > figure out how to evolve YANG without making waves in the current YANG
> pond
> > > and
> > > let the operators and vendors do their work, without which YANG can
> never
> > > succeed.
> > >
> >
> > IMO a new version of YANG would not be disruptive (if done right).
> > The issue is whether it is cleaner in the long-run to introduce NBC
> changes
> > properly
> > with a new version number, or not so properly, through YANG extensions.
>
> I don't see much difference provided that the extensions will be properly
> signalled. But we have to take into account that some tools that people
> use may
> not be updated for quite some time, and if they cannot properly work with
> modules written for the new version (or extensions), then things will
> break.
>
>
So you want to work on YANG 1.2, but just the parts you want to change? ;-)
There is no such thing as a critical extension in YANG 1.1.
IMO it would be a bad idea to develop standard modules that relied on tool
support of
any extension. A tool is allowed to skip any extension when parsing a
module.
This cannot be changed in YANG 1.1.


> This problem is actually not limited to YANG itself - people are reporting
> problems with the transition to NMDA.
>
> >
> > E.g -- adding a leaf to the datastore that says "I don't follow the
> rules in
> > 7950"
> > is still breaking the YANG 1.1 contract.  Using extensions instead of
> real
> > statements
> > is problematic because they are optional to implement (as you point out
> all
> > the time).
>
> Yes, hence critical extensions. However, the problem is still the same -
> these
> changes require updated tools, and not all tools will be updated
> immediately. I
> think that we should make sure that (at least in the IETF) all modules
> will be
> compatible with tools supporting YANG 1.1, say for the next 5 years.
>
>
I am OK with the current WG priorities such as versioning.
Those YANG extensions simply clarify YANG 1.1 so no rules are broken
and no YANG 1.1 functionality is removed if a tool ignores the extensions.
Also OK with not working on YANG 1.2 or critical extensions.
There are no must-have features at this time.

Lada
>
>
Andy


> >
> > Seems like the WG is going the YANG extension route, which has its own
> set of
> > problems
> > compared to a new YANG language version.
> >
> >
> > > Lada
> >
> > Andy
> >
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>