RE: action RPC I-D

["David B Harrington" <dbharrington@comcast.net>]

Hi,

At the IAB Workshop, one of the strong points was that operators want
to be able to "read" the content on the wire. Adding such regex
formatting will make the content much less human-friendly.

I think the action increases the difficulty of access control
specification, and increases the likelihood of non-interoperable
commands.

I prefer to not have the action layer. I don't see adequate benefits
to justify the added complexity. 

dbh

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Monday, October 16, 2006 2:00 PM
> To: Martin Bjorklund
> Cc: phil@juniper.net; balazs.lengyel@ericsson.com; 
> netconf@ops.ietf.org
> Subject: Re: action RPC I-D
> 
> 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"]</cal
> lingPoint>
> >     <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/>
> 



--
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/>