Subject: Re: [netmod] leafref issues

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Jun 2009 10:27:34 +0200

Martin Bjorklund píše v Pá 29. 05. 2009 v 19:48 +0200:
> > Since leafref just returns the value of the pointed-at node
> > with no indication of the actual instance selected,
> > it is not very useful for notifications.
> 
> We changed keyref to leafref mainly for supporting leafref in
> notifications.  If you think we don't need to worry about
> notifications, can we change leafref back to keyref?

Could notifications use instance identifiers instead? The big advantage
would be that the i-i XPath refers to a concrete instance document and
needn't be specified in the data model as for leafrefs.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 01 Jun 2009 05:03:18 -0700

> needn't be specified in the data model as for leafrefs.

What is needed is a variable binding -- the instance-identifier
and the associated current value. Just knowing the value (leafref)
or just knowing the ID (instance-identifier) is worthless.
SNMP solved the notification varbind problem 2 decades ago.
(How come NETCONF messed it up so badly?)

> Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Jun 2009 14:37:55 +0200

> (How come NETCONF messed it up so badly?)

I don't understand. Having a locator for a node in the data tree means
that its value can be always determined, so IMO in notifications and RPC
data the locator (path) should always suffice.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 01 Jun 2009 06:59:05 -0700

> data the locator (path) should always suffice.

This introduces time-based skew in the data, and the application
is forced to retrieve data that is normally delivered in the
notification.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Jun 2009 16:30:42 +0200

> is forced to retrieve data that is normally delivered in the

The notification can still deliver the value and the specification of
its semantics will state that it is the value of the leaf pointed to by
the instance-identifier. Anyway, if the notification contained both
instance-identifier and leafref, there is no way in YANG to tell that
both refer to the same leaf.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Tue, 2 Jun 2009 20:21:15 +0200

----- Original Message ----- 
From: "Andy Bierman" <[email-masked]>
To: "Ladislav Lhotka" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 01, 2009 2:03 PM
Subject: Re: [netmod] leafref issues

Andy

It's not really to do with notifications but with getting anything from
device to manager.  SMI took the view that a device knowing nothing
of the data model could still make some sense of the data it received,
what its SYNTAX was, what value, where in the data tree it came from, 
this applies to get, get-next, report, anything, something I have used
with success when I had gotten the contents of a proprietary MIB module,
such as a CISCO one:-)

NETCONF takes the view that the manager must have the data model
to achieve even this, although with it, it can achieve more, just as an
SMI manager can.

We could introduce varbinds into YANG, at least for notification; it is 
only a complex type, of instance identifier and instance value.

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

---

From: "tom.petch" <[email-masked]>
Date: Tue, 2 Jun 2009 20:44:52 +0200

OK, so leafref is copy by value, but I do not see that in the wording
(which is perhaps why I have been so stubbornly not wanting to believe
it).

But two sentences in particular really give me grief.

"Its value is constrained to be the same as the value of an existing leaf."

"Its" - of course - refers back to the subject of the previous sentence, namely
"The leafref type"

so this tells me that the value of the leafref type (in XSD, everything has a
value, so why not a leafref type in YANG?) is constrained to be the same as the
value of an existing leaf.  Which does not parse.  The value of a type, in
schema tree or data tree, is going to be different to the value of a leaf!

So perhaps it means that the value of the leaf with the leafref type is
constrained
to be the same as the value etc.  But this formulation is used in the next
paragraph, so why not here, why the difference?  Just what is that sentence "Its
value ...." trying to say.

Please spell it out.

Likewise in 9.9.2.

"The value of the referring leaf MUST match the type of the referred leaf."

Again, I cannot make sense of a value matching a type.  Either I must coerce the
value into a type ie you mean that the value's type must match referred leaf's
type or I must coerce the type into a value - ie the value of the referring leaf
MUST match the value of the referred leaf or leafs.  Neither of which you say.

Please clarify.

Some time back, Joel suggested substantial changes were needed to the wording
if this description meant what you were saying on the list.  My details may
differ, but in principle, yes I agree.

Tom Petch

---

From: Phil Shafer <[email-masked]>
Date: Tue, 2 Jun 2009 16:02:26 -0400

>(which is perhaps why I have been so stubbornly not wanting to believe

leafref isn't copy by anything.  There's no copying at all.

It's a constraint on the value space of a leaf, meaning the leaf
may only contain values that appear at some other particular spot
in the configuration.

leafref allows a modeler to enforce referential integrity, so that
a reference to a name configuration item defined in one spot can
be guaranteed to exist, and to not be a dangling reference.

For example, an interface configuration can only use a firewall
filter that's defined in the firewall filter configuration.  Or a
routing peer configuration can only use an import or export policy
that's been configured under the policy configuration.

/* Define a policy */
container policy-options {
    list policy {
        key name;
        leaf name { ... }
    }
}

/* BGP config refers to that policy */
container protocols {
    container bgp {
        list neighbor {
            key name;
            leaf name { ... }
            leaf import {
                type keyref {
                    path ../../../policy-options/policy/name;
                }
            }
        }
    }
}

The config would look like:

<policy-options>
  <policy>
    <name>allow-static-routes</name>
    ...
   </>
</>
<protoocols>
  <bgp>
    <neighbor>
      <name>10.1.2.3</name>
      <import>allow-static-routes</import>
      ...
    </>
  </>
</>

If I set "import" to "allow-random-chaos", the configuration would be invalid
and both the client and server can know that it would be invalid.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 02 Jun 2009 13:32:14 -0700

> with success when I had gotten the contents of a proprietary MIB module,

I believe the OPS-NM area has received operator feedback
requesting more info in a notification, not less.
It is better to receive all the info needed to
correlate an event at the same time, rather than
getting some of it in a notification and the rest of
it with subsequent polls.

In NETCONF, the entire affected entry can be returned, but
nobody is going to want to do this for big entries.

One can always write description statements that indicate
the semantic coupling between an instance-identifier leaf
and 1 or more leafref sibling leafs which happen to
have XPath targets which resolve to the same object.
I prefer to avoid modeling really common semantics in
description statements.  But YANG has the extension-stmt
for this sort of thing, so it is not really a big deal.

> only a complex type, of instance identifier and instance value.

YANG has two hard-wired complex types,
but they are called list and container.
They cannot be reused in any way like XSD complexType,
so YANG does not call them types.

Andy

---

From: "tom.petch" <[email-masked]>
Date: Wed, 3 Jun 2009 19:07:00 +0200

---- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Ladislav Lhotka" <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 02, 2009 10:32 PM

Andy

True but rather I was referring, in my not very explicit way, to
" YANG permits the definition of complex types using reusable grouping
   of nodes."

Alternatively, we could say that the data modeller must design the data tree to
make notifications straightforward, that is that there is in the data tree a set
of objects which form a notification, eg a grouping{} or a container{}, and it
is this set, possibly plus others, that must appear as one in a notification eg
for an interface up or down, the set might be admin status, oper status,
interface number, interface description, last error. The set would have a common
index/path.

It makes the notification tail wag the configuration dog, but if notifications
are important enough, then it is worth it.  And it would be simpler to specify
than having a more generic mechanism which allows an arbitrary selection
of objects to be brought together from arbitrary places in the data tree
to form a notification, each with a potentially different index/path.

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Wed, 03 Jun 2009 11:40:44 -0700

> to form a notification, each with a potentially different index/path.

I do not agree this is a good use-case for grouping/uses.
This is simply cut-and-paste with the ability to 'refine'
config true to config false.

SMIv2 has "MAX-ACCESS notify-only" to deal with this problem.
All SNMP NOTIFICATION varbinds are pointers to database objects,
except these special objects, which can be used by any
notification definition.

We should not say how the data modeler MUST design anything,
beyond what is already there.  This is not a real problem,
since any application can be hard-wired to 'understand'
that notification payloads are just copies, not in any way
representing some actual config subtree in the system.

Extensions can be used in conjunction with description statements
to define semantic coupling of notification payload siblings,
if that is desired.

Andy