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

Ladislav Lhotka <ladislav.lhotka@nic.cz> Wed, 12 August 2020 08:04 UTC

Return-Path: <ladislav.lhotka@nic.cz>
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 170C13A112A for <netmod@ietfa.amsl.com>; Wed, 12 Aug 2020 01:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 nHOECP060_-x for <netmod@ietfa.amsl.com>; Wed, 12 Aug 2020 01:04:46 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 559AD3A1123 for <netmod@ietf.org>; Wed, 12 Aug 2020 01:04:45 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id DB78E8600D0; Wed, 12 Aug 2020 09:54:12 +0200 (CEST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id B152086004C; Wed, 12 Aug 2020 09:54:10 +0200 (CEST)
From: Ladislav Lhotka <ladislav.lhotka@nic.cz>
To: "Joe Clarke \(jclarke\)" <jclarke=40cisco.com@dmarc.ietf.org>, Martin =?utf-8?Q?Bj=C3=B6rklund?= <mbj+ietf@4668.se>
Cc: "Joe Clarke \(jclarke\)" <jclarke=40cisco.com@dmarc.ietf.org>, "netmod\@ietf.org" <netmod@ietf.org>
In-Reply-To: <A634B3C1-9F19-4A44-9479-56EC986DA1D8@cisco.com>
References: <5CF24083-4126-4BE0-93F1-9A36F6DE9296@cisco.com> <20200811.164556.608015447238311339.id@4668.se> <A634B3C1-9F19-4A44-9479-56EC986DA1D8@cisco.com>
Mail-Followup-To: "Joe Clarke \(jclarke\)" <jclarke=40cisco.com@dmarc.ietf.org>, Martin =?utf-8?Q?Bj=C3=B6rklund?= <mbj+ietf@4668.se>, "Joe Clarke \(jclarke\)" <jclarke=40cisco.com@dmarc.ietf.org>, "netmod\@ietf.org" <netmod@ietf.org>
Date: Wed, 12 Aug 2020 10:04:42 +0200
Message-ID: <878sekb885.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/HKwIRiuRYrSEdVELAkYCieDaI_0>
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 08:04:49 -0000

"Joe Clarke \(jclarke\)" <jclarke=40cisco.com@dmarc.ietf.org> writes:

>> On Aug 11, 2020, at 10:45, Martin Björklund <mbj+ietf@4668.se> wrote:
>> 
>> 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.
>
> 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.
>
>> 
>>> 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.  And a consumer would look to a canonical source (like IANA, the IETF document, or the vendor) to ensure a consistent module.
>
> 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 it would be better to define "canonical YANG". One relatively straightforward way might be to convert to YIN first and then apply XML canonicalization:

https://www.w3.org/TR/2001/REC-xml-c14n-20010315

As an additional benefit, this would also enable digital signatures of YANG modules.

Lada

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

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67