Re: [netmod] YANG 1.0 module uses a grouping from a 1.1 module and the grouping contains 1.1 XPath functions?

Andy Bierman <andy@yumaworks.com> Mon, 21 October 2019 16:12 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 CA0EF120071 for <netmod@ietfa.amsl.com>; Mon, 21 Oct 2019 09:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 eTl4LD5RQMXJ for <netmod@ietfa.amsl.com>; Mon, 21 Oct 2019 09:12:22 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6685D120044 for <netmod@ietf.org>; Mon, 21 Oct 2019 09:12:22 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id y3so13979586ljj.6 for <netmod@ietf.org>; Mon, 21 Oct 2019 09:12:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gw3JA4QUVcL0GvzuIWYaVFY6B8vCS31E320qhbcHd3c=; b=koV0X4PCS3Jxx1D6eZlo61MDH1WGERHGbNgAr8HhpP2Qa0hcQdgdKJYzwiPrINha0H LD6XKOML68wo4WpukuT41h6flQMb0ApZ7Lyc9Mzr1l47h6kbIHAyjBGPzd3K+F7m178s OTfjT4kpVcbeyQ2rN6jcnUNVz/cy2GEcuoxrCLXIAFYaS7EMJ+3vFmoYnKyuXHiZiEG3 4vwtwuaUlQD6QVXx+ddeeLifJbvIY2MfuiJSRKw1+sc0koWKP3M4HHT1SXZeF0668tj/ w5l+jjXmxcphMO8gXPISs5/q+AeEUhHTgEh+zs43jlToB0f3glbMyHQhdPWZf3oSGkHp F/Ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gw3JA4QUVcL0GvzuIWYaVFY6B8vCS31E320qhbcHd3c=; b=S4Nnz00ZlG0+eZXG5d/MW0DQ7AUnBCaERDBje2YPvvN234xzYKRLWkIie92VYvTeVP NUWrtWFGuVKwW5lh/5y1KL0yVZJ/BDtZtXfe616PjfjnOEH/lKnSboAHj8XFaRqieUE8 xkPuN4JI3A3cKDjB+J1RBLmlrHe+iOuwq20U9r7j3AKutG9KxWf3VIjHKBNoHxbPN0t3 GXVILGL/MoORkf0la3NXOvUEOMEuzGSd9R112TmcyCVhUgccR8/VDTslzLtYYIROdPex PPeY1im08ybFi+M4WxKM4rYRJ66Gm4hDvWS83ZXtkq2tGGrwOclMb58S/de//DX2WAt5 8hnw==
X-Gm-Message-State: APjAAAV29k0ka7q0J5txcxYO/VGrabRvbzDJA4sNqLB3vaX2Jwt5Xq3x B8C6Xe4vhj/AmyfjJ/J6f/sWwE1dFc4a0VKRZlIIAw==
X-Google-Smtp-Source: APXvYqzmRG/zOfZjr4TrDlBUbO+AkaikOuLg9h7jAsFaJF+IHElJbBljFVO+WWpjQjsszyKJeGPWbb7R6UERNGk9IGE=
X-Received: by 2002:a05:651c:8b:: with SMTP id 11mr15309563ljq.98.1571674340202; Mon, 21 Oct 2019 09:12:20 -0700 (PDT)
MIME-Version: 1.0
References: <d988e178-4755-61ef-dfcc-87ba432da363@mg-soft.si> <7335cf50-00a1-b967-811c-325eab916135@mg-soft.si> <20191021.144520.1263805994773817986.mbj@tail-f.com>
In-Reply-To: <20191021.144520.1263805994773817986.mbj@tail-f.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 21 Oct 2019 09:12:09 -0700
Message-ID: <CABCOCHTUPA-fqTdX7Lxo6OEZ_EWTU8mxkqQJ-gUBrVHh0byqdg@mail.gmail.com>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: Jernej Tuljak <jernej.tuljak@mg-soft.si>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c03a0005956df222"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/JJ3j2t0Z3O5DRtaYbpu_Z3MVRWM>
Subject: Re: [netmod] YANG 1.0 module uses a grouping from a 1.1 module and the grouping contains 1.1 XPath functions?
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: Mon, 21 Oct 2019 16:12:25 -0000

On Mon, Oct 21, 2019 at 5:45 AM Martin Bjorklund <mbj@tail-f.com>; wrote:

> Jernej Tuljak <jernej.tuljak@mg-soft.si>; wrote:
> > Should I clarify my question?
> >
> > Jernej
> >
> > On 10/10/2019 10:36, Jernej Tuljak wrote:
> > > Hi,
> > >
> > > there is at least one YANG 1.0 standard module that imports and uses
> > > groupings from a YANG 1.1 standard module and at least one such
> > > grouping contains must/when statements referencing XPath functions
> > > that are not available in 1.0 XPath context.
> > >
> > > The modules I'm referring to are part of RFC8533 [1] and RFC8532
> > > [2]. ietf-connectionless-oam-methods (a 1.0 module) uses
> > > cl-oam:tp-address from ietf-connectionless-oam (a 1.1 module), which
> > > calls "derived-from-or-self" in a when expression of a used
> > > node. These RFCs were published in April.
> > >
> > > Our tools complain about "derived-from-or-self" not being defined in
> > > ietf-connectionless-oam-methods's XPath context:
> > >
> > > [Error];
> > > ietf-connectionless-oam-methods@2019-04-16
> :/cloam-methods:continuity-check/cloam-methods:input/cloam-methods:destination-tp/cloam-methods:mac-address/cloam-methods:when;
> > > XPath function "derived-from-or-self" is not defined in the XPath
> > > context
> > >
> > > Is this correct? Or are XPath functions expected to be resolved
> > > statically, like types?
>
> I don't think it is correct to reject this construct.  The definition
> is done in a 1.1 module and can only be implemented in a server that
> supports 1.1.
>
> It seems a bit odd that "ietf-connectionless-oam-methods" is defined
> in YANG 1.0 though, but that's a different issue...
>
>
>From 7950, sec 12:

      If a YANG version 1 module A imports module B without revision and

   module B is updated to YANG version 1.1, a server MAY implement both
   of these modules (A and B) at the same time.  In such cases, a
   NETCONF server MUST advertise both modules using the rules defined in
   Section 5.6.4 <https://tools.ietf.org/html/rfc7950#section-5.6.4>;,
and SHOULD advertise module A and the latest revision
   of module B that is specified with YANG version 1 according to the
   rules defined in [RFC6020 <https://tools.ietf.org/html/rfc6020>].

   This rule exists in order to allow implementations of existing YANG
   version 1 modules together with YANG version 1.1 modules.  Without
   this rule, updating a single module to YANG version 1.1 would have a
   cascading effect on modules that import it, requiring all of them to
   also be updated to YANG version 1.1, and so on.




This is probably not implemented, or implementable, by many servers.


1) what if module 'B' has no latest YANG 1.0 revision?
    This can happen if A is updated to import B, but yang-version is not
changed in A

2) What if NBC changes have been made in module B?
    How does the cited text work with SEMVER and new versioning rules?

3) What if the server implements some new definitions in B that are not  in
the latest YANG 1.0 version of B?
    New YANG library does not allow more than 1 revision of an implemented
module to be represented in a module-set.

4) What if a leafref in A points to a leaf using a typedef in B, yet the
type is not allowed in YANG 1.0?
   (e.g., empty type in a union)?  How much YANG 1.1 is allowed to leak
into a YANG 1.0 module?)

5) Isn't module A parsed under YANG 1.0 rules, because its
yang-version-stmt is set to "1"?




> /martin
>
>
Andy


> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>