On Thu, Mar 16, 2017 at 10:18 AM, Robert Wilton <[email protected]> wrote:
> Hi Andy, > > On 16/03/2017 16:17, Andy Bierman wrote: > > > > On Thu, Mar 16, 2017 at 2:54 AM, Robert Wilton <[email protected]> wrote: > >> Hi Dale, >> >> >> On 15/03/2017 19:02, Dale R. Worley wrote: >> >>> JOEY BOYD <[email protected]> writes: >>> >>>> module base-module { >>>> prefix bmod; >>>> >>>> feature do-things; >>>> >>>> container things { >>>> if-feature do-things; >>>> ... >>>> } >>>> } >>>> >>>> module augment-module { >>>> prefix amod; >>>> >>>> augment "/bmod:do-things" { >>>> container other-things { >>>> } >>>> } >>>> } >>>> >>> First question: I'm not expert in Yang, but as far as I can figure out, >>> the augment statement is augmenting "container things", right? So the >>> augment statement should be 'augment "/bmod:things"' not 'augment >>> "/bmod:do-things"'. >>> >> Yes, the augment should be to "things". >> >> >>> But on the important question, I don't see it as at all unreasonable >>> that the augment needs to be qualified by the same if-feature. The >>> reason is that if you're reading the text of module augment-module, it's >>> helpful to have documented, right there, that the augmentation depends >>> on the presence of a particular feature in the augmented module. And >>> it's helpful to know that the designer did, at least for one moment, >>> think about the fact that the augmentation is conditional. >>> >> >> It isn't just any if-feature on the container that is being augmented >> that needs to be considered. You would have to consider all if-feature >> statements by walking up the augmented node's ancestors to the top of the >> tree and combine them, or have multiple if-feature statements. >> >> Further, the 7950 YANG update rules allow for the augmented module to be >> revised and some of those if-feature statements to be subsequently >> removed. If the augmenting module had restated the if-feature conditions >> then this would probably leave the augmenting module unintentionally out of >> sync with the module that it is augmenting. >> >> In short, I think that if-feature statements work better if they act on >> the given node and all descendant nodes, regardless of which module those >> descendants are defined in. >> >> > "work better" > > Please explain which protocol you are using that allows you to manage > descendant nodes of unimplemented nodes. > > NETCONF and RESTCONF do not work at all wrt/ accessing such nodes. > > I think that we may be crossing wires: > > It was NETCONF/RESTCONF that I was thinking of, and I am not considering > managing descendant nodes of unimplemented nodes. > > I think that the question is only whether an augmentation of a node that > has an if-feature statement also requires the same if-feature statement on > the augment statement. > > no -- I don't think there is any requirement. As pointed out, the if-features can be anywhere in the ancestor nodes. If any of them are false for a given server, then the augmenting nodes are inaccessible. To quote Joey's example, I think that both of the following modules are > valid (presuming that they are both implemented by a device) regardless of > which features are enabled. Do you agree? > > 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 > module base-module { > prefix bmod; > > feature things; > feature widgets; > > container things { > if-feature things; > ... > container widgets { > if-feature widgets; > ... > } > } > } > > module augment-module { > prefix amod; > > augment "/bmod:things" { > container other-things { > } > } > > augment "/bmod:things/bmod:widgets" { > container other-widgets { > } > } > } > > Thanks, > Rob > > > Andy > > >> Rob >> >> > Andy > > >> >> >>> Dale >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>> >>> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
