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

From: Ebben Aries <[email-masked]>
Date: Mon, 18 Nov 2019 00:01:57 +0000

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.

# [email-masked]

    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
- A deviation could account for adjustment of the base must statement

Obviously, the latter is not a design choice we want for SDO models

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 18 Nov 2019 08:52:12 +0100 (CET)

> - Any augmented identities cannot follow the same design pattern as

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)'

/martin

> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>

---

From: Ebben Aries <[email-masked]>
Date: Mon, 18 Nov 2019 08:12:49 +0000

>           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

---

From: Benoit Claise <[email-masked]>
Date: Wed, 20 Nov 2019 11:06:17 +0800

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.

Regards, Benoit
> .

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 20 Nov 2019 03:47:56 +0000

> On Nov 19, 2019, at 22:06, Benoit Claise <[email-masked]> wrote:
> 
> 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?

Joe

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 20 Nov 2019 12:15:44 +0800

On Wed, 2019-11-20 at 03:47 +0000, Joe Clarke (jclarke) wrote:
> > 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 {
       ...
    }
  }
}

It would be better and more instructive to have it done in the same way for
radius in the ietf-system module.

Lada 

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 20 Nov 2019 05:28:02 +0000

On Nov 19, 2019, at 23:15, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, 2019-11-20 at 03:47 +0000, Joe Clarke (jclarke) wrote:
On Nov 19, 2019, at 22:06, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:

augment "/sys:system" {
 container tacacs {

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

Lada

Joe

Regards, Benoit
On Nov 18 08:52 AM, Martin Bjorklund wrote:
Ebben Aries <[email-masked]<mailto:[email-masked]>> 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.

# [email-masked]<mailto:[email-masked]>

      description

_______________________________________________
yang-doctors mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/yang-doctors
.

[email-masked]<mailto:[email-masked]>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 20 Nov 2019 13:59:33 +0800

On Wed, 2019-11-20 at 05:28 +0000, Joe Clarke (jclarke) wrote:
> 
> 
> > On Nov 19, 2019, at 23:15, Ladislav Lhotka <[email-masked]> wrote:
> > 
> > > > order
> 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.
> 

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

Lada

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 20 Nov 2019 21:20:17 +0000

The other choice would be to use “deviate add” to add the extra TACACS+ must constraint, but the YANG author guidelines say that we are not allowed to use deviations in IETF YANG modules …

Thanks,
Rob

From: yang-doctors <[email-masked]> On Behalf Of Joe Clarke (jclarke)
Sent: 20 November 2019 13:28
To: Ladislav Lhotka <[email-masked]>
Cc: [email-masked]
Subject: Re: [yang-doctors] Ensuring top/base models are designed as augmentable

augment "/sys:system" {
 container tacacs {

Joe

Lada

Joe

Regards, Benoit

      description