Re: [netmod] YANG module versioning: Proposed change to "Import by derived revision"
Andy Bierman <andy@yumaworks.com> Mon, 10 October 2022 18:50 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 5F05DC152579 for <netmod@ietfa.amsl.com>; Mon, 10 Oct 2022 11:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.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_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=unavailable 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 3LTxXOKvBFZj for <netmod@ietfa.amsl.com>; Mon, 10 Oct 2022 11:50:18 -0700 (PDT)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 41AF8C152581 for <netmod@ietf.org>; Mon, 10 Oct 2022 11:48:49 -0700 (PDT)
Received: by mail-yb1-xb2e.google.com with SMTP id 207so14009347ybn.1 for <netmod@ietf.org>; Mon, 10 Oct 2022 11:48:49 -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=7c7XODLpglTxJIOey/JE+2+bgbTXXEYPrWAnlCQH5jQ=; b=mZ76hIHhG6qU2oVYHvMTHcvFHSqV+bdasxkMQ9A4o87VgdpqeWHIWrOyFuCXmbUJLX G8wNFZdE1bAp7t8FE0IwhMvN6hyOzDB1ydq8IdLyc1b5+0e8hZCNbl9r8P1PGQ0BITb2 WFdOkfeION+YzngVNxHxK5tIXqJY6ER/iKzKUWU4DSY/7pF32HEwZU0t1W2rCxDd1nzD 6BK1MiWOutIyMzfhxqxp+GzW38qIK2lq56vVOPc/RKJ2VdfoGQckyiFHyAcubzQl0MTE FgLqwpLLdIxgYgyzjNSB+MkHcW0jTdurBKjsw4SgnYcSJJjZiZWhHXQ4UYsTOVydT6Ge dqnA==
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=7c7XODLpglTxJIOey/JE+2+bgbTXXEYPrWAnlCQH5jQ=; b=41frkyzlzuqDZDqKgXUu5YAaFxOC6ROQfiEhOfynKv14hlS4NnMR2fn9xdHLlPgUzY R5glPOt5Y7DZtLEFerVct1qobyNXZve5Z67ZC+eJfhnwFZLj1RZ9dS4hjY0qJvG2BGyP 4WZ+t09z7JjXE/BgN+/44P81e7fTGia4TLU8BJK2XLN80G35HR5oQeYiwroMpjodeXlL x8eotXh0+MV7X3G23d0rguOrDIM5Ufn3VGTklQP2O95vH2V1bnN8LTatEuoAKPJgEDx0 wckpcpBX51mXLWYIWhQ82bmNhGd0YCBzpwc9Fxm2DKHJ07ZCDwqzm9g/jNr/yybTHXzg 6Jxw==
X-Gm-Message-State: ACrzQf2vHZnsxNSosI6ioZHoIiKTryW/BM6GnZGkfjAdyVOxy9undd7i qfp4tvtGZU31+C2XHXsEz4VA59uHBMpE+0rq1IXi2Q==
X-Google-Smtp-Source: AMsMyM4Xu5WvvlUms0ZbZ7oQWSCnl6U1RgwM8/KwqXqJYGtTSeWO9C333KYipYzFRguhAc43mSKBFXhgibuo98dfn0E=
X-Received: by 2002:a25:e781:0:b0:6bf:bd96:46a2 with SMTP id e123-20020a25e781000000b006bfbd9646a2mr14412366ybh.129.1665427728261; Mon, 10 Oct 2022 11:48:48 -0700 (PDT)
MIME-Version: 1.0
References: <BY5PR11MB4196A9ED9C5900F8AB292596B55A9@BY5PR11MB4196.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB4196A9ED9C5900F8AB292596B55A9@BY5PR11MB4196.namprd11.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 10 Oct 2022 11:48:37 -0700
Message-ID: <CABCOCHTkc0zmwjYj61NhPs+xM=x9CBAMAbMjo=0OT3NzUE9jOQ@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000024756305eab29ccd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ZdbbhfnnhHEb51w2XUP_K1XuQXY>
Subject: Re: [netmod] YANG module versioning: Proposed change to "Import by derived revision"
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, 10 Oct 2022 18:50:22 -0000
On Tue, Oct 4, 2022 at 7:02 AM Rob Wilton (rwilton) <rwilton= 40cisco.com@dmarc.ietf.org> wrote: > Hi Juergen, WG, > > draft-ietf-netmod-yang-module-versioning defines section "4. Import by > derived revision" that allows an author to specify a minimum revision of a > module that is allowed to satisfy a YANG import. > > IIRC, and hopefully you will correct me if I am wrong, you had two > concerns about this approach: > (1) It potentially changes the behaviour of a YANG compiler without a > corresponding version change in the YANG language. > (2) It is embedding version constraint information directly into the YANG > module. > > The main reason for wanting this import was to help specify a minimum > import dependency, e.g., perhaps a module depends on a new type that is > only defined in version 1.1 and not available in any of the previous > versions. Here, having some level of minimum dependency in the importing > YANG module seems broadly helpful (like a more helpful version of the > existing import by exact revision-date), given that in many cases modules > may be independently versioned. > > Anyway, I would like to propose a change (a softening) of the definition > of the "revision-or-derived" extension statement in the Module Versioning > Draft so rather than referring to a hard "minimum required revision" for > the import to be valid, instead it is changed to refer to a softer > "suggested minimum revision". I.e., the intention is that the > "revision-or-derived" statement is no longer a hard constraint on the > import statement at all, it is just a suggestion for use by tooling and > module readers, and which they are at liberty to entirely ignore. > > Tools that support the "revision-or-derived" would generally be expected > to pick a revision that is derived from the revision/version specified in > the "revision-or-derived" statement but are not required to do so. E.g., > if they don't have a suitable version available, then they can import > another module version. Further, if such a tool does choose a version that > isn't derived from the "revision-or-derived" statement then generating a > YANG compiler warning message would be reasonable, but not required. > > The potential benefits of the new approach are: > - arguably, this approach is more compatible with existing YANG 1.1 import > rules. > - sets of YANG modules that were compiled by tools that don't understand > the "revision-or-derived" statement would still compile with tools that do > understand it, possibly with the addition of some warning messages.. > - with a branched revision history, there are cases where the tighter > import constraint isn't so helpful. > > I do not think these extensions need to change. In general, I would prefer a new YANG version but this specific extension works with the most common usage mode. OK to use extension: import foo { prefix f; } Not OK to use extension: import foo { prefix f; revision-date 2000-01-01; } If no revision-date is present, then a YANG 1.1 tool should expect any revision. The 'revision-or-derived' extension cannot be used together with 'revision-date' because a YANG 1.1 tool is expecting an exact revision in this case. If/when YANG 2.0 comes along, we could either keep with the relaxed > definition proposed above, or possibly tighten the definition to what we > have today. > > The trade-off for using an extension is that is conditional and optional to implement. A general YANG tool can ignore the 'nacm:default-deny-all' extension, but it is mandatory for a NACM implementation to support it. I would be interested in Juergen's and the WG's opinion on this proposed > change in behaviour. > > Regards, > Rob > > Andy > // As a contributor to the versioning work. > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
- [netmod] YANG module versioning: Proposed change … Rob Wilton (rwilton)
- Re: [netmod] YANG module versioning: Proposed cha… Jürgen Schönwälder
- Re: [netmod] YANG module versioning: Proposed cha… Randy Presuhn
- Re: [netmod] YANG module versioning: Proposed cha… Andy Bierman
- Re: [netmod] YANG module versioning: Proposed cha… Andy Bierman
- Re: [netmod] YANG module versioning: Proposed cha… Andy Bierman