Subject: [netmod] methods and events

From: Andy Bierman <[email-masked]>
Date: Sat, 11 Oct 2008 10:26:33 -0700

Hi,

I am removing my objection to putting rpc-stmt and
notification-stmt within the data-def-stmt, if
it is done carefully and with lots of thought.
I think new constructs should be used instead of
overloading the "plain" versions.

I prefer to view the config database as "just data"
because it matches the "C" world I know.  I am
skeptical that this mechanism alone will be enough
to support OO application development, but I think
we have to try anyway.

  container foo-service {
     presence "Creates an instance of the foo service if present.";

     grouping FooServiceParameters {
       ...
     }

     grouping FooServiceStats {
       ...
     }

     method start {
       input {
         uses FooServiceParameters;
       }
     }

     method stop;

     method restart {
       input {
         uses FooServiceParameters;
       }
     }

     method status {
       output {
         uses FooServiceStats;
       }
     }

     event fooServiceEnabled {
        uses FooServiceStatus;
     }

     // config data (can it be private or read-only?)
     uses FooServiceParameters;

     // monitoring data
     uses FooServiceStats;

  }

The differences between a method and an rpc:

   1) a method has an extra parameter that can select from
      various standard method signatures.
   2) a method has extra automatic parameters (expected in
      the <rpc> PDU), based on the method signature
   3) rpc can only be top-level (as it is now) and method
      can only be a substatement of list-stmt or container-stmt.

The differences between an event and a notification:

   1) an event has extra automatic data generated in
      notification PDUs, based on a standard notification template
   2) notification can only be top-level (as it is now) and method
      can only be a substatement of list-stmt or container-stmt.

A method signature template will be needed, so it can be
automated instead of hard-wired:

   signature simple-rpc {
     leaf callingPoint {
       type instance-identifier;
     }
   }

Comments?

Andy

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

---

From: Andy Bierman <[email-masked]>
Date: Sat, 11 Oct 2008 11:23:57 -0700

> to support OO application development, but I think

In case it isn't obvious what else data-def-stmt imples here:

  grouping FooService {
    container foo-service { ... }
  }

  container interfaces {
    list interface {
      key name;
      ...

      uses FooService { // refine as needed  };
    }
  }

Andy

>   2) notification can only be top-level (as it is now) and method
                                                    event     ^^^^^^^

---

From: Andy Bierman <[email-masked]>
Date: Sat, 11 Oct 2008 12:30:02 -0700

>....

In case this part isn't obvious:

module yang {

   signature from-to-rpc {
     leaf from {
     leaf to {

module X {

   import yang { prefix yang; }

   import acme { prefix acme; }

   list Y {
    ...
       method copy {
          method-type yang:from-to-rpc;
          // add extra copy-specific details
       }

       method move {
          method-type yang:from-to-rpc;
          // add extra move-specific details
       }

       method foo {
         method-type acme:my-rpc-signature;
         // add foo-specific details
       }
    }
}

I think this helps address the very valid concern that Phil raised
at the interim about one simplistic template not being
being sufficient.

Or am I totally missing the point, and there is no need
for method signatures (or templates) because all you
really want is the 'self' parameter added to
the rpc automatically?  (Balazs?)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 13 Oct 2008 10:27:31 +0200 (CEST)

> the rpc automatically?  (Balazs?)

In our proprietary DML, we support these 'methods', but we call them
'actions'.  We do not have templates etc, just the equivalent of a
callingPoint.  In order to support locally scoped action names
(i.e. the same name 'reset' can exist in multiple locations, with
different parameters), we use a generic action rpc:

   <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <action xmlns="http://tail-f.com/ns/netconf/action">
       <interfaces xmlns="http://example.com/interfaces/1.0">
         <interface>
           <name>eth0</name>
           <reset/>
         </interface>
       </interfaces>
     </action>
    <rpc>

I.e.instead of one 'callingPoint' parameter, we use the same instance
identification mechanism as edit-config.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 13 Oct 2008 10:59:15 +0200

Hello Andy,
Thanks for the proposals.
For me one automatic parameter (self) is important.

As Phil stated, there might be cases where multiple parameters are needed, but IMO there is no 
common pattern in the other parameters. Manipulating one managed item (needing one instance 
identifier) is a common task. Tasks that need multiple instance identifiers like copying 
objects or replacing them are much less frequent, and parameters beyond "self" are typically 
different in different rpcs/actions.

Although I do not see the need for this, if we agree that is a good idea, I have no objection 
for having different names for top level rpcs and nested methods as you propose. Comments?

regards 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: Mon, 13 Oct 2008 07:16:36 -0700

Balazs Lengyel wrote:
> As Phil stated, there might be cases where multiple parameters are 
> needed, but IMO there is no common pattern in the other parameters. 
> Manipulating one managed item (needing one instance identifier) is a 
> common task. Tasks that need multiple instance identifiers like copying 
> objects or replacing them are much less frequent, and parameters beyond 
> "self" are typically different in different rpcs/actions.
> 
> Although I do not see the need for this, if we agree that is a good 
> idea, I have no objection for having different names for top level rpcs 
> and nested methods as you propose. Comments?
> 

I think we should not use the signature template.
The difference is the 'self' parameter.
I also prefer the name 'action' to 'method' because
it carries less baggage.

An implementation will always need to check the ancestors
to make sure an 'action' is not defined within an 'rpc',
no matter what it is called.

Doesn't the same callingPoint idea apply to notifications
as well as actions?

Does it ever make sense to nest an action within:
   - rpc-foo/input
   - rpc-foo/output
   - notif-foo/

Does it ever make sense to nest a notification within:
   - rpc-foo/input
   - rpc-foo/output
   - notif-foo/

IMO, NO to all of the above.  Actions and events can
only be within the database objects, and not associated
with <rpc> or <rpc-reply> PDUs at all.

Andy

---

From: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" <[email-masked]>
Date: Thu, 16 Oct 2008 18:42:03 +0300

Hi,

first, I think it is a good idea to put methods (or "actions") inside
(local to) data nodes as it makes much more obvious to which part of the
tree
the method is applied.

In my opinion, having the method target ("self" parameter) as implicit
parameter
and being able to add additional parameters as needed in the context at
hand is enough.
More complex mechanisms like signatures might turn out to be hard to
understand
and use correctly.

What is not clear to me is 
 - how is the output / result of an method invocation specified?
 - can methods statements be augmented?
   Would it be allowed to add additional, 
   optional parameters? 
 - can new methods itself be augmented?
   So would it be allowed to augment a method to lists and containers?

Best wishes,
Bernd

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Oct 2008 09:56:16 -0700

> (local to) data nodes as it makes much more obvious to which part of the

I realized by the time I sent the original mail
that the 'self' parameter is all that is added.

>  - how is the output / result of an method invocation specified?

TBD: the tail-f 'action' construct seems a good place to start.

>  - can methods statements be augmented?

good question.
I hope not, and I strongly oppose
making 'action' one of the data-def-stmt options.

Andy