Re: [netmod] augment and if-feature

[Robert Wilton <[e-mail]>]

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