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 > > >
- [netmod] draft-ietf-netmod-yang-module-versioning… Andy Bierman
- Re: [netmod] draft-ietf-netmod-yang-module-versio… Balázs Lengyel
- Re: [netmod] draft-ietf-netmod-yang-module-versio… Andy Bierman