Re: [YANG] keyref

Martin Bjorklund wrote:
> 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.
> 

Why does it work the same as other types.
That's kind of a circular definition.

I don't see the use case for writable keyrefs.
When you read the object the first time, it has the value
from the ptarh target, and when you set the keyref leaf,
it has the new value and no longer is a reference to the key leaf.
Then it changes back to a reference if the manager deletes the
keyref leaf?

IMO, this should be just another documentation clause, added to a
leaf like the current 'description' and 'reference'.  I don't
understand why this is a data type.

Andy

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