Re: [netmod] schematree-statement extension?
On 15/10/2018 21:49, Kent Watsen wrote: > Hi Robert, > > Picking up on your YANG 1.2 comment. Please add a YANG-next issue, if this > is not being tracked already. https://github.com/netmod-wg/yang-next/issues. https://github.com/netmod-wg/yang-next/issues/53 I think I captured the gist of the issue, but let's fleshing out the definition. Regards, Robert signature.asc Description: OpenPGP digital signature ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] schematree-statement extension?
Hi Robert, Picking up on your YANG 1.2 comment. Please add a YANG-next issue, if this is not being tracked already. https://github.com/netmod-wg/yang-next/issues. Thanks, Kent -Original Message- From: netmod on behalf of Robert Varga Date: Monday, October 15, 2018 at 3:36 PM To: Martin Bjorklund Cc: "netmod@ietf.org" Subject: Re: [netmod] schematree-statement extension? On 15/10/2018 21:09, Martin Bjorklund wrote: > Hi, > > Robert Varga wrote: >> It is wide-spread practice to use tailf:action and target statements >> within it with augment/deviate statements -- which I think is a failure >> to follow RFC7950 section 6.3.1: >> >>Care must be taken when defining extensions so that modules that use >>the extensions are meaningful also for applications that do not >>support the extensions. > > Yes, but note that 7950 means a 1.1 module, and tailf:action should be > replaced with 'action' in a 1.1 module. I think the argument applies (and proposed extension would be applicable) to RFC6020 as well. I am not complaining about tailf:action specifically, I will just map it YANG 1.1 action even in YANG 1.0 mode and I'm done :) > One reason we added the quoted paragraph to 7950 was because of the > problem you describe with tailf:action. I suspected as much, thank you for that :) >> I think the proper way of fixing this would be to define a YANG >> extension, which, when used within another extension, would indicate >> that the extension being defined is part of the schema tree, for example: >> >>extension schematree-statement; >> >>extension foo { >>argument bar; >> >>sts:schematree-statement; >>} > > Unfortunately, this doesn't solve the problem, since a parser that > doesn't understand sts:schematree-statement still wouldn't know that > foo defined a schema node, and thus it will still complain if it sees > an augment of a node introduced with "ex:foo". > > In order for this to work, "schematree-statement" would have to be a > builtin statement. > > (... and if we had this statement, we could have used it in yang-ext > as well, and avoid augement-yang-data) Understood and agreed, parsers not supporting schematree-statement would be left unfixed, but also no worse off. My skin in the game is to future-proof my parser (based on supporting widely-available specifications) until this is fixed for everyone with YANG 1.2. Adding support for a language extension is much simpler than to bump YANG language support by 0.1, at least in my experience. This could even help augment-yang-data in that the semantics of what it does would be kept with the extension (yang-data) as opposed to a different, related (as understandable by humans), language extension. An an implementor, Such extension would also address a piece of RFC7950 section 7.19's: An extension can allow refinement (see Section 7.13.2) and deviations (Section 7.20.3.2), but the mechanism for how this is defined is outside the scope of this specification. by defining how an extension can declare that it _does_allow_ refinement and deviations without getting into the business of how that refinement/deviations are done. This could even be separate extensions: extension augmentable-statement; extension deviable-statement; Such a language extension can be picked up by parsers across all YANG versions, making adoption much easier and faster. >> Using that knowledge, the parser can correctly interpret >> augment/deviation arguments as validly pointing to a particular use of >> foo (or its descendants) and correctly ignore their effects. >> >> Is this something the WG feels is a real problem and would be interested >> in solving? > > The current advice is of course to NEVER add nodes to the schema tree > with an extension. I think it is probably best to stick to this > advice... That advice I missed. Is there a link I can quote? :) Thanks, Robert ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] schematree-statement extension?
On 15/10/2018 21:09, Martin Bjorklund wrote: > Hi, > > Robert Varga wrote: >> It is wide-spread practice to use tailf:action and target statements >> within it with augment/deviate statements -- which I think is a failure >> to follow RFC7950 section 6.3.1: >> >>Care must be taken when defining extensions so that modules that use >>the extensions are meaningful also for applications that do not >>support the extensions. > > Yes, but note that 7950 means a 1.1 module, and tailf:action should be > replaced with 'action' in a 1.1 module. I think the argument applies (and proposed extension would be applicable) to RFC6020 as well. I am not complaining about tailf:action specifically, I will just map it YANG 1.1 action even in YANG 1.0 mode and I'm done :) > One reason we added the quoted paragraph to 7950 was because of the > problem you describe with tailf:action. I suspected as much, thank you for that :) >> I think the proper way of fixing this would be to define a YANG >> extension, which, when used within another extension, would indicate >> that the extension being defined is part of the schema tree, for example: >> >>extension schematree-statement; >> >>extension foo { >>argument bar; >> >>sts:schematree-statement; >>} > > Unfortunately, this doesn't solve the problem, since a parser that > doesn't understand sts:schematree-statement still wouldn't know that > foo defined a schema node, and thus it will still complain if it sees > an augment of a node introduced with "ex:foo". > > In order for this to work, "schematree-statement" would have to be a > builtin statement. > > (... and if we had this statement, we could have used it in yang-ext > as well, and avoid augement-yang-data) Understood and agreed, parsers not supporting schematree-statement would be left unfixed, but also no worse off. My skin in the game is to future-proof my parser (based on supporting widely-available specifications) until this is fixed for everyone with YANG 1.2. Adding support for a language extension is much simpler than to bump YANG language support by 0.1, at least in my experience. This could even help augment-yang-data in that the semantics of what it does would be kept with the extension (yang-data) as opposed to a different, related (as understandable by humans), language extension. An an implementor, Such extension would also address a piece of RFC7950 section 7.19's: An extension can allow refinement (see Section 7.13.2) and deviations (Section 7.20.3.2), but the mechanism for how this is defined is outside the scope of this specification. by defining how an extension can declare that it _does_allow_ refinement and deviations without getting into the business of how that refinement/deviations are done. This could even be separate extensions: extension augmentable-statement; extension deviable-statement; Such a language extension can be picked up by parsers across all YANG versions, making adoption much easier and faster. >> Using that knowledge, the parser can correctly interpret >> augment/deviation arguments as validly pointing to a particular use of >> foo (or its descendants) and correctly ignore their effects. >> >> Is this something the WG feels is a real problem and would be interested >> in solving? > > The current advice is of course to NEVER add nodes to the schema tree > with an extension. I think it is probably best to stick to this > advice... That advice I missed. Is there a link I can quote? :) Thanks, Robert signature.asc Description: OpenPGP digital signature ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] schematree-statement extension?
Hi, Robert Varga wrote: > Hello, > > I have recently been reminded that there is a potential interoperability > issue between RFC6020/RFC7950 and extension statements. So far the only > case where this has manifested is tailf:action, but there may be others > lurking in the future. > > The issue is that a YANG extension has no standardized way of declaring > it is a part of the schema tree, which means that unless a parser has at > least partial support for a particular extension, attempting to use > deviation or augment statements with it cannot work. > > It is wide-spread practice to use tailf:action and target statements > within it with augment/deviate statements -- which I think is a failure > to follow RFC7950 section 6.3.1: > >Care must be taken when defining extensions so that modules that use >the extensions are meaningful also for applications that do not >support the extensions. Yes, but note that 7950 means a 1.1 module, and tailf:action should be replaced with 'action' in a 1.1 module. One reason we added the quoted paragraph to 7950 was because of the problem you describe with tailf:action. > Therefore a parser which ignores the extension in its entirety, as per > section 6.3.1, will not populate the schema tree with the production of > (for example) 'tailf:action foo' nor its descendants and hence an > attempt to augment the use of the extension or any of its descendant > will result in failure to resolve the schema node identifier to a schema > tree node -- similar to what happens when an attempt is made to augment > a non-existing statement, a grouping, a typedef or an extension > statement (which may itself be unsupported). > > I think the proper way of fixing this would be to define a YANG > extension, which, when used within another extension, would indicate > that the extension being defined is part of the schema tree, for example: > >extension schematree-statement; > >extension foo { >argument bar; > >sts:schematree-statement; >} Unfortunately, this doesn't solve the problem, since a parser that doesn't understand sts:schematree-statement still wouldn't know that foo defined a schema node, and thus it will still complain if it sees an augment of a node introduced with "ex:foo". In order for this to work, "schematree-statement" would have to be a builtin statement. (... and if we had this statement, we could have used it in yang-ext as well, and avoid augement-yang-data) > With that, any parser not knowing "foo", but understanding > "sts:schematree-statement" would know that: > - foo's argument is an identifier as per RFC7950 section 14 > - the use of "foo" follows the usual schema tree population rules > > Using that knowledge, the parser can correctly interpret > augment/deviation arguments as validly pointing to a particular use of > foo (or its descendants) and correctly ignore their effects. > > Is this something the WG feels is a real problem and would be interested > in solving? The current advice is of course to NEVER add nodes to the schema tree with an extension. I think it is probably best to stick to this advice... /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] schematree-statement extension?
Hello, I have recently been reminded that there is a potential interoperability issue between RFC6020/RFC7950 and extension statements. So far the only case where this has manifested is tailf:action, but there may be others lurking in the future. The issue is that a YANG extension has no standardized way of declaring it is a part of the schema tree, which means that unless a parser has at least partial support for a particular extension, attempting to use deviation or augment statements with it cannot work. It is wide-spread practice to use tailf:action and target statements within it with augment/deviate statements -- which I think is a failure to follow RFC7950 section 6.3.1: Care must be taken when defining extensions so that modules that use the extensions are meaningful also for applications that do not support the extensions. Therefore a parser which ignores the extension in its entirety, as per section 6.3.1, will not populate the schema tree with the production of (for example) 'tailf:action foo' nor its descendants and hence an attempt to augment the use of the extension or any of its descendant will result in failure to resolve the schema node identifier to a schema tree node -- similar to what happens when an attempt is made to augment a non-existing statement, a grouping, a typedef or an extension statement (which may itself be unsupported). I think the proper way of fixing this would be to define a YANG extension, which, when used within another extension, would indicate that the extension being defined is part of the schema tree, for example: extension schematree-statement; extension foo { argument bar; sts:schematree-statement; } With that, any parser not knowing "foo", but understanding "sts:schematree-statement" would know that: - foo's argument is an identifier as per RFC7950 section 14 - the use of "foo" follows the usual schema tree population rules Using that knowledge, the parser can correctly interpret augment/deviation arguments as validly pointing to a particular use of foo (or its descendants) and correctly ignore their effects. Is this something the WG feels is a real problem and would be interested in solving? Thanks, Robert signature.asc Description: OpenPGP digital signature ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod