Subject: [netmod] Fwd: Re: Leafref and require-instance=false

From: Balazs Lengyel <[email-masked]>
Date: Mon, 8 Jun 2015 14:08:05 +0200

Hello,

I propose a small clarification to the yang draft as described
below.

regards Balazs

-------- Forwarded Message --------

Subject:

Re: Leafref and require-instance=false

Date:

Mon, 8 Jun 2015 13:44:55 +0200

From:

Martin Bjorklund <[email-masked]>

To:

[email-masked]

Balazs Lengyel <[email-masked]> wrote:
> Hello Martin,
> Any thoughts on this?
> regards Balazs
>
>
> Hello Martin,
> If I have a leafref with require-instance=false which references an
> uint8 with range 1..10, and the leafref contains the value 20, can
> this be a valid configuration?
> As I see it, there is nothing in the draft that says this is not
> allowed.
>
> IMHO this should not be valid. You could add something like:
> "The leafref must have a value that is a possible allowed value for
> the referenced leaf."

I agree, this makes sense!

/martin

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Jun 2015 14:11:35 +0200

RFC 6020 section 9.9:

   The leafref type is used to reference a particular leaf instance in
   the data tree.  The "path" substatement (Section 9.9.2) selects a set
   of leaf instances, and the leafref value space is the set of values
   of these leaf instances.

I think the last statement above already clarifies this, no?

/js

On Mon, Jun 08, 2015 at 02:08:05PM +0200, Balazs Lengyel wrote:
>    Hello,
>    I propose a small clarification to the yang draft as described below.
>    regards Balazs
>    Subject: Re: Leafref and require-instance=false
>       Date: Mon, 8 Jun 2015 13:44:55 +0200
>       From: Martin Bjorklund [1]<[email-masked]>
>         To: [2][email-masked]
> 
>  Balazs Lengyel [3]<[email-masked]> wrote:
>  > Hello Martin,
>  > Any thoughts on this?
>  > regards Balazs
>  >
>  >
>  > Hello Martin,
>  Mobile: +36-70-330-7909              email: [4][email-masked]
> 
> References
> 
>    Visible links
>    1. mailto:[email-masked]
>    2. mailto:[email-masked]
>    3. mailto:[email-masked]
>    4. mailto:[email-masked]

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

-- 
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: Ladislav Lhotka <[email-masked]>
Date: Mon, 08 Jun 2015 15:22:11 +0200

> I think the last statement above already clarifies this, no?

I think this is a stricter constraint that addresses the
"require-instance true" case : possible leafref values are limited to
those that instances of the referenced leaf really have.

6020bis should IMO say something like this:

The "path" substatement (Section 9.9.2) selects a set of leaf
instances. If the "require-instance" property (Section 9.9.3) is set to
"true", the leafref value space is the set of values of these leaf
instances.  Otherwise, the leafref value MUST be a valid value of the
data type that is defined for the referenced leaf.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Jun 2015 15:27:20 +0200 (CEST)

> data type that is defined for the referenced leaf.

You were quicker than me ;)  I agree with this.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Jun 2015 16:22:08 +0200

> data type that is defined for the referenced leaf.

This makes sense.

/js

---

From: Kent Watsen <[email-masked]>
Date: Mon, 8 Jun 2015 14:40:10 +0000

> Otherwise, the leafref value MUST be a valid value of the

Is it a MUST or a SHOULD?

Obviously, if it's not a valid value, a match will never occur, but that's
a user error, no?

It comes down to a validation warning versus a validation error.  I argue
that the validation should not fail in this case.

Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 8 Jun 2015 17:14:54 +0200

> On 08 Jun 2015, at 16:40, Kent Watsen <[email-masked]> wrote:
> 
> 

I think the two leafs are coupled through the path statement and so the values of both should conform to the same type. If I extend Balazs’ example with uint8 and 1..10 range:

1. Would a leafref value of 256 be acceptable?

2. How about "foo"?

Lada

---

From: Kent Watsen <[email-masked]>
Date: Mon, 8 Jun 2015 15:39:30 +0000

>I think the two leafs are coupled through the path statement and so the
>values of both should conform to the same type. If I extend Balazs¹
>example with uint8 and 1..10 range:
>

I agree it doesn't makes sense, but is the configuration invalid?

The leafref is marked require-instance=false, it just means a matching
condition will never succeed.

Would a configuration be invalid if a "when" expression could never
evaluate to true?

Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 8 Jun 2015 18:02:34 +0200

> On 08 Jun 2015, at 17:39, Kent Watsen <[email-masked]> wrote:
> 
> 
> 
> 

It’s a matter of definition but IMO it should be defined as invalid. For example, an implementor can use the type information for allocating an internal data type for the leafref.

> Would a configuration be invalid if a "when" expression could never

We should distinguish between syntactic (schema & datatypes) and semantic errors (must & when, and actually also a violation of require-instance=true for leafrefs).

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Jun 2015 09:14:07 -0700

> condition will never succeed.

If require-instance = false then the node must conform to
the data type for the leaf.  This means the typedef used
in the implemented version.

> Would a configuration be invalid if a "when" expression could never

The node would never appear in a configuration.
A must-stmt then is always false would make the config invalid.

> Kent

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Jun 2015 18:33:13 +0200 (CEST)

> in the implemented version.

+1

/martin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 8 Jun 2015 16:37:32 +0000

>> in the implemented version.

OK, fine, a MUST it is then.

Thanks,
Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 08 Jun 2015 20:49:50 +0200

> A must-stmt then is always false would make the config invalid.

What's actually relevant to the subject of this thread (and supports
Kent's point somewhat) is this example:

leaf foo {
  type uint8;
  must ". <= 10";
}
leaf bar {
  type leafref {
    require-instance false;
    path "../foo";
  }
}

Should <bar>20</bar> be flagged as invalid? IMO no. At first sight it
looks exactly like Balazs' example but in fact it is different - if
there is no "foo", the must expression doesn't apply.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Jun 2015 12:15:06 -0700

> there is no "foo", the must expression doesn't apply.

I don't see where a range "1..20" is introduced.
The "leaf bar" has the same type as /foo,
so that is uint8.

I see your point... does "require-instance false"
mean it could be a valid value for the leaf, but
no instances happen to exist with that value?

Or does it mean valid for the same data-type but the instance
may never exist?

I think "valid for the data type" is correct.
The must-stmt says valid for the leaf to exist.
That is a separate test.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Jun 2015 21:16:53 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> Should <bar>20</bar> be flagged as invalid? IMO no.

No!  "flagged as invalid" is not precise enough - note that
<foo>20</foo> is ok in some circumstances, e.g., it is ok to have
<foo>20</foo> in the candidate.  However <foo>20</foo> can never be
part of a valid configuration.

<bar>20</bar> is always ok.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 09 Jun 2015 15:57:25 +0200

> The must-stmt says valid for the leaf to exist.

Agreed. Lada