Subject: [netmod] RPCs in Lists

From: Balazs Lengyel <[email-masked]>
Date: Fri, 08 Aug 2008 14:24:06 +0200

Hello,
In Dublin I presented a proposal to allow RPC definitions in lists. I believe this is an 
important and needed feature for a big part of the NETCONF/NETMOD community and something that 
will not disturb others who don't want to use it. My presentation can be found at:
http://www3.ietf.org/proceedings/08jul/slides/netmod-4.ppt

Due to the shortage of time there was no debate about the proposal. But now please voice your 
opinion
- is this a good idea (of course it is)?
- which encoding would you prefer (slides 7 and 8)?
- is this needed for notifications as well?
- if you don't need it can you at least live with it, if not why not?

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 08 Aug 2008 09:01:04 -0700

Balazs Lengyel wrote:
> Hello,
> In Dublin I presented a proposal to allow RPC definitions in lists. I 
> believe this is an important and needed feature for a big part of the 
> NETCONF/NETMOD community and something that will not disturb others who 
> don't want to use it. My presentation can be found at:
> Due to the shortage of time there was no debate about the proposal. But 
> now please voice your opinion

You brought up this 'exec' and 'callingPoint' idea before.

I'm unclear on what problem needs to be solved here.
"Need to make YANG seem more OO-like" is not an actual
NETCONF problem.

The input parameters to an RPC method can handle any
data that needs to be conveyed.  I don't see how
placing an RPC (or notification) inside the database
helps convey any info that could not just be passed
as a parameter, if this 'callingPoint' is really important.

Right now we have config true/false to determine if any
nested data can be written.  This would no longer be good enough
because an RPC method is not config data.

Would the RPCs and notifications show up in a <get> or <get-config>
like normal data?  Does it make any sense whatsoever
to reuse these constructs within a grouping? Do they
affect NV-storage at all? (no)

I prefer to keep the configuration database separate from
the other NETCONF protocol support.

I prefer to use a new conformance statement to declare what
must be implemented, with the RPC or notification tagged
as part of a 'feature'.  This makes it clear which
config data is associated with which RPC or notification,
regardless of module location.

> Balazs

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 08 Aug 2008 13:58:15 -0400

>- is this a good idea (of course it is)?

I dislike this idea for two big reasons:
(a) it only handles trivial cases
(b) it defines "similar procedures" using completely distinct RPCs

Details: (a): This technique only works for _one_ argument.  If I
want to shutdown an interface, great.  But if I want to give a
second argument that's the name of a user, I'm stuck.  I only get
one "calling point", which may work for simple cases, but add
something outside your containment tree and it stops working.

(b) You've defined a shutdown RPC, but you need to define it again
for every object that you want it to work for.  You end up with
fifteen "shutdown" functions that _might_ looks similar, but that's
not enough.  Your sales point was "Often the same management action
is relevant for different managed entities" but you've ended up
with <n> different mechanisms for doing the same thing.  Your
commonality is lost.

>- which encoding would you prefer (slides 7 and 8)?

Consider your encoding:

<rpc message-id="101">
     <shutDown 
       callingPoint =/mib-2/interface[ifId=3]>
           <mode>immediate</name>
     </shutDown>
</rpc>

This could easily be:

<rpc message-id="101">
     <shutDown>
       <callingPoint>/mib-2/interface[ifId=3]</callingPoint>
       <mode>immediate</name>
     </shutDown>
</rpc>

(which avoids annoying attribute namespace issues)

But this suddenly looks just like a normal RPC.  If you had:

    rpc shutdown {
        choice target {
            // placeholder
        }
        leaf mode {
            ...
        }
    }

then your module can augment this RPC as needed.  You can define
this augmentation in your module using normal YANG-fu:

    augment /rpc/shutdown/target {
        leaf interface {
            type instance-identifier { ... }
        }
    }

And you end up with the XML encoding of:

    <rpc>
        <shutdown>
            <my:interface>/what/ever</my:interface>
            <mode>sure</mode>
        </shutdown>
    </rpc>

If you want to define this content along side the definition for
the "interface" node, we can relax the rule about "no absolute
argument paths except for top level".

Using the technique of augmenting choices provides a set of consistent
RPCs (only one shutdown, not one per "action").  It scales to include
any number of arguments.  The encoding is simpler and more consistent.

Thanks,
 Phil