Re: [yang-doctors] Ensuring top/base models are designed as augmentable

[Ebben Aries <[e-mail]>]

On Nov 18 08:52 AM, Martin Bjorklund wrote:
> Ebben Aries <[e-mail]> wrote:
> > I was looking for any such possible wording in 8407 but could not find
> > anything around this design consideration.
> > 
> > Case in point, there are many modules that may be defined with top-level
> > nodes where the intention is that other domains add/augment in either at
> > a later date or at a bare minimum via another set of
> > definitions/modules in related domains.  When this occurs, it seems
> > important that the top level modules are designed in such a way to
> > account for such augmentation and to pick on one case, is the use of
> > 'must' statements in top-level modules.
> > 
> > If we look at ietf-system below, for authentication, there are 2
> > definitions carried in the top-level module (local-users/radius) with a
> > must restriction being placed at a node which is a target candidate for
> > augmentation.
> > 
> > # [e-mail]
> > 
> >     container authentication {
> >       nacm:default-deny-write;
> >       if-feature authentication;
> > 
> >        description
> >          "The authentication configuration subtree.";
> > 
> >        leaf-list user-authentication-order {
> >          type identityref {
> >            base authentication-method;
> >          }
> >          must '(. != "sys:radius" or ../../radius/server)' {
> >            error-message
> >              "When 'radius' is used, a RADIUS server"
> >            + " must be configured.";
> >            description
> >              "When 'radius' is used as an authentication method,
> >               a RADIUS server must be configured.";
> >          }
> >          ordered-by user;
> > 
> > Now if one were to augment in with say 'tacacs' which would define an
> > identity that would base off sys:authentication-method, this would
> > either mean
> > 
> > - Any augmented identities cannot follow the same design pattern as
> >   those in the base module
> 
> Can you provide an example of what you want to do and show what
> doesn't work?  From what I understand, it seems you can add the nodes
> you want, but you can't just augment a must expression:
> 
>           must '(. != "x:tacacs" or ../../x:tacacs/server)'

The question is more generic wrt. ensuring nodes are augmentable or some
verbiage around such otherwise there could very well be cases that a
base restriction prevents and/or makes this difficult either for other
future SDO modules or other implementation augments.

For this specific case - that is precisely it as you have above.  The
augmented module cannot enforce similar restrictions for design
consistency sake