Re: [netmod] [netconf] YANG Push module errors
On 06/04/2021 09:04, Ladislav Lhotka wrote:
>> 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.
> 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.
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
OpenPGP_signature
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [netconf] YANG Push module errors
Michal Vaško writes:
> On Saturday, April 03, 2021 15:07 CEST, Ladislav Lhotka
> wrote:
>
>> Andy Bierman writes:
>>
>> > On Fri, Apr 2, 2021 at 12:49 PM Michal Vaško wrote:
>> >
>> >> Hi Eric,
>> >>
>> >> thanks for the answer.
>> >>
>> >> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)"
>> >>
>> >> 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.
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
>
> 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 On Behalf Of Michal Vaško
>> >> > > Sent: Thursday, April 1, 2021 11:14 AM
>> >> > > To: netconf
>> >> > > 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
>> >> > > netc...@ietf.org
>> >> > > https://www.ietf.org/mailman/listinfo/netconf
>> >>
>> >> ___
>> >> netconf mailing list
>> >> netc...@ietf.org
>> >>
Re: [netmod] [netconf] YANG Push module errors
On Saturday, April 03, 2021 15:07 CEST, Ladislav Lhotka
wrote:
> Andy Bierman writes:
>
> > On Fri, Apr 2, 2021 at 12:49 PM Michal Vaško wrote:
> >
> >> Hi Eric,
> >>
> >> thanks for the answer.
> >>
> >> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)"
> >> 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 On Behalf Of Michal Vaško
> >> > > Sent: Thursday, April 1, 2021 11:14 AM
> >> > > To: netconf
> >> > > 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
> >> > > netc...@ietf.org
> >> > > https://www.ietf.org/mailman/listinfo/netconf
> >>
> >> ___
> >> netconf mailing list
> >> netc...@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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [netconf] YANG Push module errors
Andy Bierman writes:
> On Fri, Apr 2, 2021 at 12:49 PM Michal Vaško wrote:
>
>> Hi Eric,
>>
>> thanks for the answer.
>>
>> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)"
>> 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.
>
> 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 On Behalf Of Michal Vaško
>> > > Sent: Thursday, April 1, 2021 11:14 AM
>> > > To: netconf
>> > > 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
>> > > netc...@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/netconf
>>
>> ___
>> netconf mailing list
>> netc...@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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [netconf] YANG Push module errors
On Fri, Apr 2, 2021 at 12:49 PM Michal Vaško wrote:
> Hi Eric,
>
> thanks for the answer.
>
> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)"
> 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 On Behalf Of Michal Vaško
> > > Sent: Thursday, April 1, 2021 11:14 AM
> > > To: netconf
> > > 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
> > > netc...@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
>
> ___
> netconf mailing list
> netc...@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [netconf] YANG Push module errors
Hi Eric, thanks for the answer. On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" 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 On Behalf Of Michal Vaško > > Sent: Thursday, April 1, 2021 11:14 AM > > To: netconf > > 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 > > netc...@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
