Re: [YANG] keyref

Juergen Schoenwaelder wrote:
> On Tue, Jan 22, 2008 at 09:44:30AM +0100, Martin Bjorklund wrote:
> 
>> That's why we don't want to allow keyrefs from config to non-config.
>>
>> Maybe this is a use case that we want to support as well.  But I don't
>> see the difference between such a ref and a InterfaceIndex type
>> solution.
> 

IMO, it is not clear what problem is being solved by keyref.
There seems to be some assumption that the purpose of all this
complexity is justified because of all the value it provides.

The InterfaceIndex approach is well-established and simple.

      leaf mgmt-interface {
          type keyref {
              path "/if:interfaces/if:interface/if:ifIndex";
          }
      }

      leaf mgmt-interface {
          type if:InterfaceIndex;
      }

Not only is the TC approach simpler, but keyref does not support
the ability to hold a 'not-set' value, such as InterfaceIndexOrZero.

YANG is also missing the ability to use key leafs from different
tables, like SMIv2.  This is where keyref/leafref (as a documentation clause)
would help:

   list myIfTable {
      key myIfIndex;

      leaf myIfIndex {
        type if:InterfaceIndex;
        leafref "/if:interfaces/if:interface/if:ifIndex";
      }

      leaf myInOctets {
        type smi:Counter32;
        leafref "/if:interfaces/if:interface/if:ifInOctets";
      }
   }

> Well, the InterfaceIndex type just says "the value identifies an
> interface" - no more no less. The keyref is much more ambitiuous.
> Despite the fact that it is only usable for keys, your aim is to bind
> things together such that value changes automatically propagate. This
> somehow sounds like you want to do several things at once with a
> single construct.
> 
> /js
> 

Andy

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