Re: [netmod] adoption poll for yang-versioning-reqs-02
Martin Bjorklund <mbj@tail-f.com> Tue, 19 March 2019 15:12 UTC
Return-Path: <mbj@tail-f.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 786B2131409 for <netmod@ietfa.amsl.com>; Tue, 19 Mar 2019 08:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 LSblhhHZf2Jw for <netmod@ietfa.amsl.com>; Tue, 19 Mar 2019 08:12:31 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 70CA31313F9 for <netmod@ietf.org>; Tue, 19 Mar 2019 08:12:30 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 74D301AE00A0; Tue, 19 Mar 2019 16:12:28 +0100 (CET)
Date: Tue, 19 Mar 2019 16:12:29 +0100
Message-Id: <20190319.161229.1910835285804688041.mbj@tail-f.com>
To: kent+ietf@watsen.net
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com>
References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/QFuahRlIEDwwdW9KmWs628hgfxs>
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02
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, 19 Mar 2019 15:12:41 -0000
Hi, I have read this document, and I do not think it should be adopted. I object to the idea that we should allow non-backwards-compatible changes to published YANG modules. The draft motivates this idea with: we must recognize that many YANG modules are actually generated YANG modules (for example, from internal databases) I do not agree that we should change what we allow in published modules b/c of this. It also motivates this idea with: The points made above lead to the logical conclusion that the standardized YANG modules have to be perfect on day one (at least the structure and meaning), which in turn might explain why IETF YANG modules take so long to standardize. I disagree with this. First of all, we have already published revision two of several YANG modules (ietf-inet-types, ietf-yang-type, ietf-interfaces, ietf-ip, ietf-routing, ...), so the statement that "standardized YANG modules have to be perfect on day one" is simply not true. Second, I don't think the upgrade rules are the reason it takes a long time to standardize IETF models (I think it has to do with the process itself, including the fact that models get reviews from many different people with different background.) [BTW, is it true that drafts with YANG models take longer time from wg -00 to published RFC than other drafts?] This said, I think there are some important points that the draft raises, and that I think we should continue to work on; specifically 2.3, 2.5, 2.6, 2.7. But I don't think that these areas require changes to the versioning scheme, and I think it is a mistake to include these areas in this draft. Some comments on section 4, The Problem Statement: o Any non-backwards-compatible change of a definition requires either a new module name or a new path. This has been found costly to support in implementations, in particular on the client side. Yes I agree there is a cost associated with this. But I have come across vendor modules that make NBC changes w/o introducing a new path, and this is also costly to handle. o Since non-backwards-compatible changes require either a new module name or a new path, such changes will impact other modules that import definitions. In fact, with the current module versioning scheme other modules have to opt-in in order to use the new version. This essentially leads to a ripple effect where a non- backwards-compatible change of a core module causes updates on a potentially large number of dependent modules. This is by design. We cannot have a situation where a legal modification to a module leads to other modules becoming invalid. o YANG has a mechanism to mark definitions deprecated but it leaves it open whether implementations are expected to implement deprecated definitions and there is no way (other than trial and error) for a client to find out whether deprecated definitions are supported by a given implementation. As I wrote above, I agree that this is a problem that should be solved. But this is not a motivation for changing YANG versioning. o YANG does not have a robust mechanism to document which data definitions have changed and to provide guidance how implementations should deal with the change. While it is possible to have this described in general description statements, having these details embedded in general description statements does not make this information accessible to tools. This might also be worth exploring, but this is not a motivation for changing YANG versioning. /martin Kent Watsen <kent+ietf@watsen.net> wrote: > Seeing as how we all need to read this draft anyways, in preparation for our meeting in Prague, it seems like a good time for this poll. Thusly, this email begins a 1-week adoption poll for: > > https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 <https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02> > > Please voice your support or objections before March 20. > > Note that this draft defines *requirements* and its intended status is "Informational." I believe that it is good for WGs to formalize requirements, even taking such drafts thru Last Call, in order to ensure consensus on the requirements. This is the "adoption" call, to ascertain if the WG agrees with that statement; if adopted, a separate "last call" will be issued to ensure to correctness of the draft's content. > > Kent (and Lou and Joel) > >
- [netmod] adoption poll for yang-versioning-reqs-02 Kent Watsen
- Re: [netmod] adoption poll for yang-versioning-re… Balázs Lengyel
- Re: [netmod] adoption poll for yang-versioning-re… Joe Clarke
- Re: [netmod] adoption poll for yang-versioning-re… Rob Wilton (rwilton)
- Re: [netmod] adoption poll for yang-versioning-re… Reshad Rahman (rrahman)
- Re: [netmod] adoption poll for yang-versioning-re… Martin Bjorklund
- Re: [netmod] adoption poll for yang-versioning-re… Rob Wilton (rwilton)
- Re: [netmod] adoption poll for yang-versioning-re… Andy Bierman
- Re: [netmod] adoption poll for yang-versioning-re… Martin Bjorklund
- Re: [netmod] adoption poll for yang-versioning-re… Rob Wilton (rwilton)
- Re: [netmod] adoption poll for yang-versioning-re… Rob Wilton (rwilton)
- Re: [netmod] adoption poll for yang-versioning-re… Andy Bierman
- Re: [netmod] adoption poll for yang-versioning-re… Martin Bjorklund
- Re: [netmod] adoption poll for yang-versioning-re… Rob Wilton (rwilton)
- Re: [netmod] adoption poll for yang-versioning-re… Rob Wilton (rwilton)
- Re: [netmod] adoption poll for yang-versioning-re… Reshad Rahman (rrahman)
- Re: [netmod] adoption poll for yang-versioning-re… Kent Watsen
- Re: [netmod] adoption poll for yang-versioning-re… Andy Bierman
- Re: [netmod] adoption poll for yang-versioning-re… Kent Watsen
- Re: [netmod] adoption poll for yang-versioning-re… Lou Berger
- Re: [netmod] adoption poll for yang-versioning-re… Joel Jaeggli
- Re: [netmod] adoption poll for yang-versioning-re… Andy Bierman
- Re: [netmod] adoption poll for yang-versioning-re… Charles Eckel (eckelcu)
- Re: [netmod] adoption poll for yang-versioning-re… Kent Watsen
- Re: [netmod] adoption poll for yang-versioning-re… Martin Bjorklund
- Re: [netmod] adoption poll for yang-versioning-re… Andy Bierman
- Re: [netmod] adoption poll for yang-versioning-re… Reshad Rahman (rrahman)
- Re: [netmod] adoption poll for yang-versioning-re… Andy Bierman
- Re: [netmod] adoption poll for yang-versioning-re… Balázs Lengyel