Re: [netmod] augment and if-feature

On Thu, Mar 16, 2017 at 10:18 AM, Robert Wilton <rwilton@cisco.com> wrote:

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