Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

Balázs Lengyel <balazs.lengyel@ericsson.com> Sun, 04 November 2018 12:39 UTC

Return-Path: <balazs.lengyel@ericsson.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 5D7D5127332 for <netmod@ietfa.amsl.com>; Sun, 4 Nov 2018 04:39:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.067
X-Spam-Level:
X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=hLJCzx5b; dkim=pass (1024-bit key) header.d=ericsson.com header.b=U6gD+P5+
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 IMuATn38m1NT for <netmod@ietfa.amsl.com>; Sun, 4 Nov 2018 04:39:09 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA961200D7 for <netmod@ietf.org>; Sun, 4 Nov 2018 04:39:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541335145; x=1543927145; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=atAtr6unpZ6CT0dypznZVoy+c4ct1zzagQHY6iX+bHQ=; b=hLJCzx5bf1hCbS5crYvcH5NiNdu9D5UFFTdqy5Pqh0Kyu/MaSv5JZMngJ6rn/VUz Dd+aqjpk4QiiLt7W1LNOLiXxvNbTvkPjo6vfmmPDXpQe2bOkQpehSnXqb3AXkGMa wLvTPntJTbXhvC0zZPZmBedpg89kOFkANU6yhIGzHTY=;
X-AuditID: c1b4fb30-203ff70000007d19-93-5bdee869ee41
Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CA.17.32025.968EEDB5; Sun, 4 Nov 2018 13:39:05 +0100 (CET)
Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 4 Nov 2018 13:39:05 +0100
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sun, 4 Nov 2018 13:39:05 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DZP7vPW+GSGd0cPrrP1HZqYKv92aIEtDwsE6OhszHB8=; b=U6gD+P5+nw/leLrZaxYGPeWJ27BmhFSREk7sMKJbckayZ12S2vuIFd2NNaGGP6xgYxzVr5fpCymSATVNqWsAIqPFrtVEsN0iNKeaDMcGFuR6aVDVXYG8rE8+Xs1THlNaSg0Gr8JoXlQtwVi8uvjhwJX7Y1tfzRLjQ94m00E6wso=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2494.eurprd07.prod.outlook.com (10.168.139.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.15; Sun, 4 Nov 2018 12:39:04 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%11]) with mapi id 15.20.1294.028; Sun, 4 Nov 2018 12:39:04 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= <balazs.lengyel@ericsson.com>
To: Robert Wilton <rwilton@cisco.com>, Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
Thread-Index: AQHUdDteOhP2A3sul0+FiL1KlR/0Ug==
Date: Sun, 4 Nov 2018 12:39:04 +0000
Message-ID: <c204852f-eaeb-2f45-53c8-4f88a8d50179@ericsson.com>
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org> <a0392622-4405-8286-374b-effd652114cd@cisco.com> <sa636st2a97.fsf@chopps.org> <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com> <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de> <CABCOCHS6Vp6=HS6HPztDqojh=U84LuwbAJGB73HA01S9ukjfZg@mail.gmail.com> <69e3974e-69a9-acd4-b0c8-efec63afd8a9@cisco.com>
In-Reply-To: <69e3974e-69a9-acd4-b0c8-efec63afd8a9@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.176.1.82]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
x-clientproxiedby: AM5PR0402CA0012.eurprd04.prod.outlook.com (2603:10a6:203:90::22) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2494; 6:5CI4E7FK7dutwgnExY9/b9xamysolJ4ZFf5yM5ysPIBQoa+RjPEP5ShZr3D++Zu3vvlzg8o9dLrNWio1dVfDBq3ZKR9zeA9dsSN2ja0lWpGYoo434/J+RCc+so24CNlLfbjUucrhPX1CfI+X60K98H71WFC6sSGyqTnsg2TNd8DiLM/X8QVG1dN5GTEtZKz3kIdfw4hlR6luJrOlvwIpE2K3TT9C6OJJInG1aGV8vtKSskD10SmKsv7GDJJIaEg8L+JexpqOvim86kOci6xbd11j8jnYMic7T0/guSnZKkG+/ksL0HAcBY0PrdJ4s2+jUNj7KbOzpFcPrxm+AR+IxdG2qZxRW1inWqujAaVdf9vS+ey1ctTFfdNVgcNzJ+CyXUkkh4U4b7O75PvtyW3hZKqV7UrnRqA1q6b2vqVOojQUQc4/LO6npPyWnuj5oRAMB7I7Pz2UZ9nXp32/C8/ELQ==; 5:YYi32CX3g+rFKnA8LyVoDpMh706VkEUZE5grnopn/hKvYuaShcEeRyULb9oFEpk2vcCiTgdo43hz1avgB2JRFvkBMNjgK0lVAvS4oyAfkcJOYV4q6Az0pb+Pi0N5hA7uSOTY2bkgBxkzZwJkMht3tTVP0pk6XvH2n6I4wh34TdM=; 7:BtZAWe1lPGFyoPQR1Euk6gWOPtgYn7FcX8r6Oon9t2oIMXh3DlxE4EU8lRogiKZ2hBJxovihx8+0/HDPSfepeH0hLPsNlzapHtpuq8/OvlnZEDdC2mUDMkkHPgO94JV/lCl0t/QzlycLKMu13lGW1Q==
x-ms-office365-filtering-correlation-id: 7f8d4131-2551-47f6-5bde-08d642528044
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2494;
x-ms-traffictypediagnostic: VI1PR0701MB2494:
x-microsoft-antispam-prvs: <VI1PR0701MB2494C0663FE48491E93EA427F0C90@VI1PR0701MB2494.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(100405760836317)(158342451672863)(95692535739014)(248295561703944)(37575265505322)(85827821059158);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231382)(944501410)(4983020)(52105095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2494; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2494;
x-forefront-prvs: 084674B2CF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(136003)(346002)(396003)(39860400002)(252514010)(199004)(189003)(51444003)(2501003)(6436002)(93886005)(105586002)(58126008)(316002)(186003)(6486002)(478600001)(25786009)(68736007)(8936002)(81156014)(81166006)(3260700006)(26005)(14454004)(8676002)(6246003)(386003)(53546011)(52116002)(102836004)(76176011)(5660300001)(6506007)(97736004)(6306002)(54896002)(6512007)(236005)(66066001)(65806001)(86362001)(966005)(31686004)(99286004)(65956001)(85182001)(31696002)(65826007)(53936002)(110136005)(71190400001)(71200400001)(6116002)(3846002)(5070765005)(36756003)(15650500001)(2906002)(2900100001)(256004)(14444005)(606006)(99936001)(7736002)(4744004)(64126003)(486006)(229853002)(85202003)(2616005)(11346002)(106356001)(446003)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2494; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: DZI/3qwTwjX+ipYftD/w7FjGpR+xnFm5MwH0OKts3UOdTDlKr2QZY6Sj1RzoOByL1WSt+YbnTWgNnveARiVowEEM7B79QrMhWrjbKUmyXmQQtn+bquMlgBEH26MbPADnk8LoUbAi2MYUuj7GKYupebpMpbSkwQMZD4NThMVpBkbcDdQDuaDasA0S+6dkKJrXRmBy6anes7CfAefiso8l+LUR6LVdS0m3CjzKCg6Qfhi4ScmW5FaBV/giaNJHq5J2Prreief3GeNj+5VfoVVgOnGlg8HQKiRDRVgltQCft+mIV0LsRtiJZrL9CZ/Lyvfx5Hpm1jkV1RrrR6GhkOxJDqSvKug9NjJO6f1rkQ0sxQc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080009050701000206090305"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7f8d4131-2551-47f6-5bde-08d642528044
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2018 12:39:04.2102 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2494
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHOffebdfh4KQzf2jPJUKWpvZgvS0qFmQPKAhX6tKbj3STTSUN wmC9ZpZZhJvCTGWWmpoV9qKcbvgiy3xFD00dmo8MMRM1q93dBfXf5/f7/r7fc86PQ5NuEzwv Ok6ZzKiVigQJX0jpj9ak+sd96ZEHTvVtkH62GATSzvszSGpsO8eTNrZeJUMo2c25+zxZcfEM Iauq3SvTXmujDlJhwi3RTEJcKqNesy1SGNvbcY9MMucRp3vrJ1EGuvoM6ZALDXgddNtGSR0S 0m7YgmC+pZPgiikEQxmNzqKIAOO1DsQWFM4mobPoO+KUWwTcap2kuKIfgfVjk4BN5uNdcHH8 pcMvxpX2sO4xh+COo2CmVMdjWYyjoaakmuA4ALRXyimWKewDeaYGx4wIb4fCkqd8561IKHtR YD+bpl3wVqiZPcDOILwQppvLHTkk9oT3NiPBPU8MfW0tfI49YHjgF4+1Al4G9SMitu2Bj4O2 ycBj4wEbEHy7nEtwmeHwvOeS07saXnXbnCtbDG+NmYgzvONDR1ezgAsNhWrtSa7fjuBJfivv r9laPO9kFVyfbie5oSwEFY2zZDYKMvxzcYNdI/FlBB8K80mDYwMLoElvowz2Q0jsC6bzkv/n WV4FptujJMebIXfWzOd4OdzM7BNwvB5GrROI47VgqpjnFyBhKfLQMJoTiTHBwQGMOi5Ko1Ep A5RMcjWyfz7zw7nAx2h4aEcdwjSSuIr2mnvkbjxFqiYtsQ752HP6q8reIC9KqVIyErHIN8su i6IVaemMWhWhTklgNHXIm6YkniLp/gdhbjhGkcycYpgkRv1XJWgXrwz0aNngnOtX1VSIX7n3 eNJK+WH973q/jrC+n4svmPQrcsb2/Yqljk0t97dO+//Mea0L2jjiKrku8DbKK9Nrc2Shk+aA B5ZeRVrp3fDEOwMNuCC+v+vIYIlkU1bnjcjdbUtyVUsv6s9m++3UTf5YNBO/x6IMT9Hqznyy RfiTCvEhdyShNLGKID9SrVH8AWSeWx2EAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/NPzcSDAVMDoLIxoVyBVIVuCF5y4>
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
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: Sun, 04 Nov 2018 12:39:12 -0000

Implementing 3.2 will be very costly. IMHO Ericsson will not implement it. We will do our utmost to avoid NBC changes, but if they do happen, I don't believe we would support multiple versions.

If the data models are sufficiently NBC e.g. changing a boolean to an integer 3.2 may not even be possible. The underlying data that drives the device may be an integer or a boolean, but not both. (Strange mapping may be possible to imagine, but they will not always work.)

regards Balazs


On 2018. 10. 27. 1:15, Robert Wilton wrote:



On 26/10/2018 17:35, Andy Bierman wrote:


On Fri, Oct 26, 2018 at 2:33 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Let me add that there was large disagreement what a bug fix is in the
design team. Hence, any text that talks about 'bug fixes' is ambiguous
and of limited value to achieve consensus. (Or we may find consensus
but then not agree on what we have found consensus on.)

To be more concrete, I learned that Rob's notion of a bug fix is very
different from my notion of a bug fix. I think it is important for
having a productive discussion to be aware of this.

For me, a bug fix is rather limited, i.e., fixing something where the
correct intention was clear but the model did not properly capture the
intention correctly, i.e., roughly what we can do with errata in the
IETF. I think Rob understands bug fixes in a much broader sense,
including fixes to what essentially are in my view module design
errors.

With my narrow definition of bug fixes, bug fixes are essentially
backwards compatible (even if they may violate RFC 7950 rules - but as
long as the original intention was clear, we can be flexible).

With Rob's notion of bug fixes, we have to handle them as part of the
versioning system since they may be non-backwards compatible.



IMO requirements 3.1 and 3.2 are the most  important and have the most impact
on the solution space. I do not agree with either of these requirements.
OK.

For 3.1, I think that just means that the solution has to be backwards compatible with existing clients (e.g. don't change the protocols in a non backwards compatible way).


Implementing multiple non-compatible revisions of a module on a server sounds hard,
not to mention that it breaks RFC 7950 rules.
Completely agree that it will be hard.  I envisage that it will optional for servers to implement this.

The current protocols do not support the
ability to specify different versions of the same QName. This change makes YANG validation
much to difficult to specify and implement (as that has to be rewritten as well).
The way that I think of one solution for this problem is using datastore schema (as per the NMDA definition):

Say for release X, the server natively supports Module A@ver1.0.0 and ModuleB@ver1.0.0, call this schema X.
For release Y, the server natively supports Module A@ver1.1.0 and ModuleB@ver2.0.0, call this schema Y.

When a client connects it chooses which schema it wants to use, X, Y, or latest.  If it doesn't specify then perhaps it uses the earliest schema (to handle requirement 3.1).

If the client wants to use X, then the server has to translate the request into the equivalent request using schema Y instead.  Perhaps the server has to validate the config both in the context of X and Y.

If the clients wants to use Y then it just talks to the server normally, i.e. as it does today.

I think that this is logically the equivalent model mapping that clients would have to do to support multiple server revisions.  Yes, I think that it is complex.  No, I'm not sure how many vendors will decide to implement this, but I think that it is OK to require the solution to specify how this is done, so that servers that do want to support this, and clients that want to use this, can do so.

But all the QNames, validations, etc, I think would be constrained to a particular schema.


It is one thing to deploy rapidly changing, buggy YANG modules in order to
gain experience quickly..  It is quite another to complicate YANG and the protocols
to preserve these interim mistakes, and bake into the standards the notion that this
is good engineering.
Thanks,
Rob



/js

Andy
 

On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote:
> Hi Chris,
>
>
> On 25/10/2018 18:42, Christian Hopps wrote:
> >
> > Hi Rob,
> >
> > We've more privately discussed the bug-fix scenario and I'm sympathetic
> > to it; however, the requirement as written does not restrict itself to
> > fixing module definition bugs (e.g., a pattern or other value
> > constraint) in some small but incompatible way -- instead it's wide open
> > and it will be [ab]used that way.
> I think that everyone on design team agrees that non-backwards-compatible
> changes should be minimized and should really only to used for bug fixes
> where it is anticipated that clients should not be affected.
>
> We want to allow non-backwards-compatible changes at the head of the
> development tree, but again, I think that everyone agrees that keeping it
> backwards compatible where possible is a good goal.
>
> However, I think that there will be cases where a vendor decides that it is
> right for an enhancement or non backwards compatible change to be made to an
> already released module.  I agree that this is highly undesirable and an
> abuse of the rules, but I don't believe that whatever versioning scheme we
> come up with will prevent vendors from doing this.  So then the question
> becomes: Is it better to pretend that this scenario will never happen,
> design the versioning scheme so that it cannot be expressed, which probably
> just means that clients will not be able to detect when vendors do this by
> cheating the rules!  Or is it better to accept that this will sometimes
> occur, provide strong guidance as to why this is bad practice and should be
> avoided, but have a versioning scheme that still allows this to be expressed
> (in a bounded way)?  I.e. even if the vendors are doing something that is
> less than ideal, at least the clients can spot where they have done this.
>
> ---
>
> A separate concern that we had about ties this strictly to bug fixes is that
> some one will ask for a definition of a bug fix.  The design team tried this
> but we couldn't even agree what a bug fix is, let alone agree with a single
> definition of a bug fix as it related to a YANG module.  So our conclusion
> was that perhaps it is better not to tie the requirements themselves to bug
> fix vs enhancement, because the boundary between the two is too vague, and
> module writers will bend the rules.
>
> So I see that the rules should be:
>  - backwards compatible bug fix  - this is fine.
>  - non backwards compatible bug fix - this is fine if it is pragmatically
> expected to not impact any clients, but careful consideration is required if
> it might break clients.
>  - backwards compatible enhancement - not ideal, but pragmatically OK.
>  - non backwards compatible enhancement - this is bad and should be avoided.
>
> But if we don't want to define the difference between a bug fix vs
> enhancement then I think that you end up with the most general requirement
> being that we do want to allow for non-backwards-compatible changes in
> released modules to accommodate the bug fix scenario, but the expectation
> (and guidance) will be that they should only be used for bug fixes.
>
>
> >
> > For example:
> >
> > > Here is what I am afraid the vendors want here: A developer on
> > > release train X can easily change some data structure and then push
> > > the change into an automated system which generates a new YANG
> > > module definition and revs a version number -- all done! They don't
> > > have to deal with the inertia of making this change in their release
> > > train Y or Z and they don't have to treat modules as a stable API
> > > they are exporting, b/c they now have these new wonderful versions
> > > from this work. Meanwhile we the users now have to deal with N forks
> > > with all the various little incompatible changes random developers
> > > at the company wanted to make without having to coordinate with
> > > their coworkers/other internal teams. Now multiply this by M
> > > vendors. It's a nightmare. It shouldn't be what we are optimizing
> > > for, let alone making a requirement.
> >
> > Regarding enhancements, these are features, and are naturally
> > augmentative. I find it hard to believe we have a pressing
> > need/requirement to support non-backward compatible changes to existing
> > modules in order to support enhancements.
> I agree.  It was a backwards compatible enhancement that I was considering.
>
> Thanks,
> Rob
>
>
> >
> > Thanks,
> > Chris.
> >
> >
> > Robert Wilton <rwilton@cisco.com> writes:
> >
> > > Hi Chris,
> > >
> > > I think that there are two things driving this requirement:
> > >
> > > What I regard as the key one, is that we want to be able to support
> > > the software
> > > that we have shipped. In particular, we may need to fix bugs
> > > (perhaps at the
> > > operators request) to a YANG model that has already been released.
> > > I.e. I think
> > > that there are some scenarios, where forking a YANG module, although
> > > undesirable
> > > is the right thing to do to include a fix. I don't believe that
> > > features or
> > > deviations help solve this problem.
> > > The two alternative solutions to being able to fix bugs, neither of
> > > which I
> > > think is pragmatic, that I can think of are:
> > > (i) Vendors ensure that their YANG modules are perfect before they
> > > ship in a
> > > release.
> > > (ii) If a bug is reported, operators are happy to wait until the bug
> > > has been
> > > fixed in the current development release, and will migrate to that
> > > latest
> > > release to pick up the fix.
> > >
> > > The second thing driving this requirement is that vendors sometimes
> > > get asked
> > > for enhancements to existing releases, perhaps because the latest
> > > development
> > > release is too far out, or ask for an enhancement on the current
> > > train to be
> > > back ported to an older release.
> > >
> > > So, aiming to have stable YANG modules, trying a lot harder to avoid
> > > non-backwards-compatible changes, and keeping new functionality to
> > > the head of
> > > the development I completely agree with you on. But I still believe
> > > that there
> > > are some valid scenarios, that should be limited as much as
> > > possible, where it
> > > is necessary to make changes that sometimes break these rules, and
> > > having a
> > > limited scheme that clearly indicates where such breakages have
> > > occurred is
> > > probably better that the status quo of where the modules get
> > > changed, but the
> > > operator doesn't get any useful indication of what type of changes
> > > are being
> > > made.
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> > > On 25/10/2018 16:26, Christian Hopps wrote:
> > > >
> > > > > On Oct 20, 2018, at 1:55 PM, Joe Clarke <jclarke@cisco.com> wrote:
> > > > >
> > > > > * New requirement 1.4 for supporting over-arching software releases
> > > > [ I read this as supporting various different module versions
> > > > based on a vendor's different software release trains. If this
> > > > is wrong then the rest of this doesn't apply and I would just
> > > > ask for the text to be update to clarify what it means. ]
> > > >
> > > > How many operators/users have asked for this or indicated it's a
> > > > requirement for them?
> > > >
> > > > What problem is intractable without this requirement being met,
> > > > and what is the cost of this requirement on the actual users?
> > > >
> > > > I have pushed back multiple times on this b/c I believe this
> > > > "requirement" is really being pushed to make it easier for
> > > > vendors (a small affected group) to develop their software at
> > > > the cost of their users (the much larger affected group) who
> > > > would then have to deal with multiple trains of the same module.
> > > >
> > > >
> > > > We already have features and deviations why are they not enough
> > > > to deal with functionality that is present or not in various
> > > > software release/devices?
> > > >
> > > > FWIW I'm not against making it easier to develop software, but
> > > > we have to be mindful if we are just pushing the cost (and
> > > > magnifying it greatly) to other people in the community..
> > > >
> > > > Thanks,
> > > > Chris.
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/netmod
> > > > .
> > > >
> >
> > .
> >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/netmod

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/" rel="noreferrer nofollow" target="_blank">https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/netmod



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod" rel="nofollow">https://www.ietf.org/mailman/listinfo/netmod


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod" rel="nofollow">https://www.ietf.org/mailman/listinfo/netmod
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com