Re: [netmod] import-by-semver issue

Martin Bjorklund <mbj@tail-f.com> Sun, 24 March 2019 20:54 UTC

Return-Path: <mbj@tail-f.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 944011200F6 for <netmod@ietfa.amsl.com>; Sun, 24 Mar 2019 13:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 90t2n531kOvJ for <netmod@ietfa.amsl.com>; Sun, 24 Mar 2019 13:54:37 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1F81200C4 for <netmod@ietf.org>; Sun, 24 Mar 2019 13:54:37 -0700 (PDT)
Received: from localhost (dhcp-9104.meeting.ietf.org [31.133.145.4]) by mail.tail-f.com (Postfix) with ESMTPSA id 35F2E1AE034E; Sun, 24 Mar 2019 21:54:35 +0100 (CET)
Date: Sun, 24 Mar 2019 21:54:33 +0100 (CET)
Message-Id: <20190324.215433.23807447662347953.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: j.schoenwaelder@jacobs-university.de, rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHQ9i-=3E2FKK99quqH-d18NwAetf8MgjF8gvT3Su8qgaQ@mail.gmail.com>
References: <de771cdd329046cfa42a92d8d8ecf525@XCH-RCD-007.cisco.com> <20190324161451.35uus4wwjjwbgarh@anna.jacobs.jacobs-university.de> <CABCOCHQ9i-=3E2FKK99quqH-d18NwAetf8MgjF8gvT3Su8qgaQ@mail.gmail.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/yvinlHjolyyg54rHBKuDhKZuqSY>
Subject: Re: [netmod] import-by-semver issue
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, 24 Mar 2019 20:54:40 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> On Sun, Mar 24, 2019 at 9:14 AM Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Sun, Mar 24, 2019 at 03:14:18PM +0000, Rob Wilton (rwilton) wrote:
> > >
> > > But that is true of YANG compilers today.  If there are multiple
> > revisions of a module that could be chosen, then each compiler is at
> > liberty to decide which revision to choose (last paragraph of section 5.1.1
> > in RFC 7950).
> > >
> >
> > The difference is that NBC changes are not allowed. As long as you
> > find a certain symbol, it has fixed and predictable semantics.
> >
> > Sorry, but changing the way the import statement works is an NBC
> > change of YANG and this can't be done with extensions.
> >
> >
> I strongly agree.
> The expected behavior for tools needs to be consistent, especially for
> the construction of the schema tree, which depends on the import rules.
> 
> Implementation complexity should matter in the IETF, but it does not.
> Just keep raising the complexity up to 10 and complain that the tools have
> bugs,
> as if the two are unrelated. (Simply looking for a hardwired string
> "semver:version"
> will not work since the prefix is not required to be "semver" in the
> import-stmt.)

Agreed, but it quite easy to first build a prefix map (prefix ->
module name), and then instead of "xxxx:semver" you see ("ietf-semver",
"semver"); and _this_ can be hardcoded in the compiler.  (pyang works
like this)

This said, it is a bit weird with:

    import ietf-semver {
      prefix "semver";
      semver:version 1.1.2;
    }

so in order to handle the "semver:version" statement, you need to
import the module that has the prefix "semver".  But we can't just
import it like a normal import, b/c it has the semver: statement that
modifies how we do imports!



/matrin