Re: [netconf] YANG Push module errors

Andy Bierman <andy@yumaworks.com> Fri, 02 April 2021 20:18 UTC

Return-Path: <andy@yumaworks.com>
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 0F0FC3A221A for <netconf@ietfa.amsl.com>; Fri, 2 Apr 2021 13:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 9FfPtDjbMhYf for <netconf@ietfa.amsl.com>; Fri, 2 Apr 2021 13:18:26 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 440E03A221B for <netconf@ietf.org>; Fri, 2 Apr 2021 13:18:26 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id z8so6595171ljm.12 for <netconf@ietf.org>; Fri, 02 Apr 2021 13:18:26 -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=4IyyCK1jmtrdzgxZMKl/8liXdCyy51e7g2XijYTc3bY=; b=JkKNQ+/kaOXv4ofn1M9huFIEFKjfkTjkaJRxHxtQ5MDh5BhJNzeu9PC1sAEzhBZs6e h1lhT41AUlW/qvJwnt3LxvYMmoBbmXtm5PDQpyXzWyxdhFDaOT8RHk+Qt8kDzmurMg75 PgwilXwonnnGVTHtgpCpyK4WBmD+a7PT1sox8ei2PB7+GaZQFDOzIuk8uzmLyjff21A8 l8n+xMVuon1OTM3mYb4OABtLMB9IVxH5uNoA0npyl6HF7EF3Uu3DkGiLzkUdG3SGhDhH vHULGkOz0cUeVwVmv+qspJusYir4XWR5QC2y8y96b7RyBDi0paoMvfROCoS1XOWZBMcb XGkw==
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=4IyyCK1jmtrdzgxZMKl/8liXdCyy51e7g2XijYTc3bY=; b=AtzgIVJhnyEKaF375FGGntoj3W/XS3uAVilI6B/nWOQrKNomGCE+kPCO1Qs5KQymyv zWkzVQXvVyuPM5Z/snuo2QFLF1kNnSM70oVwauicg6rATOu+qtbuFQWZET5ZPyKpqBAv MVrnX0uA3U9oG/EowbaAATvlV+qDbvRGFZqfzdf/wYDtwyib4Y4JKyl1CPKivU3Zfbmz Ea0/mx98HnVD9KbHjrFPwz8PR1EShqjpwBcvwOHltEBopA35lEF0d4h2vdiO1sURA637 /L+cXGRRO11uADmCR0+fVq+wMfYW5BSn02vfTtBl3p01IKpatnrd3tEu35rrmyUadEpa 6Kyg==
X-Gm-Message-State: AOAM533SHuufkTFEv/fU+nA+7J3Fpd/9ZCkViXAYicj4yxLo+5iUxmEF lwAYf98PBnRGLAjVbqJ8wvBttdbUVbvg6323sY/jrQ==
X-Google-Smtp-Source: ABdhPJzD88TtHqHGalaeA7DjyDXCbv9TpKIwIkHVq/CdIv2rDniTpoERkPWYoS9nrsgx00fjgCfoSAQHWHbRvpmJ2C8=
X-Received: by 2002:a2e:2c0d:: with SMTP id s13mr9073566ljs.105.1617394701988; Fri, 02 Apr 2021 13:18:21 -0700 (PDT)
MIME-Version: 1.0
References: <BL0PR11MB31226974AEC11A5936BA40C9A17A9@BL0PR11MB3122.namprd11.prod.outlook.com> <5830-60677580-9-1569b540@260964559>
In-Reply-To: <5830-60677580-9-1569b540@260964559>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 02 Apr 2021 13:18:11 -0700
Message-ID: <CABCOCHSfR8dzSwpcE+R6-6hs96XO52wmaowj-O77=bdHa5sAQQ@mail.gmail.com>
To: Michal Vaško <mvasko@cesnet.cz>
Cc: "Eric Voit (evoit)" <evoit@cisco.com>, netconf <netconf@ietf.org>, netmod <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ac893d05bf030ce5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/c3z61CzMcvANdmWQcSncQxtMyXQ>
Subject: Re: [netconf] 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: Fri, 02 Apr 2021 20:18:31 -0000

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.

Another related issue:

   container zed {
      leaf baz {
           type leafref {
              path /foo/bar;
           }
       }
    }


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
>