[YANG] keyref

Hi,

The keyref builtin type is confusing.
It is not very clear why this needs to be a built-in type,
or why all the various forms are needed.

What do all these clauses within a leaf mean for a keyref?
   - units
   - must
   - default
   - config
   - mandatory

What does it mean for a keyref leaf to have different values of these clauses
than the leaf for the target of the 'path' statement?

Does a keyref variable always contain the value of the variable
it points to, or not?   If not, when?

Can a keyref be status current and the path reference
a leaf that is deprecated or obsolete?

What are writable keyrefs used for?

Why are keyrefs needed within a configuration database?

The notification use case in the example below makes sense,
but that's it.  I would rather have a mechanism within
the notification clause to deal with this feature, not a built-in
data type that can be used everywhere.

---------

4.2.10.  Notification Definitions

    YANG allows the definition of notifications suitable for NETCONF.
    YANG data definition statements are used to model the content of the
    notification.

    YANG Example:

      notification link-failure {
          description "A link failure has been detected";
          leaf if-index {
              type int32 { range "1 .. max"; }
          }
          leaf if-name {
              type keyref {
                  path "/interfaces/interface/name";
              }
          }
      }

    NETCONF XML Encoding:

      <notification
          xmlns="urn:ietf:params:netconf:capability:notification:1.0">
        <eventTime>2007-09-01T10:00:00Z</eventTime>
        <link-failure xmlns="http://acme.example.com/system">
          <if-name>so-1/2/3.0</if-name>
        </link-failure>
      </notification>

Why is it sufficient to make the if-index leaf an int32
but the if-name needs to be a keyref to something inside the
interfaces entry?  Clearly, when the notification is generated,
both of these values come from a particular interface.

---------

 From section 8.8.4:

      leaf mgmt-interface {
          type keyref {
              path "../interface/name";
          }
      }

    The following keyrefs refer to an existing address of an interface:

   container default-address {
       leaf ifname {
           type keyref {
               path "../../interface/name";
           }
       }
       leaf address {
           type keyref {
               path "../../interface[name = $this/../ifname]/address/ip";
           }
       }
   }

    A corresponding XML snippet is e.g.:

      <interface>
        <name>eth0</name>
        <address>
          <ip>192.0.2.1</ip>
        </address>
        <address>
          <ip>192.0.2.2</ip>
        </address>
      </interface>
      <interface>
        <name>lo</name>
        <address>
          <ip>127.0.0.1</ip>
        </address>
      </interface>

      <default-address>
        <ifname>eth0</ifname>
        <ip>192.0.2.2</ip>
      </default-address>

IMO, this 2nd form is complicated, and I don't really see why WGs
need it, or why they will use it.  The simple absolute-schema-nodeid form
makes sense to me, as a mechanism within notifications to reference
config data that is copied into the notification.

Andy

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang