On 16/03/2017 17:26, Andy Bierman wrote:
On Thu, Mar 16, 2017 at 10:18 AM, Robert Wilton <[email protected]
<mailto:[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]
<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.
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.
Agreed.
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
Also agreed.
Thanks,
Rob
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] <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
