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

Martin Björklund <mbj+ietf@4668.se> Tue, 11 August 2020 14:46 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 EF2393A10F2 for <netmod@ietfa.amsl.com>; Tue, 11 Aug 2020 07:46:01 -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=v9LtmBVb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RyfI3cCc
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 f028rCj5MoK1 for <netmod@ietfa.amsl.com>; Tue, 11 Aug 2020 07:46:00 -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 4F59E3A10F1 for <netmod@ietf.org>; Tue, 11 Aug 2020 07:46:00 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 7051D5C0117; Tue, 11 Aug 2020 10:45:59 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 11 Aug 2020 10:45:59 -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= mrAWz2LZd8dR6ICykqXoaEIXK30D/dW19Yfm6lKwEsA=; b=v9LtmBVbzz1IgOmX vCdn4b0urfybGxf80fa9hr0Q9Kz5SW+idkqjJmT6qKgiXRZSZDc1ipjGUrDafaoy Ko4PtLEcBBq1OYdA/TMq/ATp8eLot0p2dPWowW0yM23TKwvQS5ASR0UJ/qaIUnQu 0ey1tdPrXM7RfCy9ww/MNbKe/jAy4Vg3y1vLeH6wVoplHO4tTd7/avjweeD+b5tI /w5gBE1enrjvSMrw+D1lFpMJJrY/ZGth5WiSz+OkV/xibDrRWyv98wOE1iiIWRhj wkpyL6JDBnOksfLKzj3Vk/6YZDi+8dl7zLl63EEiCtQx4OA+Z0hiRclZR5DTd7pR 1Hr/Jw==
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=mrAWz2LZd8dR6ICykqXoaEIXK30D/dW19Yfm6lKwE sA=; b=RyfI3cCc0enpFk/iii/y1A1clNuC4h7oanxVQlLMmvbij6LSEfLSoxZXY BDV0lmOmpCwVYYMRuwREMr0sdgBPmV2u61GvkuP4tW+t44FZ3DOC9Is36iAraPzA fLbZ92VfMyYtd5+FE5y2m7j5cutp2ehbjOUgOKyHCK5OEBTIpqj23zdP8+LNMCNy gy1MTnxq5YbIk+m8b81aPFCT4F9yCEETpDqoNtgDo+P90MmOWAeiMRF221jhH1io 0qX/648kupd0eCR4tWRHwjmpQl3w0GRPtKnIImVeWSl4uQD4ww84Iw1d2MlEXm7d TTel7cpiuHQh9kA1HHJX3HK3QCRVg==
X-ME-Sender: <xms:Jq8yXzGcPukxjO5PX6B8BDj7xzeE5AyB5ebGpPyRxRaO7UAwL4VJVw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrledtgdekvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthgsre dtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeefheekgfdukeefheeihefhke egvdffheetvefgfeefgefhvdefueeluddvvdfgheenucffohhmrghinhepihgvthhfrdho rhhgnecukfhppeduheekrddujeegrdegrdeggeenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieekrdhsvg
X-ME-Proxy: <xmx:Jq8yXwWjHlMeTlYmFPSTw2epLBgzAqz52Ytks23if_9bjV_m27Au7A> <xmx:Jq8yX1I_foC7ioQ2q7FXE0m0C6oZnASUrr9mgUpgQG1z-Mih-P-9Rw> <xmx:Jq8yXxEOIOMVoyOEznGbqcX3VF-aoowCpikZpdmEhPOPygZ3ROsZgw> <xmx:J68yXxj8eYK2K3Utt6ndyRVauh4j03tETn0DtlznOnp7w4LGXbzn1A>
Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 86C033060272; Tue, 11 Aug 2020 10:45:58 -0400 (EDT)
Date: Tue, 11 Aug 2020 16:45:56 +0200 (CEST)
Message-Id: <20200811.164556.608015447238311339.id@4668.se>
To: jclarke=40cisco.com@dmarc.ietf.org
Cc: netmod@ietf.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <5CF24083-4126-4BE0-93F1-9A36F6DE9296@cisco.com>
References: <5CF24083-4126-4BE0-93F1-9A36F6DE9296@cisco.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/fVAyzv2hYllYXkO-G6o3g9PQUyg>
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 14:46:02 -0000

Hi,

"Joe Clarke \(jclarke\)" <jclarke=40cisco.com@dmarc.ietf.org> 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.

I think this is the wrong way to go.  I clean up formatting issues all
the time, including IETF modules.  I am pretty sure that if you
retrieve modules like "ietf-interfaces" or "ietf-yang-types" from
different vendors' products, you will get modules with differences in
whitespace - and this is not a problem AFAIK.

I think it is ok that a simple "diff" show whitespace changes in this
case.  I don't think it leads to any real problems.

> 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.

This seems a bit inconsistent.  Suppose I round-trip from YANG to YIN
to YANG, and the result is different whitespace in the two YANG
modules.  The revision is the same, as explained above.  How is this
different from changing the whitespace in YANG directly?


/martin


> Thoughts?
> 
> Joe
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod