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

[Ladislav Lhotka <[e-mail]>]

On Wed, 2019-11-20 at 05:28 +0000, Joe Clarke (jclarke) wrote:
> 
> 
> > On Nov 19, 2019, at 23:15, Ladislav Lhotka <[e-mail]> wrote:
> > 
> > On Wed, 2019-11-20 at 03:47 +0000, Joe Clarke (jclarke) wrote:
> > > > On Nov 19, 2019, at 22:06, Benoit Claise <[e-mail]> wrote:
> > > > 
> > > > Including Joe Clarke in the loop.
> > > > As OPSAWG chair, Joe took the AI to follow up with the YANG doctors in
> > > > order
> > > > to find the best solution for the TACACS+ YANG model.
> > >  
> > > Thanks, Benoit.  YANG docs, specifically for the YANG TACACS+ module and
> > > its
> > > interaction with ietf-system, we can certainly push for a new rev of ietf-
> > > system, but what would be the recommendation to move this forward in lieu
> > > of
> > > this strict enforcement?
> >  
> > My suggestion would be to do this in the tacacs module:
> > 
> > augment "/sys:system" {
> >  container tacacs {
> >    must "not(derived-from-or-self("
> >       + "../sys:authentication/sys:user-authentication-order, 'tacacs')"
> >       + "or server";
> >    list server {
> >       ...
> >    }
> >  }
> > }
> 
> Thanks, Lada.  This makes sense within tacacs (or tacacsplus) itself.  I agree
> it would have been good if this had been done for RADIUS previously as it
> would have been easier to extend with new authn types.
> 
> I’ll update the authors on this.  I suppose this could be an item for ietf-
> system.bis should it happen.

It should, because the identityref value is tested using plain string comparison
and, moreover, the module isn't NMDA compatible.

Lada

> 
> Joe
> 
> > It would be better and more instructive to have it done in the same way for
> > radius in the ietf-system module.
> > 
> > Lada 
> > 
> > > Joe
> > > 
> > > > Regards, Benoit
> > > > > 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
> > > > > 
> > > > > _______________________________________________
> > > > > yang-doctors mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/yang-doctors
> > > > > .
> > > > > 
> > >  
> > > _______________________________________________
> > > yang-doctors mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/yang-doctors
> >  -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67