Re: [netmod] adoption poll for yang-versioning-reqs-02

"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 19 March 2019 16:37 UTC

Return-Path: <rwilton@cisco.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 59541131071 for <netmod@ietfa.amsl.com>; Tue, 19 Mar 2019 09:37:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 62niy888Za-D for <netmod@ietfa.amsl.com>; Tue, 19 Mar 2019 09:37:50 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84FE1200B3 for <netmod@ietf.org>; Tue, 19 Mar 2019 09:37:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7188; q=dns/txt; s=iport; t=1553013469; x=1554223069; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OhaWsuI22oxSOL28D6/mBkCdjMU9CqnttBOpUeBIdRs=; b=kNr0vrJWH2JEEPv+GyOjmSsz7ZR2s3L27qvuU4EgBDtc5ZjVsNfufycd EOrYuhFpzgE0eyHBln41R0r2SW5v/CqSus5Si0W8vyxKnyk7kLmZCCBXw 8RQGGSejnDZXMlPI6u806nGJelMNOuV6rv49fmN38vkqc8zN//7Hx3Ua9 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAA9GpFc/40NJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgWEvaIEDJwqZVJgyFIFnCwEBGAuEA0Y?= =?us-ascii?q?ChGsiNQgNAQEDAQEJAQMCbRwMhUoBAQEEAQElEzQLDAQCAQgOAwQBAQEeECc?= =?us-ascii?q?LHQgCBAENBQgTgwiBdQ+rDzOENAKFdgWBLwGLMReBQD+DJX6DHgEBA4ErARI?= =?us-ascii?q?BCYV3A4ocDjMChjWSdWAJAodbhAeHQCGBfIVyg0uIJYsMhXuNCAIRFYEoIAE?= =?us-ascii?q?2KD1xcBU7gmyCFheIX4U/QTGNI4EfgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.58,498,1544486400"; d="scan'208";a="247366647"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Mar 2019 16:37:48 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x2JGblQT019821 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Mar 2019 16:37:48 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Mar 2019 11:37:47 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Tue, 19 Mar 2019 11:37:47 -0500
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>, "kent+ietf@watsen.net" <kent+ietf@watsen.net>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02
Thread-Index: AQHU2dp4LgK63tqezk2Dd3s9wP+vpaYTbHKA//+y6SA=
Date: Tue, 19 Mar 2019 16:37:46 +0000
Message-ID: <aee7d9770a2c4570a3185a1ebeef4c36@XCH-RCD-007.cisco.com>
References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <20190319.161229.1910835285804688041.mbj@tail-f.com>
In-Reply-To: <20190319.161229.1910835285804688041.mbj@tail-f.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.63.23.135]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/9Yt4_wXqxMFIxygX2rxTGdKvBYc>
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 16:37:52 -0000

Hi Martin,

Thanks for the review and comments.

A couple of points:
 
1) Lots of models outside those published in SDOs are already not following the RFC 7950 revision rules.  I think that it is better to have a versioning scheme that reflects how YANG models are actually evolving rather than have all vendor and OC YANG modules either just ignoring the rules, or using clever tricks that strictly conform with the rules but go against the spirit of them (e.g. just publish an entirely new set of YANG modules for each release).  Also noting that having a scheme that allows non-backwards-compatible changes does not require that everyone uses them - IETF could continue to always publish backwards compatible modules.  The obvious alternative here is that each vendor comes up with their own versioning extension and ignores the RFC 7950 section 11 rules anyway, but I'm not sure how that really helps client<->server interop.

2) I don't understand how the RFC 7950 approach of "deprecate a buggy node, and replace with a working node" really works in practice, particularly for configuration data nodes where you have two clients interacting with a server, one interacting with the old path, and another using the new path.  Perhaps there is a robust scheme that works in all cases, but it isn't obvious to me.  Historically, for CLI we just translate the CLI from old to new format and then return the new format when the running config is requested.  But that will still break an old client that doesn't understand how to read the new CLI, even if the server supports them writing via the old CLI.

Even if there is a workable solution for this simple case, I suspect that there are many slightly more complicated cases that don't work (e.g. rekeying a list, changing defaults, incompatible types).

In short, I don't agree with the premise that the current YANG versioning schema using revision dates is working just fine, and no changes are needed.

Thanks,
Rob


-----Original Message-----
From: netmod <netmod-bounces@ietf.org> On Behalf Of Martin Bjorklund
Sent: 19 March 2019 15:12
To: kent+ietf@watsen.net
Cc: netmod@ietf.org
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02

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-0
> 2>
> 
> 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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod