`deprecated` statement under `uses` statement

[rolandphung]

It seems that when deprecating uses statement in order to restructure the model, the pyang output is not able to represent this at all. This causes restructuring of groupings to be much harder to notice, especially when trying to maintain backwards compatibility. The output of pyang would contain all of the paths and nothing will be indicated as deprecated (x--rw <node> vs +--rw <node>)

Doing a bit of research, the pyang devs interpreted the RFC for deprecated to not be recursively applied for containers (See https://github.com/mbj4668/pyang/issues/577). Looking at both RFC6020 and RFC7950 there isn't a defined behavior for the uses statement.

What would be the guidance for OpenConfig wrt. adding status deprecated; to uses statements?

The PR #1105 is one of such changes that are affected by this.

For example:

  grouping foo-config {
    leaf a {
      type uint32;
    }

    leaf b {
      type string;
    }
  }

  grouping foo {
    container config {
      uses foo-config;
    }

    container state {
      uses foo-config;
    }
  }

  grouping top {
    container new {
      uses foo;
    }

    container old {
      uses foo {
         status deprecated;
      }
    }
  }

  uses top;

module: openconfig-test
  +--rw new
  |  +--rw config
  |  |  +--rw a?   uint32
  |  |  +--rw b?   string
  |  +--rw state
  |     +--rw a?   uint32
  |     +--rw b?   string
  +--rw old
     +--rw config
     |  +--rw a?   uint32
     |  +--rw b?   string
     +--rw state
        +--rw a?   uint32
        +--rw b?   string

[dplore]

The Yang RFC 6020 Section 7.12.1 says status is a valid substatement for the uses statement. So it seems what you want to do is supposed to be allowed by RFC.

However, my intuition is that the status field should only be used on nodes and types that appear in the tree (ie: leaf, container, typedef etc) and not to yang language like groupings or uses. Would this have the effect you're looking for?

[earies]

Personally I disagree with the statements in https://github.com/mbj4668/pyang/issues/577

There is no verbiage in YANG 1.0 or 1.1 stating inheritance rules which then I assume could be interpreted as there are none thus means every node must be explicitly marked.

https://datatracker.ietf.org/doc/html/rfc6020#section-7.19.2

However I believe that a status on a parent must very well be inherited and affect it's children. Can anyone think of a case where this would not hold true?

If a container is marked as deprecated, then how could its children not be?

If a container is marked as obsolete, then how could its children not be?

Regarding proper tree rendering, that is a secondary issue once above is solved imo

[dplore]

https://github.com/mbj4668/pyang/issues/577#issuecomment-600485288 provides their opinion that inheritance is not supported, so they agree with you Ebben. They say to properly deprecate a container or uses statement, one must deprecate each node individually.

I guess a side effect of this is if a uses statement appears in multiple places, and one is deprecated and the other isn't, then you'd need to restructure your model to achieve your intent.

[earies]

mbj4668/pyang#577 (comment) provides their opinion that inheritance is not supported, so they agree with you Ebben. They say to properly deprecate a container or uses statement, one must deprecate each node individually.

I guess a side effect of this is if a uses statement appears in multiple places, and one is deprecated and the other isn't, then you'd need to restructure your model to achieve your intent.

Well so I think there are a few things here...

deprecated on a uses imo should render a tree view that shows all child nodes of that usage of that grouping as deprecated. The grouping may be a bunch of flat leaves and it's not the same as node inheritance but rather inheritance of a status statement against that single use of a grouping.

That means that another use of that grouping could very well be current and be perfectly fine - we aren't deprecating the grouping entirely in that case.

In addition is node inheritance which I cannot think of a good reason where you flag a container or list as deprecated but children would have some other status other than something "greater"

In the order of current, deprecated, obsolete

e.g.

• If a container is flagged as current, children can be of any status
• If a container is flagged as deprecated, all children must be deprecated or obsolete but cannot be current
• If a container is flagged as obsolete, all children must be obsolete

Would everyone agree?

I believe the statements in the pyang PR are interpretation of the RFC since inheritance is not explicitly called out in any of above forms

[Shashank-arista]

I am facing a similar issue here: https://github.com/openconfig/public/issues/1140

[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.

[dplore]

I think I agree with you Ebben. At the moment, for toolchain compatibility and to properly represent intent, I think we need to update the status field in every node we want to be affected. So if you set status deprecated on a container node, then you must also explicitly deprecate it's children .