list pattern

[novakmi]

Hello,

I have question regarding OC data model structure. Why do you use list pattern like this:

list interface {
    key "name";
    leaf name {
      type leafref {
        path "../config/name";
      }
    }
    container config {
      uses interface;
    }
    container state {
      uses interface;
    }  
  }

instead of this

list interface {
    key "name";        
    uses interface;
    container state {
       uses interface;
    }
}

I guess the second case is more simple to read and probably more simple for application processing (e.g. validation). In the second case, the list contains config elements (without container config) and container state for state elements. It has the same information and reuse like first pattern, but you get rid of leafref. Or is there any other reason I have missed? Maybe you really want to have config keyword in the datamodel? Thanks for feedback.

[aashaikh]

We considered a few different patterns for opstate + config modeling, and decided on explicit config/state containers as the most programmatically simple, esp. considering the use case of comparing the intended and applied configuration data. Agree it's not ideal from a human readability perspective, but we view these models as primarily for machine-to-machine interactions, hence bias toward consistency and programmatic consumption.

On lists, YANG language rules require i) list key to be part of the data, and ii) list key to be a direct descendent of the list node -- the leafref key construct is our approach for complying with this. There is a bit more discussion on the overall opstate modeling approach, and lists specifically, in draft-openconfig-netmod-opstate.

[novakmi]

I think I understand you have a reason for this design (need for container config), even though it may not be apparent from the outside point of view (in some implementations leafref may be performance extensive operation).

On lists, YANG language rules require i) list key to be part of the data, and ii) list key to be a direct descendant of the list node -- the leafref key construct is our approach for complying with this.

I think this is also fulfilled with approach without leafref and config container`.

I have spent myself some time analyzing good approach for big yang data models (reuse and maintainability), so I know it is not always simple task (since I like groovy language, I tend to generate yang with yangbuilder, if possible).

Thanks for the feedback and reference to the draft explaining your point of view in more details.

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