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

"Joe Clarke (jclarke)" <jclarke@cisco.com> Thu, 13 August 2020 08:52 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 DE40D3A0982 for <netmod@ietfa.amsl.com>; Thu, 13 Aug 2020 01:52:19 -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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=cTLX9pw7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vCNO28y1
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 fXjvbK4illig for <netmod@ietfa.amsl.com>; Thu, 13 Aug 2020 01:52:18 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA3E3A097D for <netmod@ietf.org>; Thu, 13 Aug 2020 01:52:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6392; q=dns/txt; s=iport; t=1597308737; x=1598518337; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BIaekY+PiqRpfW9/zms9xahPnohLwfXyOQymd25msqw=; b=cTLX9pw7UDsc8t2GQ2HCZhE2owAgbrQ/XngZeSDgAH/3H3J30yT3ZKqR HdQkHAvYD3k6emAhSF0Rh5p8Keyf477bTw5buOsRfD1fjTHBZ2ctfrKtn lu/561Zk9n9PzpVFxt0UFEKF+j773dWCvbDHWGGgqeH6kCPnWB0cEhoX3 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3ALUK79xXa9PQtiv7h8ef+zWOJ+UjV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN2LufRFgKzdofOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX4ZlaUqW/hpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrAgCd/jRf/4wNJK1fGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBSoFSUQdwWC8shDaDRgONMiWYZ4JTA1ULAQEBDAE?= =?us-ascii?q?BIwoCBAEBhEwCF4IhAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcQEBAQMBEhE?= =?us-ascii?q?RDAEBNwEECwIBCBgCAhUBAQ8CAgIwFRACBA4FHwODBAGCSwMOIAEOpyUCgTm?= =?us-ascii?q?IYXaBMoMBAQEFgTMBAweBDIJWGIIOAwaBDiqCcYNfhkAagUE/gREnDBCBT34?= =?us-ascii?q?+gQSBWAICgVxcBII4M4ItkAUSgmijLQqCYpocAx6gFa4Tg1YCBAIEBQIOAQE?= =?us-ascii?q?FgWojgVdwFWUBgj4+EhcCDY4fDAwLFIM6hRSFQnQCNQIGAQkBAQMJfJABAQE?=
X-IronPort-AV: E=Sophos;i="5.76,307,1592870400"; d="scan'208";a="525952170"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Aug 2020 08:52:14 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 07D8qEpL005262 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Aug 2020 08:52:14 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 03:52:14 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 04:52:13 -0400
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 13 Aug 2020 03:52:13 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ppgx8K1sldDGcyQe1aW2QJv82LEj6i1a5d4NgFja+LHaecUcGEGQOdbDQ/HGsDkEK4dHkuzmIP7KPnvyOZbGyQ5UX8ZLg0CSLLKSZjUxXUQUun5p50hbtPp9e9e7KqU/BfYyQ9hj1VXW05tIKHCpL4+KuPbiQLKbxmAqzq36Ba0JsWzd37vlJzVQjoOdWJAPcZ5XFCTj01gAJXUBZOUZzmzy0taH9IeDGwG90Ut/XwWq5syhMu1qRUlGNAFFWWZiwI2sol5Fvc9E3bGdNUZncLKT9PfCrGWin78afVtt3qSoDyQuKv4IW1CGQwCfq4CqcebW9UrYE51rgqW8lQ71zw==
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=BIaekY+PiqRpfW9/zms9xahPnohLwfXyOQymd25msqw=; b=j+DzhfhvMcgKKA+FdbM8UN5MjBBIOIDXYLG7OmJdayhtfwktiYWgNpmzFJgcVeZH5uYbf26iL1y2HWwPfISf/COhb9MqLqUPKFScekorvUIH7qJOIBtRLs28B9xw91oBoNbZGUPesLSbrmgIdLs0iEKH+8xfGbtNqICp3xxx35ben+slFJGA5NMJBYa9zFVeRv5hue2IBIvknPkSP3lV1+sJUl1eMo20m7Wq5/R0qWZEfsy8uVVgFfjF31JrRQNJE2nUEdL0iGWL2Yv0MnQocrqjZPF1rQpzLgfXcPD/FL1CQUJQlwxAFdDiWESsFxxViSaVcdJFUtT+12PIPQburQ==
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=BIaekY+PiqRpfW9/zms9xahPnohLwfXyOQymd25msqw=; b=vCNO28y1/lvE4rmLZ+Y59jRykWUEwDJAptHRCWERVTgae5OeamOj+1I5UOcgwAFIoKpx3L9P7UdDDNInNPsAxW4sP6S75J7IXKsVNLXWN5WbN0FhLSYwLja6OY/1pHjTuJYazkKOkleSvkuNJGHPSQQWHZHSztG3lnKBaLx4t18=
Received: from BN6PR11MB1667.namprd11.prod.outlook.com (2603:10b6:405:e::12) by BN6PR11MB1843.namprd11.prod.outlook.com (2603:10b6:404:fb::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.21; Thu, 13 Aug 2020 08:52:12 +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.026; Thu, 13 Aug 2020 08:52:12 +0000
From: "Joe Clarke (jclarke)" <jclarke@cisco.com>
To: Ladislav Lhotka <ladislav.lhotka@nic.cz>
CC: =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= <mbj+ietf@4668.se>, "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/HIAgAAopwCAAPmUAIABn5mA
Date: Thu, 13 Aug 2020 08:52:11 +0000
Message-ID: <11245BD3-6E79-4F02-9962-53BE87264460@cisco.com>
References: <5CF24083-4126-4BE0-93F1-9A36F6DE9296@cisco.com> <20200811.164556.608015447238311339.id@4668.se> <A634B3C1-9F19-4A44-9479-56EC986DA1D8@cisco.com> <878sekb885.fsf@nic.cz>
In-Reply-To: <878sekb885.fsf@nic.cz>
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: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2001:7d0:8474:c380:6536:6007:7d62:5158]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ec3a2735-68a0-4c20-13e2-08d83f662b6e
x-ms-traffictypediagnostic: BN6PR11MB1843:
x-microsoft-antispam-prvs: <BN6PR11MB18432BC4A20B032C031E9BDCB8430@BN6PR11MB1843.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: g0+0klV90NcAFa0Dcm4SflnbCXICQzZfhKI+xxZUWkpvr2UguBF0A1XJvR2gA+A9L40W1pfBLYpPQYfJCrzfrCvASLc9t2G8JJqRQDTiXSqaBJo3UKW9e/RUguykqqqgIiEEdSTR3IsOLyKV63oJ+xa1e6NwlTvjbItL2FncQ88QD02Sd4N2x4VImryx80o6+8O0xnSq7XsnbpX2vh09swegBdJ4GB8l3PbNSFKiX4YSuW76GkIiaj4YK4V4jXeO5b+ZwW230gNpK5wyhmAF75L1GGl/QsUNp+F4WoP6PhdesyauTnfzTCPsjYHsty4qDiTTbvNUX9oK4Ol30rGsBwq/zPUGZLVrXmvTsIR/9lFYgsjQ+apo2pHyRCq5kk3SLt97RjCAT5nQsnLje6IiaA==
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)(396003)(376002)(136003)(346002)(39860400002)(366004)(6512007)(66556008)(66446008)(86362001)(2616005)(83380400001)(2906002)(36756003)(33656002)(66574015)(91956017)(316002)(64756008)(66476007)(4326008)(5660300002)(76116006)(66946007)(54906003)(71200400001)(53546011)(6506007)(8936002)(6916009)(6486002)(966005)(8676002)(186003)(478600001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: oXr6r2fPZ3omWYpIVyV9VG2sPaZLHMyOsfhj4gGA+yZiJXAAC8nJCHBhRQQgUbOG2zlMErYH5vIoq0aePSAsYa+6/ZS/RdEcGgqlSJB9tw2ps4mLY6mMaMg/B25Qb7wGtIrEeJJawBGTTCJP+qHL57V0s5njh2x1g31J3hnE0DLE/2lzDcIrDUvXulMLm40dQFxyGPAXj0mw4hfWMwKGSwpF2daKPmQyY9atKzlstpDN2ujWoQrTxOAkEpV0j7khl7mQMyhR1pVsr53clT/aSxGfWZTJaoochcSuJYAiCP7OiPSYbJ1zx+OmNgf0GYeo2y6jPdVSG3zUw16Us2gZGdcjEBd/5xoXZ+NHAm/b9LtpGPNwfQ9g6+Nj2O6oamxP2hK4KV6iTqRk63ZkvjsphNXxZ4czKYrK4YhAN2QrsIPfn0mOj4h27bHstHyMKw3NSDEf4LAhJ+qXUaq6RciMB4k9h5IZGy0JFsiSS6Zt4Uqa64hTBAU71hjnmERG5lv1YF8t/ngWdOLFiG1nranjGs9QQb8XlgfybMOvSHCkZy79rbd07ACHiuZBRwRZUlfmP/nLWkZpTlmTpv8GIBtKTOENFSi+rQ9iF5GefqesyT618B78iEY8FvbIyTug9dOu0HTGFogdavRJY8hv/VTauOkd6WkzN/Ac2aWWKwcdLXxDveVjhSoRQnuxpQF9tNiWX4WN3ABkAfbWeHid4irFQw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <5D4E0AC15FDB6A46972AD25D2FC8A868@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: ec3a2735-68a0-4c20-13e2-08d83f662b6e
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 08:52:11.9504 (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: X41BYEjIyVnqmHHpQRbijmlbps6EGMoMdRchsmDQVoVDDrwZLqw5Czj0RqhU5aAr41exYrXmMKtOB+7SaBcmCw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1843
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/1EgrK5_7exqIULHwjsV7GdfU_tY>
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: Thu, 13 Aug 2020 08:52:20 -0000


> On Aug 12, 2020, at 04:04, Ladislav Lhotka <ladislav.lhotka@nic.cz> wrote:
> 
> "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.

This came up on our last call as well, but the consensus there was that defining canonical YANG would be a large undertaking and out of scope for this work.  That said, I think codifying such things would be useful.

Joe