Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 28 August 2020 07:30 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 207983A0DF8 for <netmod@ietfa.amsl.com>; Fri, 28 Aug 2020 00:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 1A6zmlBBe8YU for <netmod@ietfa.amsl.com>; Fri, 28 Aug 2020 00:30:38 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12C73A0DF6 for <netmod@ietf.org>; Fri, 28 Aug 2020 00:30:37 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 6C411375; Fri, 28 Aug 2020 09:30:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id fnCK0fhAEY3A; Fri, 28 Aug 2020 09:30:36 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 28 Aug 2020 09:30:36 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 156F020156; Fri, 28 Aug 2020 09:30:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id jFLf0UWvJ4pz; Fri, 28 Aug 2020 09:30:35 +0200 (CEST)
Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id A69AB20154; Fri, 28 Aug 2020 09:30:34 +0200 (CEST)
Date: Fri, 28 Aug 2020 09:30:34 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Joe Clarke (jclarke)" <jclarke@cisco.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20200828073034.iq3ow4tpyxq2hfpq@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Joe Clarke (jclarke)" <jclarke@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <5CF24083-4126-4BE0-93F1-9A36F6DE9296@cisco.com> <20200811.164556.608015447238311339.id@4668.se> <A634B3C1-9F19-4A44-9479-56EC986DA1D8@cisco.com> <878sekb885.fsf@nic.cz> <11245BD3-6E79-4F02-9962-53BE87264460@cisco.com> <acfe1b95-e0f3-0b7e-2635-9582eb11b4e6@nic.cz> <20200813102302.xwowkncgur4s7yuc@anna.jacobs.jacobs-university.de> <E8EFFABC-B60F-438C-B9AB-3204A834DC9D@cisco.com> <20200826195527.dfl45srxuqprmhlm@anna.jacobs.jacobs-university.de> <18AE715A-1FD8-4981-BEB6-7778A84B91A0@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <18AE715A-1FD8-4981-BEB6-7778A84B91A0@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/4O0VJUebY4AQQIaFL2hbDZ8kcH8>
Subject: Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning
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: Fri, 28 Aug 2020 07:30:40 -0000

On Thu, Aug 27, 2020 at 05:21:13PM +0000, Joe Clarke (jclarke) wrote:
> 
> If I make a non-backwards compatible change to the definition of
> object-identifier in ietf-yang-types, then likely >98% of the modules
> importing ietf-yang-types will not at all be affected by this. Still I
> would have to declare a major version change triggering a lot of 'uhm,
> ehm, what'. Expressing incompatibilities at the module level is pretty
> arbitrary since the way definitions are organized into modules is
> already somewhat arbitrary.
> 
> I feel the hint is still helpful, especially for those that may be in the <2% group, whereas not causing an undue burden given that without it, that >98% group would have to take every module change and analyze them for relevant changes.
>

If you mark the definitions that changed, tools can do the work to
figure out whether importing modules are affected or not. This is
relatively straight forward for a compiler that already knows what is
used and what is not used, this does not require much magic.

Instead, the approch taken here is to provide a somewhat vague warning
indicator (the version number) at the module level and then you rely
on tools (or humans) to identify semantic changes. And tools will
likely fail if semantics in descriptions have changed or they will
fail to decide whether two regular expressions are backwards
compatible or not or if a must statement is equivalent to a previous
when statement in a certain context. For the person making the change,
however, it is fairly easy to leave a mark since he/she can be
expected to understand the nature of the change.

It turns out that we already have some marks in the form of the status
statement. We can mark definitions as deprecated or obsolete. We do
not have a value to say 'changed' in an nbc way and we do not have a
mechanism to document the history of status changes for a given
definition, but that is easy to engineer into YANG.

/js

PS: I assume that we focus on 'published' YANG modules where the nbc
    change churn is reasonably under control. During active
    development phases, modules may undergo many little (nbc) changes
    but dealing with them should be left to version management
    systems.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>