Subject: [netmod] leaf-ref questions

From: Balazs Lengyel <[email-masked]>
Date: Fri, 22 May 2009 12:09:09 +0200

Hello,
I am trying to understand leafref purely from the draft. I had a very hard time. I have some 
questions that the draft does not answer:

1) Does path point to a leaf node in the datastore or just a potential leaf node? The draft 
says about path:
"It takes as an argument a string which MUST refer to a leaf node."
However I think if require-instance is false, path only points to a potential leaf.

2) Does a leafref has it's own value or is it just a second way of accessing the referenced 
leaf? Can the value of the leafref and the referenced leaf be different? This is a potentially 
critical clarification. (I assume it is just a second handle, so state it does NOT have an own 
value.)

3) Can I write to a leaf of type leafref? Will that modify the value of the referenced leaf?

4) What does it mean if path's nodeset is empty? What happens if we read/write to this leafref?

5) What does it mean if path's nodeset consists of multiple nodes? What if they contain 
different values? What will we get at a read? If we write to such a leafref will we set all 
referenced leafs? Why do we have to allow multiple node nodesets?

Balazs

PS> Sorry if the questions have already been asked, I am lost in the many mail.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 May 2009 15:09:29 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:
> Hello,
> I am trying to understand leafref purely from the draft. I had a very hard
> time. I have some questions that the draft does not answer:
> 
> 1) Does path point to a leaf node in the datastore or just a potential leaf
> node? The draft says about path:

I think this is clear from the text on require-instance, which has
been clarified as suggested by Lada.

> 2) Does a leafref has it's own value or is it just a second way of accessing
> the referenced leaf?

It has it's own value.  If not, 'require-instance false' would not
make much sense.

> 3) Can I write to a leaf of type leafref?

Of course.  Is there anything in the text that suggest otherwise?

> Will that modify the value of the
> referenced leaf?

No.  Is there anything in the text that suggest this?

> 4) What does it mean if path's nodeset is empty? What happens if we read/write

If it is a require-instance true, then it will not be valid (at
validate / commit time).

> 5) What does it mean if path's nodeset consists of multiple nodes? What if they
> contain different values?

This is fine; it is also necessary if a list has multiple keys, e.g.:

  list server {
    key "ip port";
    ...
  }
 
  leaf my-srv-ip {
    type leafref {
      path "../server/ip";  // this xpath may return mulitple nodes
    }
  }
  ...

/martin

---

From: David Reid <[email-masked]>
Date: Fri, 22 May 2009 15:17:15 -0400

> > 5) What does it mean if path's nodeset consists of multiple nodes? 
> > What if they contain different values?
> 

I'm not sure I understand. How can I return multiple nodes under one leaf?

-David Reid

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 May 2009 12:29:45 -0700

> I'm not sure I understand. How can I return multiple nodes under one leaf?

9.9.  The leafref Built-in Type

    The leafref type is used to reference a particular leaf instance in
    the data tree.  Its value is constrained to be the same as the value
    of an existing leaf.

So, when require-instance=true (as it is by default in your example),
the 'my-srv-ip' leaf is constrained to the set of actual values
for "../server/ip" (i.e., must pick one of the 'ip' instances).

If require-instance=false, then 'my-srv-ip' is constrained to
the same data type as leaf 'ip'.

The canonical output form for 'my-srv-ip' is the same as
the referenced 'ip' leaf, regardless of the require-instance
value.

Easier to understand than implement correctly, especially
when union, instance-identifier, leafref loops, and other
interactions are added to the equation.

> -David Reid

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 May 2009 15:42:45 -0400

As far as I can tell, there are several different confusions about what 
leafref means and how it is supposed to work.  At the very least, 
significant clarifying text is needed.

The meaning Andy suggests below, that the path defines a set of nodes 
which constrain the type and legal values of the leaf being defined, but 
does not actually define the value, is an interesting and 
self-consistent view.  It would resolve many of the issues.  If that is 
what the WG intended, significant additional text is needed.

Personally, if I read that X (a leafref) is a reference to Y (a leaf), 
then I tend to expect that setting X sets Y.  And that the distinction 
between which Y X points to and what the value Y has is clear.

Yours,
Joel

Andy Bierman wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 May 2009 14:00:36 -0700

> what the WG intended, significant additional text is needed.

I think leafref is implemented as I described,
according to discussions with Martin about it.

> between which Y X points to and what the value Y has is clear.

What kind of normative text is needed?
More examples instead?

Is it clear that the path statements can form a loop
in 2 to N connected leafrefs?

Is it clear that the XPath comparison problem shows
up when the leafref path points to an instance-identifier?
The manager-provided value needs to be compared
to existing values of an instance-identifier leaf.

Is the normalization of whitespace, token parsing,
and prefix to expanded-name conversion required to
properly compare 2 instance-identifiers clear?

Is it clear that comparing any XPath expression or
instance-identifier contained in an XML PDU to
an agent-stored XPath expression or instance-identifier
cannot be done with strcmp()?

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 25 May 2009 10:07:30 +0200

> No.  Is there anything in the text that suggest this?

   list interface {
       key "name";
       leaf name {
           type string;
       }
       leaf admin-status {
           type admin-status;
       }
   }
	
-------------------------

   leaf mgmt-interface-state {
       type leafref {
           path "../interface/name/admin-status";
       }
   }
	
-----------------------

A) If I change the value of mgmt-interface-state it will always be an error, because its value 
will become different from the value of the relevant admin-status?

B) If I change the value of admin-status it will always be an error because, its value will 
become different from the value of the relevant mgmt-interface-state?

True? (Forget for the moment manually setting both values at the same time, which is not nice.)

Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 May 2009 10:17:18 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:
> A) If I change the value of mgmt-interface-state it will always be an error,
> because its value will become different from the value of the relevant
> admin-status?
> 
> B) If I change the value of admin-status it will always be an error because,
> its value will become different from the value of the relevant
> mgmt-interface-state?
> 
> True?

Yes, unless it's the candidate which is allowed to be invalid.

But note that this is a very odd use-case.  At first we had just
keyref, which didn't have this problem.  Then we generalized it to
leafref, mainly to handle the use case where you include such leafrefs
in notifications.  We did not add a CLR which made use cases like this
one illegal.  (And I prefer to keep it this way; who knows, maybe
there's a great use case for this that we can't see right now).

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 25 May 2009 10:17:55 +0200

> been clarified as suggested by Lada.
Quote:
"The leafref type is used to reference a particular leaf instance in the data tree. Its value 
is constrained to be the same as the value of an existing leaf."

To me the quoted sentences above say that the referred leaf must exists, contradicting the 
later explanation. How about:

The leafref type is used to reference a particular leaf instance in the data tree which MAY or 
MAY NOT exist. If it exists, its value is constrained to be the same as the value of the 
referenced leaf."

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 25 May 2009 10:19:09 +0200

My fear is that we introduced Many such odd cases.
Balazs

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

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 25 May 2009 10:24:29 +0200

> If it is a require-instance true, then it will not be valid (at
Yes but if require-instance is false what happens if I read or write to the leafref?
a) What will I get in a <get> operation for such a leafref?

b) Can I write anything successfully to such a leafref?  What does it really refer to?

c) Why do we want to allow this in a valid configuration? What is the use-case?

Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 May 2009 10:29:09 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:
> >> However I think if require-instance is false, path only points to a
> >> potential
> >> leaf.
> "The leafref type is used to reference a particular leaf instance in the data
> tree. Its value is constrained to be the same as the value of an existing
> leaf."
> 
> To me the quoted sentences above say that the referred leaf must exists,
> contradicting the later explanation.

Agreed.  It is clear that the text on leafrefs needs to be rewritten,
and I will send a proposal to the list once its done.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 25 May 2009 10:39:09 +0200

> there's a great use case for this that we can't see right now).
IMO is there a real use case for allowing write operations for a leafref that points to a real 
leaf (not a key)? I would argue NO.
How about Balazs' rule:
If a leafref points to a non-key leaf it must be config false;

Balazs

---

From: "tom.petch" <[email-masked]>
Date: Tue, 26 May 2009 11:32:25 +0200

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 25, 2009 10:29 AM
Subject: Re: [netmod] leaf-ref questions

> and I will send a proposal to the list once its done.

Disagree; what I think is lacking is a consensus on what the aim is
and we would be better agreeing that before turning it into text.

Andy asked for leaf-ref back in September, and said
"But many times you want a pointer-to-a-leaf instead of
cut-and-paste-of-a-leaf. The use-cases are very different."
which I thought spot on, then and now.  Balazs queried, then as now,
whether the value was an XPath pointer or more like a linux soft-link.

I did not see a resolution then and do not see one now and, perhaps
as a result, we have something complex, self-contradictory even,
in the I-D.

I think that the use case is exactly what Andy said, a pointer to
a leaf, so if the pointed-to changes, then so does the leaf-ref.
Allowing the leaf-ref to be written to I think wrong.  We are 
turning the schema tree into a schema mesh and having 
multiple-write, as opposed to multiple-read-write-once, is, for
me, a step too far.

I fundamentally disagree with the
"(And I prefer to keep it this way; who knows, maybe
there's a great use case for this that we can't see right now)."
I see this approach as what has made this I-D so complex; as Andy said,
you have to implement YANG in order to understand it (not what I would
see as a positive feature).

Rather, we have a use case, let's first agree - or not - on what it is and
stick to it, not wander off.

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 May 2009 05:07:42 -0700

> a leaf, so if the pointed-to changes, then so does the leaf-ref.

I don't think I said that.
The leafref we have now is what I had in mind.
By 'pointer' I just mean that the path indicates
the referenced object instead of a description statement.

> multiple-write, as opposed to multiple-read-write-once, is, for

I do not understand this 'multiple write' problem.
The client can lock the database and write whatever
is needed, especially in the candidate.

> stick to it, not wander off.

The use-case is a machine-readable coupling instead of
relying on description statements.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 26 May 2009 15:03:48 +0200

Hello,
I agree that it is hard to understand the concept of leafref.
I see a danger of having one more complicated concept in YANG, the leafref. Martin's original 
keyref was much more simple.

As an example, can someone explain the use case for writing to a leafref that is not a key, and 
what happens at writing?

My problem is that I feel I have a number of such questions that are not answered today.

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 May 2009 06:30:30 -0700

Balazs Lengyel wrote:
> I see a danger of having one more complicated concept in YANG, the 
> leafref. Martin's original keyref was much more simple.
> 
> As an example, can someone explain the use case for writing to a leafref 
> that is not a key, and what happens at writing?
> 

The most simple example is a foreign key.
YANG allows lists nested within other lists,
but the data modeler is not forced to do that.
Perhaps alignment with SMIv2 or SQL applications
makes 2 sibling tables more appropriate than
1 nested table:

    list rmonHostControlEntry {
        key rmonHostControlIndex;

        leaf rmonHostControlIndex {...}

         // rest of control table columns

    }

    list rmonHostHistoryControlEntry {
       key "rmonHostControlIndex rmonHostHistoryControlIndex";

       leaf rmonHostControlIndex {
           type leafref {
               path "/rmonHostControlEntry/rmonHostControlIndex";
           }
        }
        leaf rmonHostHistoryControlIndex {
           type uint32;
        }
        // rest of aux control table

        // embedded host history data table
     }

Perhaps the 2nd control table cannot be in the same
module as the first.  Perhaps it is not really
a sparse augments because the condition for adding
the augmenting control columns is not deterministic.
The client decides when the 2nd control entry is needed,
not the agent.  Maybe the data modeler does not want
the embedded host entry to be placed directly under
the main control entry because an inadvertent <get>
of the top-level entry would include millions of bytes
of statistics data.

Perhaps these are weak use cases, and YANG should
force the data modeler to use augment or nested lists,
but the leafref seems OK to me the way it is defined now.

Andy

>>>>>> 1) Does path point to a leaf node in the datastore or just a 
>>>>>> potential
>> leaf
>>>> "The leafref type is used to reference a particular leaf instance in 
>>>> the
>> data
>> Allowing the leaf-ref to be written to I think wrong.  We are turning 
>> the schema tree into a schema mesh and having multiple-write, as 
>> opposed to multiple-read-write-once, is, for
>> me, a step too far.
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 May 2009 09:40:26 -0400

(I have been talking with folks trying to understand leafref.  I am 
getting close to being able to suggest text that reflects what I think 
the WG has agreed.  Below is a paraphrase of my current understanding.)

Declaring something as a leafref declares it to be the same type as the 
target identified by the path, and for non-config or require-instance 
also declares that the value of the leaf of type leafref must match the 
target of the path.

Unfortunately, there are two different factors that affect the meaning 
and real-world constraints on the value.  Some of these are 
consequences, not definitions.  (Which makes writing a clear definition 
hard.)
There is the spectrum of non-config, config with no require-instance, 
and config with require-isntances.
These is also the spectrum of whether the path identifies a single leaf 
isntance or a set of instances (for example if there is a key field 
whose value is not specified in the path.  Or, I think, a leaflist.)

Let me remove one case.  If the leaf of type leafref is config data, and 
is not require-instance, then all that declaring it as a leafref does is 
declare the type, and provide a semantic suggestion of the  meaning to 
the human user.

For non-config data, a leafref value will be the value of a node 
selected by the path.  If the path selects one leaf, then the leafref 
leaf will have the same value as the selected leaf.  If the path selects 
a set of leafs, then the leafref leaf will have a value from that set, 
determined by the system.  The description clause and name will 
prsumably given the human user information as to which leaf will be 
swelected and what it means (as with all systems like this, semantics 
ends up being the human responsibility.)

This leafs us with require-instance config leafrefs.  That setup means 
that the value the leaf is set to must be the value of one of the leafs 
selected by the path.  (In the corner case where the path selects 
exactly one leaf there was not much point in making this config data, as 
the value is fixed to match the selected leaf.  In fact, in that case, 
setting either leaf requires setting both leaves; at least by the time 
validation is done.)

I think it is reasonable that these pieces are all under one type.

I am personally not sure that allowing require-instance to be false is 
particularly useful, but I believe the WG wanted it.

This leafref is not an indirect pointer or alias.  Rather, it is a value 
constraint.  It uses a leaf or leaf set as the value constraint and type 
source, instead of a type and range, etc.  This provides integrity 
constraints and better semantic clarity.

Yours,
Joel M. Halpern

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 May 2009 07:10:15 -0700

> the WG has agreed.  Below is a paraphrase of my current understanding.)

leafref use-cases are overloaded, which adds to the confusion.

  1) a read-only leafref in a notification is like an alias

  2) a leafref acting as a key, and pointing at another key,
     is like an SQL foreign key

  3) a read-only leafref acting as a leaf, and pointing at a key,
     is almost like a RowPointer in SNMP

  4) a read-write leafref acting as a leaf, and pointing at any
     leaf, is like a 'MyServer' kind of config copy.  Some localized
     config is constrained to the global config values.

  5) an RPC input parameter, pointing at any database leaf,
     is just another form of constraint semantics.

The main confusion and concern is over (4),
which is kind of an access control nightmare.

There is confusion over the pointed-at semantics.
The path only indicates constraint semantics for
the leafref.  The pointed-at leaf is never altered
by changes to the leafref.

One issue you raised (wrt/ #4) has not been answered at all:

  - If require-instance is true, and the pointed-at instance
    is deleted, what is the agent supposed to do with the
    leafref, and when is it supposed to be done?

I do not view the require-instance as a special case.
It just adds more constraints if true.

> particularly useful, but I believe the WG wanted it.

This is needed to support pre-provisioning.
Without it, then secondary config tables would
have to remain empty until the primary entry
is instantiated.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 May 2009 07:24:11 -0700

> that is not a key, and what happens at writing?

It would be OK with me if there was a CLR
preventing database leafrefs with config=true.

Implementation details vary greatly so we should
not discuss them here, but I would rank robust
implementation of this little part of YANG around
8.5 out of 10 in complexity.  I seriously doubt there will be
even one correct implementation for all corner cases.
(I won't tell you which corner-cases I cheated on ;-)

Leafref is easy enough -- it's the interactions
with all the other YANG bits that makes it complicated.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 May 2009 16:32:48 +0200 (CEST)

Hi,

Thank you Joel, I think this is a (mostly) correct description of the
leafref idea.  Some comments inline.

"Joel M. Halpern" <[email-masked]> wrote:
> (I have been talking with folks trying to understand leafref.  I am getting
> close to being able to suggest text that reflects what I think the WG has
> agreed.  Below is a paraphrase of my current understanding.)
> 
> Declaring something as a leafref declares it to be the same type as the target
> identified by the path, and for non-config or require-instance also declares
> that the value of the leaf of type leafref must match the target of the path.
> 
> Unfortunately, there are two different factors that affect the meaning and
> real-world constraints on the value.  Some of these are consequences, not
> definitions.  (Which makes writing a clear definition hard.)
> There is the spectrum of non-config, config with no require-instance, and
> config with require-isntances.
> isntance or a set of instances

In both cases, your description below applies:
 
  The path selects a set of leafs, and the leafref value is constrained
  to be from this set (for require-instance true leafrefs).

> (for example if there is a key field whose value
> is not specified in the path.  Or, I think, a leaflist.)

Currently a leafref cannot reference a leaf-list.

> Let me remove one case.  If the leaf of type leafref is config data, and is not
> require-instance, then all that declaring it as a leafref does is declare the
> type, and provide a semantic suggestion of the meaning to the human user.

And to tools.  As a simple example, a graphical interface may indicate
a relation between the leafref value and the target leaf when the
target leaf exist (e.g. by making the leafref value clickable).

> For non-config data, a leafref value will be the value of a node selected by
> the path.  If the path selects one leaf, then the leafref leaf will have the
> same value as the selected leaf.  If the path selects a set of leafs, then the
> leafref leaf will have a value from that set, determined by the system.  The
> description clause and name will prsumably given the human user information as
> to which leaf will be swelected and what it means (as with all systems like
> this, semantics ends up being the human responsibility.)
> 
> This leafs us with require-instance config leafrefs.  That setup means that the
> value the leaf is set to must be the value of one of the leafs selected by the
> path.  (In the corner case where the path selects exactly one leaf there was
> not much point in making this config data, as the value is fixed to match the
> selected leaf.  In fact, in that case, setting either leaf requires setting
> both leaves; at least by the time validation is done.)
> 
> source, instead of a type and range, etc.  This provides integrity constraints
> and better semantic clarity.

/martin

---

From: "tom.petch" <[email-masked]>
Date: Tue, 26 May 2009 18:02:14 +0200

----- Original Message ----- 
From: "Andy Bierman" <[email-masked]>
To: "Balazs Lengyel" <[email-masked]>
Cc: "tom.petch" <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 26, 2009 4:24 PM
Subject: Re: [netmod] leaf-ref questions

> preventing database leafrefs with config=true.

It would be ok with me as well.

> with all the other YANG bits that makes it complicated.

Yes, a comment I would generalise to other parts of YANG.
I cannot even separate it out into discrete sets or axes to master 
independently - which sounds like the same thing; sigh:-(

Tom Petch.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 May 2009 22:08:56 -0400

The more I think about it, the more convinced I am that for me, the 
problem is "require-instance = false;".

If that did not exist (and hence, there were no "require-instance" 
statement, then the definition of leafref would simply be:
This is a type declaration which matches a type of an existing leaf 
declaration of a target leaf (defined via the path statement.)  The 
values of this leaf are range restricted to match the values of 
estinsting leafs pointed to by the defined path.

> have to remain empty until the primary entry

Given that the enforcement rules (which still would need to be 
referenced) are such that there are several ways to define leaf/leafref 
sets where both need to be updated, even if we always 
"require-isntance=true", it seems to me that allowing false merely 
introduces more ways to achieve the same goal, while adding confusion. 
If we don't need the statement, then life seems simpler without it.

---

From: WashamFan <[email-masked]>
Date: Wed, 27 May 2009 10:21:20 +0800

>    to be from this set (for require-instance true leafrefs).

The path might not always select the same set of leafs, i.e.,
the leafref value is constrained to be from a floating set rather
a fixed set. How to deal with a leafref whose value is valid
before but invalid now?

washam

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 May 2009 22:33:15 -0400

When the leaf, which is a target of a leafref path, is changed, and the 
change is validated ...(section 8 of the YANG document explains exactly 
when that is.  It is unfortunately more complex than one would really like.)
then validation will fail, and an error will be returned.  The user will 
need to fix things.  Yes, leafref inconsistency is an obscure error. 
But that is what it means to use a set of leaves as a validity constraint.

Yours,
Joel

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 27 May 2009 09:12:35 +0200 (CEST)

"Joel M. Halpern" <[email-masked]> wrote:
> The more I think about it, the more convinced I am that for me, the problem is
> "require-instance = false;".

The reason we added this was to allow config data that refers to
non-config data, e.g. a pointer to a physical slot.  Without
require-instance false, if we allow config to refer to non-config
(state), the state data might change dynamically, making the
configuration invalid.

Another use case is pre-provisioning, as Andy described.

/martin

> Given that the enforcement rules (which still would need to be referenced) are
> such that there are several ways to define leaf/leafref sets where both need to
> be updated, even if we always "require-isntance=true", it seems to me that
> allowing false merely introduces more ways to achieve the same goal, while
> adding confusion. 

If it was just another way of doing the same thing, then I agree with
you.  But how could you do this pre-provisioning with just
require-instance true?

/martin

---

From: "tom.petch" <[email-masked]>
Date: Wed, 27 May 2009 11:39:22 +0200

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 27, 2009 9:12 AM
Subject: Re: [netmod] leaf-ref questions

> Another use case is pre-provisioning, as Andy described.

I am getting into a terminological confusion here.  Config is writable and
non-config is not so this allows me to write to read-only data.

Does this mean that a second writable instance of the node is created?
It's not the require-instance false that bothers me but the life-cycle of
this leaf-ref'd node, when it exists, what causes it to be updated etc.

And where does this fit in Andy's excellent list of five use cases?

Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 27 May 2009 14:21:40 +0200 (CEST)

> non-config is not so this allows me to write to read-only data.

No, since the leafref is not like a symbolic link.  Consider this:

  list slot {
      config "false";
      key "index";
      leaf index {
          type int32;
      }
  }
  
  leafref vip-slot {
      config "true";
      type leafref {
          path "/slot/index";
          require-instance "true";
      }
  }

The 'vip-slot' leaf is its very own, writable, leaf.  A leaf has a
value which matches its type.  When you write to the leaf, the leaf's
value is changed.

Compare with this:

  struct slot slots[MAX_SLOTS];

  int vip_slot; /* index into the slots array */

When you set the variable vip_slot, nothing in the slots array gets
modified.  A leafref works the same way (but the comment in the code
is formalized in the path statement in a leafref).

> And where does this fit in Andy's excellent list of five use cases?

I don't think it is covered in his list.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Wed, 27 May 2009 08:05:09 -0400

>>    to be from this set (for require-instance true leafrefs).

Nice simple language.

>a fixed set. How to deal with a leafref whose value is valid

If you are modeling something where the value is either a member
of a fixed set or is allowed to be something else, then you really
have a union of two types, one that is constrained and one that is
not.

In JUNOS, a common scenario is when a value is constrained to either
a user-defined value or a small set of JUNOS-defined (builtin)
values.  In YANG, this would be a union of a enumeration and a leafref.
I see joining a set of user-defined values and non-defined values
as a similar scenario.

+1 for removing 'require-instance'.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 May 2009 07:38:36 -0700

> have a union of two types, one that is constrained and one that is

The most common use of require-instance=false is to
pre-provision for known instances that are not currently
available.

However, config pre-provisioning is not actually
supported in NETCONF/YANG.  NETCONF does not have
any concept of RowStatus='notInService'.  An application
cannot distinguish live config from pending config
in a standard way.

> I see joining a set of user-defined values and non-defined values

So the user variables do not conform to the original typedef semantics?

This seems rather strange to me:

typedef foo {
    type union {
       type leafref {
          path "/some/uint32/leaf";
          require-instance false;
       }
       type string;
    }
}

Allowing the user to enter a string when the pointed-at
leaf takes a uint32 seems odd.  The intent of leafref
is to constrain the new leaf to the same set of values
that are allowed in the pointed-at leaf.

> +1 for removing 'require-instance'.

then how will any pre-provisioning be supported?

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 27 May 2009 10:56:10 -0400

(Responding to both Andy and Martin.)

Both of these cases (pre-provisioning, and referencing to dynamic 
operational data that may change) seem to not be leafrefs.  That is the 
definition of the leaf in these cases seems to be
"has a value which should be thought of as naming a foo (path-target) 
even if there is no foo with that name."
The "system" value seems to be that if the foo with the given name 
exists, then the system can understand the relationship.  It can not 
enforce it.  Adding an entire statement, and complicating a definition, 
so that that some gui might sometime be able to show a relationship?

The system, as described, does not have enough information to know when 
something must shift from being pre-provisioning to provision (and hence 
enforced.)

There are other ways to represent this.  Remember that the actual system 
being configured is generally going to need programmed logic to 
understand the semantics of a field.  Yes, a leafref (even one with 
require-instance set to false) can slightly simplify that logic.  But in 
fact, if pre-provisioning is different from deferring commit on 
candidate, it would introduce additional complications for the system, 
and raise a number of interesting error cases for configuration.

All in all, I still think it is a bad idea.

Joel

---

From: Phil Shafer <[email-masked]>
Date: Wed, 27 May 2009 10:49:11 -0400

>So the user variables do not conform to the original typedef semantics?

Sure, just use the original typedef for the non-leafref part
of the union.  Don't say "string" if you mean "uint32".

>then how will any pre-provisioning be supported?

This feels like a red herring.  You said:

But if you are intentionally making dangling references, then what's
the value of the leafref?  If the user can put anything in the leaf,
what is the value of the constraint that the leafref represents?
You are asking for a constraint that isn't enforced.

Thanks,
 Phil

---

From: "tom.petch" <[email-masked]>
Date: Thu, 28 May 2009 09:47:19 +0200

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 27, 2009 2:21 PM
Subject: Re: [netmod] leaf-ref questions

> > > > The more I think about it, the more convinced I am that for me, the
problem
> > is

Martin,

Thank you, I now understand this use case ( although it leaves me unclear about
Andy's case four which I would have thought covered it).

I assume that as vip-slot is config and so writable, then it can be changed as
long as the new value is within the slot/index set of values.

To me, this is more like an 'External enumeration', to coin a phrase; would it
be better handled by putting the constraint on the slot list, that the vip-slot
leafref must appear in the slot list, as opposed to putting the constraint on
the vip-slot leafref?

Conceptually, we do seem to be mixing
- a single object instance with different paths to get to it in the data mesh
(which is how I see Andy's case 1 although I could be wrong:-(
- multiple object instances with different life cycles which have a mutual
constraint between the values or sets therof.

Which may confuse more than me.
Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 May 2009 11:15:51 +0200 (CEST)

Hi,

> Andy's case four which I would have thought covered it).

Maybe it did - I read it as a config leafref pointing to config leaf.

> leafref must appear in the slot list, as opposed to putting the constraint on

The the slot list might be published in one module, and the vip-slot
in some other module later on.

If we remove require instance, this kind of reference will have to
described in the description clause.

> (which is how I see Andy's case 1 although I could be wrong:-(

When the leafref is included in a notification, as in Andy's use-case
1, it is more like a copy of the data.  You can't really access the
same instance this way.

So IMO, we never have multiple paths to a single instance.

> constraint between the values or sets therof.

This description matches my view of this.

/martin