Return-Path: 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 A7675127148 for ; Fri, 26 Oct 2018 16:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 oNRCwaq0SlAI for ; Fri, 26 Oct 2018 16:36:31 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 4382912008A for ; Fri, 26 Oct 2018 16:36:31 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id c21-v6so2655862ljj.1 for ; Fri, 26 Oct 2018 16:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=iVW8Pb/LuZyCJvaS2FaN7IRzenXQm+uPDVGgjwmIdVk=; b=R9Kd7SULFPc9X8u7zGdiJaCC3muOUbb5ZDkvwwFMq6zpQ77LXiXeP/oEaiIh6bSMCm Eomvux/voejVqaz/d+RjUWmqN9f8fCpYFBR0DMKSyEP6YWl+DqhgPGx1dYYpuaUXe7Qt RySHK49+vxXjV8emIhH9jux4ayw08RFE1YTzQ12GRoLLYvFjjnfbn3dbBIlV8s2jvtia RiaIR95c9ZQTKyULrHWagKDdsFKA8cDvS9NGXxqNzuaOsJTQBtx3XTg3NNzloUuWJ5GD 8LRbLVbfaAlQ61ryRPiWPdgLuOeE3Iou+4HEOC2eeueYn6XMjK0tzAVvWDslc16QSxRw 6VEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=iVW8Pb/LuZyCJvaS2FaN7IRzenXQm+uPDVGgjwmIdVk=; b=CHrx5VnsWYqZtoIxEpBZBevb/AYJfK6MnpGqPBjM3RTS48RsHb+fNMBuGkI4P38Q2p 2XugyJn/wVVpSmkt3AAqgbG+RMZ9mA9L/wmni/VLKjEwcY8/uLuNHPC72TOkPcUTh07p mhiYSUHSsv3rnSiTuxtsaC90+bgC1F3vr07oqsR36IDaGD/8tiHfRoRTZYWVYcLtGB9b fcS1XHetsW72rLhepw8D/erW0KdBRUaKP8FNur2Fjo9R7jdY/+2DEmLooLovUja+3ZDA aEPCKOYhqPHgRjMWs+Xim58qi5BJlrLjm2PexCaJaW3XMg7EiLkPXU+CftTZvn5hBXlT x4Dw== X-Gm-Message-State: AGRZ1gJ5tuRgopdfSZtg1/aubil0yyiRlLRdcOg2iTsyMYQGeuP+yjwV f28uWytd7lWGmjYEz+FllGHqHsSdvMCoX58IrZHhbg== X-Google-Smtp-Source: AJdET5cB1W8tBBebSkI7M5voP36Z155w3iyLiGeBl4jvJ4+EBY2p+/YjTkH4yxFrzROdN2OKjega7rr5FOOyzd5n98Y= X-Received: by 2002:a2e:4408:: with SMTP id r8-v6mr3978803lja.21.1540596989042; Fri, 26 Oct 2018 16:36:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Fri, 26 Oct 2018 16:36:26 -0700 (PDT) In-Reply-To: <20181026230148.xnv7kxgqd43abb7g@anna.jacobs.jacobs-university.de> References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org> <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com> <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de> <20181026230148.xnv7kxgqd43abb7g@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Fri, 26 Oct 2018 16:36:26 -0700 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000462faf05792a30ce" Archived-At: Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 23:36:34 -0000 --000000000000462faf05792a30ce Content-Type: text/plain; charset="UTF-8" On Fri, Oct 26, 2018 at 4:01 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Oct 26, 2018 at 09:35:39AM -0700, Andy Bierman wrote: > > > > IMO requirements 3.1 and 3.2 are the most important and have the most > > impact > > on the solution space. I do not agree with either of these requirements. > > > > Implementing multiple non-compatible revisions of a module on a server > > sounds hard, > > not to mention that it breaks RFC 7950 rules. The current protocols do > not > > support the > > ability to specify different versions of the same QName. This change > makes > > YANG validation > > much to difficult to specify and implement (as that has to be rewritten > as > > well). > > > > It is one thing to deploy rapidly changing, buggy YANG modules in order > to > > gain experience quickly. It is quite another to complicate YANG and the > > protocols > > to preserve these interim mistakes, and bake into the standards the > notion > > that this > > is good engineering. > > > > So how do you think this conflict between more agility and client > stability should be handled? It seems you can't easily have both at > the same time. Are you saying that backwards compatibility to support > existing clients is not important? > > It depends on the data model and how broken it is in the replaced version. YANG validation is slow and complicated enough without pretending there are 8 or 10 separate schema trees within a datastore. It might be impossible for all constraints to be true in all schema trees at once. It is a burden on operators and client developers to understand and properly manage multiple incompatible revisions of the same module yang-library is a good example of a clean break. The /yang-library tree completely replaces the /modules-state tree. A server can easily support both subtrees. No new YANG or protocol features are needed at all. This was not a bugfix, just the normal instability in the IETF. Even with this clean break, there could be external modules that have leafref or must/when that point at the /modules-state subtree. They have to be rewritten to use /yang-library instead. But this can happen as needed since the old tree is unchanged. For truly broken changes (e.g. change a node from a container to a list; change a leaf from type boolean to an enumerated type w/ 6 enums; remove or rename lots of existing nodes) the cross-references from external modules can easily be incorrect if used with the new version. The NETMOD WG chose to add a new /yang-library tree instead of mangling the existing nodes. One design choice makes req. 3.1 easy and 3.2 not needed. Another - just the opposite. Andy /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --000000000000462faf05792a30ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 26, 2018 at 4:01 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Oct 26, 2018 at 09:35:39AM -0700, Andy Bierm= an wrote:
>
> IMO requirements 3.1 and 3.2 are the most=C2=A0 important and have the= most
> impact
> on the solution space. I do not agree with either of these requirement= s.
>
> Implementing multiple non-compatible revisions of a module on a server=
> sounds hard,
> not to mention that it breaks RFC 7950 rules. The current protocols do= not
> support the
> ability to specify different versions of the same QName. This change m= akes
> YANG validation
> much to difficult to specify and implement (as that has to be rewritte= n as
> well).
>
> It is one thing to deploy rapidly changing, buggy YANG modules in orde= r to
> gain experience quickly.=C2=A0 It is quite another to complicate YANG = and the
> protocols
> to preserve these interim mistakes, and bake into the standards the no= tion
> that this
> is good engineering.
>

So how do you think this conflict between more agility and client
stability should be handled? It seems you can't easily have both at
the same time. Are you saying that backwards compatibility to support
existing clients is not important?


It depends on the data model and how broken it is in= the replaced version.
YANG validation is slow and complicated en= ough without pretending there
are 8 or 10 separate schema trees w= ithin a datastore. It might be impossible
for all constraints to = be true in all schema trees at once.=C2=A0 It is a burden on operators
and client developers to understand and properly manage multiple inco= mpatible revisions
of the same module

ya= ng-library is a good example of a clean break.
The /yang-library = tree completely replaces the /modules-state tree.
A server can ea= sily support both subtrees.
No new YANG or protocol features are = needed at all.
This was not a bugfix, just the normal instability= in the IETF.

Even with this clean break, there co= uld be external modules that have leafref
or must/when that point= at the /modules-state subtree.=C2=A0 They have to be rewritten
to use /yang-library instead. But this can happen as needed since the ol= d tree is unchanged.

For truly broken changes (e.g= . change a node from a container to a list;
change a leaf from ty= pe boolean to an enumerated type w/ 6 enums;
remove or rename lot= s of existing nodes) the cross-references from external
modules c= an easily be incorrect if used with the new version.

The NETMOD WG chose to add a new /yang-library tree instead of
mangling the existing nodes. One design choice makes req. 3.1 easy and 3.2= not needed.
Another - just the opposite.


Andy



/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>

--000000000000462faf05792a30ce--