Re: [netmod] YANG next

Ladislav Lhotka <lhotka@nic.cz> Thu, 25 July 2019 23:00 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 1C2C01202BB for <netmod@ietfa.amsl.com>; Thu, 25 Jul 2019 16:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.997
X-Spam-Level:
X-Spam-Status: No, score=-6.997 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_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 C3pdxmTBhRXA for <netmod@ietfa.amsl.com>; Thu, 25 Jul 2019 15:59:57 -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 BC2EA1201D1 for <netmod@ietf.org>; Thu, 25 Jul 2019 15:59:56 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:67c:1232:144:1a4f:a84b:2bfd:c611]) by mail.nic.cz (Postfix) with ESMTPSA id 49388140B8F; Fri, 26 Jul 2019 00:59:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1564095595; bh=UZ3GRbP/UB3dyBT6H6lpAn1przUuopTZUbt1rzSz9F8=; h=From:To:Date; b=ChfNxOaoCOGqqMjnvWKNxbM20jePN6dLshXI0iCsZm2x/m9Jn2GtuwapU/QgCEElH k0QkqoJX1riN1ULJJf4E3rW2PJsBClbMT2a7PdbuvG6Ad6wzsQXkDgGWeAK/d3kYsZ b9q+tPKeg2s5/JB+hHh/LcKAtAK20nscGO46imeM=
Message-ID: <3426b6811a802f47bfd49409bb2bdd66d923d6c5.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>, "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: Kent Watsen <kent@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>
Date: Thu, 25 Jul 2019 18:59:52 -0400
In-Reply-To: <CABCOCHToOuB=bomA6JEnS8VTgUGyTo1tRcHfiMWeHy6o4Pr90g@mail.gmail.com>
References: <ff5d90b51872df190abb226cb10d51a635e88521.camel@nic.cz> <CABCOCHRxfKWh1OS3bUJAabk3XAqTCiOswiE65JtMC8eyxMUxMA@mail.gmail.com> <02c4110737b4ff23f966e6153fad764f04436089.camel@nic.cz> <CABCOCHQoKAiugVsDhuHSvhfnCbP2D2caLU88cF-AkkH0aCSOUA@mail.gmail.com> <c35ae918e65411575b7e18dfd24547cbbf9d216d.camel@nic.cz> <856cce29-f524-be31-b5e5-bcb679721e9a@hq.sk> <0100016c25074dba-bffd4eea-f851-4913-83da-df3da8774f76-000000@email.amazonses.com> <CABCOCHR5MJLuRVtZBa_VbBXX4nrRJMUQBpU13P8a1oRE1_6C2g@mail.gmail.com> <BYAPR11MB26313098C4AABAF268329BDCB5C10@BYAPR11MB2631.namprd11.prod.outlook.com> <CABCOCHToOuB=bomA6JEnS8VTgUGyTo1tRcHfiMWeHy6o4Pr90g@mail.gmail.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.4
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Afma0LF7P_iOjA9D43-rsmHw2eQ>
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: Thu, 25 Jul 2019 23:00:06 -0000

On Thu, 2019-07-25 at 07:41 -0700, Andy Bierman wrote:
> Hi,
> 
> Was this a big topic at the side meeting?

I think I wrote quite clearly that YANG itself was no topic there - except
perhaps complaints regarding the IETF/OpenConfig schism.

This fact means to me that the problem is not missing features in YANG but
rather missing YANG modules at all different places, and so making a new version
of YANG doesn't seem like a good idea to me - we should leave existing module
writers in peace and encourage new ones. And a better specification could
certainly help with the latter. 

> The issues blocking NMDA, schema-mount, and other deployment problems
> are related to YANG document organization?  I doubt it.

Well, people at that meeting probably already made their way through the
existing specs, although I seriously doubt that they understand all the dark
corners. The problems is with newcomers, who may be deterred by the existing
complexity and turn to something else - and alternatives do exist.

> 
> So how would this work?
> There will be 2 versions of YANG 1.1?
> If old YANG 1.1 is equivalent to new YANG 1.1, can a developer safely ignore
> the new RFCs?
> If not, then something changed that was not supposed to change.

The new RFCs may obsolete/update 7950 as necessary. I assume, however, that some
limited changes may be necessary, so it may in fact be YANG 1.2 that's described
in the new RFCs. I don't think it is a big deal.
> 
> The old YANG 1.1 RFC will be obsolete and the 2 (or more) new YANG 1.1 RFCs
> will replace it?
> Then of course all the RFCs that reference RFC 7950 might have to be updated
> so the subject matter
> is cited from the correct new YANG 1.1 RFC.
> 
> IMO this will only serve to confuse the end-users and offer them no real
> benefit at all.

I have a different opinion.

> As for finishing quickly because the NETMOD WG is so fast and has nothing
> better to work on anyway...  sure.

Well, if you compare time spent on YANG 1.1, it was considerably shorter than
the time spent of many modules, and not only in NETMOD - routing, acl, ospf, is-
is, to name a few.

Lada

> 
> 
> Andy
> 
> 
> 
> On Thu, Jul 25, 2019 at 5:56 AM Rob Wilton (rwilton) <rwilton@cisco.com>
> wrote:
> > I also think that there is significant value to splitting the NETCONF and
> > XML specification out of RFC 7950 (but keeping XML examples).  I think that
> > this may be beneficial to YANG’s longevity, and I’m sure that it would make
> > it easier to maintain and extend the NETCONF/RESTCONF/YANG document set in
> > future.
> > 
> >  
> > 
> > Thanks,
> > 
> > Rob
> > 
> >  
> > 
> >  
> > 
> > From: netmod <netmod-bounces@ietf.org> On Behalf Of Andy Bierman
> > Sent: 24 July 2019 14:32
> > To: Kent Watsen <kent@watsen.net>
> > Cc: netmod@ietf..org
> > Subject: Re: [netmod] YANG next
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> > On Wed, Jul 24, 2019 at 10:28 AM Kent Watsen <kent@watsen.net> wrote:
> > 
> > >  
> > > 
> > > > > > So you want to work on YANG 1.2, but just the parts you want to
> > > > > > change? ;-)
> > > > > > 
> > > > > 
> > > > > I am actually fine with not doing any changes to YANG 1.1 at all,
> > > > > except perhaps
> > > > > bug fixes. This doesn't necessarily mean closing the NETMOD WG, it
> > > > > would IMO be
> > > > > immensely useful to rewrite the language specification and remove
> > > > > NETCONF- and
> > > > > XML-specific part.
> > > > > 
> > > > 
> > > > +1. There are plenty of ambiguities and NETCONF/XML pollution in the
> > > > spec. Having the specifications in a DAG would be immensely useful :)
> > > > 
> > > 
> > >  
> > > 
> > > Agreed and I should've mentioned before that Martin said in Prague that
> > > he'd already started this effort, seeing it as a necessary pre-step before
> > > making other changes..  I'm unsure if the intention is to release this by
> > > itself as an RFC 7950 bis but, if looking for a minimal change, that might
> > > be it.  The next rung up would be to just add clarifications.  The next
> > > rung up from there would be to add only backwards-compatible changes
> > > (currently targeted by [1]).  The last rung being to also target NBC
> > > changes (there's no consensus to do this).
> > > 
> > >  
> > > 
> > 
> >  
> > 
> > This WG sure likes to spend time refactoring documents.
> > 
> > Moving lots of text will create bugs and strong coupling, and only help the
> > standards purists.
> > 
> > It will be a lot of work for the WG and IESG to review such a massive
> > document split,
> > 
> > and in the end we have no improvement in YANG, just more RFCs to read.
> > 
> >  
> > 
> > Andy
> > 
> >  
> > 
> > > [1] https://github.com/netmod-wg/yang-next/projects/2
> > > 
> > >  
> > > 
> > > Kent 
> > > 
> > >  
> > > 
> > >  
> > > 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67