Hi Andy,
On 16/03/2017 16:17, Andy Bierman wrote:
On Thu, Mar 16, 2017 at 2:54 AM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
Hi Dale,
On 15/03/2017 19:02, Dale R. Worley wrote:
JOEY BOYD <[email protected] <mailto:[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.
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?
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
Rob
Andy
Dale
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
.
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
