Subject: [Netconf] handling YANG leafrefs

From: Bartosz Michalik <[email-masked]>
Date: Thu, 5 Jun 2014 09:33:47 +0200

Hi all,
We are implementing database-backed YANG datastore with RESTCONF API.
I have some problems with interpreting the spec when it comes to data 
updates when leafrefs are involved.
More specifically I would like to know how the leafref would behave when 
referred leaf got updated.
Let me give you an example

module toy_example {
   namespace "http://com/example/artist";
   prefix artist;

   container music {
    list artist {
      key name;
      leaf name {type string;}
      leaf nick_name {type string;}
      ...
    }
    container prerferences {
      leaf best_artist { type leafref { path "../artist/nick_name"; }}
    }
   }
}

Lets imagine I have two artists in the database Aartist("XXX") and 
Bartist("YYY") - nicknames in brackets.
Now i have POSTed my preferences and best artist links to "YYY". Lets 
imagine we update Bartist nick name to "ZZZ".
What would happen with best_artist leaf ?

Thank you in advance for the answers,
Bartosz

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Jun 2014 09:50:03 +0200 (CEST)

Bartosz Michalik <[email-masked]> wrote:
> More specifically I would like to know how the leafref would behave
> when referred leaf got updated.

Nothing, but the resulting configuration would not be valid since the
leafref points to a non-existing leaf, and thus your POST request
would fail.

/martin

---

From: Bartosz Michalik <[email-masked]>
Date: Thu, 5 Jun 2014 09:57:30 +0200

> leafref points to a non-existing leaf, and thus your POST request
So leafref is  a "reference by value" and adds modification-lock to the 
leaf it refers to.
Thank you for the clarification.
Greetings,
Bartosz

---

From: Per Hedeland <[email-masked]>
Date: Thu, 05 Jun 2014 10:30:54 +0200

On 2014-06-05 09:57, Bartosz Michalik wrote:
> So leafref is  a "reference by value" and adds modification-lock to the leaf it refers to.

I believe a more correct way to look at leafref is (besides the
type-copy) purely as a constraint on the value space. If you update
Bartist nick name to "ZZZ" *and* Aartist nick name to "YYY", the
resulting configuration is still fine, even though the leafref then
"refers to" a different leaf (and of course you could have both nick
names be "YYY", in which case there is no way to tell which of them the
leafref "refers to").

I frequently see confusion about the semantics of leafref among our
"YANG newbie" customers, mostly that it is thought of as some kind of
"link" rather than a constraint. Maybe the name isn't ideal (I'm not
suggesting to change it though:-), and the text in RFC 6020, while it
does eventually tell everything, is perhaps not ideal either. E.g. it
starts out with

  The leafref type is used to reference a particular leaf instance in
  the data tree.

- which, if not actually incorrect in the general case (see above), is
at least IMHO leading the reader down the wrong thought path. Maybe

  The leafref type is used to declare a constraint on the value space of
  a leaf, based on a reference to a set of leaf instances in the data
  tree.

would be better...

--Per Hedeland

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jun 2014 10:39:16 +0200

>   a leaf, based on a reference to a set of leaf instances in the data

I agree that the first sentence in 9.9, in particular the phrase
"reference a particular leaf instance", is likely confusing. If others
feel the same, perhaps the right thing is to open an erratum so we can
track this and finally fix it in YANG 1.1.

/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: Jernej Tuljak <[email-masked]>
Date: Thu, 05 Jun 2014 10:47:13 +0200

> track this and finally fix it in YANG 1.1.

+1

Jernej

---

From: Radek Krejčí <[email-masked]>
Date: Thu, 05 Jun 2014 10:47:39 +0200

+1

Radek

---

From: Bartosz Michalik <[email-masked]>
Date: Thu, 5 Jun 2014 10:55:11 +0200

+1
Bartosz

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Jun 2014 11:00:26 +0200 (CEST)

> track this and finally fix it in YANG 1.1.

+1 for fix in 1.1, but do we really need to open an errata?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jun 2014 12:17:03 +0200

> +1 for fix in 1.1, but do we really need to open an errata?

It is a way of documenting the issue right now in a place where people
can easily find it right now and we won't loose it during the work on
YANG 1.1.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Jun 2014 12:28:48 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> can easily find it right now 

Ok.

>and we won't loose it during the work on
> YANG 1.1.

I won't loose it; I've already edited the source.

/martin