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

["Joe Clarke (jclarke)" <[e-mail]>]

On Nov 19, 2019, at 23:15, Ladislav Lhotka <[e-mail]<mailto:[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]<mailto:[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.

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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/yang-doctors
.


_______________________________________________
yang-doctors mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/yang-doctors
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67