Re: [netmod] All IETF YANG modules MUST include revision-label statements

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 01 April 2020 17:41 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 4B5233A145C for <netmod@ietfa.amsl.com>; Wed, 1 Apr 2020 10:41:22 -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=EkNpxHCd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xZ91/7Dt
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 VgpFZaqQ2en6 for <netmod@ietfa.amsl.com>; Wed, 1 Apr 2020 10:41:19 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EBA33A1463 for <netmod@ietf.org>; Wed, 1 Apr 2020 10:41:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26180; q=dns/txt; s=iport; t=1585762879; x=1586972479; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QGA01qzbHJruJijMPl7oHdD1tobOOm3WmEmnrCFOG7U=; b=EkNpxHCd7nhD4BD5RnbHrTEt0NmPdU0eS2BJOedkdmGq9zfWglQ/EQdu 6hW6+bn9yS9o2gg2OseV4Lqoxe///Rk7EfYlILZPlkhq6kJx8H8IQ/8vV pQhljxwIqkpGplaLkd0cf/seAAWR0FnmPTt0NbEOeq2caRaOZGvyj7ngL 4=;
IronPort-PHdr: =?us-ascii?q?9a23=3AIobjLRbe7plpFPqK8Q8wqiH/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavwcC0+AMNEfFRk5Hq8d0NSHZW2ag=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+CwCj0YRe/4sNJK1mHQEBAQkBEQU?= =?us-ascii?q?FAYF7gSUvUAVsWCAECyoKg1BAg0UDinCCX5gdglIDVAoBAQEMAQEtAgQBAYF?= =?us-ascii?q?QgnQCF4IhJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVwAQEBAQMMBhEKEwEBNwE?= =?us-ascii?q?PAgEGAhEEAQEoAwICAjAUCQgCBAENBQgRAgeDBYF+TQMuAQOTI5BnAoE5iGJ?= =?us-ascii?q?1gTKCfwEBBYUnGIIMCYE4jDEagUE/gRFHgh8uPoJnBIFLGjSCXDKCLI46AoJ?= =?us-ascii?q?IhX4kigqPVAqCPZc9gkyIM5BzjyeBUpo8AgQCBAUCDgEBBYFpIoFYcBWDJ1A?= =?us-ascii?q?YDY4dDBeDUIpVdIEpi0stgQQBgQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.72,332,1580774400"; d="scan'208,217";a="733466669"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Apr 2020 17:41:17 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 031HfHEp006102 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Apr 2020 17:41:17 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Apr 2020 12:41:17 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Apr 2020 13:41:16 -0400
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 1 Apr 2020 12:41:16 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZNgisnxH8UVo8D0nE1S9Cr1HIbNPAYYozTe7RgBmV0v9XmQkCP6ahbX3UgwNrYuaStTvfX+TA5Eu4gEK/knPu2t0budkdzt8o6SgZAHynQnhH1PfCysXOrEtTPLHPm395HVpn1b7EzPXwvmOsqXQVigBx3e10ZZhQTYau6EM/oD8UZMhpuUutG9mRCPAyaPnN2UgOWA1MQhu14epRUdF2j+d3Gp30HsnMtKnTzkLmDhrNgrioxLO3Tu8poJoRCNC290FwfA8jcMwr6EtPhHEaN9kNiU7460fzihXsyRF82cZVrzoPTcKjmIXhuNmcjttvMtLh4dMJY23+OzsiGcb0Q==
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=QGA01qzbHJruJijMPl7oHdD1tobOOm3WmEmnrCFOG7U=; b=mDvF02mz53jALMvyzAHRzn8nmaIDRNIN9ySVNWFL7TYSipKQaZwVwO0L2WwGZ+SOFp4o0o60+dUCbGjz6uEYItp/s4A8/9olUFMPuTDrLZjOT6B/CcePMaZG/fzYSnOXiFposLFJxbE0edfTr4K7dZATRe8EXiZ9AmCGAu1k2vkVPM/E79HQw+b5dkTjED2F8pfNqizYACpr3mf6L29L+P90F+8qmNPcnGRzNlPKk9fKk/RmT9BuDd2/KUQ/8ZfLl2eLKD8okSJI5gQiABnF6cxQCLLW5Tbo+9+LtxAE91AF1olPnWuAW8kgJO27If+Sc7Rb4y5HyAMC0WJS3OG/Ew==
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=QGA01qzbHJruJijMPl7oHdD1tobOOm3WmEmnrCFOG7U=; b=xZ91/7DtzOxKlJdQ2CwVfKeEc5XWKYo2/j+uIZWJNtJvcfluIiJiz2hA1oebdsyeraENbdOLT8ChG2AvKZmui+psyTbp67RGXRtVu7P/0Y8C0OrUUsSJd7tx/KcJchGYP1Z7uASTLLKYMx0hfMBpkN5SFnCncYaIONiLKYovsj0=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4533.namprd11.prod.outlook.com (2603:10b6:208:264::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Wed, 1 Apr 2020 17:41:15 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3%5]) with mapi id 15.20.2856.019; Wed, 1 Apr 2020 17:41:15 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Andy Bierman <andy@yumaworks.com>, Kent Watsen <kent+ietf@watsen.net>
CC: =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= <mbj+ietf@4668.se>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] All IETF YANG modules MUST include revision-label statements
Thread-Index: AQHWBryXXEWOVM1ZWkW+qvBAGEwM/Khhcj8AgAAIq4CAARsOMIAAQQwAgAAL1ACAAX3IoA==
Date: Wed, 1 Apr 2020 17:41:15 +0000
Message-ID: <MN2PR11MB4366BD84001F84F79EA14C61B5C90@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <75CFDBD9-143C-407A-B7C3-26CEC51E229C@cisco.com> <20200328.094121.1160081114435152145.id@4668.se> <76623C79-BB91-4B5F-8FEA-406ADEAD1647@cisco.com> <20200330.202016.930329343788112268.id@4668.se> <CABCOCHS=y8d00xHLzV+LNpvN_=jScw5VizGYWXGopsQAi8qZUw@mail.gmail.com> <MN2PR11MB4366775C8E9A5488D33E484EB5C80@MN2PR11MB4366.namprd11.prod.outlook.com> <01000171313d4b26-a5e29676-2bd1-4bd0-9598-d3eee7fbf32d-000000@email.amazonses.com> <CABCOCHQ0-8VQNaSUzihZLko8VvZ_3o4bC1Jc7K0rN43Ru8suiQ@mail.gmail.com>
In-Reply-To: <CABCOCHQ0-8VQNaSUzihZLko8VvZ_3o4bC1Jc7K0rN43Ru8suiQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [82.15.79.32]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1943856b-9e05-4af1-e311-08d7d663e0b0
x-ms-traffictypediagnostic: MN2PR11MB4533:
x-microsoft-antispam-prvs: <MN2PR11MB4533DE166A36570F1D06AB84B5C90@MN2PR11MB4533.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 03607C04F0
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:(10009020)(4636009)(39860400002)(136003)(396003)(346002)(376002)(366004)(316002)(8676002)(64756008)(66946007)(8936002)(52536014)(110136005)(9686003)(86362001)(81166006)(55016002)(66476007)(66446008)(66556008)(54906003)(5660300002)(53546011)(6506007)(7696005)(76116006)(478600001)(66574012)(81156014)(2906002)(4326008)(186003)(26005)(71200400001)(33656002); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hn5Zh6me237SQrvQhMqzqNR0a7/XwSWUAlVqAbAvZTDi7FrsodhJdaBW4AtS5DskSTF7qxa6Yx1mMQ3r+UaEM1y8r7rcW6VYeuGl6UVr2rMHsiDcHgtzUa7NtTjJAKOpE8DU7ftBvd0DDiCwbJU2czHW9HKDr6R/X6kFqncb+bi6FXxnYVU9Jk00un0K6aTA5Cubd1rSJRjc2ins1uOBn+n69i+qkEi/fFaPC/muMvoD/EF8prBWFNjvwdgQaPfGqZe+IBTf5F4icEi1qphVRFKOL2OfTALXQifSM2gC+HB011qqcZyqaE260SEIDniCizJRsqwECXeZbx4aROWoFN/BUMmYzRLHa5y51nVT+sx4KtfONQU7ZXNdCKxYEzZZpyBpB34o3m166DAPeDSIthEMIqML2ZgW/od69T1HWsegEePTC4sueAC3TB1uR6q7
x-ms-exchange-antispam-messagedata: 57x4kvGsKwgoedxp55WYcpdvl1z4WrF1Xo3RhJyzomCmdRaEPj7w7vBFD5lVCRC8lMZyHYbaJXVmkq9U/t00mKuUZDbXkM5/uyoQHbzM1ATxLfNHZlCUAUtbTnPOYdt7ze8wJ1mcn4fPu1NzY34D6A==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366BD84001F84F79EA14C61B5C90MN2PR11MB4366namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1943856b-9e05-4af1-e311-08d7d663e0b0
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 17:41:15.4300 (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: XP5ohhVAW2nWbS+VANOqLeLx6Sjxt6CoGAXz4d1Uf4B/hx2lYZqPNENVQFsc7I16fSpeErDAyHb3g7Wy5N3f9Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4533
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/L0HXKxrJztbw0VcZvZV5BzFPZBI>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements
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, 01 Apr 2020 17:41:22 -0000

[As an individual contributor]

Hi Andy,

Please see [RW] inline

From: Andy Bierman <andy@yumaworks.com>
Sent: 31 March 2020 17:20
To: Kent Watsen <kent+ietf@watsen.net>
Cc: Rob Wilton (rwilton) <rwilton@cisco.com>om>; Martin Björklund <mbj+ietf@4668.se>se>; netmod@ietf.org
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements



On Tue, Mar 31, 2020 at 8:37 AM Kent Watsen <kent+ietf@watsen.net<mailto:kent%2Bietf@watsen.net>> wrote:
[replying to Reshad as well]

Hi Rob,


My impression is that Semver 2.0.0 works fine if you can always force clients to move to the latest version of the API whenever any bugfixes are made to the API (whether they are BC or NBC).  This is a natural fit for open source projects, but not so great for long life paid support contracts.

Agreed.



The goal of YANG semver is not to facilitate release branching.  It is to allow vendors to fix YANG modules without forcing clients to update to the latest version of that YANG module (which may contain other unrelated NBC changes and have lots of dependencies on other modules).

This is what Reshad was pointing to as well.  I’m very familiar with the issue, from my Juniper days, where there were all sorts of patch and (gasp) customer special releases, either of which could introduce any number of NBCs.

The background, of course, is that [very important] customers have working/validated infrastructure running a specific release and simply cannot tolerate any change beyond the very specific one they need *NOW*

I get it, truly,  but I feel that the ‘m’ / ‘M’ suffixes are both inconsistent with general understanding and insufficiently to express what is needed.



+1

I also find the granularity of NBC info to be mostly worthless at the module level.
There is no difference between a 1 leaf bugfix and a complete rewrite of the module.
Let's say 1 leaf "type string" needs to be changed to add "length 1..max".
This reduces the value set for 1 leaf by 1 value.

This flags the entire module as NBC and you would bump the major revision number.
The entire premise that one can decide if it is safe to upgrade based on the version string is flawed.
[RW]
Yes, for NBC changes, I think that this is probably correct.  I.e. if a module user sees a major version change then they have to understand what the changes are and whether they will be impacted by those changes.  Note, this is what the YANG schema comparison draft aims to define.

But the goal here is not to encourage NBC changes, but allow them to be expressed when they do occur.

So, if the module author is following the rules, and a client sees a minor version change (e.g. 1.0.0 to 1.1.0) then their existing client software should be compatible with the new server release.  The desire is that this is the mainline case that everyone should be striving for (and of course RFC 7950 currently says that this is the only case that is allowed).



A possible fix might be to allow for <major>.<minor>.<patch>[-<anystring>], thereby enabling vendors to encode any format off a base release…and rely on inspection of the “revision” history indicate if/when NBC changes occurred.

But then I question (again) the need for the simplified format at all, as opposed to just using revision dates.  For instance, if <anysting> represents a long history of NBCs, that they were based on some source M.m.p starts to lose relevance.

Is the expectation that the vendor's module versions will use <major>.<minor>.<patch> values mimicking their release numbers?  For instance, would FooBar OS version 20.1.2 implement YANG module "foobar@20.1.2<mailto:foobar@20.1.2>”?    I can see product mangers pushing for this, but then are companies (like Juniper) that use alternate release name-formatting strategies disadvantaged?  How is that fair?   To thwart this, would the WG be willing to assert that the history MUST start at 0.0.0 and MUST only monotonically increment values?



Note that OpenConfig also hit this problem, but they proposed a different solution.  I..e. ship the base module with another module that contains deviations to fix any bugs in the base module.  Alas this completely decouples the real module history from any revision-date/version number contained in the module, since to really understand the version of the module you also need to know the set of associated patch modules containing any deviations to the base module.

I’d need to see an illustration of this to be sure I understand, but my first impression is that it is yet another attempt to fit a square into a circle.



I don't have a solution proposal, but it would be great if a vendor could issue a patch
to a standard module which says "this is the standard module plus these known Errata ".
OK if this is in the form of deviations
[RW]
For an individual module I don’t have a great solution.

But if this is done at the schema level, then I think that YANG packages can cover this case well, the only additional work that might be helpful would be a convention to specify how to name the module containing the deviations.

Regards,
Rob


In the end, I see no substitute to relying on “revision” history which 1) perfectly tracks branching history and can flag if/when NBC changes occurred.


Agreed


Kent // contributor




Andy