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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 12 August 2020 08:56 UTC

Return-Path: <rwilton@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 4CC9B3A114E for <netmod@ietfa.amsl.com>; Wed, 12 Aug 2020 01:56:55 -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=Uv+LqgY2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Fif1rijB
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 L9iO_LtxBiAO for <netmod@ietfa.amsl.com>; Wed, 12 Aug 2020 01:56:52 -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 B09463A114A for <netmod@ietf.org>; Wed, 12 Aug 2020 01:56:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7288; q=dns/txt; s=iport; t=1597222612; x=1598432212; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Gi4tZUhKUAQSjnvIpmmg1s9T5O0YkWM9YLWmB6iMaSk=; b=Uv+LqgY2m/xGWb0MzSBaj97wuYDEb/jhbngMTXC9EWGX3mbldQKMx5pz HLvursDeO0f68hHwULDWvEXx11Ce3pHUFKc1gchrzM5qNpaU7WFt8G+rg zDQEYK6zSbfJ/F5ISHfuYeBDT7ZXiXYRlHfApkybfQUqpmB9T/SBeABk6 I=;
IronPort-PHdr: 9a23:pAiuUBzNSdcUvsnXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5ZRSPt/NshxnCT9aT5/FFjr/QtKbtESwF7I2auX8POJpLS1ceiMoQkgBhZazNCUDyIPPwKSBvGsNEWQxj/nr9OloGUMr7bkfZ93u16zNaEx7jNA1zc+LyHIOaj8m+2+2ovZPJZAAdjzumarQ0JxKz/gg=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DfAQCIrjNf/5JdJa1gGwEBAQEBAQEBBQEBARIBAQEDAwEBAUCBSoFSUQdvWC8sCoQsg0YDjVSYZoJTA1ULAQEBDAEBGAsKAgQBAYQIRAIXgh0CJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBAwEBARARBA0MAQEsCwELBAIBCBEEAQEBAgIVAQEPAgICJQsVCAgCBAENBQgXA4MFgksDDiABAwunQQKBOYhhdn8zgwEBAQWFIRiCDgMGgQ4qgnGDX4ZAGoFBP4ERQ4JNPoEEgVgBAQKBRRoVRASCODOCLZJ/oiWBCAqCYpo6oBWSL580AgQCBAUCDgEBBYFqI4FXcBU7gmlQFwINjh8MFxSDOoUUhUJ0AjUCBgEHAQEDCXyPAgGBEAEB
X-IronPort-AV: E=Sophos;i="5.76,303,1592870400"; d="scan'208";a="540898811"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Aug 2020 08:56:51 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 07C8upgB003340 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2020 08:56:51 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 12 Aug 2020 03:56:51 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 12 Aug 2020 03:56:50 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 12 Aug 2020 03:56:50 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cXe0Uq+Q/8m0k+qZQeNVYYBhWybg/PanUUNq4M65L2T+WXo6IH8RPQtOY6NgQMqYQmKH3XZJCzxe4MXL3yNZDoz4+9h4jRiwatj1MWSBcdxnlqzK5znTraabRbWx3554iUu3Od78k6pnJjoIqApmOFOouNTGX/uZ7o9fP8iAkHw8i7aYMs3sQ1LeRzf98+jQ7iL4AOIjxCSTZyaG3CTn59uQ2nAOskky7IURVrMpbxjBCfj14e8BTE1rRkg9eKoxZSkcYrUYk5l5SB7EMFDg2xSwkDNGwS9FbC/YTn+RWgK0bJKezC8w+kbXT5wCplI5ks8xSY66O7SjbK1S4UzRfA==
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=Gi4tZUhKUAQSjnvIpmmg1s9T5O0YkWM9YLWmB6iMaSk=; b=HEWAVOtKPbCrAdYpXX/SUnejKLhQeO1deWQjIcI+QK4tMVJ9klPi1rCL9TWu2+XFnAC7IFw2hZbrnZ+ksECoqGq0R3d59QBUy+iEbyAkjpJdsGx7iNKXITjbom/RuYlsr7NOxV7M7ffOIZ2nqwb0Uc/aqIjCdhMrPqSDhTrteCUPn1XvpCzjpVBzPyvSar739OfcVovfl4Vtvi1rkzTn/vMsdrqKz63PoZdylYzMf7ziAbEN2tjydNFAQUr9r0q9w+mpcf5ZD+NmUD5wD0HqbTUi2wkliOu2JxErSf0lvssc/75WhLMWtstvKK7RM6hcWbKophg80dDJ8IzV6eaRCw==
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=Gi4tZUhKUAQSjnvIpmmg1s9T5O0YkWM9YLWmB6iMaSk=; b=Fif1rijB8jfliAHhrR5SQv2Cj9TsfAHwexsw41RdbI/7r5dpEqSb2vAedTi6SBC4DRlViIRLmm12e9eifnOdCNfg6lgtjtmO4pbCzuSvs0BoKx7UNoFFd8/hCU3dj4xYJeFsgvd1Sond0oxNx1FWwzbZMp9ESEmIRlw3v/UgLIw=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3475.namprd11.prod.outlook.com (2603:10b6:208:64::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.19; Wed, 12 Aug 2020 08:56:49 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1%3]) with mapi id 15.20.3261.025; Wed, 12 Aug 2020 08:56:49 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Ladislav Lhotka <ladislav.lhotka@nic.cz>, Martin Björklund <mbj+ietf@4668.se>
CC: "jclarke=40cisco.com@dmarc.ietf.org" <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+UaDK+JsHSAhkmXSGM8cHEKI6ky/lqAgAADw4CAARZngIAAE4XA
Date: Wed, 12 Aug 2020 08:56:49 +0000
Message-ID: <MN2PR11MB436610EB684FF7C029C2095CB5420@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <5CF24083-4126-4BE0-93F1-9A36F6DE9296@cisco.com> <19f17f7b-a48a-add0-351d-7a93e959dd7b@nic.cz> <20200811.170613.15308869624694470.id@4668.se> <87bljgb98w.fsf@nic.cz>
In-Reply-To: <87bljgb98w.fsf@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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: [82.15.79.32]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e0e7a82b-2b31-48ce-1668-08d83e9da68a
x-ms-traffictypediagnostic: BL0PR11MB3475:
x-microsoft-antispam-prvs: <BL0PR11MB34752542C865369740457E02B5420@BL0PR11MB3475.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: kDo0Ocb0M3QGo02fTFL8y6/Ljt6r/1iAnNzuggbqIiKZpnep8VHpIKvbpmkx5YTpcQE0sz/rPcIkU3z51cJEehh1tJvHwdYi/ZiyDkRfD66tbKCR8U/bhSzO7g5rDqGbxWcpmEjVMD31/ajUTVqbVp5LfkT4Emrv18pw69TYswNL6AhnM6yFPHplLV7Gu/UdbGtOSVBt4lZdoji2pi5SCvgltp2Nca1YiVlAYolpwFX8Z7oxk+hgKyrsqMGyqCZ8APiDO5CvcfP9uuvhYaEAf2DG8kH8NsndO3ebJdZJo9u0kLx9aHko72S6h7lp+RDu76EBb0PLaTjEBPS3YRfp9sUGGvWEWhNtLd1thSUPv0xR5E6DtK2PhsSc7TWjFrYwOrDQU29SDklpUXhRGz/iNQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(136003)(376002)(346002)(396003)(6506007)(4326008)(55016002)(2906002)(966005)(110136005)(316002)(71200400001)(5660300002)(53546011)(478600001)(54906003)(186003)(8676002)(26005)(66574015)(52536014)(7696005)(9686003)(86362001)(64756008)(66946007)(66556008)(8936002)(66446008)(76116006)(66476007)(33656002)(83380400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: X3h10llOy0Zl1EKyGDflhd2ADNlNSxpCkK9NcSraEh2sTby0YfPaTwqAFBfHpU+//h/BWOic3LQvuTuPmcG6zdS0iwYQEp+tkQwQvHoV365mUNZJ0QvEBNVybWndGla/XgTP3SBziEF+LYc3bJ3NxqAxrEaJjor0YjsjwthwBNGB22EE6lCO8t4+GGF5NS5ZJzWH87eHuyoIHWsnTyU2kjCiFgeBG7Ia4XSbu1lkAV3VTnS15D+0qxLHLk712f15PdS8EJhv90VKJK2K7jTIQLWJzahJgC3khvCgkVF3kntlQyCvb31H24Rmu+ym0kRJsVyJYFRRiawi+BiknITijYAiJuVe32Ksctan2ZyHO7WA5UpkrcB3S0uqWUIP6q/uYvc6OO9HI7IjlgxFhCDCi3GE90gMtPtJDSYoKjkSDdlqSHUDTumepsTPB4WnfVaZ4vsSNeRow7kJdFWsgxxtU4G5htT6aMdBc+aZ9/hBktFKSALCiW3sQ3JW7EXB8RR+dICQEv2JVnqZXY3H/E0ChEiE+qDZlfCbCATtVEUdr8UiA2f7aEqv3+KJCk54kx7QKdYTzGGzHEFTKE1pboanP51+I+GP5cSbgamZdnuBEvZBqETViIyYwa9vTZB0ngHUJW88zd+8AGxjqnEKHHoVTQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e0e7a82b-2b31-48ce-1668-08d83e9da68a
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2020 08:56:49.6271 (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: CHARpVlJvNHuYtrDmiCblyf+6LttsyffHJQtkh6U7tR3ett1L3nJ7iWviwl8J/tpsRkwhuaznEKuzsb+gc9zlQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3475
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/91Mu2JnDssH86rWbu4CqS-mTALE>
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:56:55 -0000


> -----Original Message-----
> From: netmod <netmod-bounces@ietf.org> On Behalf Of Ladislav Lhotka
> Sent: 12 August 2020 08:43
> To: Martin Björklund <mbj+ietf@4668.se>
> Cc: jclarke=40cisco.com@dmarc.ietf.org; netmod@ietf.org
> Subject: Re: [netmod] IETF 108: Summary of insignificant whitespace
> changes and versioning
> 
> Martin Björklund <mbj+ietf@4668.se> writes:
> 
> > Hi,
> >
> >
> > Ladislav Lhotka <ladislav.lhotka@nic.cz> wrote:
> >>
> >>
> >> On 11. 08. 20 15:41, 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.
> >> >
> >> > 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.
> >>
> >> The last paragraph means that after a round trip YANG -> YIN -> YANG
> the
> >> initial and final YANG modules MUST have the same revision. However,
> >> depending on the conversion tools used, they may easily differ in
> >> whitespace, so their byte-oriented checksums won't be equal.
> >>
> >> I think there are in fact three cases:
> >>
> >> 1. Whitespace outside statement arguments - I believe this should never
> >> be significant.
> >
> > Agreed.
> >
> >> 2. Whitespace in the argument of "contact", "description",
> >> "error-message" and "organization" - this is tricky because tools may
> >> format such arguments differently. I am leaning towards making
> >> whitespace insignificant in this case as well.
> >>
> >> 3. Whitespace in other arguments has to be significant and lead to a
> >> revision bump.
> >
> > I think that any change in an argument string is an editorial change.
> >
> > For example, compare these two changes:
> >
> >    A1.  description "a server.";
> >    A2.  description "A server.";
> >
> >    B1.  description "A  server.";
> >    B2.  description "A server.";
> >
> > These are editorial changes, and thus the revision should be changed.
> 
> But consider
> 
>    description
>        "A server and
>         its data.";
> 
> versus
> 
>    description
>        "A server and
>        its data.";
> 
> Here the difference is only in presentation - a YANG parser gives the same
> string in both cases. Another awkward case is whitespace before a line
> break.
[RW] 

[As an individual contributor]

What about:

    description
        "A server and
         its data.";
 
versus
 
    description
        "A server and its data.";

Or any cases where description statements might be reflowed by tooling to fit different line width limits?

Regards,
Rob


> 
> Lada
> 
> >
> > Note however that the following change might look like an editorial
> > whitespace change in the argument, but in fact it is not:
> >
> >   C1.
> >       description
> >           "A server and
> >            its data.";
> >
> >   C2.
> >       description
> >         "A server and
> >          its data.";
> >
> >
> > /martin
> >
> >
> >>
> >> And one more corner case for both 2 a 3: what if "\t" is replaced with
> >> the tab character in a double-quoted string? For YANG, these two
> strings
> >> are absolutely equivalent.
> >>
> >> Lada
> >>
> >> >
> >> > Thoughts?
> >> >
> >> > Joe
> >> > _______________________________________________
> >> > netmod mailing list
> >> > netmod@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/netmod
> >> >
> >>
> >> --
> >> Ladislav Lhotka
> >> Head, CZ.NIC Labs
> >> PGP Key ID: 0xB8F92B08A9F76C67
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod