Re: netconf WG charter proposal

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> 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
Andy> or more output parameters? It is understood that some work may
Andy> be done on the device to produce the response, and that the
Andy> response may be delayed (hence the rpc-progress reports).  This
Andy> looks to me like an RPC model, not a generic request/response
Andy> model.

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.

>> Anyway, does this item imply that locking and rollback capabilities
>> are a required feature? If yes, I applaud (and look forward for an
>> xmlconf revision that actually makes this mandatory).

Andy> These features are optional. Not all devices will be capable of
Andy> supporting them.

And this might be a bug that needs to get fixed. Sure, we disagree
and that won't change so let us not try to convince each other.

>>  I do not recall that the operators were loudly asking for BEEP. So
>> why is this initial (and I guess default) transport mapping already
>> determined by the charter?

Andy> I don't recall operators being very specific in this matter.
Andy> The WG will need to discuss the appropriate initial transport
Andy> mapping.  If you are objecting to BEEP, then specify which
Andy> protocol should be used in the initial release.  Should we map
Andy> more than one?  Being first doesn't imply a default.

If indeed the WG will discuss the appropriate initial transport, then
please do not prescribe the solution in the charter. Just say that an
initial default transport will be defined.

Andy> There is a valid reason for the base+extensions model that was
Andy> added to XMLCONF -- we need to be able to support devices from
Andy> lots of vendors, not just one.  It is not realistic to assume
Andy> all vendors will build products that are configured with the
Andy> exact same operational model and exact same capabilities.  The
Andy> XMLCONF draft attempts to provide for market reality using a
Andy> small set of well-constrained extensions, which are based on
Andy> capabilities/device characteristics that are advertised in a
Andy> standard way.

The enns draft goes IMHO too far with this. With minimal wrapping, I
can just ship any proprietary format back and forth without any
additional support to realize network-wide transactions and I can call
myself compliant to the specification. I believe this approach is counter
productive in the long term since it does not help to solve the hard
problems.

/js

-- 
Juergen Schoenwaelder    <http://www.iu-bremen.de/>

--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>