[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: netconf WG charter proposal



Title: RE: netconf WG charter proposal


-----Original Message-----
From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
Sent: Monday, April 07, 2003 9:53 AM
To: abierman@cisco.com
Cc: xmlconf@ops.ietf.org
Subject: Re: netconf WG charter proposal


I agree with Juergen. The proposed request/response method is not
like RPC mechanisms I have seen/used in the past. It is more like a
remote CLI, or programmatic CLI than it is an RPC mechanism. There
is no provision for method signatures, no data types (other than String)
and there is no notion of the remote service or object that the RPC
is being called on. Personally, I think that a standard, existing
RPC mechanism (XML/RPC, SOAP)  would likely be beneficial.

Bryan


>>>>> Andy Bierman writes:

>> Furthermore, I do not understand why the charter requires RPCs. And
>> in fact, JunoScript and xmlconf both seem to be just request/response
>> protocols very similar to SNMP by the way. I fail to see real support
>> for RPC abstractions in the classic sense. I suggest just to drop the
>> text about RPCs - I do not find it convincing or helpful.

Andy> What is the difference between an RPC and a request that carries
Andy> zero or more input parameters, followed by a response with zero or
Andy> more output parameters? It is understood that some work may be
Andy> done on the device to produce the response, and that the response
Andy> may be delayed (hence the rpc-progress reports).  This looks to me
Andy> like an RPC model, not a generic request/response model.

>> Juergen Schoenwaelder writes:

>>In my world model, request-response protocols are a mechanism which you can use to build RPC protocols. But there >>are request-response protocols that are not RPC protocols. In fact, I believe that RPCs in general were invented >>with the notion of procedure or function calls where one can call a remote function/procedure almost like a local >>function/procedure call. This basically means that RPCs have a signature which defines the input and output

>>parameters. Your RPCs just send XML blobs or even non-XML blobs around, which does not really match my
>>understanding of RPCs.