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

"Joe Clarke (jclarke)" <jclarke@cisco.com> Thu, 27 August 2020 17:21 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 D36113A10DA for <netmod@ietfa.amsl.com>; Thu, 27 Aug 2020 10:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, 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=CMGbPl+k; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vnizi126
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 uNdQ8_IN2jBV for <netmod@ietfa.amsl.com>; Thu, 27 Aug 2020 10:21:16 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2DF3A10D7 for <netmod@ietf.org>; Thu, 27 Aug 2020 10:21:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35803; q=dns/txt; s=iport; t=1598548876; x=1599758476; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wwjkeJOZQSvTu+1uwF3GZW4sim+6nkTlPlwrCzP2AlA=; b=CMGbPl+khEKXv1/O8DwGENfcZd4x0xj86eQfZP2nDCuon0Sw0XtEzP93 DBWVczpeSqCC2zObWN+VCVpJbyeHewXyF+6QyB/LjQhWu+IwqSyMEq+DC C18nX50/04w33mgtSJznwiC1KSN3wf5f7VD5HLQHJSy9bDZLNXr5B00OE c=;
IronPort-PHdr: =?us-ascii?q?9a23=3A5YcPWxzDhvUnQjnXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRePt/dkh1jDRsDG7fNahvDNsrzxH2ANst6Ns3EHJZpLUR?= =?us-ascii?q?JNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8X+75jkYAV?= =?us-ascii?q?DiMwtrK/7uG5LDyci6hKi+/pTJaFBOgzywKbp5MBSxq1DXsc8b5OkqKqs4xh?= =?us-ascii?q?bT5HVSfOEDzmJzLlXVlBH5tco=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAACp6kdf/4oNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGBdgcBAQsBgSIvKSgHgUgvLAqELYNGA4RYiHUlmHGBLoElA1U?= =?us-ascii?q?LAQEBDAEBLQIEAQGETAIXgjICJDQJDgIDAQELAQEFAQEBAgEGBG2FXAyFcwI?= =?us-ascii?q?EEhEdAQE3AQ8CAQgOAigBBgMCAgIwFBECBA4FIoMEgX9NAy4BqEECgTmIYXa?= =?us-ascii?q?BMoMBAQEFhTQYghAJgTgBgnCDZYZPG4FBP4E4DBCCTT6BBIM4gxgzgi2PcDS?= =?us-ascii?q?CbYZpnGIKgmOaLQMeoEWuP4NYAgQCBAUCDgEBBYFUOoFXcBVlAYI+PhIXAg2?= =?us-ascii?q?LRoJZGB9uAQmCQopWdDcCBgEJAQEDCXyOZAGBEAEB?=
X-IronPort-AV: E=Sophos;i="5.76,360,1592870400"; d="scan'208,217";a="549006901"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Aug 2020 17:21:15 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 07RHLFTY003861 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2020 17:21:15 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 Aug 2020 12:21:15 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 Aug 2020 12:21:14 -0500
Received: from NAM04-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 27 Aug 2020 13:21:14 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ngEZHGGb/BAQRIDVInJOZ2GoliUpmiDtLEikaiPUd7ZvgXT7n/rb2YKaolNmXoV0fK77I+6zGaBXE5XBu6UDmcwwxroS23VLS3mJqAV5va4i0CzN0z8u4/UuIPihojoBYQdpakNO8snreS8JPl8loGCsZXpGpXhCXX89MUyAxlTOf/1UXAjDyqnPfz+jMr/O1UrnpQxAmxC5WAwK6akMuUR0QLzPrhpGpm5FiRrhsGp9zlu+7S08p5vyDFBUTCU8/t3KOwUWm45Sl8eIizFhWmcWCDOXR+8jT5cxBBHMkAotZ5WOlCLBqjxfOvNySXbSBhkjYzaNwLGbY5g/XEQGuw==
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=wwjkeJOZQSvTu+1uwF3GZW4sim+6nkTlPlwrCzP2AlA=; b=bluoPUAK2UZlV0+irais2jYqEFvf1CQEJZutJ6vVOD29NeZ2IL3ZLa0C0LQF3EmNuqD+AT3xve5wFHL7IzqmW/wt/XjUkJ4hu1xU/PT6PONBSBgrh/7X6z1vhfx7irWojh/EHuln888jYCEyAZ6Qq0LvZtG3tD25+I7rchU6fpfemSoOHRLHbp9OmO3pRc/JvZokKl4ppDVUAvKe0J+8WWR/TVSUU9ezJPvLx8AHxfo+N3aVft2Zfdk1D7BDUPllDKWG5xSfxIpEDj95oXBByGq2fZ0KYlyq5uVZbT9qWqSEwIPM6zERLNVMOna7IH3ko0WXCdbhs4s/y/MjkZzbqw==
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=wwjkeJOZQSvTu+1uwF3GZW4sim+6nkTlPlwrCzP2AlA=; b=vnizi126p8hVXRPGu98x8Dwzwv81w3M53jr7n21YFM/cshYCwIUqbwLUSn/E2TXBhFHIG/8fMNT/yxZrWKkjKR1Wxj5fHk5PlXEfCO99PyTJ6+YnQ0G1zUjVjnQd4UOM01iBkpL5bcv4FLfrBFcIaqKYdOmK8rlGJpisBjTyuQ0=
Received: from BN6PR11MB1667.namprd11.prod.outlook.com (2603:10b6:405:e::12) by BN6PR11MB1300.namprd11.prod.outlook.com (2603:10b6:404:3c::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Thu, 27 Aug 2020 17:21:13 +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.3305.031; Thu, 27 Aug 2020 17:21:13 +0000
From: "Joe Clarke (jclarke)" <jclarke@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: Ladislav Lhotka <ladislav.lhotka@nic.cz>, "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/HIAgAAopwCAAPmUAIABn5mAgAAMmwCAAAzHAIAU6VyAgAAk4YCAAWc8AA==
Date: Thu, 27 Aug 2020 17:21:13 +0000
Message-ID: <18AE715A-1FD8-4981-BEB6-7778A84B91A0@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> <11245BD3-6E79-4F02-9962-53BE87264460@cisco.com> <acfe1b95-e0f3-0b7e-2635-9582eb11b4e6@nic.cz> <20200813102302.xwowkncgur4s7yuc@anna.jacobs.jacobs-university.de> <E8EFFABC-B60F-438C-B9AB-3204A834DC9D@cisco.com> <20200826195527.dfl45srxuqprmhlm@anna.jacobs.jacobs-university.de>
In-Reply-To: <20200826195527.dfl45srxuqprmhlm@anna.jacobs.jacobs-university.de>
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: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.68]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bff18cf3-c599-4bc4-bd1f-08d84aad9979
x-ms-traffictypediagnostic: BN6PR11MB1300:
x-microsoft-antispam-prvs: <BN6PR11MB1300E1EBA2E1856787BAE5DDB8550@BN6PR11MB1300.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: n7U9xVoZoZ+Bw+CZRqWv7/ZPisCsrjOPZ6tGl7NwMkxs1o/KcdgzOhUWMi4plad8us8lzusAPQYlzfUg/YPOKeuYf+hD+igSCwNlL4PWmX+DLcUl3fAhmObcAw/Zy9gS8cC4ea3+7sNvIezrHN8MQC6gKZBGGcFqCC/4yV1NjGGpkV8RcYRUkMc8uUwqRJvT9rCA2IbZy9BZBEuucTePdPIZTnaHKewJzEuIYjdP+o8GaeHkYCsdIZ1l1QWB/ETWJEwO/32nL+1E/PYU6q8kTGPTK0Eup67cMWPp5UKG1fPeL8poxmVw6zjIxwlrIk/yfxCA9Saj3ocQrzeotuyw9A==
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; SFS:(4636009)(376002)(346002)(136003)(396003)(39860400002)(366004)(6916009)(2616005)(5660300002)(54906003)(71200400001)(4326008)(91956017)(64756008)(66446008)(66556008)(6506007)(76116006)(33656002)(86362001)(53546011)(478600001)(66476007)(66946007)(36756003)(186003)(26005)(2906002)(6512007)(8676002)(8936002)(6486002)(316002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: M4ogYC5QsjSYTe8iajN7lY89WBJsobSqjUGJoBgFA/szYsdQJB6epmxoNdVKv+JzUxZp9+I8J/Tp/jUt3Z6tNZPjUKvy8mWpP+3crXVqoTDRijlxTJUAsbldWqsATZNza1xD1BVhEz0fs1X9vXOLMK4tXDzpmRhu7gNjJltEeXMQei95b4kGqZjylXpL4YlTOmF3xdlyzVOWtYXxwhg5RlkQ0fPKKw7fAArKED1kvxQaWjOV5saPq2gZQo7uD7JfVpuM+degQTDsFBp0NR8Oa+YjWDc+J7+bBT81pb9rbh3neK/XgC3vd1F66R08s9ZxrZ2OCDe7tUTjatuiGqnCORk1t+elLBDaHMQzagFme3TmDgY/QL94HB5oc/14HuD+jmb+4Pdrpkmyj6OUqL87TjKv6RkRW3HQGpSqY7arUnP652oHTc8q9QlFzB58+otxhphOsa8KFnhwBBeWbvePFY5N/80GHGFJV/jLiPiCElP6K+caTLrhnzPK18qpsZO402XpeZsgA8iHSJfz31KtgGAyuxu5Z3YJpEBRyMsRcMZIr4Hfhfoyk0LSZBA8YsPFPlePVCTlqYl6g3w7coRM4XnVYw+wEQ0gkG4DZYU36qgux+a3OruAJ5OkvsXtvKZMLrOL9UJiO7zID+6CQC0C2A==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_18AE715A1FD84981BEB67778A84B91A0ciscocom_"
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: bff18cf3-c599-4bc4-bd1f-08d84aad9979
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2020 17:21:13.5975 (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: siFzqAzBwL6WHEcodfaOZFOYSBvaXHoPEfVP3I9uS5fkDg234Q5KKkdNUCC5XjStP7apjRefMYWKuszF5v1Q2Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1300
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/A1RHCw68oLwbIM0fUVBouYNd8ns>
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, 27 Aug 2020 17:21:19 -0000


On Aug 26, 2020, at 15:55, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>> wrote:

On Wed, Aug 26, 2020 at 05:43:27PM +0000, Joe Clarke (jclarke) wrote:


On Aug 13, 2020, at 06:23, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>> wrote:

On Thu, Aug 13, 2020 at 11:37:18AM +0200, Ladislav Lhotka wrote:


$ pyang -f yin ietf-inet-types.yang | xmllint --c14n - | sha256sum
8d1ca8f30566ce8cbeffa095e20642f8f6e9f3a724286be4ead863b4467dc40b  -

might be a very good start. It is certainly much more robust than
relying on a simple checksum of the YANG module text.

This work started with the need for _semantic_ version numbers and now
we are down to hashes of modules? Do we still have a clear idea which
problem we are solving?

Sorry for the delay.  I was traveling and then trying to get caught back up.  Yes, things got off track a bit here.


- Sane development environments use version control systems, we should
in my view not attempt to go there. We should assume that people
developing YANG modules use version control systems to track
changes.

Agreed.  And through that development, we are not trying to impose any versioning up to the point that a module would be published (e.g., in a draft where it might be implemented).  Certainly, people could also pull and implement any arbitrary revision from a VCS, but we haven’t created any text to cover that (nor do I think we want to impose that each commit revs some version in the module itself).


- There apparently is a need for a packaging system that can express
which combinations of YANG module version are known to work
together.

The YANG versioning work was driven (I think) by the desire to
support non-backwards compatible changes (section 4 of
draft-ietf-netmod-yang-versioning-reqs-03). Why do we end up
discussing how to calculate hashes or the impact of whitespace
changes? Whitespace and layout changes are backwards compatible,
even today's YANG versioning rules handle them well.

The intent, at least for the whitespace changes was at a module release time to indicate what constitutes a version bump.  But the question could likely be rephrased.  Would one change the _revision_ of a module for any of the changes mentioned thus far?  And if a new revision is created, and semantic versioning is used a revision-label scheme, then that revision should have a new version label.  At least this was the opinion of the contributors in the regular weekly calls.


The goal of the effort was to allow for non-backwards compatible
changes. Backwards compatible changes already work today (and white
space changes are obviously backwards compatible). If you want to
_publish_ a module with just whitespace changes, it is defined how to
do this.

To be fair, the goal was to create a way to _express_ NBC changes.  We were very specific on wording it as “allowing NBC changes” versus documenting when NBC changes happen.


I would find it way more important to mark which specific definitions
had backwards incompatible changes (plus perhaps hints how to deal
with them) instead of sticking a label on an entire module and then to
let others figure out what this label actually means for them (and
ultimately it is then the package maintainer's job to dig out which
revision sets can meaningfully work together).

And we have the ability to do that in the module versioning document.  The [YANG Semver] label is there to make it easier for humans to quickly inspect two modules (or a package of modules) and know whether or not to spend more time digging into (via tooling) as to what changes have occurred and if the changes may break their applications.


If I make a non-backwards compatible change to the definition of
object-identifier in ietf-yang-types, then likely >98% of the modules
importing ietf-yang-types will not at all be affected by this. Still I
would have to declare a major version change triggering a lot of 'uhm,
ehm, what'. Expressing incompatibilities at the module level is pretty
arbitrary since the way definitions are organized into modules is
already somewhat arbitrary.

I feel the hint is still helpful, especially for those that may be in the <2% group, whereas not causing an undue burden given that without it, that >98% group would have to take every module change and analyze them for relevant changes.

Joe