Re: [netmod] draft-ietf-netmod-yang-module-versioning-05: NBC Changes

Andy Bierman <andy@yumaworks.com> Mon, 17 October 2022 18:19 UTC

Return-Path: <andy@yumaworks.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 05F26C1524C7 for <netmod@ietfa.amsl.com>; Mon, 17 Oct 2022 11:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DA26T0AFIyMQ for <netmod@ietfa.amsl.com>; Mon, 17 Oct 2022 11:19:00 -0700 (PDT)
Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com [IPv6:2607:f8b0:4864:20::112f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D237DC1522D2 for <netmod@ietf.org>; Mon, 17 Oct 2022 11:19:00 -0700 (PDT)
Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-35befab86a4so115353867b3.8 for <netmod@ietf.org>; Mon, 17 Oct 2022 11:19:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EW4csuybi8eNowXV6QEVr7OQ0hlBFpheKo/2+b6B4YI=; b=HQyUiQKQUj7VhPoB2zsGcSMvlyiCse1lrrmWw0syP9mG5V3maYYUDUuSSbMkw2NgWi xr+95MauWdanpTg6/lbX7NdAmfSSzdzUHHTb8h804B41pLhuOdl8lsLcp4jwQh1zrTOL 5fk45LdavpP6ruilMk12dPlrfCNOVrZxYVImq2sMVJBw9Pvp66p7N3DJ62synD3DdPHN 3Xh6fchGKMeKKrOIL9LAQCGIPo85fIwpGFStjA0StvYLyOryzQBW5kudEZRnnC6an2bS sqknmTKTJSjFu8oo0VMwK3U7nhWrkswzWe2n03BFAJtHekzTCCvK36HqKB00W4WYgUtl jHVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EW4csuybi8eNowXV6QEVr7OQ0hlBFpheKo/2+b6B4YI=; b=aO/BH6Fp0j/qzrf0RRJub/FeV5qLoUDkW2QedbXU+3GMkV6moSbjlXdfLEX7GacX9D zc5FBxtQIABSlV0mdQzKmkTTcHg2Q5T6Us1i+v9IClHa4q/Mk40vsOPuScLiKdqi99Rh puL2nArwn6cgSnq7C7V1C24lx/pSw9kzJRDDyC9rHi+sKISg6YhyBPssBqLpu7vS1x63 YI2z4bSP61vjPkb48qHvsEQPwthEf7Y7m/pUTAy4hXtSJGGsOS2/w1/vvKvMkoHPFAJ+ cFsdSnnch13XyjeHKAfK0RTOQrYlQYBFk8MLQMesQHuJ19DvKONYBBM4zNWNZKJaIV0D BiTg==
X-Gm-Message-State: ACrzQf0tSM5H0D/9TcGFiyYzRovpxfpdep3/FqJWab2YB1WeCS4hHN5V HT7bDxpjWzWCos8EDjJRENDXAbG6L2QMDl8ACIecD3iNF9fbMQ==
X-Google-Smtp-Source: AMsMyM7g+LXVDYpnhIaLB3i1RblZqp8og0Y/FQGJpbNSWN+upcDDfEJxPoOzVfBhaXEdqAogdBVZ2HPL+j2FMUdV3Sk=
X-Received: by 2002:a81:b047:0:b0:358:9750:d859 with SMTP id x7-20020a81b047000000b003589750d859mr10529193ywk.212.1666030739525; Mon, 17 Oct 2022 11:18:59 -0700 (PDT)
MIME-Version: 1.0
References: <CABCOCHS+6Oi+1sbhaAt2k5QWNLBEGExeBJre0B5CzYNkAkshaA@mail.gmail.com> <PAWPR07MB9274FBA39B25C3F544DE570AF0299@PAWPR07MB9274.eurprd07.prod.outlook.com>
In-Reply-To: <PAWPR07MB9274FBA39B25C3F544DE570AF0299@PAWPR07MB9274.eurprd07.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 17 Oct 2022 11:18:48 -0700
Message-ID: <CABCOCHRZSkMmnjmhnciaiiBxdin5ag9Q=f9XtSuYkcjqZ0GwEg@mail.gmail.com>
To: Balázs Lengyel <balazs.lengyel@ericsson.com>
Cc: NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006a277a05eb3f029d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Xsx2ct7s3eRLwPjkPjMbk23V2ws>
Subject: Re: [netmod] draft-ietf-netmod-yang-module-versioning-05: NBC Changes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 17 Oct 2022 18:19:05 -0000

On Mon, Oct 17, 2022 at 10:52 AM Balázs Lengyel <balazs.lengyel@ericsson.com>
wrote:

> Hello Andy,
>
> Found this older email.
>
> The draft discourages, but allows NBC changes , including in standard
> modules (and that is needed, IETF has already made NBC changes).
>
> Other SDOs ORAN, 3GPP and others have much faster release cycles, so they
> have more chance to deprecate or obsolete  YANG nodes thereby doing NBC
> changes.
>
> Vendors, with even faster cycles, will have even more cases where they
> deprecate, obsolete, remove data nodes.
>
>
>
> Yes, NBC changes are bad, but sometimes needed. The draft encourages to
> keep changes BC, but allows NBC.
>
> This is a significant departure from RFC 7950, just as you say, but the
> idea in RFC7950 that NBC changes can be fully avoided was unrealistic to
> begin with.
>
>
>



The term 'Where pragmatic' could be removed from the text.
It implies that only people who do not want to be pragmatic need to follow
the SHOULD.

I do not object to the versioning work.
We might even implement some of it when the RFCs get published.



> Regards Balazs
>

Andy


>
>
> *From:* netmod <netmod-bounces@ietf.org> *On Behalf Of *Andy Bierman
> *Sent:* Tuesday, 14 June, 2022 20:35
> *To:* NetMod WG <netmod@ietf.org>
> *Subject:* [netmod] draft-ietf-netmod-yang-module-versioning-05: NBC
> Changes
>
>
>
> Hi,
>
>
>
> The draft-05 version has expired and is no longer on the NETMOD WG WEB
> page.
>
>
>
> Sec 3.1 includes this text:
>
>
>
>    Where pragmatic, updates to YANG modules SHOULD be backwards-
>
>    compatible, following the definition in Section 3.1.1 <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning#section-3.1.1>.
>
>
>
>
>
> This is a significant departure from RFC 7950.
>
>
>
> There are normal "lifecycle" changes that can occur to YANG-based APIs
>
> that are currently classified as NBC changes in 7950, sec 11.
>
> They are often related to the release train. Maybe this concept is
>
> common enough to standardize.
>
>
>
> For example, we often introduce a leaf with a default of 'disabled'
>
> because we mandate that ALL new features or behavior changes MUST
>
> require the client to opt-in.  But after a year or two, we may change that
>
> default to 'enabled' in a new release train.  Then if the feature is
> deprecated
>
>  at the end of the lifecycle, the default may get changed back to
> 'disabled'
>
> in a new release train.  BC compatibility is ALWAYS maintained within
>
> a release train.
>
>
>
> Given that RFCs take so long to publish, it seems unlikely that
>
> we would ever be in a position to make a "real" NBC change
>
> in the middle of a release train, such that all of the client code
>
> already deployed will break immediately when the upgrade is done.
>
> We can NEVER just remove the old version.
>
>
>
> It is hard to imagine a situation where breaking real deployments
>
> is a better option than introducing a new identifier, so old clients
>
> and new clients can coexist.
>
>
>
>
>
> Andy
>
>
>