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

Martin Björklund <> Wed, 12 August 2020 07:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49AB03A0CD3 for <>; Wed, 12 Aug 2020 00:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (2048-bit key) header.b=D94DazyJ; dkim=pass (2048-bit key) header.b=cw39bA2o
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O_5FqJiBWkTb for <>; Wed, 12 Aug 2020 00:10:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 738653A0CCE for <>; Wed, 12 Aug 2020 00:10:50 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id B6D215C018C; Wed, 12 Aug 2020 03:10:49 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute2.internal (MEProxy); Wed, 12 Aug 2020 03:10:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= 2rHCsXl0PKlz3Jy2RjYeTDQesViJs45LqPy0fEkUDg4=; b=D94DazyJw0ytruAW lmyH3UQEYkkG5q7ek/HAXGmr6GUO/YJ+shPz95igN9PdXQ7vSfbhxH8yvyvEXwpR 3b5qnYH/E/9qvvITtn/vFEkmY25ls5564SWAD15sifLkgNVdbzxX+O6ySQ6ylYZ7 bnP6lEOlhC8/y7q+FebJ5Gqu348bVCWTMs2frzJPrM9ezRjpADA9sqPib5X+YiYI ohhSDnbEM7y+pVV0xiqIgxqeTppugcglTjSX2icyRG7+hzZc2W9cHqsXyblvrW7w xAW5vfQCTOsGmMwMX6DnikhB2JZW3NU8jxmh2Y9tLJfDHwYk2q69BcdB3dFawos3 epMOQQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; 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=2rHCsXl0PKlz3Jy2RjYeTDQesViJs45LqPy0fEkUD g4=; b=cw39bA2oeKseruZSO4QtN0pl7Ijfeb9pk+rKJND9qNInkwgTj9kL6qrr7 cnJspasrsPN1o0w77HXeq8LM9KlqIFycX5/OcG56QJAI0MS5MFgb9/rEsz7Mtm0P uBBLyTaGdUxIlV8fJNQ1+32euYy013eQIlXetTYlcSU+CtL9feAs+0irqReH+KTS aK+py1LMps0K4AT24wx0kI1+l1I/JbzfNzJW5bKlSDBueQqfjJ4KtessbO44DkDw Z946BpwHdVOOBAom1prAbxSMZu7IFo8Q3sjcA8z49N7TME1RGJsgi6A+GT6GXCdV mDNS+SXsV5ygXC8duRBr0Vu4nIW8g==
X-ME-Sender: <xms:-ZUzXxK7qLBQFdjXwCQR_eYg7UCHcwnYP6JjsnVf9mOdrn5ImuD9Pg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrledugdduudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepheetgedtfffggeffkedvje ekveelteeuuddttdffhfelgfetvdevhedvgeeutddunecukfhppeduheekrddujeegrdeg rdeggeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmsghjodhivghtfhesgeeiieekrdhsvg
X-ME-Proxy: <xmx:-ZUzX9LudygGHb5pPALEOVJRK-w7m0KuNaxJCWbMWfy9sIJH0_qg_w> <xmx:-ZUzX5uzmThj1y7NCocaoNIM7UALy_ocbutr1M0nGaDDmJGR1UTqMw> <xmx:-ZUzXyYnlnI_QXBUPfPxyqF7I6fHQGwtiwCloncek_THzYiyuO9A9g> <xmx:-ZUzX-1p6BYtvR2rG0llZA9e9voyCKzXvdnxbkB7BVDq9Naw089Abw>
Received: from localhost (unknown []) by (Postfix) with ESMTPA id B7C1A306005F; Wed, 12 Aug 2020 03:10:48 -0400 (EDT)
Date: Wed, 12 Aug 2020 09:10:46 +0200
Message-Id: <>
From: Martin Björklund <>
In-Reply-To: <>
References: <> <> <>
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: <>
Subject: Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Aug 2020 07:10:52 -0000


"Joe Clarke (jclarke)" <> wrote:
> > On Aug 11, 2020, at 10:45, Martin Björklund <> wrote:
> > 
> > Hi,
> > 
> > "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.
> > 
> > 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.
> We discussed this on the call.  The thinking was that a long diff
> output would essentially be unwieldy for some modules and important
> changes might be lost.  If the versions were the same, it would be
> ambiguous to the consume as to whether or not the module was only
> changed in trivial (i.e., less-than-editorial) or if more substantive
> changes happened.  If you trust the producer, maybe you assume they
> regenerated the module without trailing whitespace (or the like).  We
> felt there should be a more explicit signal.

But if you don't trust the producer, perhaps they didn't update the
revision according to the rules anyway?  I think we should have sound
rules and if people don't follow the rules then it's up to them.

> >> 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?
> We didn’t discuss this directly, but we did discuss auto-generators
> that could do this type of round-tripping.  The general consensus was
> that you would use the same post-processing tool (e.g., pyang -f yang)
> on the result to ensure consistency.

I don't think we can or should have a solution that works only if
people are using a (specific version of a) specific tool.

> And a consumer would look to a
> canonical source (like IANA, the IETF document, or the vendor) to
> ensure a consistent module.

It is quite common that clients download the modules from the servers,
rather than from a "canonical source".

> In terms of alternate sources, I would think that if one wanted to
> trust an IETF module downloaded from some other site, they could.  If
> that site did some additional formatting, that would be up to the
> consumer to resolve compared to what might be required by a package.
> But if the publisher (IETF in this case) were to republish a module
> with these stripped whitespace line endings, then that would be a
> different revision.

I think they (IETF/IANA) should be able to change insignificant
whitespace w/o changing the revision.