Re: [YANG] keyref

Hi Andy,

Andy Bierman <ietf@andybierman.com> wrote:
> Hi,
> 
> The keyref builtin type is confusing.
> It is not very clear why this needs to be a built-in type,

It's a type b/c it works as all the other types; you can have a leaf
or leaf-list of this type etc.

> or why all the various forms are needed.
> 
> What do all these clauses within a leaf mean for a keyref?
>    - units

Not much I think.

>    - must

Same as for other leafs.

>    - default

Same as for other leafs, although it's pretty pointless.

>    - config

Same as for other leafs, except that we don't want to allow a
reference from config into non-config (not added to the draft yet).

>    - mandatory

Same as for other leafs.

> 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?

See below.

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

Note that in order to find "the variable it points to", you need the
path from the schema, and the value of the keyref leaf.

So I guess I don't understand your question.

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

Good question.  I think that the answer is yes, if the keyref is to
another module (since if there is a keyref from module A to module B,
and B gets updated, it cannot require A to be updated.)

> What are writable keyrefs used for?

An example is 'channelIfIndex' from the RMON-MIB.  It could have been
defined in YANG (ignoring some details about config/non-config) as:

   leaf channelIfIndex {
     type keyref {
       path "/if:interfaces/if:ifEntry/if:ifIndex";
     }
   }

The idea is that the keyref formalizes the stuff found in description
clauses in mibs:

        The interface identified by a particular value
        of this object is the same interface as identified by the
        same value of the ifIndex object

So, writable keyrefs are used to configure relationships.

[...]

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

As soon as the list has more than one leaf as key, you will need this
second form.

This being said, if anyone can come up with a simpler solution to the
problem of having references to multi-keyed lists, it will be more
than welcome!

/martin

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