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

From: Michal Vaško <[email-masked]>
Date: Fri, 02 Apr 2021 21:49:25 +0200

Hi Eric,

thanks for the answer.

On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" <[email-masked]> 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.

> 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-masked]> On Behalf Of Michal Vaško
> > Sent: Thursday, April 1, 2021 11:14 AM
> > To: netconf <[email-masked]>
> > 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-masked]
> > https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 Apr 2021 13:18:11 -0700

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

> 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

> I have sent the email to "netconf" because that is WG that published it
> but no harm in adding a copy for "netmod".
>
> > Eric
> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 03 Apr 2021 15:07:48 +0200

Andy Bierman <[email-masked]> writes:

> augment-stmt argument specifies a schema node.

Agreed.

>               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

> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Michal Vaško <[email-masked]>
Date: Mon, 05 Apr 2021 16:23:34 +0200

> > augment-stmt argument specifies a schema node.

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 06 Apr 2021 09:04:53 +0200

> 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.

I think it also depends on whether features are set before or after processing the modules. In the former case, an augment statement with an effectively missing target node can IMO be silently ignored, without even parsing its contents.

Lada

---

From: Robert Varga <[email-masked]>
Date: Tue, 13 Apr 2021 13:43:38 +0200

> I think it also depends on whether features are set before or after processing the modules. In the former case, an augment statement with an effectively missing target node can IMO be silently igno…

This very case has been discussed here:
https://mailarchive.ietf.org/arch/msg/netmod/Icd5c8J27P3UKjloNG8VC9fApoM/

FTR the original request for OpenDaylight lives here:
https://jira.opendaylight.org/browse/YANGTOOLS-859 and it provides some
additional context.

As an implementation author, I certainly did not like the implications
of the request, but Andy brought up a very important point in that thread:

> The modules are valid.
> The conformance decision (i.e., which features are advertised and which are
> not by a server implementation)
> does not change the compile-time validity of the YANG modules

i.e. even if the YANG modules are being interpreted as part of
assembling a server implementation, if-feature processing phase comes
only after cross-statement relationships have been established and
therefore the augment is valid, but 'container Y' disappears just as
'container bar' does.

This is further reinforced by Martin's response in this (related)
thread:
https://mailarchive.ietf.org/arch/msg/netmod/9JgPZphOdim-wLZA3NrSe3I1un4/

Regards,
Robert