Re: [netmod] yang versioning solution complexity and alternative approaches

Andy Bierman <andy@yumaworks.com> Wed, 08 June 2022 17:28 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 ED91BC159482 for <netmod@ietfa.amsl.com>; Wed, 8 Jun 2022 10:28:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 XZSTyXxLofjo for <netmod@ietfa.amsl.com>; Wed, 8 Jun 2022 10:28:44 -0700 (PDT)
Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) (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 09B51C14EB1E for <netmod@ietf.org>; Wed, 8 Jun 2022 10:28:43 -0700 (PDT)
Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-30c2f288f13so216451447b3.7 for <netmod@ietf.org>; Wed, 08 Jun 2022 10:28:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DdhVAW6lnPXOqn84RJYlSF2wYKooU71pqFdIe23FCkA=; b=QGMJDEgu3d/oxjEnCk/QtvJ+UHLXponUaWc5ujg5Vm2s1IYHpaUqcYhSkyrTHuv6fb iVfQdx+6vN9Hvk1qPMYV18eDyZdrYhgV9I+XRe1iyHCzc3mSHvHQTbB5+343a88g9GhL oGjU0SJxK5e/HEbQIpCLfGExdjxNbHQF8vp/UBk7YuUzgwXP7hT3tmIfK1+N2OpAlOjf J0LzrGW13RccYsJKR7Zl/3niO197Sm8+VtMuzNcY0vygVEWz7IzHPY1dr+RPSWgInVo1 oTAG0Fwy1sWGNcHjx0MhreTXTLFpV7dqhMeSM12QaqglymuDTZOaTNFiW6FjhU6auUrM +Ppg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DdhVAW6lnPXOqn84RJYlSF2wYKooU71pqFdIe23FCkA=; b=eLb5SUCoU+eczpHREs40N9qbi3jCVSh9bCDuoSH7tgBYBOl6UPj3MQpkEcyidiecqF IA3TzCy2BC7vinE+9yHQ1/GvEAEwfCB1/kYcFzN+aMFcIvD2cGODmG9AOD5cagPfpSNA L0karlq+JTX0gmr83mQO+4qUN6hiIC7nbp473fr2IWtgTuTAHo9s91q1HHkjkHXp665+ WjXRT0RSrQkYqLihGlw6qPPyTYxoHbQx53jVsZaKPiP9YfcvUq/ZkxWENjg5DTYc6jkl DXrHimVPxRMxdYACnp/8saKp+4N+FE5d5oyPA4OuLj92kXR28c6kxh/BBBUxzIq96FB7 mq2g==
X-Gm-Message-State: AOAM530HgtP4idJP1HOqCo1aGa3byCjnaJvA50aGfgM1+cztDKSOseH2 pY2QUXDMlTqnjshpzhXIhZt1sIJ/0LqcXjU9YWTel820E4k=
X-Google-Smtp-Source: ABdhPJxCXDZhIVXfI9U6mSorbONAOEzNNfVcB2UkHUz7Qu5HeFygZoq+kEcQXfA68NupQU2f6gfDn+il8oukN7W3B3E=
X-Received: by 2002:a05:690c:39e:b0:313:38a7:cc11 with SMTP id bh30-20020a05690c039e00b0031338a7cc11mr10564031ywb.322.1654709322867; Wed, 08 Jun 2022 10:28:42 -0700 (PDT)
MIME-Version: 1.0
References: <20220309101609.d33knxlhyq62wejq@anna> <BY5PR11MB41967D79E62D8D08CBEF6128B5A59@BY5PR11MB4196.namprd11.prod.outlook.com> <20220608153802.63h7knp5ezmhfjya@anna> <BY5PR11MB419609600B2ECFE2DD029D4FB5A49@BY5PR11MB4196.namprd11.prod.outlook.com> <20220608170433.7psmk7n2ti5er2kl@anna>
In-Reply-To: <20220608170433.7psmk7n2ti5er2kl@anna>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 8 Jun 2022 10:28:31 -0700
Message-ID: <CABCOCHR_1kXyx6fS+EmzqLjwf+ZKSJM6bn2Z4whpiYnt9WcTvA@mail.gmail.com>
To: =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= <j.schoenwaelder@jacobs-university.de>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006582bb05e0f309ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/qiAcd0csTprIuppMi7wSL6naqnU>
Subject: Re: [netmod] yang versioning solution complexity and alternative approaches
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: Wed, 08 Jun 2022 17:28:48 -0000

On Wed, Jun 8, 2022 at 10:04 AM Jürgen Schönwälder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, Jun 08, 2022 at 04:40:05PM +0000, Rob Wilton (rwilton) wrote:
> > >
> > > Rob,
> > >
> > > discussing details is likely distracting from the main difference in
> > > our viewpoints so I will only give a top posting response.
> >
> > Okay.
> >
> > I believe that the consensus of the authors on the weekly calls is also
> that annotations at the "data definition" level are helpful, alongside
> module and package (i.e., schema level) version numbers.
> >
> > Hence, my understanding of the main difference is whether
> non-backwards-compatible changes MUST always be explicitly documented at
> the data node level (and hence whether that means that data nodes can never
> be deleted from a YANG module), or whether these annotations are
> unnecessary, and potentially unhelpfully clutter the YANG module in the
> cases where tooling can robustly infer whether the change is backwards
> compatible or not.
>
> For me, its a MUST. If you potentially break things, you have to tell
> others. If you choose to violate the YANG 1.1 update rules, you have
> to document that. Deleting data nodes (well, data nodes is actually
> too limiting but that is likely a detail) is a special case and some
> way to document that something was remvoed is indeed needed. I think
> it is wrong to use a corner case to design the general case here.
>
>

Strongly agree with all of Juergen's concerns.
It is normal engineering practice to identify API changes
in the documentation for a specific API (not at some global level).

The interactions between YANG modules are too complex for a "module-is-NBC"
flag to really help.

IMO only NBC changes are a MUST. BC changes are a MAY.
These changes should not be documented in an extension that MAY be ignored.
The existing description-stmt is mandatory-to-implement for all tools.


Andy


If your YANG module gets cluttered because of NBC changes, perhaps
> there is something to be said about the engineering process. To
> unclutter a module, you give it a new new and remove the history.  I
> do not believe that there is a robust algorithm to infer in the
> general case whether a change in NBC or not, so it is pointless to
> consider this option.
>
> > Possibly there is also a second difference of opinion as to whether it
> is appropriate/safe to assume that any changes that are not explicitly
> marked as being non-backwards-compatible are in fact backwards compatible.
> I.e., specifically, is a "backwards-compatible" annotation also required in
> the cases where a tool cannot safely infer that a change is
> backwards-compatible.
>
> If NBC markers are a MUST, then everything not marked is a BC
> change. In YANG 1.1, everything following the update rules is a BC
> change, hence there are no markers. It seems logical to me to keep the
> existing assumptions.
>
> > Do you think that accurately represents the difference in opinion
> > from your perspective?
>
> There is another one concerning the implementation. If YANG is changed
> in such a way that existing deployed tools derive wrong conclusions,
> then this is an NBC change to YANG and the YANG version number needs
> to be incremented.
>
> /js
>
> --
> Jürgen Schönwälder              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/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>