Subject: [netmod] Issue Y36: associate RPCs AND notification with a data node

From: Balázs Lengyel <[email-masked]>
Date: Sun, 3 Aug 2014 21:56:51 +0000

Hello
I attached my proposal for the action statement in YANG. Please comment.
Regards Balazs

On 2014-07-29 15:40, Balazs Lengyel wrote:
Hello Juergen,
We should declare this issue alive because IETF is about rough consensus and running code:
- Rough consensus: Major players (Martin, Andy :-) ) and myself for Ericsson indicated strong interest and support (at least for connecting RPCs, a.k.a. actions, to data nodes). That is at least a begining for a consensus.
- Running code: Tail-f, Ericsson, and probably Huawei already has implementations of actions.

I have a reasonable proposal, which I will publish hopefully this week, but want to check with Martin first.
Also, actions are similar in many ways to RPCs so IMHO they are not a major new feature, no need to wait for a major YANG version: 2.0.
regards Balazs

On 2014-07-23 21:16, Juergen Schoenwaelder wrote:

On Wed, Jul 23, 2014 at 02:58:58PM -0400, Martin Bjorklund wrote:

In NACM, you can have a rule that looks like this:

   <rule>
     <name>xx</name>
     <path>/system/authentication/user[name=$USER]</path>
     <access-operations>exec</access-operations>
     <action>accept</accept>
   </rule>

(this would give a user access to any inline operations available for
a user, maybe 'generate-ssh-keys')

So while the NACM procedure defined in RFC 6536 doesn't spell out how
to handle inline operations (not surpringsly...) the data model
supports them.

I support Balazs in this; I think especially inline operations
(a.k.a. actions) have proven to be very useful.  We support them in
our software, and a majority of our customers use them.
Lets see what has happened. We discussed Y36 on 2014-06-04. Below is
the excerpt from the minutes. A call was made on the mailing list on
Fri, 27 Jun 2014 and nobody objected against the proposal to move this
to DEAD.

Why do we reconsider this now? What makes this a YANG 1.1 issue now?

/js

* Y36 associate a notification with a data node

   MB says that he did not have customers asking for this but Tail-f
   has something similar called actions (inlined rpcs). If we do this,
   it makes sense to add inline RPCs as well.

   AZ sees a use case.

   PO sees value in notification source properties attached to leafs.

   PO says that this is essentially about associating a notification
   with a resource object.

   MB says this is a nice to have feature because you can do
   without. Sounds more like a YANG 2.0 issue.

   AB agrees that this is an optimization, perhaps this can also be
   dealt with by certain design patterns.

   JS suggests that one could also think about guidelines on how to
   structure notifications to make resource identification easier.

   Proposal: Reject this issue. May be considered for YANG 2.0.

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

---

From: Andy Bierman <[email-masked]>
Date: Sun, 3 Aug 2014 18:46:09 -0700

Hi,

I have some questions and concerns about this proposal.

1) scope is inaccurate:
 * Y36 associate a notification with a data node
  This proposal has nothing to do with notifications.
  Where is the support to associate a notification with a data node?

2) In your example, how would the <rpc> be encoded if there was a
    list above server:

        list group {
            key "a b ";
            leaf a { type string; }
            leaf b { type int32; }
            list server {  ... action reset { ... } }
      }

 3) What if there are 2 'reset' actions:

 module server-farm {
         namespace "http://example.net/server-farm";
         prefix "sfarm";

         list server {
            key name;
            leaf name {
                type string;
            }
            action reset {
                input {
                    leaf reset-at {
                        type yang:date-and-time;
                        mandatory true;
                    }
                }
                output {
                    leaf reset-finished-at {
                     type string;
                      mandatory true;
                    }
                }
            }
        }

        container top {
            list server {
              key name;
               leaf name {
                  type string;
               }
               action reset {
                   input {
                       leaf reset-at {
                          type string;
                      }
                  }
             }
        }

    }

We have /server/reset and /top/server/reset.
How do the server know which 1 is being invoked?

4) Ehat is the purpose of the extra <data> container inserted in the action
input
and output?

Andy

On Sun, Aug 3, 2014 at 2:56 PM, Balázs Lengyel <[email-masked]>
wrote:

> - Rough consensus: Major players (Martin, Andy :-) ) and myself for
> Ericsson indicated strong interest and support (at least for connecting
> RPCs, a.k.a. actions, to data nodes). That is at least a begining for a
> consensus.
> Also, actions are similar in many ways to RPCs so IMHO they are not a
> major new feature, no need to wait for a major YANG version: 2.0.
> regards Balazs
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 5 Aug 2014 00:07:27 +0000

From: Andy Bierman [mailto:[email-masked]]
Sent: Monday, 04 August, 2014 03:46
To: Balázs Lengyel
Cc: [email-masked]
Subject: Re: [netmod] Issue Y36: associate RPCs AND notification with a data node

Hi,

1) scope is inaccurate:
 * Y36 associate a notification with a data node
  This proposal has nothing to do with notifications.
  Where is the support to associate a notification with a data node?
BALAZS: Will be added if interest is indicated by the group.

        list group {
            key "a b ";
            leaf a { type string; }
            leaf b { type int32; }

BALAZS:
You just need to add the <group> keys-of-the-group</group> encapsulation.
     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:yang="urn:ietf:params:xml:ns:yang:1">
        <yang:action>
            <data>
               <group xmlns="http://example.net/server-farm">
                   <a>myKey1</a>
                   <b>23</b>
                   <server>
                       <name>apache-1</name>
                       <reset>
                           <reset-at>2014-07-29T13:42Z</reset-at>
                       </reset>
                   </server>
               </group>
            </data>
        </action>
     </rpc>

 module server-farm {

         list server {
            key name;
            leaf name {
                type string;
            }
            action reset {
                input {
                    leaf reset-at {
                        type yang:date-and-time;
                        mandatory true;
                    }
                }
                output {
                    leaf reset-finished-at {
                     type string;
                      mandatory true;
                    }
                }
            }
        }

        container top {
            list server {
              key name;
               leaf name {
                  type string;
               }
               action reset {
                   input {
                       leaf reset-at {
                          type string;
                      }
                  }
             }
        }

    }

We have /server/reset and /top/server/reset.
How do the server know which 1 is being invoked?
BALAZS:
The encoding for /server/reset does not change. The encoding for /top/server/reset would additionally contain the <top>...</top> encapsulating element. SO the presence or absence of  <top></top> will tell the server which reset to choose.
It's the same logic <edit-config>  uses. For each container or list you add one more level of XML element encapsulation.
/top/server/reset:
     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:yang="urn:ietf:params:xml:ns:yang:1">
        <yang:action>
            <data>
               <top xmlns="http://example.net/server-farm">
                   <server>
                       <name>apache-1</name>
                       <reset>
                           <reset-at>anyString</reset-at>
                       </reset>
                   </server>
               </top>
            </data>
        </action>
     </rpc>

4) Ehat is the purpose of the extra <data> container inserted in the action input
and output?

BALAZS: It is there for data encapsulation similarly as for a reply for <get-config>. Not crucial, but at the time we implemented it, it looked like, the clean and  consistent way to do things.

Andy

On Sun, Aug 3, 2014 at 2:56 PM, Balázs Lengyel <[email-masked]<mailto:[email-masked]>> wrote:
Hello
I attached my proposal for the action statement in YANG. Please comment.
Regards Balazs

   <rule>
     <name>xx</name>

/js

   AZ sees a use case.

--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>

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