On Fri, Apr 2, 2021 at 12:49 PM Michal Vaško <[email protected]> wrote:

> Hi Eric,
>
> thanks for the answer.
>
> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" <[email protected]>
> 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 <[email protected]> On Behalf Of Michal Vaško
> > > Sent: Thursday, April 1, 2021 11:14 AM
> > > To: netconf <[email protected]>
> > > 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
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/netconf
>
> _______________________________________________
> netconf mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netconf
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to