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

Martin Björklund <mbj+ietf@4668.se> Wed, 12 August 2020 09:02 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 49C453A0E69 for <netmod@ietfa.amsl.com>; Wed, 12 Aug 2020 02:02:54 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=TceS+LKL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AR5pEo1u
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 aTuuZJXdOtqM for <netmod@ietfa.amsl.com>; Wed, 12 Aug 2020 02:02:51 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE4F3A114A for <netmod@ietf.org>; Wed, 12 Aug 2020 02:02:51 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D0E6A5C012A; Wed, 12 Aug 2020 05:02:50 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 12 Aug 2020 05:02:50 -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= 9K6FqW0aC9IFzoZBEhOTWgdo2FvWUUH1IctMMHcV80s=; b=TceS+LKLDofZZlGS LzNW5JiFpZqoyzEsWgQsiTYJWopVDZj7jhNr9pLzDLHT81nSXjfJf3AYAlNGGhl0 za+vf72iTV6O/4H1dX4eTGCp22Gy17iVXpg3O7RXJUVcJLgRkXUs3i/HkvFcFCyM SYbtVDt/pYugOZCahtaR2bjKOTdKFCjLSH07r7t5HEY1KlLBb6c9Y2VctTdweu54 KbDQTsLobjpwYcyJQ6Zam7bGa/fQW+z2DEOgkejRRz78kg3g4b7a6A6C++sik8Pl 2M6NhaVrA7KbRzIdT36ak4/55YtnMA4IFOaUIrJaqiTOgUYEAJbYrXwA7+o8ShCj QP7j8g==
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=9K6FqW0aC9IFzoZBEhOTWgdo2FvWUUH1IctMMHcV8 0s=; b=AR5pEo1uOMcMAZitOu+vphTz3W/DkzMT0B2Ug7ZUbWWc9TJQvPn9vPIhD UYGCpqfzqwe0iGdt9Y89QjM+UxLcob3/OrZmpcVv65WwtFb2xY5gwIu4aV+lsIYo LlEbZe+D4NfDGYbHMeebPz3UdYxLICLLLhykIDS9+CISF59wMcXAnG72S2xpqODM 11Oj/CMXlfYBodCgbxg4NyD1hsX7jzwGIUb7Jeohj8FrlYOo8MHGsMp60BpavNF1 6yIAl5h6W0ZGwqYbeRf3N0vg84BvACGunPgtON4BxBMYsUAVB4G7fM//VO/KthM5 JFTedDd2uHUNX82+XslqDtAzztDIA==
X-ME-Sender: <xms:OrAzX_WIsL8wlOBkidKrA-w236EPOuTb6Jw2N65EveDe8qfhwjW-0A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrledvgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthgsre dtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeefheekgfdukeefheeihefhke egvdffheetvefgfeefgefhvdefueeluddvvdfgheenucffohhmrghinhepihgvthhfrdho rhhgnecukfhppeduheekrddujeegrdegrdeggeenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieekrdhsvg
X-ME-Proxy: <xmx:OrAzX3mKCDl7cUuVRLb4tdrzWx6R5YI6IEZxEwn5utGpO0x8OZHqyQ> <xmx:OrAzX7YD-IEvHyLdX0s5OfZGSM3MmL1cI1e6dlFf18iCrBl8EDNzmw> <xmx:OrAzX6WEmq7gWWYbsQ58F2qVD0P8Uvb30GIdyvSH9PHRIlF9-J7Syg> <xmx:OrAzX5uffTwUQkEjLVtFZJjBlyzFsKG848mfGVD78VEHU5Vk3HwYeA>
Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 62F7D30600B1; Wed, 12 Aug 2020 05:02:49 -0400 (EDT)
Date: Wed, 12 Aug 2020 11:02:48 +0200 (CEST)
Message-Id: <20200812.110248.113318645201074225.id@4668.se>
To: rwilton@cisco.com
Cc: ladislav.lhotka@nic.cz, mbj+ietf@4668.se, jclarke=40cisco.com@dmarc.ietf.org, netmod@ietf.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <MN2PR11MB436610EB684FF7C029C2095CB5420@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <20200811.170613.15308869624694470.id@4668.se> <87bljgb98w.fsf@nic.cz> <MN2PR11MB436610EB684FF7C029C2095CB5420@MN2PR11MB4366.namprd11.prod.outlook.com>
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/mEOkYTby_36FMcdtMvnxKyAvXyE>
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: Wed, 12 Aug 2020 09:02:54 -0000

"Rob Wilton (rwilton)" <rwilton@cisco.com> wrote:
> 
> 
> > -----Original Message-----
> > From: netmod <netmod-bounces@ietf.org> On Behalf Of Ladislav Lhotka
> > Sent: 12 August 2020 08:43
> > To: Martin Björklund <mbj+ietf@4668.se>
> > Cc: jclarke=40cisco.com@dmarc.ietf.org; netmod@ietf.org
> > Subject: Re: [netmod] IETF 108: Summary of insignificant whitespace
> > changes and versioning
> > 
> > Martin Björklund <mbj+ietf@4668.se> writes:
> > 
> > > 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.
> > 
> > But consider
> > 
> >    description
> >        "A server and
> >         its data.";
> > 
> > versus
> > 
> >    description
> >        "A server and
> >        its data.";
> > 
> > Here the difference is only in presentation - a YANG parser gives the
> > same
> > string in both cases. Another awkward case is whitespace before a line
> > break.
> [RW] 
> 
> [As an individual contributor]
> 
> What about:
> 
>     description
>         "A server and
>          its data.";
>  
> versus
>  
>     description
>         "A server and its data.";

I wrote:

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

Your example changes the argument string; hence this is a significant
(editorial) change, and requires a new revision.

> Or any cases where description statements might be reflowed by tooling
> to fit different line width limits?

See above.



/martin


> 
> Regards,
> Rob
> 
> 
> > 
> > Lada
> > 
> > >
> > > 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
> > 
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod