Subject: [netmod] notification mapping in draft-ietf-netmod-smi-yang-00

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Jun 2011 12:31:22 +0200 (CEST)

Hi,

The mapping algorithm for notification objects describe how each
object is mapped to a container with N+1 leafs, where N is the number
of indexes:

      If the current object belongs to a conceptual table,
      then a sequence of leaf statements is generated for each INDEX
      object of the conceptual table.  These leafs are named after the
      INDEX objects and of type leafref.  Finally, a leaf statement is
      generated named after the current object.  If the current object
      has a MAX-ACCESS of "read-only", "read-write" or ""read-create",
      then the generated leaf is of type leafref.

And an example:

      container object-2 {
         leaf ifIndex {
           type leafref {
             path "/if-mib:ifTable/if-mib:ifEntry/if-mib:ifIndex";
           }
           description
            "[Automatically generated leaf for a notification object
              index.]";
         }
         leaf ifAdminStatus {
           type leafref {
             path "/if-mib:ifTable/if-mib:ifEntry/if-mib:ifAdminStatus";
           }
           description
            "[Automatically generated leaf for a notification object.]";
         }
       }

But this mapping fails to connect the leafrefs in the container with
each other.  The idea is that the value of ifIndex in the example
above is the value for the corresponding ifAdminStatus.

I think it should be:

         leaf ifAdminStatus {
           type leafref {
             path "/if-mib:ifTable/if-mib:ifEntry"
                + "[if-mib:ifIndex = current()/../ifIndex]"
                + "/if-mib:ifAdminStatus";
           }

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Jun 2011 16:22:33 +0200

On Wed, Jun 08, 2011 at 12:31:22PM +0200, Martin Bjorklund wrote:

[...]
 
>                 + "/if-mib:ifAdminStatus";

While I see what you want to achieve, I am not sure YANG really allows
to do this or it may not be very clear from my reading of RFC
6020. The issue is that ifAdminStatus is part of the notification
definition while section 9.9.2 says:

See also the definition of context node in 9.9.2:

   o  The context node is the node in the data tree for which the "path"
      statement is defined.

Here is the definition of data tree:

  data tree: The instantiated tree of configuration and state data
        on a device.

Furthermore, section 9.9.2 says:

   The predicates are only used when more than one key reference is
   needed to uniquely identify a leaf instance.  This occurs if a list
   has multiple keys, or a reference to a leaf other than the key in a
   list is needed.  In these cases, multiple leafrefs are typically
   specified, and predicates are used to tie them together.

In your example, the list has only a single key...

/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: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Jun 2011 16:30:49 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> 6020.

Are you saying that you think YANG, in notifications, allows leafrefs
w/o predicates but not w/ predicates?  Or that leafrefs cannot be used
in notifications at all?  Or something else?

> The issue is that ifAdminStatus is part of the notification

With multiple keys, you get multiple predicates.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Jun 2011 16:40:53 +0200 (CEST)

> in notifications at all?  Or something else?

Sorry, I was too quick.  I understand your concern.  The problem is
in 9.9.2:

   The accessible tree depends on the context node:

   o  If the context node represents configuration data, the tree is the
      data in the NETCONF datastore where the context node exists.  The
      XPath root node has all top-level configuration data nodes in all
      modules as children.

   o  Otherwise, the tree is all state data on the device, and the
      <running/> datastore.  The XPath root node has all top-level data
      nodes in all modules as children.

And it doesn't work to say that for notifs, the tree is made up of all
state + running + the notification instance, since the notif might
have the same name as a data node...

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Jun 2011 21:49:08 +0200

> in notifications at all?  Or something else?

I got the impression that a notification leafref path xpath expression
can only refer to data tree nodes, not to nodes in the notification
itself. I assume there are namespace reasons behind the rule, that is
there is a technical reason for this rule.
 
> With multiple keys, you get multiple predicates.

Yes, but my reading of this text is that it is not allowed to use
predicates if you only have a single simple key. I assume this rule is
a case of an overspecification and should likely not have been here.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Jun 2011 21:56:16 +0200 (CEST)

> a case of an overspecification and should likely not have been here.

This text is probably a left over from when we had keyrefs only;
slightly updated, but not completely correct.  The second sentence is
correct, it mentions that predicates are used if a reference to a
non-key leaf is used.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Jun 2011 22:07:31 +0200

> correct, it mentions that predicates are used if a reference to a

What about working out replacement text and filing an errata? This way
we can be sure we won't forget this detail when RFC 6020 is revised.

/js