On Thu, Mar 16, 2017 at 2:54 AM, Robert Wilton <rwil...@cisco.com> wrote:
> Hi Dale,
>
>
> On 15/03/2017 19:02, Dale R. Worley wrote:
>
>> JOEY BOYD <joey.b...@adtran.com> 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.
> Rob
>
>
Andy
>
>
>> Dale
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
