RE: Separation of protocol and information model

["Chen, Weijing" <Weijing_Chen@labs.sbc.com>]

> Not at all.  I want a protocol that exposes the operations my
> application needs to perform to load/merge/etc a piece of configuration
> into a device's configuration.  I want to be able to issue operations
> as RPC calls and get results.  I want to have control over how and
> when the configuration is processed.  I want to be able to load a
> delta, test that the syntax and semantics of the delta are valid,
> commit the delta into the running configuration, test that the
> device is operating (reachability, lack of breakage, appearance of
> requested feature), and either rollback the delta if something's
> gone wrong or make the change permanent.
> 
>
It is not a simple file transfer protocol, no it is not.  It is a file
transfer and manipulation protocol.  It got much granular control of file
maniuplation than FTP/TFTP.  It also has some basic transaction behaviour
like stop on error, rollback on error, lock, unlock, commit.  However, I
still can't  picture how a such protocol works seamlessly with a good data
model.  I will look into your URL to do further study.



--

Weijing Chen

> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net]
> Sent: Thursday, September 04, 2003 8:59 AM
> To: Chen, Weijing
> Cc: netconf@ops.ietf.org
> Subject: Re: Separation of protocol and information model
> 
> "Chen, Weijing" writes:
> >By looking at the above pseudo code, I have feeling that what you wants
> is
> >not really a network management protocol, but a XMLized nice file
> transport
> >protocol
> 
> Not at all.  I want a protocol that exposes the operations my
> application needs to perform to load/merge/etc a piece of configuration
> into a device's configuration.  I want to be able to issue operations
> as RPC calls and get results.  I want to have control over how and
> when the configuration is processed.  I want to be able to load a
> delta, test that the syntax and semantics of the delta are valid,
> commit the delta into the running configuration, test that the
> device is operating (reachability, lack of breakage, appearance of
> requested feature), and either rollback the delta if something's
> gone wrong or make the change permanent.
> 
> Transfering the delta is a small piece.  This is not a file transfer
> protocol at all. It's an API to the device's CLI.  Please read the
> Junoscript docs on www.juniper.net/support/junoscript to see what
> I have in mind. It's certainly not FTP.
> 
> Thanks,
>  Phil

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