Re: [netconf] [netmod] YANG Push module errors

Michal Vaško <mvasko@cesnet.cz> Mon, 05 April 2021 14:23 UTC

Return-Path: <mvasko@cesnet.cz>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784343A1AC0; Mon, 5 Apr 2021 07:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
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 02lnaB9DT4b8; Mon, 5 Apr 2021 07:23:37 -0700 (PDT)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B713A1ABF; Mon, 5 Apr 2021 07:23:36 -0700 (PDT)
Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 5A37060086; Mon, 5 Apr 2021 16:23:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1617632614; bh=sqRIyi3TaHbmA29HI9qsROUlY3383gNY8XFCPcUrGYs=; h=From:In-Reply-To:Date:Cc:To:Subject; b=W6XVCGT163NM2ScvZI0jgf8Mq6G0KbnjBgcMYFs1rNQ4n3XWtRAe3k8wbjcU1rUc/ mdf6o8Klec/PZ6HioV2ebaulONqK2YQgHaCuI4uekw5xsZdD4+U+x3cIFx4NwQMZV5 3raMw6/ZPgtNDsPXIDSaw8UMjTWF/yJX+qfgG0dg=
From: =?utf-8?q?Michal_Va=C5=A1ko?= <mvasko@cesnet.cz>
In-Reply-To: <878s5ztt23.fsf@nic.cz>
Content-Type: text/plain; charset="utf-8"
X-Forward: 84.42.188.124
Date: Mon, 05 Apr 2021 16:23:34 +0200
Cc: "Andy Bierman" <andy@yumaworks.com>, "Eric Voit (evoit)" <evoit@cisco.com>, "netconf" <netconf@ietf.org>, "netmod" <netmod@ietf.org>
To: "Ladislav Lhotka" <ladislav.lhotka@nic.cz>
MIME-Version: 1.0
Message-ID: <52f2-606b1d80-d-7afd9d00@152658395>
User-Agent: SOGoMail 5.0.1
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/aTzQLIhv4Z7SinuGNDSsXtjKkls>
Subject: Re: [netconf] =?utf-8?q?=5Bnetmod=5D__YANG_Push_module_errors?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Apr 2021 14:23:42 -0000

On Saturday, April 03, 2021 15:07 CEST, Ladislav Lhotka <ladislav.lhotka@nic.cz> wrote: 
 
> Andy Bierman <andy@yumaworks.com> writes:
> 
> > On Fri, Apr 2, 2021 at 12:49 PM Michal Vaško <mvasko@cesnet.cz> wrote:
> >
> >> Hi Eric,
> >>
> >> thanks for the answer.
> >>
> >> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" <evoit@cisco.com>
> >> wrote:
> >>
> >> > Hi Michal,
> >> >
> >> > This sounds like a tooling issue to me.  I would expect that any augments
> >> > would inherit the conditional nature of anything augmented.
> >>
> >> Perhaps, but there is nothing in the specification to hint this. On the
> >> contrary, leafrefs, for example, explicitly require to be conditional on
> >> the same set of if-features than their targets. But you are right, there is
> >> no such requirements for augments. Still, if the feature is disabled and
> >> the augment should be applied, since its target does not technically exist
> >> in the schema, it cannot be found. That is the error our tools currently
> >> produce.
> >>
> >>
> > Maybe this is not clear enough in RFC 7950.
> >
> > This seems valid:
> >
> >     container foo {
> >        if-feature X;
> >         leaf bar { type string; }
> >     }
> >
> >     augment /foo {
> >         container Y;
> >     }
> >
> > The YANG syntax validation should be done as if all features are enabled.
> > It is a tooling issue if this is rejected. This is clear because the
> > augment-stmt argument specifies a schema node.
> 
> Agreed.

I see. Okay, thanks for the clarification and yes, if this was explicitly mentioned in the RFC it would be great. Although, the validity of your example was not in question. Rather something like:

    container foo {
        if-feature X;
        container bar;
    }

    augment /foo/bar {
        container Y;
    }

I am just going to assume this is what you meant and simply that the requirement is that any schema path must point to an existing schema node, ignoring any "if-feature" statements.

Regards,
Michal

> >
> > Another related issue:
> >
> >    container zed {
> >       leaf baz {
> >            type leafref {
> >               path /foo/bar;
> >            }
> >        }
> >     }
> 
> This is not permitted, see section 9.9 in RFC 7950:
> 
>    If the leaf that the leafref refers to is conditional based on one or
>    more features (see Section 7.20.2), then the leaf with the leafref
>    type MUST also be conditional based on at least the same set of
>    features.
> 
> Lada
> 
> >
> >
> > This example is not clear because the path-stmt argument specifies a data
> > node.
> >
> > Is it also valid YANG to have a leafref in an unconditional leaf point at
> > an if-feature conditional leaf?
> > Does leaf baz need "if-feature X" added?
> > Is this a syntax error? A run-time error?  Neither?
> > Is it invalid or does leaf /zed/baz simply have an empty value set?
> > Is it OK for a leafref node to have an empty value set?
> >
> > This corner case keeps coming up in real YANG modules so it would be great
> > if the standard clarified this behavior.
> >
> >
> > Andy
> >
> >
> >
> >> > If you disagree, perhaps a thread to the netmod alias would get you an
> >> > 'official' answer on the proper behavior.
> >>
> >> I have sent the email to "netconf" because that is WG that published it
> >> but no harm in adding a copy for "netmod".
> >>
> >> > Eric
> >> >
> >> > > -----Original Message-----
> >> > > From: netconf <netconf-bounces@ietf.org> On Behalf Of Michal Vaško
> >> > > Sent: Thursday, April 1, 2021 11:14 AM
> >> > > To: netconf <netconf@ietf.org>
> >> > > Subject: [netconf] YANG Push module errors
> >> > >
> >> > > Hi,
> >> > >
> >> > > we are led to believe there is an error in the ietf-yang-push module
> >> > published in
> >> > > RFC 8641 but I wanted to discuss it here before submitting an errata.
> >> > There are 2
> >> > > augments [1] on a notification that is conditional on "configured"
> >> feature
> >> > but
> >> > > these 2 augments are not conditional. Having this feature disabled, we
> >> > were not
> >> > > able to load this module into our tools. Does anyone disagree with
> >> this or
> >> > with
> >> > > submitting an errata?
> >> > >
> >> > > Regards,
> >> > > Michal
> >> > >
> >> > > [1] https://tools.ietf.org/html/rfc8641#page-48 and the next page
> >> > >
> >> > > _______________________________________________
> >> > > netconf mailing list
> >> > > netconf@ietf.org
> >> > > https://www.ietf.org/mailman/listinfo/netconf
> >>
> >> _______________________________________________
> >> netconf mailing list
> >> netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netconf
> >>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67