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

Martin Björklund <mbj+ietf@4668.se> Tue, 11 August 2020 15:06 UTC

Return-Path: <mbj+ietf@4668.se>
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 783333A10FE for <netmod@ietfa.amsl.com>; Tue, 11 Aug 2020 08:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=t+Bh6W/K; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PGIJEnFa
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 M8SwIx0-sLoZ for <netmod@ietfa.amsl.com>; Tue, 11 Aug 2020 08:06:16 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5CAA3A112B for <netmod@ietf.org>; Tue, 11 Aug 2020 08:06:15 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4C0B05C0198; Tue, 11 Aug 2020 11:06:15 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 11 Aug 2020 11:06:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= 4I60ymjN0Zm/LS+BFSuBpIzNdxqVRNLiIBld3gPM5aA=; b=t+Bh6W/KIDG9IAB1 zvHs+JzNuJrH5Y8fUrROrjKAAJsQJDbCQphjWaT288AMHIVDVB1AuVrXdjfFocAe tTG7E+FNWmr3Yr2R84Lk2FEMhZnJlmWN8hRhJ87lBqLNUxrrsmuRwG6kH8nVlxrk 0plKkC+pP/BSsoFDPBnyMVBvOLk1v9CjqdVPQjdLxgmiioDou9Q9cEsBM15mJNIw SlKjxp29UscAYvqAACh7/Kz5qvnRHZWEJHLmskSujr/iwrq/cJBbokhAW5caNOz4 pNo8/1aduAoxtNFZA7zoWvEN//THyS9u0dvbxo7r31to9a9E5GMBjahLzW+za80d 19TUWA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=4I60ymjN0Zm/LS+BFSuBpIzNdxqVRNLiIBld3gPM5 aA=; b=PGIJEnFaWEEMrCsLnqlN7ySq9YnzYAsoOy8w2ZbtLmZVxvRDR8OGOUGCb UVgXTe4JBN+l3fA24fHeBT3XywgUG1MZAB8p3qy6HHmULcEQFzOHhS5/oUFOPE4f WF46UcB1AY0n1DCk29zZs/5n5Zuysi+xsmdr/SkRlQz6rrdnz6EixL+GvbICGFCt nW2dwMSBNhapat8eY9+ADLQTmTICUcwMIavB/i9Hv4/7SrVVemCrN9ZdjBPvSLOy 2KsaGNK2+ExuLy2w9QUP6ZWhluXva7tVZQ1MHk+Qj8vTh8+0hEtC+9aicDTaQBjl f6bidFtaqfN2y/V+2/DhBKY5LVzUQ==
X-ME-Sender: <xms:57MyXwczm1_K0kwgtBUOuEeNf157Xp5MaHvSWkNUsI9Um8_r28U8sA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrledtgdekiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthgsre dtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeefheekgfdukeefheeihefhke egvdffheetvefgfeefgefhvdefueeluddvvdfgheenucffohhmrghinhepihgvthhfrdho rhhgnecukfhppeduheekrddujeegrdegrdeggeenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieekrdhsvg
X-ME-Proxy: <xmx:57MyXyMgV4mAD0bijs2OGgPZDPJzZKzI2GD-t5afmSIlkLJOZzEekA> <xmx:57MyXxh5nLLXnKHFv632AoDVevE8P-bmz7J1VDyZ-7pT7fxSjPA2qg> <xmx:57MyX1-Lblg8ItzfPhJAPXYil5RpBLfbiCR33t-byshpgfW0rwe8kg> <xmx:57MyX14UBKPLER1ZmGRUtN-9wVQ0a5qvcOrKuiXs1CslAWzgD5Wm8g>
Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 77F143060067; Tue, 11 Aug 2020 11:06:14 -0400 (EDT)
Date: Tue, 11 Aug 2020 17:06:13 +0200
Message-Id: <20200811.170613.15308869624694470.id@4668.se>
To: ladislav.lhotka@nic.cz
Cc: jclarke=40cisco.com@dmarc.ietf.org, netmod@ietf.org
From: Martin Björklund <mbj+ietf@4668.se>
In-Reply-To: <19f17f7b-a48a-add0-351d-7a93e959dd7b@nic.cz>
References: <5CF24083-4126-4BE0-93F1-9A36F6DE9296@cisco.com> <19f17f7b-a48a-add0-351d-7a93e959dd7b@nic.cz>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/KQZiazZSuRrHtM86IuZqZZ0gXcA>
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: Tue, 11 Aug 2020 15:06:19 -0000

Hi,


Ladislav Lhotka <ladislav.lhotka@nic.cz> wrote:
> 
> 
> On 11. 08. 20 15:41, Joe Clarke (jclarke) wrote:
> > At the IETF 108 virtual meeting, Lada asked about what would happen if he converted a YANG module to YIN syntax (or vice versa, or to some other format).  This was during the discussion of the issue of what should happen if a module changes and the only changes are insignificant whitespaces (e.g., strip trailing spaces, change line length of descriptions, etc.).
> > 
> > The authors/contributors discussed on this on our weekly calls, and we propose:
> > 
> > If a module changes and those changes are only insignificant whitespace changes and the syntax of the module remains the same (i.e., YANG to YANG, YIN, YIN, etc.), a new revision of the module MUST be created.  If you are using YANG semver as your revision scheme, you MUST apply a PATCH version bump to that new module revision to indicate an editorial change.
> > 
> > The reasoning behind this decision is that it makes it very clear and unambiguous to consumers that this module has been consciously changed, and those changes are only editorial.  This way one won’t be concerned if they note that a module of a given syntax with the same version but different checksums and diffs wasn’t otherwise manipulated.
> > 
> > That said, if a module changes format from one syntax to another but maintains semantic equivalency, then the revision and YANG semver MUST be the same.  In that case, one will use the extension to realize that this module file cannot be directly compared to one of another syntax without looking at compiled or semantic representation.
> 
> The last paragraph means that after a round trip YANG -> YIN -> YANG the
> initial and final YANG modules MUST have the same revision. However,
> depending on the conversion tools used, they may easily differ in
> whitespace, so their byte-oriented checksums won't be equal.
> 
> I think there are in fact three cases:
> 
> 1. Whitespace outside statement arguments - I believe this should never
> be significant.

Agreed.

> 2. Whitespace in the argument of "contact", "description",
> "error-message" and "organization" - this is tricky because tools may
> format such arguments differently. I am leaning towards making
> whitespace insignificant in this case as well.
> 
> 3. Whitespace in other arguments has to be significant and lead to a
> revision bump.

I think that any change in an argument string is an editorial change.

For example, compare these two changes:

   A1.  description "a server.";
   A2.  description "A server.";

   B1.  description "A  server.";
   B2.  description "A server.";

These are editorial changes, and thus the revision should be changed.

Note however that the following change might look like an editorial
whitespace change in the argument, but in fact it is not:

  C1.
      description
          "A server and
           its data.";

  C2.
      description
        "A server and
         its data.";


/martin


> 
> And one more corner case for both 2 a 3: what if "\t" is replaced with
> the tab character in a double-quoted string? For YANG, these two strings
> are absolutely equivalent.
> 
> Lada
> 
> > 
> > Thoughts?
> > 
> > Joe
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod