Martin Bjorklund wrote:
Phil Shafer <phil@juniper.net> wrote:Martin Bjorklund writes:...
But anyway, I just said that I do agree with the "intermediate SW
argument", i.e. using a well-known <action> rpc might make it easier
to write this kind of software.
As an example, suppose you have a set of hosts, each with a set of
services, and a service can be reset. Using a normal rpc, this reset
could be:
<reset-service-in-host>
<host>foo</host>
<service>web</service>
<when>now</when>
</reset-service-in-host>
Using the <action>, with Balazs syntax,
<action>
<callingPoint>/hosts/host[name="foo"]/service[name="foo"]</callingPoint>
<name>reset</name>
<parameters>
<when>now</when>
</parameters>
</action>
My only point is that the latter might be easier for a SW component
like a master agent.
IMO this is an implementation choice. I prefer the former approach because I already have SW components that auto-generate PDU fragments based on the <rpc> element in the existing netconf-prot document. Plus, the less XML layers the better. I also agree with Phil that the <rpc> version is more XSD-friendly. Some people prefer not to couple all the 'action' RPC implementation details together. Others may prefer a common gateway approach. The <reset-service-in-host> RPC method could use internal (implementation specific) mechanisms to convert the XML parameters to different forms. Exposing the complex <action> RPC to managers seems to make things harder on the manager than the <reset-service-in-host> version in your example.
/martin
Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>