openconfig / public

Repository for publishing OpenConfig models, documentation, and other material for the community.
Apache License 2.0
894 stars 652 forks source link

why not inherit name from interface list in openconfig-interfaces.yang #149

Closed sunseawq closed 1 month ago

sunseawq commented 6 years ago

In the openconfig-interfaces.yang file, the key of interface list is chosen as name, the name, the name uses leafref to refer to /config/name under config container, I am wondering why not remove both name under config and state container, define the leaf name under list interface as string? or define name under interface list as string, the name under config container and state container uses leafref to refer to the name under interface list? This will help remove dependency between child node name (each container name) and parent node name(i.e., list name), am my understanding correct? " list interface { key "name";

    description
      "The list of named interfaces on the device.";

    leaf name {
      type leafref {
        path "../config/name";
      }
    container config {
      description
        "Configurable items at the global, physical interface
        level";

      leaf name {
       type string;
       description
         "The name of the interface.
      }
     ......
    }
    container state {
      config false;
     leaf name {
     type string;
     description
      "The name of the interface.
     }

"

robshakir commented 6 years ago

OpenConfig requires that a leaf that can be set has the intended and applied configuration represented in the model. This is explained at some length in draft-openconfig-netmod-opstate. This allows for a consistent mechanism to check whether the intended configuration has been applied by the system.

YANG places a constraint that the list key MUST be a direct child of the list, and therefore, to meet this constraint whilst also allowing for consistent modelling of the state of the device, we use a reference from the list key to the specific node that it has the value of.

This leafref should be interpreted as "must have the value of the leaf it points to". Some YANG toolkit implementations may also support "write-through" behaviours for such leafrefs (i.e., those that resolve to a single schema path that is not a leaf-list).

github-actions[bot] commented 3 months ago

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.