OpenConfig AAA: Default ports populated for both server types when creating one server

[atomicbaum1]

Hey all,

There seems to be an issue with the AAA models when you add a AAA server entry of either type to the server list. The aaa-tacacs-server-config grouping and the aaa-radius-server-config grouping both have "default"s which according to the standard must be used even if the ancestor is not populated. If I add a TACACS server where the AAA config type is oc-aaa:TACACS then I also get default leafs created for the RADIUS auth-port and acct-port values. Since this isn't a RADIUS server I don't think that makes sense.

If I understand this correctly, there could be a conditional for the "uses aaa-tacacs-server-top" and the "uses aaa-radius-server-top" (or the defaults could be removed). According to the YANG 1.1 rfc7950 section 7.6.1

Note that if the leaf or any of its ancestors has a "when" condition or "if-feature" expression that evaluates to "false", then the default value is not in use.

So something like this may work:

uses aaa-tacacs-server-top {
  when "../../config/type = 'oc-aaa:TACACS'";
}
 uses aaa-radius-server-top {
  when "../../config/type = 'oc-aaa:RADIUS'";
}

If you follow the flow of the TACACS groupings you can see how it eventually leads to the default port number:

The openconfig-aaa.yang:
-> In the aaa-server-top grouping:
   -> There  is a container named "servers" which uses the aaa-server-config grouping.
	aaa-tacacs-server-top grouping:
	-> The "tacacs" container uses aaa-tacacs-server-config grouping
	   -> The aaa-tacacs-server-config grouping has a leaf called "port" has a default value of 49.

If we look at the at a simplified version of the AAA tree:

module: openconfig-system
   +--rw system
      +--rw aaa
      |  +--rw server-groups
      |     +--rw server-group* [name]
      |        +--rw name       -> ../config/name
      |        +--rw config
      |        |  +--rw name?   string
      |        |  +--rw type?   identityref
      |        +--ro state
      |        |  +--ro name?   string
      |        |  +--ro type?   identityref
      |        +--rw servers
      |           +--rw server* [address]
      |              +--rw address    -> ../config/address
      |              +--rw tacacs
      |              |  +--rw config
      |              |  |  +--rw port?             oc-inet:port-number                   << If we add a RADIUS server, the default TACACS port is created as well.
      |              |  |  +--rw secret-key?       oc-types:routing-password
      |              |  |  +--rw source-address?   oc-inet:ip-address
      |              |  +--ro state
      |              |     +--ro port?             oc-inet:port-number                   
      |              |     +--ro secret-key?       oc-types:routing-password
      |              |     +--ro source-address?   oc-inet:ip-address
      |              +--rw radius
      |                 +--rw config
      |                 |  +--rw auth-port?             oc-inet:port-number              << If we add a TACACS server, the default RADIUS port is created as well
      |                 |  +--rw acct-port?             oc-inet:port-number              << If we add a TACACS server, the default RADIUS port is created as well
      |                 |  +--rw secret-key?            oc-types:routing-password
      |                 |  +--rw source-address?        oc-inet:ip-address
      |                 |  +--rw retransmit-attempts?   uint8

Any thoughts on this issue would be appreciated.

--Matt

[aashaikh]

YANG 1.0 is less precise about this, but I think has the same effect:

"The usage of the default value depends on the leaf's closest ancestor node in the
schema tree that is not a non-presence container... [if such an ancestor exists, and
it's not a case node] the default value MUST be used if the ancestor node exists in
the data tree"

In this case it's a list node (server) -- all other ancestor containers are non-presence (we generally avoid presence containers in the models). In this case the default must be used as you mention. I think the suggestion to use when conditions will work here and makes clear the intent of the model. This is a pattern we've used in a number of places (i.e., set a type field, and then have the corresponding subtree apply).

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.