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

"Joe Clarke (jclarke)" <jclarke@cisco.com> Tue, 11 August 2020 17:11 UTC

Return-Path: <jclarke@cisco.com>
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 5A3573A0836 for <netmod@ietfa.amsl.com>; Tue, 11 Aug 2020 10:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=VEHpcReM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hGyxaFV6
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 g_X3cfNksHlb for <netmod@ietfa.amsl.com>; Tue, 11 Aug 2020 10:11:32 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3913A0839 for <netmod@ietf.org>; Tue, 11 Aug 2020 10:11:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5284; q=dns/txt; s=iport; t=1597165892; x=1598375492; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CEAl5nnMKl3J/P06isfEQEVMMXzIMx7v5iPgiA3sNd4=; b=VEHpcReM3uJZPA3TB8vx95aZ7+7EWUseBFFF1Loq+xQy6O7cnZndNHoJ 92XW695Yp+BCoE6+EZs+4QSekO1pqdrovPj+Jqem3V9XTbfwbajetxjd1 XK6IClLYmwHR3dU+7uPrAlxtagqZZfTHe6Vzqm9HEVA0NJ/9hhe+OvXvW 8=;
IronPort-PHdr: =?us-ascii?q?9a23=3A0wVH4x1PKiY310n6smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGvacx0gGZG57WuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorC3lbxgTA8utL1HXq2e5uDgVHB?= =?us-ascii?q?i3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJxLwpgLU5cQ=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAgBS0DJf/5hdJa1gGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBSoFSUQeBRy8shDaDRgONLiWYZoJTA1ULAQEBDAE?= =?us-ascii?q?BLQIEAQGETAIXghwCJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBAwESERE?= =?us-ascii?q?MAQE3AQQLAgEIGAICFQEBDwICAjAVEAIEDgUfA4MEgkwDDiABp1kCgTmIYXa?= =?us-ascii?q?BMoMBAQEFgkqCTxiCDgmBDiqCcYNfhkAagUE/gREnDBCCTT6BBIFYBIFcXAS?= =?us-ascii?q?CODOCLZAFEoJooy0KgmKaGQMeoBWuDYNWAgQCBAUCDgEBBYFqI4FXcBVlAYI?= =?us-ascii?q?+PhIXAg2OHwwMCxSDOopWdAI1AgYBBwEBAwl8kAgBAQ?=
X-IronPort-AV: E=Sophos;i="5.76,301,1592870400"; d="scan'208";a="540617103"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Aug 2020 17:11:30 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 07BHBUTu001102 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Aug 2020 17:11:30 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 11 Aug 2020 12:11:29 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 11 Aug 2020 12:11:29 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 11 Aug 2020 12:11:29 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YfMMcipPsE3C86/nbX5ifMkSv+AO/4qgxJnr+SsgbUPs6ilTi5xwwNpxIEN2CoCu5Pil//xuW30sbbFbReX6x+s6EJ3f4MCxZJMD+mHU/RfUrWYaVZCADJKbh/dl7LFesGcpXsv9A3uxO470FpZ2JSq5iG+ulIkWPFffKtoSfoKi/3outRjUVFEpmh/U2UIxjkKrormRfnr0i35L95fTe92gL6EPaNFqIS74Nl3FdF3NXvahE5pGawUCdvyBVQ45DHF3/IVKINxgkOS6bZpJPVBWALna6JzIyHj2VEK3HiLbCiJ6aQqUV1skr4R1JovFeqhFpCpS/reSE7pcVxGYZQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CEAl5nnMKl3J/P06isfEQEVMMXzIMx7v5iPgiA3sNd4=; b=mdGQuZ3DNTiqBfJZ8sQszoiSKtGLstuCrEeEZgDK4ukaioZnrjHiTbB8R48zM+99SLOI7YP7No3pYPtTp5jFL612MvXtS3Ebu51YoDqbvdN7yzw5UJNXj8ViNhhbNxePMTcc4VhxLLh7ul3CAR/YlH/QehNWLAnJJJeM/4Tnx6UHm1tG/vPeBh3VxV2/FKzcCaKd5DM36abEg8QXuoX+23aZSpZ9gN3Xy4UjrttcAbwUy9afN6Rl21YQDHk5YJTyhoyMiuFoqnKkdsAe2QdqTQkpKY9rhgPbG9kNO24gjhngDoCnXemZBJYnWOEqhjESOocPvzHkaT4MhclAo3geMg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CEAl5nnMKl3J/P06isfEQEVMMXzIMx7v5iPgiA3sNd4=; b=hGyxaFV66PlwIqg//L3eMVeNmXS9Asn7g1yaR4J2xVVqZePZRYF98jEuoG1Qu8HPx5S/BiMdGz0ABrdVAV5z9PSaJxagJfLptB24vhJ61+azZSGC268tBgSPg/jL5aR/Sd7us1tcneyvvCQdXo3tbKgopp7ndXc1qYv2fMZRrjA=
Received: from BN6PR11MB1667.namprd11.prod.outlook.com (2603:10b6:405:e::12) by BN6PR1101MB2260.namprd11.prod.outlook.com (2603:10b6:405:53::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.19; Tue, 11 Aug 2020 17:11:29 +0000
Received: from BN6PR11MB1667.namprd11.prod.outlook.com ([fe80::c75:66f5:d072:746a]) by BN6PR11MB1667.namprd11.prod.outlook.com ([fe80::c75:66f5:d072:746a%12]) with mapi id 15.20.3261.025; Tue, 11 Aug 2020 17:11:28 +0000
From: "Joe Clarke (jclarke)" <jclarke@cisco.com>
To: =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= <mbj+ietf@4668.se>
CC: "Joe Clarke (jclarke)" <jclarke=40cisco.com@dmarc.ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning
Thread-Index: AQHWb+UbHoRASKbTwU+7Kq/q+RMeJ6ky/HIAgAAopwA=
Date: Tue, 11 Aug 2020 17:11:28 +0000
Message-ID: <A634B3C1-9F19-4A44-9479-56EC986DA1D8@cisco.com>
References: <5CF24083-4126-4BE0-93F1-9A36F6DE9296@cisco.com> <20200811.164556.608015447238311339.id@4668.se>
In-Reply-To: <20200811.164556.608015447238311339.id@4668.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.1)
authentication-results: 4668.se; dkim=none (message not signed) header.d=none;4668.se; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2001:7d0:8474:c380:745a:7834:4d7c:aaad]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b7abbbea-f458-4e60-242e-08d83e19964d
x-ms-traffictypediagnostic: BN6PR1101MB2260:
x-microsoft-antispam-prvs: <BN6PR1101MB2260B26E28DEE5E091EA12F3B8450@BN6PR1101MB2260.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: k6woGJMXBbHDX6otzH/Syy4EWjfDteSLp6XqZ+P2GDzoYUx/WuMFkBitzWh5UCHGbJwZ4wM/Pz1Gpmh/VB7/KCpX4Z4gbyQxYaYf2fU1Vq1QxaMloKoZlXWjoqdvFqfOkXlOirnw6sR0+j6/Ca4KHjwKc6UdB/HvFUaZ0mVURC9uJa7vIB+fqkxVMk3/9fm2jymqS0KOmGu3ST+m7klh+YaB+i3/XvGcb5Sl9BiOm/hov1SQXw4+eg2lcsjAspq/PHjkhyVPikUxpYEr4onjVZlSL2ofFZNzbItnItjQf/rN8NPpI1nRphDdlRX62nnJdXPdf1DgYvrkXvBh/4xaiw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB1667.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(346002)(396003)(136003)(376002)(64756008)(316002)(186003)(4326008)(66446008)(91956017)(8676002)(66476007)(8936002)(66556008)(2616005)(71200400001)(76116006)(66946007)(5660300002)(53546011)(6512007)(36756003)(6506007)(66574015)(478600001)(6486002)(2906002)(33656002)(83380400001)(54906003)(86362001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Yg+E0Fkvr4UpCkSzlHVZOWW69WOc8CnndXGJGH/D3+4A14H4AxsIqvodZzGog4L03To9kGlWP4pLvTJBv0jaIGcKRZDuQnb5di8viTEo43HvpQPEnOXg/snpOrXskAGbWNkiOjNM/mkj/PhD3YfrlvExGLyfEXjHuear93+ojmwNL6C3vX4zaJvxnI3JqcSAovb2fhmE2RmN5OplgR6xPmNpRKzxa+SrfnnN06cHp0my7ii0/DgYSbnh3zpG92EafoSGBFS2PHTsbq3cq02odNXVZtYvW8LoC5cF3H8u7c4/mdVH8YjGk2w1sxrJJpJXxwrkB2q2n1u0x2qJEzONFz1LO1RZVbGlpQos4PjazoawOuDE1dRKqI1KecMp2zT26WUdEmeCYgylHSJJ1Axiqzxzl4e1IccJ3Zaz+FPj76Tv593plKutYtWLyCJIrmNy/VbI0uB3D1x9xrnS74LJyYus7Cw21X3MJzLqjrfYCY4tmx5cbkYYq5ZB50mHlHVrt9Cb3xh2FBuX4Dv3EHK/dFkc/44g/uJaKWB9VD/9ulDIQ9I+7gV9ykrtf9l+9xsZJk5wHmFmwdvsAQCiLFIsb24A+uy54vBg3nOWXcGprAwAFLQ8GiW39olwBDcv7O5UgjqjtiV4St/cp7TcRMeUC2WFFLDQx2aoiM4DKsqZTrjkkMBQxVvz+wQkb0IN1CCROfLol8rH0cR8v/wC94qhkg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <A65B993C97FC214DA3BE8724AF504AC0@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB1667.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b7abbbea-f458-4e60-242e-08d83e19964d
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 17:11:28.8348 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: IHWKMYnvV0n0/yEQPUXmy0a4J2vy5L0+NGQuBEYHudrcbVtGkcchbUCTz0HdiyeGGiccRICkQuR8xXxSpW0DtA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2260
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Qp3DN9AgyCVPAFed_R8vGSPa21A>
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 17:11:34 -0000


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

Joe