Subject: [netmod] YANG notification content proposal

From: Andy Bierman <[email-masked]>
Date: Tue, 28 Oct 2008 14:51:24 -0700

Hi,

I do think the YANG notification construct is quite good enough.
SMIv2 provides an OBJECTS list in the notification definition,
so copies of 'real' objects can be easily included in the
payload without any redefining needed.

YANG requires 'local' nodes to be created within the notification
statement, which are like SMIv2 'notification-only' objects.
The problem is that this mode is the exception, not the
common case.

A NETCONF notification cannot really support an SMIv2-style object.
You have to provide the entire XML instance tree for the root
to any given 'object' node.  There is no XML 'varbind',
which contains a fully specified object instance ID and
a value.

This would only work well if the YANG to XML encoding was something
like SMIv2:

Implied XML content from the object-stmt:

    container object {
      config false;
      leaf id { type instance-identifier; }
      anyxml value;
    }

Example notification-stmt:

    notification mtu-changed {
       description "Return the new MTU value when it changes.";

       object /if:interfaces/if:interface/if:mtu {
         description
           "Identifies the interface instance that changed,
            and the new MTU value for that interface.";
       }

       leaf changed-by {
         description "Indicates how the MTU was changed.";
         type enumeration {
           enum other;
           enum agent;
           enum manager;
         }
       }
    }

Example <notification> PDU:

    <nn:notification xmlns:nn="NETCONF-notification-NS">
      <nnc:eventTime xmlns:nnc="NETCONF-notification-content-NS">
         2008-10-28T14:46:04.000-07:00
      </nnc:eventTime>
      <y:object xmlns:y="YANG-NS">
        <y:id>/if:interfaces/if:interface[if:name='eth0']/if:mtu</y:id>
        <y:value>1518</y:value>
      </y:object>
      <foo:changed-by xmlns:foo="module-foo-NS">manager</foo:changed-by>
    </nn:notification>

I think this will make YANG notifications better:
   * easier to understand
   * more consistent with SMIv2 notifications
   * allows arbitrary content, not just leafs
   * XPath allows simpler and less verbose encoding than XML
     for specifying the path from root with all the key values
   * notification-only content and copy of config object content
     are clearly distinguished, and each is easy to specify

Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Oct 2008 04:47:06 +0100

On Tue, Oct 28, 2008 at 02:51:24PM -0700, Andy Bierman wrote:

[...]

>     are clearly distinguished, and each is easy to specify

Carrying XPATH in instance documents is IMHO a major change and it
might take some effort to convince myself this is goodness.

/js

PS: I am wondering why all this is supposed to be notification
    specific. I can very well envision to carry "objects" as RPC
    input/output parameters - so if a new mechanism is needed (and I
    am not convinced yet) it should probably more general.

-- 
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: Balazs Lengyel <[email-masked]>
Date: Wed, 29 Oct 2008 11:24:15 +0100

Isn't the leafref supposed to solve this problem?
Instead of locally creating the leafs in the notification you just reference them.
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: Andy Bierman <[email-masked]>
Date: Wed, 29 Oct 2008 04:37:17 -0700

> Instead of locally creating the leafs in the notification you just 

leafref only works when you specify all the keys.
It falls apart as soon as the desired leaf is nested
within 2 or more lists.

But I agree with Juergen that this is not a notification-only
issue.  Certainly anything send in a notification can also be
sent in an <rpc-reply>.

I don't mind punting this, and every single new feature,
since YANG is already too complicated.  The 80/20 rule
has to kick in before the draft tops 200 pages.

Andy