Re: [YANG] keyref

[Juergen Schoenwaelder <[e-mail]>]

On Mon, Jan 21, 2008 at 06:04:20PM -0800, Andy Bierman wrote:

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

I don't think this is how a keyref works according to my understanding
of this thing.

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

My understanding is that a keyref type essentially says "this leaf
contains a value that is consistent with the type and the semantics of
the leaf identified by the attached expression".

In SMIv2, we did not have such a mechanism and we used conventions to
achieve the same, that is we ended up with TC such as InterfaceIndex
that were then usually used for objects that contain values
identifying and interface. The keyref mechanism (which I think should
be a leafref or something like that since not only keys need to be
referenced) allows to make it machine readable who refering to whom,
which in the SMIv2 world is not machine readable and thus tools have
to resort to heuristics to best guess this information.

Of course, there are several aspects here to discuss. First of all, do
we need to have machine readable information about who is refering to
whom. If so, is a keyref^Hleafref type the correct approach or should
this be handled by introducing say a leafref statement. The next
question then is whether we want keyrefs^Hleafrefs to maintain
consistency with the leaf they are pointing to. In some cases, this
will be really useful, in other it might not. Taking the interface
example, sometimes I really like to refer to interface #3 regardless
how interface #3 is used while in other cases I really like to refer
to an interface that has a certain purpose, regardless in which port
it happens to be. So I think we would have to support multiple needed
semantics - and sometimes these might actually be deployment specific
and perhaps reach beyond what is needed in YANG 1.0.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>


_______________________________________________
YANG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/yang