Subject: [netmod] object, not leafref

From: Andy Bierman <[email-masked]>
Date: Sat, 18 Oct 2008 09:40:14 -0700

Hi,
I was asked to propose a 'leafref' built-in data type.
Change of plans...

The only use-case I know of for leafref is notification content.
The notification-stmt needs work, and adding
another built-in type is not the right answer.

In SMIv2, a NOTIFICATION-TYPE macro has an OBJECTS clause.
This is better than the YANG data-def-stmt contents
because it is more terse, and clearly conveys the
fact that a notification contains copies of database objects,
and/or notification-only objects.

YANG needs an 'object' sub-clause, which specifies a database
object that will be copied into the notification:

   notification foo {

      object "/foo/bar/leaf1" {
         description "copied data from leaf1";
         reference "...";
         mandatory true;
      }

      object "/if:interfaces/if:interface/foo:fooEntry";

      leaf foo-only {
        description
          "This leaf exists only in the foo notification.";
        type string;
      }
   }

IMO this makes the notification content definition easier
to understand, without suffering a massive ripple-effect
that a new built-in type would cause.

Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 19 Oct 2008 08:59:48 +0200

> another built-in type is not the right answer.

I question that assumption. Are you saying that are no references
to non key objects in SMIv2 MIB modules other than notifications?
I doubt that very much.

/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/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 19 Oct 2008 12:08:24 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Andy Bierman" <[email-masked]>
> Cc: "NETMOD Working Group" <[email-masked]>
> Sent: Saturday, October 18, 2008 11:59 PM
> Subject: Re: [netmod] object, not leafref
>
...

The disman schedule (RFC 2591) and expression MIBs come to mind....
I don't know whether anyone ever intends to use netconf to configure such
beasts.  These MIBs have several quirks that are direct conseqneuces
of the way SNMP and the SMI work.  Providing equivalent functionality
in a netmod world might lead to a different design, but the need to
refer to specific instances of management information would remain.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 19 Oct 2008 17:56:18 -0700

> refer to specific instances of management information would remain.

So you think we need a leafref built-in type?
Maybe we do.  IMO, leafref is an unconstrained keyref.
That means it is just like keyref, but it does not
have to point at a config leaf, or a key leaf -- just a leaf.

I don't know if it should be constrained to existing
instances of the 'pointed-at' leaf, or just valid
instances of the leaf.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 19 Oct 2008 21:59:50 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Sent: Sunday, October 19, 2008 5:56 PM
...
> instances of the 'pointed-at' leaf, or just valid

Dunno.  I *can* think of cases where it would be preferable to *not*
enforce such a constraint.  For example, configuring an expression/schedule
like gizmo to reference something that lives on another system.  It's
probably more robust to define its semantics when the thing referenced
  (1) cannot be accessed (access control or unreachable)
  (2) doesn't exist (at the moment)
  (3) cannot exist
  (4) isn't a leaf

But perhaps this more properly belongs to the plumbing of such gizmos,
rather than to a base type.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Oct 2008 07:22:16 +0200

On Sun, Oct 19, 2008 at 05:56:18PM -0700, Andy Bierman wrote:

> IMO, leafref is an unconstrained keyref.

I think we need to sort out what the different constraints are we
assume for a keyref and once we understand this it might be better to
have a general leafref type where the keyref falls out as a special
case or a subtype.

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 20 Oct 2008 15:04:42 +0200

Hello,
I see two constraints:
1) It must point to a key leaf (not an ordinary leaf)
2) The a list entry with a key leaf containing that particular key leaf with that particular 
value must exist
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Oct 2008 15:30:58 +0200

On Mon, Oct 20, 2008 at 03:04:42PM +0200, Balazs Lengyel wrote:

> 2) The a list entry with a key leaf containing that particular key leaf 
> with that particular value must exist

We had some discussion at the interim about the "must exist" property
since sometimes it is perfectly valid to provision configuration for
something that does not exist when it is configured but might exist at
a later point in time. Phil said you can deal with this by creating a
union of a keyref and a string if I recall correctly, which however
makes it not obvious what is going on if you ask me.

I think it will be useful to have control over the "must exist"
property of a keyref and this also applies to more general leafrefs.
So I like to have a general leaf reference type which is not
restricted to point to keys and a keyword or so to express that the
referenced leaft must exist (which I can use as needed).

(I could question why it is useful to have a keyref since tools can
 figure out that a leafref is actually pointing to a key, but having
 some redundant information might help readers.)

I have searched for keyref in the YANG specs and I did not see
anything that could break if we replace the keyref type with a leafref
type (and if needed, we can derive a keyref type from the leafref type
in the common data types document).

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 20 Oct 2008 16:03:53 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> property of a keyref

+1

> and this also applies to more general leafrefs.

+1 if we add leafref.

>  some redundant information might help readers.)

Maybe Andy's proposed 'object' is better than 'leafref'.

The 'keyref' construct is known from XSD and two proprietary DMLs.
AFAIK, 'leafref' is something new, and the only use case we have seen is
handled (better) with Andy's proposal.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Oct 2008 16:21:41 +0200

> handled (better) with Andy's proposal.

So you agree with Andy that we will never have to refer to a leaf that
his not a key? I am still not convinced...

/js

PS: To some extend, keyref is a misnomer since for complex keys, a
    keyref is just refering to a part of a key. So keyref is really
    a 'partialkeyref'. ;-)

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Oct 2008 08:05:29 -0700

> his not a key? I am still not convinced...

I did not say there are no other use cases.

One monitoring-related use would be statistics
broken out by some metric, which happens to be
a leaf in some 'static' record.

For example, consider a classic database application
with a record called 'person', that has a 'zipcode'
column.

The company may want to know the geographical distribution
of its employees, so it maintains a list indexed by zipcode.

   list employee-distribution {
      key zipcode;

      leaf zipcode {
         type leafref { path "/person/address/zipcode"; }
      }

      leaf count { type uint32; }
   }

This is a true leaf ref (foreign key), since only the zipcodes
which have employees living in them are of interest, and only
those instances of zipcode are valid/relevant.

I think leafref will show up in data models once in awhile.

If we had to pick just one, I would go with leafref over keyref,
since it covers every use-case.

>     keyref is just refering to a part of a key. So keyref is really

We discussed this at the meeting (when I asked if any
missing predicates are allowed for a list-in-list
example.  Martin said no -- the XPath must identify
one instance of the 'outside' list, otherwise the
keyref (or leafref) value would be ambiguous.

We need to nail down the details on keyref/leafref,
or at least identify the aspects that are open to
implementation choice.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 20 Oct 2008 18:03:37 +0200

Hello,
I see a use case for leafrefs in rpc/output parameters as well.
Balazs