Subject: [YANG] keyref

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Jan 2008 09:02:14 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/yang

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Jan 2008 23:04:29 +0100 (CET)

Hi Andy,

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

> What do all these clauses within a leaf mean for a keyref?

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.

> than the leaf for the target of the 'path' statement?

See below.

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

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

[...]

> 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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Jan 2008 18:04:20 -0800

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Jan 2008 08:58:01 +0100

> Then it changes back to a reference if the manager deletes the

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

> 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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Jan 2008 09:12:46 +0100 (CET)

> Then it changes back to a reference if the manager deletes the

That's not how it works.  What part of the text supports this
interpretation?  The idea is that the value space of the keyref type
is constrained to the set of values of the existing instances.

This means that if you have a keyref to ifIndex, and the interface 1,
3, and 4 exists, the value space is {1, 3, 4}.  When setting a leaf of
this type, you must set it to one of 1, 3, and 4.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Jan 2008 09:18:21 +0100

On Tue, Jan 22, 2008 at 09:12:46AM +0100, Martin Bjorklund wrote:
 
> The idea is that the value space of the keyref type is constrained
> to the set of values of the existing instances.

But that is time varying.

> this type, you must set it to one of 1, 3, and 4.

So what happens if I choose 3 and interface 3 disappears?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Jan 2008 09:44:30 +0100 (CET)

> But that is time varying.

Yes.

> So what happens if I choose 3 and interface 3 disappears?

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.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Jan 2008 09:59:18 +0100

> see the difference between such a ref and a InterfaceIndex type

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Jan 2008 10:09:16 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> things together such that value changes automatically propagate.

No, no automatic propagation.

See
http://www.yang-central.org/twiki/bin/view/Main/YangExamplesExecdNtp
for a YANG example.  The idea in this example is that there is a list
of keys and a list of servers.  Each server uses exactly one key, and
this is done through a keyref.  When you try to set server/key, it
will only accept the name of an existing key.  If you try to remove
the key, the config will not validate.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Jan 2008 10:13:21 +0100

> the key, the config will not validate.

But if I change the value of key.name of a key referenced by say
requestkey, does the value of requestkey change as well?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Jan 2008 10:19:09 +0100 (CET)

> requestkey, does the value of requestkey change as well?

No.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 22 Jan 2008 14:42:27 +0100

So if I have a keyref to ifIndex 3 and then I remove interface with ifIndex 3, that is I get a 
dangling reference that points into the void, will I have an invalid configuration?

If you want to check at delete interface all the leafs that reference the interface, that might 
not be simple.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 22 Jan 2008 14:50:14 +0100

In the Ericsson DML we had something like

leaf my-if-status> {
   type instance-identifier {
     refers-to /if:interfaces/if:ifEntry/adminStatus;
   }
}

and in the XML

   <myIfStatus>/if:interfaces/if:ifEntry["if:ifIndex=2"]/adminStatus</myIfStatus>

This is quite simple, it works as a leafref as well, and works with multiple keys. refers-to 
restricts the kind of instance identifiers you can actually use. The actual XML value is 
somewhat more complicated, but I think the instance identifier format is quite intuitive even 
for people unfamiliar with XPATH.

Balazs

---

From: "Bert Wijnen" <[email-masked]>
Date: Tue, 22 Jan 2008 15:26:34 +0100

Balazs writes:
> If you want to check at delete interface all the leafs that 
> reference the interface, that might not be simple.
> 

Let me remind everyone that the referential integrity (specifically 
for ifIndex) was/is one of the big open issues in the MIB space.

It would be good if we can solve it in the NETCONF DML space.

Unfortunately, I have no solution to offer at this point. Sorry.

> Balazs

Bert

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Jan 2008 06:33:48 -0800

>> see the difference between such a ref and a InterfaceIndex type

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";
      }
   }

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Jan 2008 15:45:25 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> Not only is the TC approach simpler

As Juergen pointed out, there is no formalism to help tools.  Also, it
becomes awkward to reference mulit-level and/or multi-key instances.

> but keyref does not support

Mark it as optional instead - why set to some in-band invalid value?

      leaf mgmt-interface {
          mandatory false;
          type keyref {

If it is set, it has to point to an existing interface.

> tables, like SMIv2.

No:

  list myIfTable {
    key myIfIndex;
    leaf myIfIndex {
       type keyref {
       
covers this case.

>         leafref "/if:interfaces/if:interface/if:ifInOctets";

This is a very good example.  How can you tell which ifEntry's
ifInOctets this myInOctets actually refer to??

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Jan 2008 07:11:41 -0800

>          path "/if:interfaces/if:interface/if:ifIndex";

This is basically the same construct, except you have no
idea the data type is really InterfaceIndex.

IMO, leafref as a documentation clause does the same thing
but way simpler.  The DM reader should not have to be an expert
in Xpath, and need to hunt down the relevant documentation,
just to find out a leaf's data type.

> ifInOctets this myInOctets actually refer to??

You could use any keyref 'path' expression in the leafref argument.

IMO, the whole issue of relationships between config database nodes is larger
than this keyref clause.  The requirements for machine readable
object constraint languages and object/entity relationships needs to
be documented in detail and agreed upon.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 22 Jan 2008 16:31:58 +0100

Hello,
We are trying to define a formal way to specify relationships between config database nodes. 
The this problem has many facets
- reference to multi-keyed items
- reference to leafs versus keys
- constraining references to certain items or having free pointers
- reference integrity

The problem we try to solve is how to define these relations in a way that allows automatic 
checking. We need some solution, even if we do not solve the complete problem. E.g. I think 
referential integrity is a too high goal.

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Jan 2008 09:00:47 -0800

Balazs Lengyel wrote:
> Hello,
> We are trying to define a formal way to specify relationships between 
> config database nodes. The this problem has many facets
> The problem we try to solve is how to define these relations in a way 
> that allows automatic checking. We need some solution, even if we do not 
> solve the complete problem. E.g. I think referential integrity is a too 
> high goal.
> 

Human usability is the highest priority.
That has to be balanced with machine readability.

Ex 1) become an expert in Xpath first, then hunt around the draft to
       find out the real data type for 'address'

       leaf address {
           type keyref {

Ex 2) data type for 'address' is in the leaf clause

       leaf address {
           type yang:ip-address;
           leafref "../../interface[name = $this/../ifname]/address/ip";
       }

Win-win scenario: works for humans, and works for tools.

----

One reason I was confused -- a bug in the example on p. 94-95:

OLD:

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

NEW:

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

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Jan 2008 22:23:18 +0100 (CET)

> Win-win scenario: works for humans, and works for tools.

Do you want this new 'leafref' statement to have the same semantics as
the keyref type?

> One reason I was confused -- a bug in the example on p. 94-95:

Ok, fixed.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Jan 2008 22:55:20 +0100

On Tue, Jan 22, 2008 at 02:50:14PM +0100, Balazs Lengyel wrote:
> This is quite simple, it works as a leafref as well, and works with 
> multiple keys. refers-to restricts the kind of instance identifiers you can 
> actually use. The actual XML value is somewhat more complicated, but I 
> think the instance identifier format is quite intuitive even for people 
> unfamiliar with XPATH.

It is actually unclear to me what the example does. I get back an
xpath expression that points to some other object to consult? I
believe this is not really the same as the current keyref and this
also raises questions related to referential integrity or what if the
expression actually refers to a node set with more than 1 node and
similar things. I am also not sure management applications and humans
like to extrace the ifIndex value 2 out of the expression. And then
there is the question why to ship redundant information at run time if
it is already hard wired in the scheme? What happens if the expression
is not consistent with refers-to?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Jan 2008 23:14:51 +0100

> Unfortunately, I have no solution to offer at this point. Sorry.

Whether you want to have the config for your wlan card move with the
wlan card or be statically bound to the slot you insert your wlan card
into is a configuration decision to be taken by the owner of the
device. We should not invent DML mechanisms to enforce a specific
behaviour in the data model - this will be a failure.  Instead, we
have to ensure that people can write configurations that are flexible
in terms of what is being used to refer to something.

The IF-MIB says "here is ifIndex to refer to an interface" (and often
the ifIndex is related to physical ports - but it does not have to be
this way; it is just common on routers and switches). But we have
heard many times that operators really like to refer to an interface
name (which on some OSes is a logical interface mapping to a physical
interface in some way) or an interface alias (which is something a
human has configured to identify the interface connected to a certain
customer, whatever physical port is used).

I assume that a decent solution will carry some weight and bring us
close to configuration templates or other advanced configuration
language features (variables and such things) which I assume to be way
too ambitious for the IETF to deliver anything useful within this
decade. We should instead concentrate on doing basic YANG 1.0 in a
timely manner; let early adoptors experiment with advanced features so
we have good input based on real world experience for YANG 2.0 if that
ever happens.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Jan 2008 16:12:02 -0800

> Do you want this new 'leafref' statement to have the same semantics as

I'm not 100% sure what the semantics are.
I do not agree that the set of instances needs to be limited to
the current values in use in the leafref target.

There are 2 important corner-cases (2 sides of the same one):

1) pre-provisioning
    creating an entry that points to an instance that represents HW
    that has not been installed yet.  The config sits harmlessly, waiting until the
    hardware is installed to become active.

2) hot-swap cards
    As Juergen pointed out with the old SNMP "interface to Chicago" problem,
    the DM writer does not know if the config for a board that was
    just removed should be saved or deleted -- only the operator knows that.

I want the 'real' type to be used in the type field
and the optional leafref-stmt is available to describe whatever
relationship the DM writer wants.  The description clause
SHOULD identify this relationship in plain text as well.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 22 Jan 2008 22:58:54 -0500

>just to find out a leaf's data type.

Are you saying you prefer this relationship to be defined in English
words instead of a formal language?  The "description" statement
for the leaf can provide the words, but we hope to provide something
that a generic manager implementation can use to process module
contents.

>be documented in detail and agreed upon.

So you want this issue pushed onto the Requirements Team?  Or do
you want a distinct requirements effort for this?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Jan 2008 20:29:13 -0800

> that a generic manager implementation can use to process module

I already made a proposal -- instead of a builtin type called keyref
there would be an optional clause for a leaf of leaf-list called
leafref that has the path-stmt from the keyref as its argument.

As a separate matter, it is also good practice to document
the leafref in the description clause.

> you want a distinct requirements effort for this?

I expect the requirements team to write the initial draft.
I don't know what the RFC will look like yet.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 22 Jan 2008 21:10:26 -0800

Hi -

> From: "Phil Shafer" <[email-masked]>
> To: "Andy Bierman" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, January 22, 2008 7:58 PM
> Subject: Re: [YANG] keyref 
...
> you want a distinct requirements effort for this?
...

Would you consider ITU Recommendation X.725 to be a reasonable
starting point?  (Even if it is a dozen years old, and is based
on even older work...)

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 22 Jan 2008 21:15:13 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Phil Shafer" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, January 22, 2008 8:29 PM
...
...

Don't hold your breath.  We're only putting together an I-D
with our view of potential requirements in order to facilitate
progress at a BOF.  I have no expectation that the work will
be all-encompassing, and encourage others to document
any requirements they see as important.  In any case, I
see no point in turning it into an RFC effort.  Doing so would
only delay progress on the real work even more.

Randy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 23 Jan 2008 00:21:15 -0500

>leafref that has the path-stmt from the keyref as its argument.

Your proposal called this a "documentation clause", which implies
something targeted to humans and not usable by software.  This
would be bad, but I would live with a distinct statement for the
ref target that is a formal target.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Jan 2008 22:11:01 -0800

> ref target that is a formal target.

Yes -- only used like like an optional documentation clause,
but the argument would be the same path-stmt from keyref-stmt.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 23 Jan 2008 10:05:01 +0100 (CET)

> ref target that is a formal target.

Why is formal redundancy good?  If you're using a leafref, the type is
well known; it is the type if the target node.  But you still have to
specify it again.  I assume that it would be an error to say that the
leaf is of type int32, but the leafref points to a string leaf.   This
also brings up the question when two types are considered to be equal.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 23 Jan 2008 11:08:14 +0100

Juergen Schoenwaelder wrote:
> xpath expression that points to some other object to consult? 
[BALAZS]: It gives you a pointer to an object that you should use for whatever reason you need 
it. E.g. points to a Diameter based server for accounting that a specific subscriber should 
use. Or points to a status to check before you start a process.
> I
> believe this is not really the same as the current keyref
[BALAZS]: Not exactly. It gives you more freedom, which you might decide to restrict with 
refers-to. In some case you will not restrict it, but rather use the freedom.
> and this
> similar things.
[BALAZS]: I don't see why this has bigger problems with referential integrity here then keyref. 
If you only store an ifIndex value and not the full path, the specific interface might still 
get deleted while you refer to it.
In the on-the-wire XML full XPath is not allowed, only identifier syntax, so that should take 
care of node sets with multiple nodes. It is the same kind of expression we use for augment. 
That also must point to one specific object; otherwise you get an error.
> I am also not sure management applications and humans
> it is already hard wired in the scheme? 
[BALAZS]: Yes the specific value in XML is longer, although I don't see it as much more 
complicated. Anyway humans will usually be aided to write it (GUI, Wizard, tab-extension).
> What happens if the expression
[BALAZS]: that's an ERROR
> /js
[BALAZS]: On the plus side,
- it gives you more freedom when you want; you can point anywhere if you don't restrict it with 
refers-to.
- it allows you to refer to leaves
- the construct is much easier to understand for the complicated cases then  keyref

Compare the two examples for a list with two keys:

container default-address {
    leaf ifname {
      // this is actually not needed as a standalone leaf, only as an auxiliary
        type keyref {
            path "../../interface/name";
        }
    }
    leaf address {
        type keyref {
            path "../../interface[name = $this/../ifname]/address/ip";
        }
    }
}

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

-----------------------------------------------------------------------------
  leaf default-address {
    type instance-identifier {
      refers-to ../../interface/address/ip;
    }
  }

   <default-address>
	../../interface[ifname="eth0"][address="192.0.2.2"]/address/ip
   </default-address>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Jan 2008 06:19:15 -0800

> also brings up the question when two types are considered to be equal.

The type is not 'well known'.

There is a cryptic Xpath expression that contains many prefixes and names.
The DM reader first has to understand the Xpath to pick the right one,
then go to the top of the file and scan all the import statements to find
the module for that prefix, then find that module, then find the correct
leaf object within it.  If the desired leaf came from a uses expansion, then
the object will not be where the Xpath says it is, so all the groupings
for all the uses-stmts need to be tracked down and checked.
(If the nested leaf is called 'name', or something else generic, good
luck finding it with grep.)

After all this detective work, the leaf is found, and the DM writer finds
the name of the data type for the original leaf.

Or the type field in the original leaf could specify this data type
and an additional leafref clause can be used by a machine to
track down the additional details.

IMO this is not formal redundancy from the POV of the DM reader.
Maybe it is to a YANG compiler, but the DM reader is top
of the food chain here.

Andy