RE: Separation of protocol and information model

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

> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: Wednesday, September 03, 2003 2:50 PM
> To: Glenn Waters
> Cc: Chen, Weijing; netconf@ops.ietf.org
> Subject: RE: Separation of protocol and information model
> 
> At 12:26 PM 9/3/2003, Glenn Waters wrote:
> 
> >It has taken a me while to understand but I think the point that Keith
> and Weijing are making is that the list of configs (running, candidate,
> etc.) is configurable and in fact configuration commands are used to
> define the set of configs. Since the list is configurable that makes it a
> part of the data model and hence it is not appropriate as a protocol
> capability.
> >
> >Is that what is trying to be said?
> 
> I don't know if that's what they are saying, but the list of
> configuration database types is not configurable by the user.
> It is defined by the vendor when the product is designed.
> 
> All devices must have a set of current operational configuration
> values (running config).  Some devices require that configuration
> changes are placed in a scratchpad (candidate config) configuration
> and then applied all at once to the running config.  Some devices
> do not overwrite the configuration for the next reboot (startup config)
> automatically, but instead require an explicit action from the user
> to copy the contents of the running config to the startup config.
> 
> It is possible that other operational models exist, and we should
> discuss whether or not netconf should support them.  For example,
> some devices retrieve their startup config from the network
> instead of storing it locally.  Some devices can associate
> different startup configs with different SW images.  There
> are probably more variants not yet supported by the protocol.
> Note that the list of configuration types can be extended
> without rewriting the protocol.
> 
> 
[Chen, Weijing] The difference is not just where the list of configurations
belongs.  It is that how one describes the variation of device
configuration.  How the current WG I-D handles the different operating model
is unclear.  In our I-D, Section 4 gives an example how one can build his
own operating model (not protocol operation) using XML schema.  The
operating model schema does not require the change of protocol operation
schema, especially protocol operation.  I don't know how to accommodate
various operating models without changing the protocol operating schema and
protocol operation in current WG I-D.  If the protocol operation schema
changes, there is no interoperability even in the protocol operation layer.




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